At 02:06 04/06/2009, Sabahattin Gucukoglu wrote:
On 4 Jun 2009, at 04:06, Mark Andrews wrote:
In message
<AAAB52EF-AD0A-4D3C-9B28-B864F342D933@xxxxxxxxxxxxxxxxxxxxxxxx >,
Sabahattin Gucukoglu writes:
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.
Except they don't. What you may be seeing is parent servers
returning glue as answers and that being accepted.
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
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
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf