Remember this?

[Mark.Andrews at nominum.com]

	Forward zones only have an effect if the server would have
	recursed to answer the query.

	In the nyc.booksellers.com case the server is authoratative
	for booksellers.com and nyc.booksellers.com is not delegated
	namespace so it won't recurse.  Your telling named to hand
	out contradictory answers based on named.conf and the zones
	contents.

	In the bogus.zonker.com case you are not authoratative for
	zonker.com hence the server will recurse and the forwarder
	directive will take effect.

	The vodoo.net queries is the clients search list coming
	into play.

	Mark
> 
> -----------------------------------------------------------------------------
> --
> Subject: Forwarding Mystery Meat
> 
> 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
> 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
> 
> 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;
>         };
> };
> -----------------------------------------------------------------------------
> --
> UPDATES:
> 
> We have upgraded to 8.2.3, added the "forward only" and still it doesn't
> work.  Same behavior as before, I am so stumped.  We made another bogus
> server & zone, just to see how ns1.voodoo.net reacts:
> 
> zone "bogus.zonker.com" IN {
> 	type forward;
> 	forwarders {
> 		192.168.150.11;
> 	};
> };
> 
> Here's debug for an entry that exist (mcgee.bogus.zonker.com):
> 
> 1 datagram from [192.168.40.240].44068, fd 22, len 45
> 2 req: nlookup(mcgee.bogus.zonker.com) id 38594 type=1 class=1
> 3 req: found 'mcgee.bogus.zonker.com' as 'bogus.zonker.com' (cname=0)
> 4 evSetTimer(ctx 0x8133e60, func 0x806d37c, uap 0, due 986848518.000000000,
>   inter 0.000000000)
> 5 forw: forw -> [192.168.150.11].53 ds=4 nsid=39077 id=38594 21ms retry 4sec
> 6 datagram from [192.168.150.11].53, fd 4, len 201
> 7 send_msg -> [192.168.40.240].44068 (UDP 22) id=38594
> 
> Clearly, ns1.voodoo.net knows how to forward and it did.
> Here's debug for an entry that does not exist (foo.bogus.zonker.com):
> 
> 1 datagram from [192.168.40.240].44053, fd 22, len 41
> 2 req: nlookup(foo.bogus.zonker.com) id 27722 type=1 class=1
> 3 req: found 'foo.bogus.zonker.com' as 'zonker.com' (cname=0)
> 4 evSetTimer(ctx 0x8133e60, func 0x806d37c, uap 0, due 986846403.000000000,
>   inter 0.000000000)
> 5 forw: forw -> [192.168.150.11].53 ds=4 nsid=42297 id=27722 25ms retry 4sec
> 6 datagram from [192.168.150.11].53, fd 4, len 119
> 7 ncache: dname foo.bogus.zonker.com, type 1, class 1
> 8 send_msg -> [192.168.40.240].44053 (UDP 22) id=27722
> 9 evSetTimer(ctx 0x8133e60, func 0x806d37c, uap 0, due 986846403.000000000,
>   inter 0.000000000)
> 10 datagram from [192.168.40.240].44054, fd 22, len 52
> 11 req: nlookup(foo.bogus.zonker.com.voodoo.net) id 27723 type=1 class=1
> 12 req: found 'foo.bogus.zonker.com.voodoo.net' as 'voodoo.net' (cname=0)
> 13 ns_req: answer -> [192.168.40.240].44054 fd=22 id=27723 size=97 rc=3
> 
> The thing that worries me is, compare lines 3:  in the first case it
> found zone "bogus.zonker.com", in the second case it found "zonker.com",
> there's no reason why it should draw this distinction.  It then forwards
> the query, as it should, but when the answer came back as not found,
> it appends voodoo.net and tries to look up itself.  Is this normal when 
> we told it explicitly to "forward only" ??
> 
> We still can't get it to forward for anything in nyc.booksellers.com.  Why
> it should forward for bogus.zonker.com and not for nyc.booksellers.com
> is really giving me a headache.  Any insight?
> 
> CT
> 
> 
> 
> 
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at nominum.com