nameserver glue rules adopted to avoid poisoning

John Wobus jw354 at cornell.edu
Wed Feb 15 16:12:18 UTC 2006


Hi,

Yesterday I spent too much time googling to find out bind9's or general 
DNS rules
used to avoid cache poisoning through glue.  I must not have hit the
right combination of keywords (glue, poison, poisioning, dns, bind, etc)
and I did not read the bind9 code.

I was tracking down a specific case where our nameservers failed to
resolve a name that some nameservers around the Internet resolved.
I am less than comfortable saying "perhaps they have data cached,
or aren't playing by the rules", without having such rules at my 
fingertips.

The situation I ran into was this:
*onintelligence.org would not resolve.
*dig +trace showed the org tld nameserver delegated it to 
ns1.plhhosting.com
*The com tld nameserver provided a glue record for ns1.plhhosting.com
*ns1.plhhosting.com did *not* have an A record for itself (Eureka!)
*Trying flushname on the domains and names involved on my own
   nameserver didn't make it resolve onintelligence.org
*www.dnsreport.org showed "red stuff" regarding onintelligence.org 
including
  this lack of an A record.
*At the same time, some other nameservers did resolve 
onintelligence.org.

Given the anti-poisoning principles that have stuck in my mind over
the years, and what I observed our nameservers were doing, I could
reconstruct some possible rules, but I don't know which ones are
now considered conventional DNS wisdom and/or are implemented in bind9.
Rule statements I could recall or think up:

-A server never gives glue as an answer (i.e. in the answer
   section) to a query it receives.
-A server "discards without using" glue unless both hold:
   * it's for a nameserver in the answer section to this server's ns 
query
   * the nameserver is within the zone this server sent a query about
-If a server does not get a nameserver's address by legal
  glue, thus has to do a "subquery" to track down that nameserver's
  address, once again, the answer it uses from that subquery
  must be authoritative, i.e. not the result of glue used within
  that subquery.
-Glue is used in precisely one circumstance: at the point
  where the server needs the address of a nameserver for
  a zone and the nameserver is inside that zone, it uses
  the glue for that, and nothing subsequent (except that
  it can cache it specifically for precisely the same
  circumstance in the future).

(Clearly the rules I've come up with are overlapping.)
Perhaps all of these are now adopted, or perhaps
one or more are stronger than what is in current use.
The "trust" model gets a little confusing.  It seems like
there are situations when a query uses glue because
it must, yet fails because it won't use the same glue at a
subsequent point in the same query, even though
that wouldn't put glue in the answer section of the
original query.

John Wobus
Cornell CIT



More information about the bind-users mailing list