trouble resolving name, caching resolver returns ServFail to client even though it does have the answer

Veaceslav Revutchi slavarevutchi at gmail.com
Mon Jan 28 22:45:58 UTC 2013


Hello,

Having trouble resolving a name, hope someone can point me in the right
direction. All my caching resolvers running "BIND
9.7.0-P2-RedHat-9.7.0-10.P2.el5_8.3" are returning ServFail for "
www.solarwinds.com". For example:

---------------------------------------------------------
slava at rocks:/tmp$ dig @ns02 www.solarwinds.com

; <<>> DiG 9.8.1-P1 <<>> @ns02 www.solarwinds.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48232
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.solarwinds.com.        IN    A

;; Query time: 97 msec
;; SERVER: 10.220.8.18#53(10.220.8.18)
;; WHEN: Mon Jan 28 17:00:17 2013
;; MSG SIZE  rcvd: 36
-----------------------------------------------------


Here is what the caching resolver (NS02, 10.220.8.18) does while it's
trying to resolve my query:

[root at ns02 ~]# tcpdump -s0 -n -ieth0 '(host 74.115.14.18 or host
74.115.13.18 or host 10.220.219.101) and port 53'

17:02:36.947658 IP 10.220.219.101.40206 > 10.220.8.18.domain:  50911+ A?
www.solarwinds.com. (36)
17:02:36.947891 IP 10.220.8.18.43935 > 74.115.14.18.domain:  3509 [1au] A?
www.solarwinds.com. (47)
17:02:37.003775 IP 74.115.14.18.domain > 10.220.8.18.43935:  3509 1/0/1 A
74.115.13.20 (63)
17:02:37.004003 IP 10.220.8.18.31756 > 74.115.13.18.domain:  15333 [1au] A?
www.solarwinds.com. (47)
17:02:37.040083 IP 74.115.13.18.domain > 10.220.8.18.31756:  15333 1/0/1 A
74.115.13.20 (63)
17:02:37.040338 IP 10.220.8.18.domain > 10.220.219.101.40206:  50911
ServFail 0/0/0 (36)

As you can see from the middle four packets the server does get the "A"
record response from the two name servers authoritative for "solarwinds.com".
It, however, turns around and sends a ServFail back to the client (client
ip: 10.220.219.101). The server will not cache the response either. What's
interesting is that the two responses it gets from the supposedly
authoritative servers do not have the "aa" set. I am assuming that is why
the responses are rejected and not cached. Digging a bit deeper I also
noticed that the two solarwinds servers are open resolvers and they also
have an NS record for www.solarwinds.com delegating it to a pair of GSS
devices.

Here is what lands in my caching resolver's cache:

------------------ from ns02 cache -----------------------
solarwinds.com.         172794  NS      ns1.solarwinds.com.
                        172794  NS      ns2.solarwinds.com.
; authauthority
ns1.solarwinds.com.     594     \-AAAA  ;-$NXRRSET
; solarwinds.com. SOA ns1.solarwinds.com. hostmaster.solarwinds.com. 659
900 600 28800 600
; glue
                        172794  A       74.115.13.18
; authauthority
ns2.solarwinds.com.     594     \-AAAA  ;-$NXRRSET
; solarwinds.com. SOA ns1.solarwinds.com. hostmaster.solarwinds.com. 659
900 600 28800 600
; glue
                        172794  A       74.115.14.18

; ns2.solarwinds.com [v4 TTL 4] [v6 TTL 594] [v4 not_found] [v6 nxrrset]
;       74.115.14.18 [srtt 28267] [flags 00002000] [ttl 1794]
; ns1.solarwinds.com [v4 TTL 4] [v6 TTL 594] [v4 not_found] [v6 nxrrset]
;       74.115.13.18 [srtt 18606] [flags 00002000] [ttl 1794]
------------------------------ end cache snippet ------------------------

I tried the same query against two other bind servers (9.8.1-P1 and  9.7.3)
and they have no problem using the non-authoritative answer they get from
the two solarwinds servers. They will cache it and return it to the client.

Here are the options I have in named.conf on NS02:
notify yes;
check-names master ignore;
check-names slave ignore;
check-names response ignore;
max-ncache-ttl  600;
recursive-clients       20000;

Any hint on what might be broken here is appreciated.

Thank you,
Slava.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130128/728b1d86/attachment.html>


More information about the bind-users mailing list