Subject: [dnsext] How well supported are unknown RRs in modern resolvers?

From: Doug Barton <[email-masked]>
Date: Tue, 08 Mar 2011 13:31:10 -0800

The point Nicholas made about moving the CLONE logic to the stub is 
something I'm interested in pursuing, but my understanding is that "a 
lot" of resolving name servers still have problems dealing with RR types 
they don't understand. Is this still true?

Imagine the following scenario:

1. stub requests clone1.example.org A
2. Old resolving name server (RNS) which doesn't understand the CLONE RR 
does it's thing, and gets back the A record, plus "clone1.example.org 
CLONE preferred.example.org" in the ANSWER section.

Does the RNS pass the unknown RR back to the stub? And sorry for my 
ignorance, but are there references to this that I can dig into?

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 8 Mar 2011 13:36:10 -0800

On Mar 8, 2011, at 1:31 PM, Doug Barton wrote:

> The point Nicholas made about moving the CLONE logic to the stub is something I'm interested in pursuing, but my understanding is that "a lot" of resolving name servers still have problems dealing with RR types they don't understand. Is this still true?
> 
> 2. Old resolving name server (RNS) which doesn't understand the CLONE RR does it's thing, and gets back the A record, plus "clone1.example.org CLONE preferred.example.org" in the ANSWER section.
> 
> Does the RNS pass the unknown RR back to the stub? And sorry for my ignorance, but are there references to this that I can dig into?

I do NOT know about:

request clone.examlple.org A
return clone1.example.org CLONE preferred.example.org.

I DO know that

request clone.examlple.org CLONE
return clone1.example.org CLONE preferred.example.org.

Actually does work, well mostly.  

Some clients are behind seriously broken resolvers (usually NATs) that basically barf on anything thats not an A record.  

But if the client can get a TXT record, they can probably get an unknown record.  (only ~1% can't do TXT XOR UNKNOWN, its almost always you can do both or you can do neither, and packet loss can inflate that value).  

And most of THOSE clients can just bypass the borken recursive resolver and do a direct fetch to the network.

---

From: Alex Bligh <[email-masked]>
Date: Tue, 08 Mar 2011 21:41:06 +0000

> they don't understand. Is this still true?

I would expand your worry-space from resolvers to include middleboxen also.

Nick should have / could collect some good data on this. I think this is
going to push us into EDNS if only for signalling reasons. Ray Bellis's
report suggests that serious SOHO CPE problems will arise if the packets
get larger than 512 bytes, but I don't think he explicitly tested unknown
RRs.

-- 
Alex Bligh

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 8 Mar 2011 13:57:47 -0800

> get larger than 512 bytes, but I don't think he explicitly tested unknown

We probe the NAT specifically, and its bad but not as bad as you think:

OFTEN you can bypass the NAT (we check direct over the wire as well).

And if you can get TXT, you can usually get unknown RRs.  (Its either 'get both or get neither', which means 'shove data into a TXT record' is a bad idea: it doesn't help)

We also test EDNS and large responses over the wire (but not all the way to the client, need to add that in).  The 512B limit is less terrifying, fragmentation is a bigger problem really.

(we have a paper in the polish stage, we'll post it here when its done).

We don't test unknown EDNS0 options however.

---

From: Doug Barton <[email-masked]>
Date: Tue, 08 Mar 2011 14:21:11 -0800

> get larger than 512 bytes, but I don't think he explicitly tested unknown

Yeah, "middleboxes are a hard problem" is one of the reasons that I 
heavily focused on the resolver for the DNSSEC part of the solution for 
CLONE, and (admittedly) ignored the stub part of the equation. OTOH, if 
we're going to get DNSSEC validation pushed down into the stub the 
middlebox problem really has to be solved.

So what are the chances that we're going to be able to reliably deal 
with stubs passing EDNS _options_ (I'm not talking about just the size 
of the packet, I'm talking about actually having the stub say "I'd like 
EDNS option foo please").

Doug

--