BIND seems to stop on first query. why?

Kevin Darcy kcd at daimlerchrysler.com
Wed Apr 3 04:06:19 UTC 2002


Looks like something is truncating packets here. The initial responses from 192.26.92.30 are
only 12 bytes long. This isn't even long enough to store a single A record. So your nameserver
is rejecting those. Eventually you get reasonable packets and the resolution process
continues. I would look at low-level networking issues as the root cause of this problem. It's
also curious why named would pound on a single nameserver (192.26.92.30, aka
C.GTLD-SERVERS.NET); it should be trying other TLD nameservers to resolve the name. Perhaps it
hasn't been able to get any answer *at*all* -- not even truncated answers -- from the other
TLD nameservers, so it's written them off (???)

As for the queries-per-second "limit", BIND 9 has ways to administratively limit the number of
simultaneous lookups it is doing. Presumably when it hits the limit it just stops listening to
the query port. Traditionally, though, when a nameserver is overloaded it just takes too long
to resolve the query and the client times out. Since UDP is stateless, the behavior probably
looks the same from the client side (although a TCP query might fail differently, depending on
whether the server is not listening on the port or whether it's just taking too long to return
an answer).


- Kevin

Richard Cabrera wrote:

> I apologize in advance for my pathetic knowledge of this subject. =)
>
> I am running BIND 8.3.1, and if I restart my local name server and then query
> it with nslookup, I will get a "No response from server" for the first (and
> sometimes through the 4th) attempt, and then I will get an answer. This
> happens consistently. Is there any logical reason for this?
>
> here is an example from named.run where it didn't answer my query: (this is
> my second attempt at querying the address)
>
> datagram from [127.0.0.1].43162, fd 20, len 44
> req: nlookup(204.205.26.24.IN-ADDR.ARPA) id 26995 type=12 class=1
> req: found '204.205.26.24.IN-ADDR.ARPA' as '24.IN-ADDR.ARPA' (cname=0)
> forw: forw -> [192.5.6.32].53 ds=5 nsid=15394 id=26995 4ms retry 4sec
> datagram from [192.5.6.32].53, fd 5, len 12
> resend(addr=0 n=1) -> [192.5.6.32].53 ds=5 nsid=15394 id=26995 4ms
> datagram from [192.5.6.32].53, fd 5, len 126
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15394
> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 0
> ;; 204.205.26.24.IN-ADDR.ARPA, type = PTR, class = IN
> 26.24.IN-ADDR.ARPA. 1D IN NS DNS1.RR.COM.
> 26.24.IN-ADDR.ARPA. 1D IN NS DNS2.RR.COM.
> 26.24.IN-ADDR.ARPA. 1D IN NS DNS3.RR.COM.
> 26.24.IN-ADDR.ARPA. 1D IN NS DNS4.RR.COM.
> resp: nlookup(204.205.26.24.IN-ADDR.ARPA) qtype=12
> resp: found '204.205.26.24.IN-ADDR.ARPA' as '26.24.IN-ADDR.ARPA' (cname=0)
> sysquery: send -> [192.26.92.30].53 dfd=5 nsid=20767 id=0 retry=1017698262
> sysquery: send -> [192.26.92.30].53 dfd=5 nsid=30080 id=0 retry=1017698262
> sysquery: send -> [192.26.92.30].53 dfd=5 nsid=14741 id=0 retry=1017698262
> sysquery: send -> [192.26.92.30].53 dfd=5 nsid=15854 id=0 retry=1017698262
> datagram from [192.26.92.30].53, fd 5, len 12
> resend(addr=0 n=1) -> [192.26.92.30].53 ds=5 nsid=20767 id=0 1ms
> datagram from [192.26.92.30].53, fd 5, len 12
> resend(addr=0 n=1) -> [192.26.92.30].53 ds=5 nsid=30080 id=0 1ms
> datagram from [192.26.92.30].53, fd 5, len 12
> resend(addr=0 n=1) -> [192.26.92.30].53 ds=5 nsid=14741 id=0 1ms
> datagram from [192.26.92.30].53, fd 5, len 12
> resend(addr=0 n=1) -> [192.26.92.30].53 ds=5 nsid=15854 id=0 1ms
> datagram from [192.26.92.30].53, fd 5, len 180
> datagram from [192.26.92.30].53, fd 5, len 180
> datagram from [192.26.92.30].53, fd 5, len 180
> datagram from [192.26.92.30].53, fd 5, len 180
>
> Also, What is a typical limit on the number of queries per second that can be
> made to a local name server? Is this at all configurable or just a matter of
> machine resources? When you reach this limit does the name server drop the
> packets, or attempt the query and/or simply return "timeout" waiting for
> resources?
>
> Thank you for any light you can shed on this.
>
> Rick =)
>
> Richard Cabrera
> Software Engineer
> Phone:678-258-6312
> Fax:  678-258-6363
> www.digitalenvoy.net
>
> -------------------------------------------------------------------------------------------
> All information is considered privileged under any NDA in force.
> -------------------------------------------------------------------------------------------



More information about the bind-users mailing list