ad.de.doubleclick.net and bind8/9

[Kevin Darcy]

Dirk Janssen wrote:

>Hi,
>
>I encountered a problem on all our recursive caching-only nameservers
>(and even others) running bind8.4.4/bind8.4.5 with resolving the host
>mentioned above. When the cache is empty (after restart) then the host
>can be resolved, but if you ask just for one time for the nameserver(s)
>of 3de.doubleclick.net (the domain to where the cname points) then you
>get an answer of an unresolvable host (with a TTL of 1 Week). After
>that, ad.de.doubleclick.net can't be resolved anymore and the query ends
>up in a timemout (probably for 1 Week) what is really annoying because a
>lot of websites using this ad-server are incredibly slow because of this
>issue.
>So far I think this is a problem of doubleclick (it would be nice if
>somebody could also check and verify this). But what I've encountered is
>that bind9.2.3 behaves in another way. What you get here is a SERVFAIL
>and not a timeout and even this SERVFAIL comes just for a short time (it
>seems to depend from how often you queried the ns of
>3de.doubleclick.net?). What's the reason for this different behaviour?
>Is the timeout a bug of bind8? What would be the correct rfc-conform
>behaviour?
>Because of performance issues I really don't want to upgrade to bind9.
>
3de.doubleclick.net is delegated to 4 nameservers 
({uk,de,fr,se}3dns1.doubleclick.net), but each of them only publishes a 
single {uk,de,fr,se}3dns1.3de.doubleclick.net NS record for the zone. In 
other words, if you happen to query, say, fr3dns1.doubleclick.net for 
the NS record of the 3de.doubleclick.net zone, it would respond with 
only an NS record pointing to fr3dns1.3de.doubleclick.net. The trouble 
is, these NS'es are not the same as the delegation NS'es, and since they 
are in the zone being delegated, if the A record times out before the NS 
record does, then any iterative resolver will get stuck, trying to 
resolve from a nameserver it knows (from the NS record it still has 
cached) but without being able to get the address of that nameserver. As 
you can see, BIND 8 and BIND 9 deal with this intolerable situation in 
slightly different ways. This should not surprise you, since BIND 8 and 
BIND 9 share no common code.

Ultimately, doubleclick.net needs to fix either their delegations or 
their in-zone NS records for 3de.doubleclick.net. The in-zone NS records 
should match the delegation NS records. At a bare minimum, they need to 
follow Internet standards and publish at least 2 NS'es for the zone.

- Kevin