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

> I've just submitted:
> 
>   http://tools.ietf.org/html/draft-bellis-dnsext-dnsproxy-00
> 
> "This document provides guidelines for the implementation of DNS 
proxies, 
> as found in broadband routers and other similar network devices."

Does anyone have any feedback on this draft?

thanks,

Ray

--
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.
archive: <http://ops.ietf.org/lists/namedroppers/>

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

On Mon, Nov 03, 2008 at 03:51:49PM +0000, Ray.Bellis <at> nominet.org.uk wrote:
> >   http://tools.ietf.org/html/draft-bellis-dnsext-dnsproxy-00
> > 
> > "This document provides guidelines for the implementation of DNS 
> proxies, 
> > as found in broadband routers and other similar network devices."
> 
> Does anyone have any feedback on this draft?

It looks like a fine document to me, and many of the points raised are
actually troublesome in real life.

What I worry about is that this draft basically says "Please adhere to the
DNS RFCs", where it is abundantly clear that proxies so far have not done
so.

It is questionable if people who disregarded the previous 20 RFCs will heed
this one.

Draft-bellis-dnsext-dnsproxy might be something nice and pointed (if not,
pointy) to hit vendors over the head with, and perhaps get them to do the
right thing.

(This was the aim of draft-forgery-resilience, but it did not work in time)

So all in all - I find many good things in this draft, but I worry if it
will achieve any effect.

	Bert

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

> It looks like a fine document to me, and many of the points raised are
> actually troublesome in real life.

Thanks.

> What I worry about is that this draft basically says "Please adhere to 
the
> DNS RFCs", where it is abundantly clear that proxies so far have not 
done
> so.
>
> It is questionable if people who disregarded the previous 20 RFCs will 
heed
> this one.
> 
> Draft-bellis-dnsext-dnsproxy might be something nice and pointed (if 
not,
> pointy) to hit vendors over the head with, and perhaps get them to do 
the
> right thing.

All of that is true.  The point is, I think, that many of the software 
engineers who have developed these proxies are unaware of the wide range 
of RFCs that need to be implemented to be fully compatible with modern 
DNS.  It's apparent to me, at least, that they've looked up RFC1035, and 
done that, and only that.

My intent is therefore to provide that single "pointer RFC" which provides 
concrete examples of known failings and clear references to where the 
necessary specifications can be found.

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

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

* Ray Bellis:

>> I've just submitted:
>> 
>>   http://tools.ietf.org/html/draft-bellis-dnsext-dnsproxy-00
>> 
>> "This document provides guidelines for the implementation of DNS 
> proxies, 
>> as found in broadband routers and other similar network devices."
>
> Does anyone have any feedback on this draft?

|   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?

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

|   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?

Compression loops and compression references in places where actually
forbidden by the RFCs would be relevant examples, IMHO.

|   o  incorrect counts for the Question, Answer, Authority and
|      Additional Sections (although care should be taken where
|      truncation is a possibility).

This raises the question of trailing garbage in the UDP packet.  For
interoperability reasons, I think this has to be accepted.

I like the draft.  But I have to agree with Bert that it's a bit like
preaching to the choir.

--
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.
archive: <http://ops.ietf.org/lists/namedroppers/>

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

On Nov 3, 2008, at 11:00 AM, bert hubert wrote:
>
> That would be good - this also argues for not adding heaps of other  
> stuff to
> the RFC - I think everybody would like to have his pet DNS difficulty
> included, but overall that would not help achieve greater compliance.

I think the most important behavior is "Get Outta the Way!"

Namely, any such device MUST not block direct access to an arbitrary  
remote DNS server from an end-host, with the packet payload unchanged,  
and SHOULD not change the UDP SRC port selected by the end-host.

There will always be cases where the policy on any in-path device is  
incorrect.  Therefore the most important policy that a NAT or similar  
device should have with regards to DNS traffic is the ability to  
bypass any proxying or other such manipulation.

This is, IMO, absolutely essential, because everything else can be  
worked around as long as the stub resolver can access whatever  
external resources it deems necessary.

--
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.
archive: <http://ops.ietf.org/lists/namedroppers/>

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

> -----Original Message-----
> From: owner-namedroppers <at> ops.ietf.org 
> [mailto:owner-namedroppers <at> ops.ietf.org] On Behalf Of Nicholas Weaver
> Sent: Monday, November 03, 2008 11:31 AM
> To: bert hubert
> Cc: Nicholas Weaver; Ray.Bellis <at> nominet.org.uk; 
> namedroppers <at> ops.ietf.org
> Subject: Re: [dnsext] draft-bellis-dnsext-dnsproxy-00
> 
> 
> On Nov 3, 2008, at 11:00 AM, bert hubert wrote:
> >
> > That would be good - this also argues for not adding heaps 
> of other  
> > stuff to
> > the RFC - I think everybody would like to have his pet DNS 
> difficulty
> > included, but overall that would not help achieve greater 
> compliance.
> 
> I think the most important behavior is "Get Outta the Way!"
> 
> Namely, any such device MUST not block direct access to an arbitrary  
> remote DNS server from an end-host, with the packet payload 
> unchanged, and SHOULD not change the UDP SRC port selected by 
> the end-host.

Preserving the UDP source port is not possible if there are two hosts 
behind a NAT and those two hosts use the same UDP source port.  

-d

> There will always be cases where the policy on any in-path device is  
> incorrect.  Therefore the most important policy that a NAT or 
> similar  
> device should have with regards to DNS traffic is the ability to  
> bypass any proxying or other such manipulation.
> 
> This is, IMO, absolutely essential, because everything else can be  
> worked around as long as the stub resolver can access whatever  
> external resources it deems necessary.
> 
> 
> --
> 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.
> archive: <http://ops.ietf.org/lists/namedroppers/>

--
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.
archive: <http://ops.ietf.org/lists/namedroppers/>

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

> |   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 namedroppers-request <at> ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

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

Ray.Bellis <at> nominet.org.uk wrote:
> Forward pointing ones certainly are:

ok

> 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.

Well, it could certainly be useful for compression of DNSSEC packets. I
have not tried to do so for interoperability reasons.  But, for DNSSEC
packets the RRSIG rdata cannot be compressed, but if put in the packet
first, it can be used to compress *to*.

Could you refrain from making this impossible? The draft is about stubs
anyway, just leave out 'at the start of another label'.

I would also leave out the backpointing requirement.  I would rather not
have my firewall check to make sure compression pointers point back.

>> 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?

Yes.

Best regards,
   Wouter

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

[re non-label pointers]
> Well, it could certainly be useful for compression of DNSSEC packets. I
> have not tried to do so for interoperability reasons.  But, for DNSSEC
> packets the RRSIG rdata cannot be compressed, but if put in the packet
> first, it can be used to compress *to*.

It could, but what's the likelyhood that the wire-format RRSIG data would 
look remotely like a legal label?

> Could you refrain from making this impossible? The draft is about stubs
> anyway, just leave out 'at the start of another label'.
>
> I would also leave out the backpointing requirement.  I would rather not
> have my firewall check to make sure compression pointers point back.

Please note that this section of the draft talks about things that MAY be 
considered acceptable for a DPI firewall to block.  The main thrust of the 
draft is that unless they've got a _really_ good reason they shouldn't 
block the packets based on their content at all.

[re: trailing garbage]
> > Interesting...  in my earlier research we were more concerned with 
missing 
> > data, and never noticed extraneous data.  Is this a common occurrence?
> 
> Yes.

Has anyone ever looked to find out why this happens?

Ray

--
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.
archive: <http://ops.ietf.org/lists/namedroppers/>