Hello guys, I have BIND 9.6-ESV-R5-P1 on SLES 11 SP1 installed and it is working fine. I only have a situation where I don't understand what's happening and why : I try to do a quad-A query to www.ryanair.com (which is doesn't exists, only single A). When trying this with "dig" on my BIND server, I get a SERVFAIL return code. When doing the same query on the google DNS (8.8.8.8) I only get no answer but a return code of NOERROR.
(I only took www.ryanair.com as an exemple but I get the same behavior with some other records like exch-eu.atdmt.com ...) *Here is the dig on google DNS* dig @8.8.8.8 AAAA www.ryanair.com ; <<>> DiG 9.9.0 <<>> @8.8.8.8 AAAA www.ryanair.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56244 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 *Here is the dig on my bind server:* dig AAAA www.ryanair.com ; <<>> DiG 9.9.0 <<>> AAAA www.ryanair.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25197 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 *So I configured a channel with a debug3 severity on my BIND to try understanding what's happening. Here is the response exerpt:* 25-Apr-2012 14:00:52.009 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): response 25-Apr-2012 14:00:52.009 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/AAAA'): noanswer_response 25-Apr-2012 14:00:52.009 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/AAAA'): cancelquery 25-Apr-2012 14:00:52.010 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/AAAA'): add_bad 25-Apr-2012 14:00:52.010 lame-servers: info: FORMERR resolving ' www.ryanair.com/AAAA/IN': 193.95.148.92#53 25-Apr-2012 14:00:52.010 lame-servers: info: FORMERR resolving ' www.ryanair.com/AAAA/IN': 193.95.148.92#53 25-Apr-2012 14:00:52.010 lame-servers: info: FORMERR resolving ' www.ryanair.com/AAAA/IN': 193.95.148.92#53 25-Apr-2012 14:00:52.010 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/AAAA'): try 25-Apr-2012 14:00:52.010 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/AAAA'): query 25-Apr-2012 14:00:52.010 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): send 25-Apr-2012 14:00:52.010 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): sent 25-Apr-2012 14:00:52.010 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): udpconnected 25-Apr-2012 14:00:52.010 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): senddone 25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): response 25-Apr-2012 14:00:52.030 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/AAAA'): cancelquery 25-Apr-2012 14:00:52.030 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/AAAA'): resend 25-Apr-2012 14:00:52.030 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/AAAA'): query 25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): send 25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): sent 25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): udpconnected 25-Apr-2012 14:00:52.030 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): senddone 25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: UDP request 25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: view MLT-EXTERNAL: query 25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: view MLT-EXTERNAL: send 25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: view MLT-EXTERNAL: sendto 25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: view MLT-EXTERNAL: senddone 25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: view MLT-EXTERNAL: next 25-Apr-2012 14:00:52.047 client: debug 3: client 195.130.131.10#3449: view MLT-EXTERNAL: endrequest 25-Apr-2012 14:00:52.047 client: debug 3: client @0x7f0d238e0380: udprecv 25-Apr-2012 14:00:52.050 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): response 25-Apr-2012 14:00:52.050 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/AAAA'): noanswer_response 25-Apr-2012 14:00:52.050 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/AAAA'): cancelquery 25-Apr-2012 14:00:52.050 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/AAAA'): add_bad 25-Apr-2012 14:00:52.050 lame-servers: info: FORMERR resolving ' www.ryanair.com/AAAA/IN': 62.73.129.182#53 25-Apr-2012 14:00:52.050 lame-servers: info: FORMERR resolving ' www.ryanair.com/AAAA/IN': 62.73.129.182#53 25-Apr-2012 14:00:52.050 lame-servers: info: FORMERR resolving ' www.ryanair.com/AAAA/IN': 62.73.129.182#53 25-Apr-2012 14:00:52.050 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/AAAA'): try 25-Apr-2012 14:00:52.050 resolver: debug 3: fctx 0x7f0d23be2dc0( www.ryanair.com/AAAA'): query 25-Apr-2012 14:00:52.050 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): send 25-Apr-2012 14:00:52.050 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): sent 25-Apr-2012 14:00:52.050 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): udpconnected 25-Apr-2012 14:00:52.050 resolver: debug 3: resquery 0x7f0d23be8dc0 (fctx 0x7f0d23be2dc0(www.ryanair.com/AAAA)): senddone So if I understand well, BIND received no answer for its query so it raise a FORMERR return code. So the difference in the return code between the google dns and bind is only a matter of DNS spec implementation difference? Or do I have a misconfiguration on my bind server? Why do I care about this? Some Windows XP which are DNS clients of my BIND server have ipv6 enabled so they try to resolve URLs with quad-A. As they received SERVFAIL they try any other known server names in their network configuration in a loop until a (very long) timeout before trying single-A resolution. When configuring google nameserver as Windows network resolvers, I don't get any timeout since I get the blank response immediately for the quad-A record (with no error as return code) and it immediately try to resolve with single-A. => I know the root cause is the enablement of IPV6 on the clients and that part of the problem will be fixed. But I also want to understand and fix if possible the behavior of my BIND server. -- Nicolas MICHEL
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
