Subject: [dnsext] Glue Caching Misbehaviours

From: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 25 Jun 2009 12:58:29 +0100

Seems a bit pointless rewriting my problem statement and the  
followups, so here's the IETF general discussion:
http://www.mail-archive.com/[email-masked]/msg42037.html

It affects all implementations to date because everybody makes the  
same mistake, that of imagining that glue is usable as persistent,  
cachable answers.

Please discuss. :-)

Cheers,
Sabahattin

--
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: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 25 Jun 2009 13:55:22 +0100

On 25 Jun 2009, at 13:34, Nicholas Weaver wrote:
> On Jun 25, 2009, at 4:58 AM, Sabahattin Gucukoglu wrote:
> This is not necessarily the case for all resolvers.  EG, unbound  
> does not, and the ones used by Comcast do not, for example.

I imagine less common ones have a good chance of doing the right  
thing, I haven't yet studied unbound though.  All of the ones I tested  
certainly do exactly the same caching.

> This is actually something I specifically check for in Netalyzr ( http://netalyzr.icsi.berkeley.edu/ 
>  ), is how DNS resolvers handle glue records, including nameserver  
> glue records.
>
> I regret that Java is inaccessible to me.

> Bind, for example, will only accept and return such interior glue  
> records for the nameserver addresses only, but not an arbitrary  
> ADDITIONAL record.

Good for security.  But the problem of what happens when the  
nameserver whose address is being cached has reasons for having  
shorter TTLs than parent supplies, or of what happens when a  
changeover of delegation occurs in time for parent data to be cached  
but not for destructive changes to the original nameserver (as often  
happens when you stop using a registrar's nameservers).

All of this sort of nonsense goes away when we stop making assumptions  
about additional data from parent zones, as we should from the start.

Cheers,
Sabahattin

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 25 Jun 2009 11:02:31 -0400

On Thu, Jun 25, 2009 at 12:58:29PM +0100, Sabahattin Gucukoglu wrote:
> Seems a bit pointless rewriting my problem statement and the followups, 
> so here's the IETF general discussion:

[…]

> Please discuss. :-)

Well, before we start discussing, you could read
http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-01.txt
and see whether you think that draft needs to be adopted by the WG, or
whether that material is at least a topic that the WG needs to
undertake.  I will point out that saying, "You should do this work,"
will be less warmly received than, "We should do this work, and I am
willing to help."

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 26 Jun 2009 09:17:37 +0900

> about additional data from parent zones, as we should from the start.

A difference between glue and other additonal data is that, unlike
other additional data, which can be queried separately, glue is
necessary for further queries beyond a refferal.

Glue in a refferal answer to a query may be cached, as long as
the cache is used only for glue of a cached refferal answer to
a query identical to the original query.

Or, the entire refferal should not be cached.

Half hearted caching of NS without glue will make the glued NS
unusable.

							Masataka Ohta

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 29 Jun 2009 15:36:23 -0700

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

At Thu, 25 Jun 2009 12:58:29 +0100,

> http://www.mail-archive.com/[email-masked]/msg42037.html

: The problem is this: the authoritative servers for a domain can
: easily never be consulted for DNS data if the resource being looked up
: happens to be available at the parent zone. That is,
: bigbox.example.net's address and the RR's TTL can never be as
: specified by the zone master unless he or she has control over the
: parent zone's delegation to example.net if bigbox.example.net happens
: to be serving for example.net. (Registries give you address control,
: of course, but often they fix on large TTLs.) 

Can you be more specific?  That is, could you provide an existent name
that causes the problem you stated, rather than the imaginary
"bigbox.example.net"?  Please also be more specific about "if the
resource being looked up happens to be available at the parent zone".
Do you mean, for example, something like this?

- A recursive server tries to resolve AAAA for "bigbox.example.net",
  and sends a query to a .net server.
- A .net server returns a referral like this:
  example.net. NS bigbox.example.net. (in the authority section)
  bigbox.example.net. AAAA 2001:db8::1234 (in the additional section)
