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!
Roundtable mailing list
Roundtable@muug.ca
https://muug.ca/mailman/listinfo/roundtable