[RndTbl] help! dns zone delegation wonky for AAAA

Trevor Cordes trevor at tecnopolis.ca
Mon Nov 21 03:57:42 CST 2016


I'm seeing some weird behaviour related to AAAA and delegation I'd like to 
correct with a BIND DNS setup.  I have no AAAA records anywhere.  Some 
lookup tools/libraries insist on looking up AAAA, I want them to fail 
immediately.  All servers/clients involved are run with the -4 option to 
run all traffic over IPv4.

The problem is that I'm seeing occassional lookup delays for AAAA records 
on some boxes (the ones that delegate), but not other ones (every other 
box).

On my box (BOX1) I'm authoritative for foo.com (only for my internal 
networks).
On the same box, I delegate sub.foo.com to ns.com (BOX2).

BOX2 is authoritative for foo.com and sub.foo.com.  I do this so BOX1 can 
have local dynamic DNS for local Windows boxes, etc, on foo.com.  Whereas 
the BOX2 view is for the whole world, to which I don't want to share the 
existence of windows.foo.com, etc.  A bit messy, but this has worked for 
me for 15 years.

The problem symptoms:

I run "host bar.sub.foo.com " on the boxes:

BOX1:
bar.sub.foo.com has address 1.2.3.4
Host bar.sub.foo.com not found: 2(SERVFAIL)
bar.sub.foo.com mail is handled by 5 bar.sub.foo.com.
<often delays 5-10sec before giving the SERVFAIL

BOX2 (and every other box in the world except BOX1!!):
bar.sub.foo.com has address 1.2.3.4
bar.sub.foo.com mail is handled by 5 bar.sub.foo.com.

I don't want the delay or the SERVFAIL on BOX1.

The host command by default does a lookup of AA, AAAA and MX in that 
order.  That's fine.  But I want them all to run without delay, and the 
AAAA to be ignored like it is on BOX2.  Again, there are no AAAA records 
in any of these zone files.

I think I'm seeing the precise bug discussed here:

https://tools.ietf.org/html/draft-ietf-dnsop-misbehavior-against-aaaa-00
search to:  4.4 Make Lame Delegation

That document doesn't seem to provide any solutions.

I think the issue is when BOX2 (or any box but BOX1) does a lookup, it 
checks only with BOX2, sees there's no AAAA and happily ignores AAAA.  I 
think in essence it's like "I'm BOX2, I'm authoritative and I have no 
AAAA".  host is happy with this.

With BOX1, it does a lookup with BOX1's named which recurses out to the 
delegation on BOX2.  BOX2 says the same as it did above, but this time 
it's talking to BOX1 named, not the host command.  BOX1 named must be 
saying "I thought BOX2 was authoritative, but I find no AAAA so it's not 
authoritative after all, and I don't know anyone who is so I'm spewing 
this error SERVFAIL".  I'm just guessing here.

I want the host command on BOX1 to behave the same as BOX2.  Can it be 
done?  I actually was seeing the exact same problem with the 
nonexistent bar.sub.foo.com MX record and I solved it by adding an MX 
record for it on BOX2.  However, I don't want any AAAA record on any box, 
as none of them have IPv6 addresses!  Surely there must be a solution to 
this weird problem.

Possibly relevant is how dig behaves with different usage:


BOX1#dig -tAAAA @localhost bar.sub.foo.com
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2619
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;bar.sub.foo.com.	IN	AAAA


BOX1#dig -tAAAA @ns.com bar.sub.foo.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5477
;; flags: qr aa 
rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;bar.sub.foo.com.	IN	AAAA

;; AUTHORITY SECTION:
foo.com.		86400	IN	SOA	ns.com. 17 1800 300 604800 86400


BOX2#dig -tAAAA @localhost bar.sub.foo.com
**pretty much the same output as above 2nd example, NOERROR**
BOX2#dig -tAAAA @ns.com bar.sub.foo.com
**pretty much the same output as above 2nd example, NOERROR**


It's that SERVFAIL in example dig #1 above that I want to eliminate, and 
thus also the SERVFAIL with host.

Thanks!


More information about the Roundtable mailing list