Re: [dnsext] draft-bellis-dnsext-dnsproxy-00

[[e-mail]]

> |   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 :)

Ray


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>