Sounds like a bug in host(1), which has been deprecated for several years now. Recommended solution: switch to "dig +short" instead. -Adam
On November 21, 2016 3:57:42 AM CST, Trevor Cordes trevor@tecnopolis.ca wrote:
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