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

From: [email-masked]
Date: Mon, 3 Nov 2008 15:51:49 +0000

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

---

From: bert hubert <[email-masked]>
Date: Mon, 3 Nov 2008 18:46:13 +0100

> 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

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: [email-masked]
Date: Mon, 3 Nov 2008 17:53:30 +0000

> actually troublesome in real life.

Thanks.
 
> pointy) to hit vendors over the head with, and perhaps get them to do 
the

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.

> So all in all - I find many good things in this draft, but I worry if it

I guess we'll just have to wait and see :)

cheers,

Ray

---

From: bert hubert <[email-masked]>
Date: Mon, 3 Nov 2008 20:00:14 +0100

> engineers who have developed these proxies are unaware of the wide range 

You use the term 'engineer' in the very widest sense of the word. The people
'assembling' these domestic devices will generally only code until they can
browse the web over it using their PC, and then slap a box around the
product and ship it.

> done that, and only that.

They haven't even done that, in my experience.

> necessary specifications can be found.

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.

	Bert

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 03 Nov 2008 14:22:33 -0500

<no-hat>

>pointy) to hit vendors over the head with, and perhaps get them to do the

My biggest hope for this one is that major ISP's will use this document as
an test/purchase guide for equipment. If that happens suddenly the
lazy vendors will fix their act.

>So all in all - I find many good things in this draft, but I worry if it

This is an attempt to in a small way start getting the effect that some
of us hoped that DNS-Profile document would do.
This is attempt #2, beat the worst offenders into submission.
(Attempt #1 was beat all into compliance)

         Olafur (no hat)

---

From: Florian Weimer <[email-masked]>
Date: Mon, 03 Nov 2008 20:27:22 +0100

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

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 3 Nov 2008 11:30:38 -0800

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 3 Nov 2008 11:53:59 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nicholas Weaver
> Sent: Monday, November 03, 2008 11:31 AM
> To: bert hubert
> Cc: Nicholas Weaver; [email-masked]; 
> [email-masked]
> Subject: Re: [dnsext] draft-bellis-dnsext-dnsproxy-00
> 
> 
> > That would be good - this also argues for not adding heaps 
> of other  
> > stuff to
> 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

---

From: [email-masked]
Date: Mon, 3 Nov 2008 21:47:17 +0000

> 65536?  Shouldn't it be 65535?

Indeed, yes!  Well done for catching the deliberate mistake ;-)

> randomized.  This requires some work for TSIG queries (as described in

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.

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

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

> 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

Yes, but the intent is that this draft will help make the choir larger :)

Ray

---

From: Wouter Wijngaards <[email-masked]>
Date: Tue, 04 Nov 2008 09:23:25 +0100

> Forward pointing ones certainly are:

ok

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

> data, and never noticed extraneous data.  Is this a common occurrence?

Yes.

Best regards,
   Wouter

---

From: [email-masked]
Date: Tue, 4 Nov 2008 09:33:42 +0000

[re non-label pointers]
> 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?

> 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]
> > data, and never noticed extraneous data.  Is this a common occurrence?

Has anyone ever looked to find out why this happens?

Ray

---

From: Edward Lewis <[email-masked]>
Date: Tue, 4 Nov 2008 11:50:52 +0200

>Has anyone ever looked to find out why this happens?

I know of one case - back when there was the hard limit of 512, one 
implementation would truncate at that and not at the end of the last 
complete RR.  Why?  All conjecture, but it is faster than clipping 
back to the last useable byte of data.

One thing to keep in mind.  When considering the receipt of data from 
the network, don't engineer to what makes sense, engineer to what 
could possibly come in.  As in the robustness principle "liberal in 
what you accept."  That doesn't mean you have to accept and digest 
what's come in, but admit that FORMERRs will happen on the remote end 
or at intermediate boxes and write code that won't barf on it.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 04 Nov 2008 21:14:21 +0100

> prior occurance of the same name"

I'm not sure if such strict reading is advisable.  From that quote,
it's not clear that compressing "ns1.example.com" as "ns1", followed
by a reference to the "example.com" in "www.example.com" is permitted.

> to an illegal compression place?

Signer's name in an RRSIG, for instance.

> data, and never noticed extraneous data.  Is this a common occurrence?

I see it quite often, but I have no idea how much of that is accepted
by initiators.