On 03/31/2018 07:34 PM, Mukund Sivaraman wrote:
> All the clarifications RFCs such as NCACHE 2308, 2181, wildcards 4592,
> etc. I'd also expect TSIG, AXFR, IXFR and UPDATE to get treatment in
> "core" DNS in the same grouping as master files.
>
Just offhand, IPv6 stuff should be merged and cons
On 03/26/2018 02:05 PM, Richard Gibson wrote:
> TSIGs cover "A whole and complete DNS message in wire format, before the
> TSIG RR has been added to the additional data section and before the DNS
> Message Header's ARCOUNT field has been incremented to contain the TSIG
> RR" (RFC 2845 section 3.4
So, a couple of thoughts as a newcomer to the list, and someone who's
wading through the virtual forest that is the DNS RFC specifications.
Breaking into the DNS world is to put it ... difficult. I thought myself
relatively knowledgeable on the subject up until about two weeks ago
when I subscribe
On 03/26/2018 10:57 AM, Evan Hunt wrote:
>>> 2. responders SHOULD NOT compress rdata when rendering obsolete/deprecated
>>>type records to wire format.
>>>
>>
>> The problem here is that right up until the point the camel declares
>> these RRtypes dead, the specification specifically allows t
On 03/26/2018 08:45 AM, Evan Hunt wrote:
> On Mon, Mar 26, 2018 at 02:09:14PM +0200, Ondřej Surý wrote:
>> That’s one of the goals of the document - saying: “it’s ok to not
>> implement those RR Types, and it’s ok to break if you receive them"
>
> We need to state clearly what is meant by "ok to
Paul: Thanks for the explanation, it clears up a fair bit for me.
Replies inline.
On 03/20/2018 09:48 AM, Paul Wouters wrote:
> On Tue, 20 Mar 2018, Michael Casadevall wrote:
>
>> Without the RRtypes logged, I'm not seeing how you're supposed to be
>> able to audit t
On 03/20/2018 07:44 AM, Paul Wouters wrote:
> The goal of the document is to make such malicious changes visible.
>
> If the parent needs to replace NS/DS records, these are easily
> auditable identically to Certificate Transparency (rfc 6962bis)
> We only need to look (log) the DS/DNSKEY and we