Hi, I tried to go debug level 2 on query-errors and have the result:
23-Jun-2011 09:57:39.182 query-errors: debug 1: client 202.14.67.27#55079: query failed (SERVFAIL) for aws.amazon.com/IN/A at query.c:4651 23-Jun-2011 09:57:39.182 query-errors: debug 2: fetch completed at resolver.c:3103 for aws.amazon.com/A in 0.000073: out of memory/success [domain:aws.amazon.com ,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] Is it because we limit the memory usage at named.conf? max-cache-size 1610612736; Eric On Thu, Jun 23, 2011 at 5:25 AM, Kevin Darcy <k...@chrysler.com> wrote: > ** > On 6/22/2011 7:26 AM, Eric Yiu wrote: > > Hi, > > I am using bind9.7.3-P1 with solaris10x86. I notice that > sometimes our bind server will reply servfail when querying > a zone aws.amazon.com which is expiring, while this > aws.amazon.com only 60sec cache lifetime, eg. > > > /usr/local/bin/dig a aws.amazon.com > > ; <<>> DiG 9.7.3-P1 <<>> a aws.amazon.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26307 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 1 > > ;; QUESTION SECTION: > ;aws.amazon.com. IN A > > ;; ANSWER SECTION: > aws.amazon.com. 1 IN A 72.21.210.163 > > ;; AUTHORITY SECTION: > aws.amazon.com. 6517 IN NS ns-932.amazon.com. > aws.amazon.com. 6517 IN NS ns-931.amazon.com. > aws.amazon.com. 6517 IN NS ns-912.amazon.com. > aws.amazon.com. 6517 IN NS ns-923.amazon.com. > aws.amazon.com. 6517 IN NS ns-911.amazon.com. > aws.amazon.com. 6517 IN NS ns-921.amazon.com. > > ;; ADDITIONAL SECTION: > ns-911.amazon.com. 3108 IN A 207.171.178.13 > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Wed Jun 22 18:59:30 2011 > ;; MSG SIZE rcvd: 190 > > > /usr/local/bin/dig a aws.amazon.com > > ; <<>> DiG 9.7.3-P1 <<>> a aws.amazon.com > ;; global options: +cmd > ;; Got answer: > *;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20884 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0* > > ;; QUESTION SECTION: > ;aws.amazon.com. IN A > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Wed Jun 22 18:59:31 2011 > ;; MSG SIZE rcvd: 32 > > > /usr/local/bin/dig a aws.amazon.com > ^[[A > ; <<>> DiG 9.7.3-P1 <<>> a aws.amazon.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47970 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 1 > > ;; QUESTION SECTION: > ;aws.amazon.com. IN A > > ;; ANSWER SECTION: > aws.amazon.com. 60 IN A 72.21.210.163 > > ;; AUTHORITY SECTION: > aws.amazon.com. 6516 IN NS ns-932.amazon.com. > aws.amazon.com. 6516 IN NS ns-911.amazon.com. > aws.amazon.com. 6516 IN NS ns-912.amazon.com. > aws.amazon.com. 6516 IN NS ns-931.amazon.com. > aws.amazon.com. 6516 IN NS ns-921.amazon.com. > aws.amazon.com. 6516 IN NS ns-923.amazon.com. > > ;; ADDITIONAL SECTION: > ns-911.amazon.com. 3107 IN A 207.171.178.13 > > ;; Query time: 229 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Wed Jun 22 18:59:31 2011 > ;; MSG SIZE rcvd: 190 > > I couldn't really see anything that would explain the SERVFAIL. Each of > those "nameservers" appears to be a load-balancer of some sort. When queried > individually for aws.amazon.com/A, they give a diversity of answers, > implying that they are attempting some form of "DNS geolocation". None of > them seem bothered by EDNS0 or DNSSEC stuff (most likely they're completely > oblivious). When queried individually for aws.amazon.com/NS, all of them > except for one return a single NS record with their own name in the RDATA. > The only exception I saw was ns-912.amazon.com, which returned > ns-945.amazon.com. But, I don't think that's the cause of the SERVFAIL, > since ns-945.amazon.com answers authoritatively for the name, even though > it's not one of the delegated nameservers for the zone. > > Time to look at logs, run named in debug mode and/or fire up a packet > tracer and see what's really going on. Possibly something between you and > the amazon.com nameservers is mangling or blocking packets. > > > > - Kevin > > > _______________________________________________ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users >
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users