- The recursive server simply caches the AAAA RR in the additional
  section, and returns that record to the client without following the
  delegation further.
(I know the answer is no, btw, because BIND9 doesn't behave this way)

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

---

From: Florian Weimer <[email-masked]>
Date: Tue, 30 Jun 2009 15:17:41 +0000

* JINMEI Tatuya / 神明達哉:

> "bigbox.example.net"?

Try NS1.MSFT.NET.

> (I know the answer is no, btw, because BIND9 doesn't behave this way)

Eh, BIND 9.5 considers some non-authorative answers as authoritative,
like the one from Verisign's servers for NS1.MSFT.NET.  Last time I
looked at the code, there was some logic to pull an AA bit out of thin
air.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Florian Weimer <[email-masked]>
Date: Tue, 30 Jun 2009 15:21:20 +0000

> a query identical to the original query.

And all downstream resolvers also follow this rule and don't use the
data in any other way.  Not returning it to clients at all (but using
it to locate name servers in the subtree given by the referral) might
be more advisable.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 30 Jun 2009 09:23:55 -0700

> looked at the code, there was some logic to pull an AA bit out of thin

You can test for yourself if you are curious.  The only authority  
for .netalyzr.icsi.berkeley.edu is roland.icir.org.  (Yes, its only  
one nameserver.  But if Roland is down, our front end is down and  
netalyzr is down...)

But it does return alternate ones in the additional/auth field  
depending on query.

One such query: glue_ns_internal.{garbage}. 
{node}.netalyzr.icsi.berkeley.edu returns the address of the node and  
also returns the node's IP as an authoritative nameserver with the  
name return_false.internal.{garbage}.{node}...

However, return_false.{anything}.netalyzr... returns the "false  
IP" (192.150.186.14.  The weird choice of addresses is to allow the  
testing to work within the Java same origin policy: unless the user  
trusts the address, Java returns either the address of the server or a  
security exception when a name is looked up, giving us a boolean test).

Bind's particular behavior seems to be "internal": If the A record is  
anywhere within the hieriarchy.

So a query for www.microsoft.com would have a .com authority return  
the glue records for ns{1-5}.msft.net, which bind will use but will  
not return the A records in response to queries to ns{1-5}.msft.net....

However, a query for www.msft.net will have .net return the glue  
records for ns{1-5}.msft.net, which bind WILL return for subsequent  
direct A record queries for those names, with the TTLs as provided by  
the .net authority, NOT what .msft.net's authorities provide.

The nameserver behavior itself:
; <<>> DiG 9.5.1-P1-RedHat-9.5.1-1.P1.fc10 <<>> +norecurse  
glue_ns_internal.n1.netalyzr.icsi.berkeley.edu @roland.icir.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35428
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;glue_ns_internal.n1.netalyzr.icsi.berkeley.edu.        IN A

;; ANSWER SECTION:
glue_ns_internal.n1.netalyzr.icsi.berkeley.edu. 100 IN A 67.202.37.63

;; AUTHORITY SECTION:
n1.netalyzr.icsi.berkeley.edu. 100 IN   NS      roland.icir.org.
n1.netalyzr.icsi.berkeley.edu. 100 IN   NS       
return_false.internal.n1.netalyzr.icsi.berkeley.edu.

;; ADDITIONAL SECTION:
roland.icir.org.        100     IN      A       192.150.187.31
return_false.internal.n1.netalyzr.icsi.berkeley.edu. 100 IN A  
67.202.37.63

; <<>> DiG 9.5.1-P1-RedHat-9.5.1-1.P1.fc10 <<>> +norecurse  
return_false.internal.n1.netalyzr.icsi.berkeley.edu @roland.icir.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18084
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;return_false.internal.n1.netalyzr.icsi.berkeley.edu. IN        A

;; ANSWER SECTION:
return_false.internal.n1.netalyzr.icsi.berkeley.edu. 1 IN A  
192.150.186.14

;; AUTHORITY SECTION:
internal.n1.netalyzr.icsi.berkeley.edu. 100 IN NS roland.icir.org.

;; ADDITIONAL SECTION:
roland.icir.org.        100     IN      A       192.150.187.31

But if you run through a Bind instance rather than direct to the  
authority.  (I forget what version we use here at ICSI, but the  
recursive resolver is some flavor of Bind):
; <<>> DiG 9.5.1-P1-RedHat-9.5.1-1.P1.fc10 <<>>  
glue_ns_internal.n1.netalyzr.icsi.berkeley.edu @192.150.186.8
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35160
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;glue_ns_internal.n1.netalyzr.icsi.berkeley.edu.        IN A

;; ANSWER SECTION:
glue_ns_internal.n1.netalyzr.icsi.berkeley.edu. 100 IN A 67.202.37.63

;; AUTHORITY SECTION:
n1.netalyzr.icsi.berkeley.edu. 100 IN   NS       
return_false.internal.n1.netalyzr.icsi.berkeley.edu.
n1.netalyzr.icsi.berkeley.edu. 100 IN   NS      roland.icir.org.

;; ADDITIONAL SECTION:
roland.icir.org.        3600    IN      A       192.150.187.31
return_false.internal.n1.netalyzr.icsi.berkeley.edu. 100 IN A  
67.202.37.63

; <<>> DiG 9.5.1-P1-RedHat-9.5.1-1.P1.fc10 <<>>  
return_false.internal.n1.netalyzr.icsi.berkeley.edu @192.150.186.8
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62754
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;return_false.internal.n1.netalyzr.icsi.berkeley.edu. IN        A

;; ANSWER SECTION:
return_false.internal.n1.netalyzr.icsi.berkeley.edu. 88 IN A  
67.202.37.63

;; AUTHORITY SECTION:
n1.netalyzr.icsi.berkeley.edu. 88 IN    NS      roland.icir.org.
n1.netalyzr.icsi.berkeley.edu. 88 IN    NS       
return_false.internal.n1.netalyzr.icsi.berkeley.edu.

;; ADDITIONAL SECTION:
roland.icir.org.        3600    IN      A       192.150.187.31

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 30 Jun 2009 09:55:52 -0700

At Tue, 30 Jun 2009 15:17:41 +0000,

> > that causes the problem you stated, rather than the imaginary

I know this problem.  My first guess when I saw the message was
something like this, but it is nothing to do with the additional
section (at least from BIND9's point of view as a recursive server) as
the original problem description claimed:
http://www.mail-archive.com/[email-masked]/msg42037.html

: As far as I can tell, every public recursive server I can reach,
: dnscache and BIND9, and one Microsoft cache and one of whatever
: OpenDNS uses, all do the wrong thing (TM) and never look up true data
: from authoritative name servers. They hang on to additional section
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: data from the delegating name server and pass this on as truth, the

I don't know about other 'they', but in the case of BIND9 recursive
server resolving NS1.MSFT.NET, it hangs on to the *answer section* of
a non-authoritative response, not the additional section.  I didn't
know whether the original question was confused or meant something
else, and that's why I requested a precise problem description with a
checkable example.

> looked at the code, there was some logic to pull an AA bit out of thin

I know, but it's not the behavior in this context (if we interpret it
most precisely) as I explained above.  Regarding the 'hanging on to
non-authoritative answer section' issue, we'll fix the behavior.
Future versions of BIND9 recursive resolver will follow the delegation
from .net to msft.net ignoring the answer section returned from the
.net server.

---
JINMEI, Tatuya

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 01 Jul 2009 02:22:56 +0900

> data in any other way.

It is merely required that all upstream resolvers of you and all
upstream name servers of your peer follow the rule, which is no
more difficult than deploying DNSSEC between you and your peer.

The resulting security is better than that of DNSSEC.

> Not returning it to clients at all (but using

Maybe, though it may increase load on root servers.

						Masataka Ohta