Subject: DNS Additional Section Processing Globally Wrong

From: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 4 Jun 2009 02:50:18 +0100

... it's that, or my reading of RFC 2181 has gone horribly wrong.

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

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  
whole truth, and nothing but the truth to everybody who asks.  This  
means that if my machine happens to be serving for my domain, I'll  
never be able to reduce the TTL to a reasonable value for my dynamic  
conditions.  Even if, in all seriousness, going ahead with a dynamic  
address is a nuisance, is this use of additional data not  
fundamentally broken?

If there is consensus on the wrong behaviour, I'd like it written  
somewhere, so I can feel happy about it just being the way it is by  
implementation, common sense, performance, or whatever.  Then I can  
conform to reality by just using a separate name in delegations.

Alternatively, if *I* wrote a DNS cache, I'd simply use non- 
authoritative data, and expect it, only when necessary: as soon as  
I've chased whatever referals are necessary, I can throw it away.  I  
can rely on two things that make this reasonable: (I) that it's the  
requested RRs I'm interested in and not the delegation, and (II) that  
I can get, and will often get, better additional data from  
authoritative name servers that I have no reason not to hang on to  
and, as needed, to propagate.  Besides, it's easier this way to detect  
discrepancies between the delegation and the zone master.

Cheers,
Sabahattin

---

From: Mark Andrews <[email-masked]>
Date: Thu, 04 Jun 2009 13:06:05 +1000

In message <[email-masked]>, Sab
ahattin Gucukoglu writes:
> whole truth, and nothing but the truth to everybody who asks.

	Except they don't.  What you may be seeing is parent servers
	returning glue as answers and that being accepted.

> This  
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 4 Jun 2009 07:06:21 +0100

On 4 Jun 2009, at 04:06, Mark Andrews wrote:
> In message <[email-masked] 
> >, Sabahattin Gucukoglu writes:

Glue data, additional and non-authoritative by design, intent and  
specification, aren't what I want caches to keep.  The data I spent my  
lunch hour putting into my zone file is. :-)

As a matter of fact, it never occurred to me to wonder at this  
misbehaviour - it clearly wasn't that much of a big deal when I was  
running things myself - but the 2008 cache-poison attacks found me  
surprised that this is how it is.  In particular, they only worked  
because the cache was happy to keep additional data for hosts that  
were pertinent to the query, but in which it had no business caching.   
If it had instead chased up the referal, the attacker would at least  
have had to run a nameserver to answer the "Is it really you?" query.

Cheers,
Sabahattin

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 04 Jun 2009 21:46:31 +0900

Sabahattin Gucukoglu wrote:

> specification, aren't what I want caches to keep.

You had better cache glue As, as long as they are tagged as glue
As with a domain name of query.

Then, the cached information may be used as glue in additional
section but not in answer section.

It is not a problem if a glue A in additional section is cached
and reused as a glue A in additional section to similar query.

> misbehaviour

The misbehavior was present because most, if not all,
implementations cache both glue and authoritative answers but
did not distinguish them by appropriate tagging.

As I have been warning on the problem for these 15 years, some
implementation may hopefully be fixed.

							Masataka Ohta

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 05 Jun 2009 12:53:44 -0400

At 02:06 04/06/2009, Sabahattin Gucukoglu wrote:
>>In message 
>><[email-masked] >, 
>>Sabahattin Gucukoglu writes:

Strictly speaking the Additional Section processing is correct.
The "Missing" step is that recursive resolvers have optimized away
the safety step of "fetching authorative" delegation information.

File bug reports, send mail to namedroppers insisting that Forgery resilience
effort mandate "fetch authorative" behavior, even if that will break some
important stuff as implementors of "fake" DNS servers do not return
NS sets when asked (actually they have started to).

         Olafur