nameserver glue rules adopted to avoid poisoning

[Mark Andrews]

> 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

	If fails because plhhosting.com has no records for
	ns1.plhhosting.com and ns2.plhhosting.com.  Named looks for
	both the AAAA and A records for these servers.  It receives
	back NXDOMAIN from the servers using the glue records from
	the COM zone.

	In addition to this plhhosting.com has a broken delegation.
	The NS records in the COM zone don't match those in the zone
	itself.

	The initial fix is to add back the address records for
	ns1.plhhosting.com and ns2.plhhosting.com to the plhhosting.com
	zone  and to restore the NS records for plhhosting.com so they
	match those in the COM zone.

	Then the change needs to be properly managed.  ns1.plhhosting.com
	and ns2.plhhosting.com can't be removed from the zone until *all*
	the zones using those servers have been re-delegated to
	ns15.websitewelcome.com and ns16.websitewelcome.com (then new
	named for ns1.plhhosting.com and ns2.plhhosting.com).

	Similarly plhhosting.com itself needs to be re-delegated to
	ns15.websitewelcome.com and ns16.websitewelcome.com.

	When re-delgating the zones it should be a two step proceedure.

	1. The new NS records should be added and the delgation changed
	in the parent zone.

	2. After the old NS RRset has disappeared from all caches
	(max zone ttl and parent zone ttl) the old NS RRs are removed
	from the NS RRset and the parent zone is again updated.

	This ensures that caches have a smooth transition.

	Mark

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org