Re: [dnsext] draft-bellis-dnsext-dnsproxy-00
<Ray.Bellis <at> nominet.org.uk>
2008-11-03 21:47:17 GMT
> | Also, whilst the EDNS0 specification allows for a buffer size of up
> | to 65536 octets, most common DNS server implementations do not
> | support a buffer size above 4096 octets.
> 65536? Shouldn't it be 65535?
Indeed, yes! Well done for catching the deliberate mistake
> | 6.1. Forgery Resilience
> It is imperative that if the the response is cached, the packet is not
> passed through unchanged, query ID and source ports MUST be
> randomized. This requires some work for TSIG queries (as described in
> RFC 2845).
I'm no expert on TSIG and included what little there is at Olafur's
behest. I'll probably need to defer that one to him.
> | o invalid compression pointers (i.e. those that run forward of the
> | current packet offset, or which don't point at the start of
> | another label).
> Are these pointers really invalid?
Forward pointing ones certainly are:
RFC1035, section 4.1.4: "In this scheme, an entire domain name or a list
of labels at the end of a domain name is replaced with a pointer to a
prior occurance of the same name"
A pointer that links to somewhere other than the start of another label
isn't (AFAIK) expressly prohibited. However I can't imagine why any
"real" upstream resolver would ever produce one for legitimate reasons. I
am aware of certain research of the use of this technique to reduce the
size of packets needed for cache-poisoning attacks, since smaller packets
implies greater attack efficiency.
> Compression loops and compression references in places where actually
> forbidden by the RFCs would be relevant examples, IMHO.
Compression loops is a good one. Can you provide an example or reference
to an illegal compression place?
> This raises the question of trailing garbage in the UDP packet. For
> interoperability reasons, I think this has to be accepted.
Interesting... in my earlier research we were more concerned with missing
data, and never noticed extraneous data. Is this a common occurrence?
> I like the draft. But I have to agree with Bert that it's a bit like
> preaching to the choir.
Yes, but the intent is that this draft will help make the choir larger :)
to unsubscribe send a message to namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.