Forwarding Mystery Meat

[Kevin Darcy]

Christine Tran wrote:

> Got call about forwarder going haywire. All this stuff is behind
> an intranet, so not possible to diagnose from outside.
>
> unhappy host is ns1.voodoo.net, slave for zone booksellers.com;
> wants to have zone type forward for nyc.booksellers.com.
>
> ns1.booksellers.com is master & authoritative for booksellers.com
> and nyc.booksellers.com
>
> turnning on debug on ns1.voodoo.net (192.168.40.240)
>
> 1 req: nlookup(www.nyc.booksellers.com) id 23064 type=1 class=1
> 2 req: found 'www.nyc.booksellers.com' as 'booksellers.com' (cname=0)
> 3 ns_req: answer -> [192.168.40.240].42888 fd=22 id=23064 size=94 rc=3
> 4 datagram from [192.168.40.240].42889, fd 22, len 48
>
> line 4 is probably ns1.voodoo.net answering that it didn't know about
> www.nyw after looking in zone booksellers.com.  Logical.

(You mean line 3, right? Line 4 is related to the second query, i.e. the one
with "voodoo.net" appended.)

Actually, that's not quite "logical". Under normal circumstances, the "type
forward" zone entry you show below should have caused the query to be
forwarded, if there was no cache entry for it. The fact that it wasn't
suggests that something strange happened.

> 5 req: nlookup(www.nyc.booksellers.com.voodoo.net) id 23065 type=1 class=1
> 6 req: found 'www.nyc.booksellers.com.voodoo.net' as 'voodoo.net' (cname=0)
> 7 ns_req: answer -> [192.168.40.240].42889 fd=22 id=23065 size=103 rc=3
>
> So it appends voodoo.net to query and tries to look it up, no cigars
> either.  The story would end here, but for the fact that I'm assured by
> hostmasters that this setup WORKED until a Monday afternoon 2 weeks ago.
> They WERE able to resolve forwarded queries for nyc.booksellers.com.
> Another hostmaster for ns1.japan.voodoo.net has same setup, corroborated
> that his stuff stopped working about the same time.  This is hard to
> refute, I wasn't there.  I can't see that anything is wrong with
> ns1.booksellers.com, the forwarded query never even got there.
> ns1.voodoo.net made up its mind that www.nyc should be searched for
> in booksellers.com, ignoring the directive to forward:
>
> zone "nyc.booksellers.com" IN {
>         type forward;
>         forwarders {
>                 10.10.40.240;
>         };
> };
>
> So, I put it to the experts, should this have EVER worked?  Two very sane
> people are convinced it did.  They run 8.2.2p5 on Solaris 5.7 x86.

It should work under normal circumstances, but I think your problem is that
there was a transient problem talking to your forwarder, and since you have
"forward first" (the default) configured, your nameserver then attempted to
resolve the query iteratively and got a NXDOMAIN response, either because
nyc.booksellers.com is not delegated from booksellers.com, or it is delegated
to some other server (not the forwarder) which doesn't happen to have a
"www" entry in the zone. Now your nameserver has a negative cache entry and
it's answering from that instead of forwarding. If you dump your cache, you
should be able to determine the existence or non-existence of that negative
cache entry.

The moral of the story is that you should only configure "forward first" if
you're using forwarding strictly as a performance enhancement. If you are
using forwarding to deal with connectivity issues or to tie together disjoint
namespaces (e.g. undelegated subzones), then use "forward only". Otherwise
you're just asking for trouble. In the scenario I outlined above, "forward
only" would cause SERVFAIL or a timeout to occur until the forwarder was
available again, at which time it would start working. If you want more
redundancy than that, make yourself a slave for the zone.



- Kevin