BIND seems to stop on first query. why?

Wed Apr 3 05:04:07 UTC 2002

Oops, is my face red! I forgot that EDNS was added to the very late versions of
BIND 8.

Richard, basically what Mark's saying here is that is normal behavior for BIND 8,
given the number of delegations involved and the lack of query restart. Perhaps
you could consider upgrading to BIND 9 (???)

- Kevin

Mark.Andrews at isc.org wrote:

> >
> > Looks like something is truncating packets here. The initial responses from 1
> > 92.26.92.30 are
> > only 12 bytes long. This isn't even long enough to store a single A record. S
> > o 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 t
> > his 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 (???)
>
>         Kevin the 12 byte responses are FORMERRs in response to EDNS
>         queries.  You will notice that the retries w/o EDNS are answered.
>
>         BIND 8 does not have query restart.  It depends upon the client
>         resending the query to restart the resolution process when it can't
>         proceed and has to fetch address records for all the nameservers.
>
>         Reverse lookups are more likely to require a restart as the
>         nameservers tend to live outside of the reverse tree.  Also with
>         the root servers no longer serving IN-ADDR.ARPA the default number
>         of retries by the clients may no longer be enough to result in
>         complete resolution.
>
> >
> > As for the queries-per-second "limit", BIND 9 has ways to administratively li
> > mit the number of
> > simultaneous lookups it is doing. Presumably when it hits the limit it just s
> > tops listening to
> > the query port. Traditionally, though, when a nameserver is overloaded it jus
> > t takes too long
> > to resolve the query and the client times out. Since UDP is stateless, the be
> > havior probably
> > looks the same from the client side (although a TCP query might fail differen
> > tly, depending on
> > whether the server is not listening on the port or whether it's just taking t
> > oo 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 que
> > ry
> > > 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 o
> > f
> > > 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.
> > > ---------------------------------------------------------------------------
> > ----------------
> >
> >
> --
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org