Don't understand why I get a FORMERR (quad-A - ipv6 related)

[Nicolas Michel]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120425/83e0a4ba/attachment.html>