Forwarding Problem (was Re: Ambiguous def of multiple CNAME)

[Kevin Darcy]

Christine.Tran at east.sun.com wrote:

> >Strange, but this works fine for me. I defined "blah.chrysler.com" in a bogus >version of the chrysler.com zone, as an alias to www.sun.com. When I queried >it, it translated the CNAME, then used the forwarder to fetch the A record. >This is just using a generic global-forward-and-master-for-chrysler.com type of >configuration. Is yours different somehow?
>
> My config is plain-jane forward-if-you-dont-know-it.  My internal server is auth for, say, foo.com.  The rest of this is real.
>
> porttracker.foo.com.    IN      CNAME   porttracker.finsys.com.
>
> Here's the debug of me nslookup porttracker.foo.com RIGHT ON THE INTERNAL NAMESERVER:
>
> req: nlookup(porttracker.foo.com) id 13204 type=1 class=1
> req: found 'porttracker.foo.com' as 'porttracker.foo.com' (cname=0)
> req: nlookup(porttracker.finsys.com) id 13204 type=1 class=1
> req: found 'porttracker.finsys.com' as 'finsys.com' (cname=1)
> evSetTimer(ctx 0x15f590, func 0x39ed4, uap 0, due 943984296.000000000, inter 0.0
> 00000000)
> forw: forw -> [1.2.3.4].53 ds=4 nsid=3597 id=8238 5ms retry 8sec

I'm a little confused here: does "[1.2.3.4]" stand for your regular forwarder, or for an external nameserver that you are timing out trying to reach (as you said in your previous message)? What happens after this point in the process? It also looks like you already had the CNAME cached, since there is no forwarding for it; how does the output look with a
freshly-restarted nameserver?

If you're forwarding everything, then I can't think of any reason why you'd be getting a referral back unless someone in your forwarding chain has recursion turned off (presumably a firewall or some external server, since you're getting back external NS records). If your firewall is misconfigured to forward to an Internet root server, then this would have the
same effect. Furthermore, if you do get a referral back, you shouldn't be trying to follow it if global forwarding is in effect; you should be returning an immediate SERVFAIL to the client (and there should also be a lame server message blaming your forwarder in the debug output). At least, this is what I'm getting with 8.2.2-p5. Is that what you are running?

Why don't you crank up the debug level to 3 and show everything from the query packet being received from the client to the answer being returned to the client? That might clarify things.

With a pure forwarding configuration, here's what I see. "xxx.xxx.xxx.xxx" stands for the forwarder (which has the blah.chrysler.com -> www.sun.com CNAME translation in a master file):


datagram from [127.0.0.1].57605, fd 20, len 35
req: nlookup(blah.chrysler.com) id 36824 type=1 class=1
req: found 'blah.chrysler.com' as 'chrysler.com' (cname=0)
findns: 13 NS's added for ''
ns_forw()
find_zone(blah.chrysler.com, 1)
find_zone: unknown zone
find_zone(chrysler.com, 1)
find_zone: unknown zone
find_zone(com, 1)
find_zone: unknown zone
find_zone(., 1)
find_zone: unknown zone
evSetTimer(ctx 0x1de1e0, func 0x589a0, uap 0, due 944009054.000000000, inter 0.000000000)
forw: forw -> [xxx.xxx.xxx.xxx].53 ds=5 nsid=1536 id=36824 -1ms retry 60sec
free_nsp: J.ROOT-SERVERS.NET rcnt 1
free_nsp: K.ROOT-SERVERS.NET rcnt 1
free_nsp: L.ROOT-SERVERS.NET rcnt 1
free_nsp: M.ROOT-SERVERS.NET rcnt 1
free_nsp: I.ROOT-SERVERS.NET rcnt 1
free_nsp: E.ROOT-SERVERS.NET rcnt 1
free_nsp: D.ROOT-SERVERS.NET rcnt 1
free_nsp: A.ROOT-SERVERS.NET rcnt 1
free_nsp: H.ROOT-SERVERS.NET rcnt 1
free_nsp: C.ROOT-SERVERS.NET rcnt 1
free_nsp: G.ROOT-SERVERS.NET rcnt 1
free_nsp: F.ROOT-SERVERS.NET rcnt 1
free_nsp: B.ROOT-SERVERS.NET rcnt 1
datagram from [xxx.xxx.xxx.xxx].53, fd 5, len 174
qfindid(1536) -> 0x1b15c8
Response (USER NORMAL -) nsid=1536 id=36824
rrextract: dname blah.chrysler.com type 5 class 1 ttl 3600
rrextract: dname www.sun.com type 5 class 1 ttl 1458
rrextract: dname wwwwseast.usec.sun.com type 1 class 1 ttl 1442
rrextract: dname usec.sun.com type 2 class 1 ttl 1458
rrextract: dname usec.sun.com type 2 class 1 ttl 1458
rrextract: dname ns.usec.sun.com type 1 class 1 ttl 86058
rrextract: dname ns-os.sun.com type 1 class 1 ttl 160693
rrsetupdate: blah.chrysler.com
rrsetcmp: name not in database
rrsetupdate: blah.chrysler.com 0
rrsetupdate: blah.chrysler.com 0
rrsetupdate: www.sun.com
rrsetcmp: name not in database
db_update(blah.chrysler.com, 0x1a6678, 0x1a6678, 0, 031, 0x1a16b8)
db_update: adding 0x1a6678
rrsetupdate: www.sun.com 0
rrsetupdate: www.sun.com 0
rrsetupdate: wwwwseast.usec.sun.com
rrsetcmp: name not in database
db_update(www.sun.com, 0x1b6600, 0x1b6600, 0, 031, 0x1a16b8)
db_update: adding 0x1b6600
rrsetupdate: wwwwseast.usec.sun.com 0
rrsetupdate: wwwwseast.usec.sun.com 0
rrsetupdate: usec.sun.com
rrsetcmp: name not in database
db_update(wwwwseast.usec.sun.com, 0x1a3d18, 0x1a3d18, 0, 031, 0x1a16b8)
db_update: adding 0x1a3d18
rrsetupdate: usec.sun.com 0
rrsetupdate: usec.sun.com 0
rrsetupdate: usec.sun.com 0
rrsetupdate: ns.usec.sun.com
rrsetcmp: name not in database
db_update(usec.sun.com, 0x1b85c8, 0x1b85c8, 0, 031, 0x1a16b8)
db_update: adding 0x1b85c8
db_update(usec.sun.com, 0x1b85f8, 0x1b85f8, 0, 031, 0x1a16b8)
db_update: adding 0x1b85f8
rrsetupdate: ns.usec.sun.com 0
rrsetupdate: ns.usec.sun.com 0
rrsetupdate: ns-os.sun.com
rrsetcmp: name not in database
db_update(ns.usec.sun.com, 0x1a3d3c, 0x1a3d3c, 0, 031, 0x1a16b8)
db_update: adding 0x1a3d3c
rrsetupdate: ns-os.sun.com 0
rrsetupdate: ns-os.sun.com 0
db_update(ns-os.sun.com, 0x1a3d60, 0x1a3d60, 0, 031, 0x1a16b8)
db_update: adding 0x1a3d60
resp: got as much answer as there is
send_msg -> [127.0.0.1].57605 (UDP 20) id=36824


                                                                                                                                                - Kevin