trouble resolving name, caching resolver returns ServFail to client even though it does have the answer
Mark Andrews
marka at isc.org
Tue Jan 29 01:34:45 UTC 2013
In message <CA+8FKT8DuodUun=m+J0qkqE7Qm7TFjfrvnGyNqWNCvuFoAnquw at mail.gmail.com>
, Veaceslav Revutchi writes:
> 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:
The servers for www.solarwinds.com are returning non-authoritative
answers. Note "aa" is *not* set in flags. A properly operating
authoritative server will set "aa" to 1 when responding. It also
won't count down the TTL.
; <<>> DiG 9.10.0pre-alpha <<>> www.solarwinds.com @ns2.solarwinds.com +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54987
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.solarwinds.com. IN A
;; ANSWER SECTION:
www.solarwinds.com. 43 IN A 74.115.13.20
;; Query time: 226 msec
;; SERVER: 74.115.14.18#53(74.115.14.18)
;; WHEN: Tue Jan 29 12:21:52 EST 2013
;; MSG SIZE rcvd: 63
BIND 9.7.0 included a workaround for parents that promote glue to
non-authorative answers. With that workaround in place it was
theoretically no longer necessary to accept non-authoritative
answers. Unfortunately there are some "supposedly" authoritative
server which aren't, like those for www.solarwinds.com, so this was
relaxed in BIND 9.7.1.
Mark
> ---------------------------------------------------------
> 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.
>
> --047d7bfcfe9e733d2b04d4610a57
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> Hello, <br><br>Having trouble resolving a name, hope someone can point me i=
> n 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 "<a href=
> =3D"http://www.solarwinds.com" target=3D"_blank">www.solarwinds.com</a>&quo=
> t;. For example:<br>
>
>
> <br>---------------------------------------------------------<br>slava at rock=
> s:/tmp$ dig @ns02 <a href=3D"http://www.solarwinds.com" target=3D"_blank">w=
> ww.solarwinds.com</a><br><br>; <<>> DiG 9.8.1-P1 <<>&g=
> t; @ns02 <a href=3D"http://www.solarwinds.com" target=3D"_blank">www.solarw=
> inds.com</a><br>
>
>
> ; (1 server found)<br>;; global options: +cmd<br>;; Got answer:<br>;; ->=
> >HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48232<br>;; flags:=
> qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0<br><br>;; QUEST=
> ION SECTION:<br>
>
>
> ;<a href=3D"http://www.solarwinds.com" target=3D"_blank">www.solarwinds.com=
> </a>.=A0=A0=A0 =A0=A0=A0 IN=A0=A0=A0 A<br><br>;; Query time: 97 msec<br>;; =
> SERVER: 10.220.8.18#53(10.220.8.18)<br>;; WHEN: Mon Jan 28 17:00:17 2013<br=
> >;; MSG SIZE=A0 rcvd: 36<br>
>
> -----------------------------------------------------<br>
> <br><br>Here is what the caching resolver (NS02, 10.220.8.18) does while it=
> 's trying to resolve my query:<br><br>[root at ns02 ~]# tcpdump -s0 -n -ie=
> th0 '(host 74.115.14.18 or host 74.115.13.18 or host 10.220.219.101) an=
> d port 53'<br>
>
>
> <br>17:02:36.947658 IP 10.220.219.101.40206 > 10.220.8.18.domain:=A0 509=
> 11+ A? <a href=3D"http://www.solarwinds.com" target=3D"_blank">www.solarwin=
> ds.com</a>. (36)<br>17:02:36.947891 IP 10.220.8.18.43935 > 74.115.14.18.=
> domain:=A0 3509 [1au] A? <a href=3D"http://www.solarwinds.com" target=3D"_b=
> lank">www.solarwinds.com</a>. (47)<br>
>
>
> 17:02:37.003775 IP 74.115.14.18.domain > 10.220.8.18.43935:=A0 3509 1/0/=
> 1 A 74.115.13.20 (63)<br>17:02:37.004003 IP 10.220.8.18.31756 > 74.115.1=
> 3.18.domain:=A0 15333 [1au] A? <a href=3D"http://www.solarwinds.com" target=
> =3D"_blank">www.solarwinds.com</a>. (47)<br>
>
>
> 17:02:37.040083 IP 74.115.13.18.domain > 10.220.8.18.31756:=A0 15333 1/0=
> /1 A 74.115.13.20 (63)<br>17:02:37.040338 IP 10.220.8.18.domain > 10.220=
> .219.101.40206:=A0 50911 ServFail 0/0/0 (36)<br><br>As you can see from the=
> middle four packets the server does get the "A" record response =
> from the two name servers authoritative for "<a href=3D"http://solarwi=
> nds.com" target=3D"_blank">solarwinds.com</a>". It, however, turns aro=
> und and sends a ServFail back to the client (client ip: 10.220.219.101). Th=
> e 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 r=
> ejected and not cached. Digging a bit deeper I also noticed that the two so=
> larwinds servers are open resolvers and they also have an NS record for <a =
> href=3D"http://www.solarwinds.com" target=3D"_blank">www.solarwinds.com</a>=
> delegating it to a pair of GSS devices. <br>
>
> <br>Here is what lands in my caching resolver's cache:<br><br>---------=
> --------- from ns02 cache -----------------------<br><a href=3D"http://sola=
> rwinds.com" target=3D"_blank">solarwinds.com</a>.=A0=A0=A0=A0=A0=A0=A0=A0 1=
> 72794=A0 NS=A0=A0=A0=A0=A0 <a href=3D"http://ns1.solarwinds.com" target=3D"=
> _blank">ns1.solarwinds.com</a>.<br>
>
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 17279=
> 4=A0 NS=A0=A0=A0=A0=A0 <a href=3D"http://ns2.solarwinds.com" target=3D"_bla=
> nk">ns2.solarwinds.com</a>.<br>; authauthority<br><a href=3D"http://ns1.sol=
> arwinds.com" target=3D"_blank">ns1.solarwinds.com</a>.=A0=A0=A0=A0 594=A0=
> =A0=A0=A0 \-AAAA=A0 ;-$NXRRSET<br>
> ; <a href=3D"http://solarwinds.com" target=3D"_blank">solarwinds.com</a>. S=
> OA <a href=3D"http://ns1.solarwinds.com" target=3D"_blank">ns1.solarwinds.c=
> om</a>. <a href=3D"http://hostmaster.solarwinds.com" target=3D"_blank">host=
> master.solarwinds.com</a>. 659 900 600 28800 600<br>
>
> ; glue<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
> =A0=A0 172794=A0 A=A0=A0=A0=A0=A0=A0 74.115.13.18<br>; authauthority<br><a =
> href=3D"http://ns2.solarwinds.com" target=3D"_blank">ns2.solarwinds.com</a>=
> .=A0=A0=A0=A0 594=A0=A0=A0=A0 \-AAAA=A0 ;-$NXRRSET<br>; <a href=3D"http://s=
> olarwinds.com" target=3D"_blank">solarwinds.com</a>. SOA <a href=3D"http://=
> ns1.solarwinds.com" target=3D"_blank">ns1.solarwinds.com</a>. <a href=3D"ht=
> tp://hostmaster.solarwinds.com" target=3D"_blank">hostmaster.solarwinds.com=
> </a>. 659 900 600 28800 600<br>
>
> ; glue<br>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
> =A0=A0 172794=A0 A=A0=A0=A0=A0=A0=A0 74.115.14.18<br><br>; <a href=3D"http:=
> //ns2.solarwinds.com" target=3D"_blank">ns2.solarwinds.com</a> [v4 TTL 4] [=
> v6 TTL 594] [v4 not_found] [v6 nxrrset]<br>;=A0=A0=A0=A0=A0=A0 74.115.14.18=
> [srtt 28267] [flags 00002000] [ttl 1794]<br>
>
> ; <a href=3D"http://ns1.solarwinds.com" target=3D"_blank">ns1.solarwinds.co=
> m</a> [v4 TTL 4] [v6 TTL 594] [v4 not_found] [v6 nxrrset]<br>;=A0=A0=A0=A0=
> =A0=A0 74.115.13.18 [srtt 18606] [flags 00002000] [ttl 1794]<br>-----------=
> ------------------- end cache snippet ------------------------<br>
>
> <br>I tried the same query against two other bind servers (9.8.1-P1 and=A0 =
> 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 c=
> lient. <br>
>
> <br>Here are the options I have in named.conf on NS02:<br>notify yes; <br>c=
> heck-names master ignore;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <br>check-names sla=
> ve ignore;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <br>check-names response ignore=
> ;<br>max-ncache-ttl=A0 600;=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <br>
>
> recursive-clients=A0=A0=A0=A0=A0=A0 20000;=A0 <br><br>Any hint on what migh=
> t be broken here is appreciated.<br><br>Thank you,<br>Slava.<br><br><br><br=
> >
> <br><br><br><br><br><br>
>
> --047d7bfcfe9e733d2b04d4610a57--
>
> --===============1043864797394220551==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> --===============1043864797394220551==--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the bind-users
mailing list