bind >> SERVFAIL

by Felipe Ceglia - PY1NB » Tue, 14 Aug 2007 01:31:58 GMT

Hello Bind gurus,

I am running BIND 9.3.3rc2 on a Centos 5 server.

Sometimes I get SERVFAIL results when querying domains. Usually all
those SERVFAILS are related to "lame servers".

I tried to enable debug, but it dindt show anything on syslog:

/usr/sbin/named -u named -d 3 -t /var/named/chroot

I've digged google, but found nothing useful.

Any help will be enourmously appreciated.



==========================================================================
[root@server conf]# dig agencia21.com

; <<>> DiG 9.3.3rc2 <<>> agencia21.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43748
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;agencia21.com. IN A

;; Query time: 477 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug 13 17:23:22 2007
;; MSG SIZE rcvd: 31

named[6374]: lame server resolving 'agencia21.com' (in
'agencia21.com'?): 201.33.18.177#53
named[6374]: lame server resolving 'agencia21.com' (in
'agencia21.com'?): 201.33.18.176#53

==========================================================================




bind >> SERVFAIL

by Kevin Darcy » Tue, 14 Aug 2007 05:11:25 GMT



The zone is delegated to ns1.dnsgeral.com and ns2.dnsgeral.com, but
neither of those nameservers seem to have knowledge of the zone.


- Kevin

bind >> SERVFAIL

by Barry Margolin » Tue, 14 Aug 2007 08:33:58 GMT

In article <f9qftr$30br$ XXXX@XXXXX.COM >,



That's normal. If the caching server can't get a valid result from the
authoritative servers, it has failed.

--
Barry Margolin, XXXX@XXXXX.COM
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

bind >> SERVFAIL

by Felipe Ceglia - PY1NB » Tue, 14 Aug 2007 18:02:19 GMT

(...)


This is strange: my server returns SERVFAIL, while other resolves it:

Thank you.

$ dig agencia21.com

; <<>> DiG 9.3.3rc2 <<>> agencia21.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 19436
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;agencia21.com. IN A

;; Query time: 505 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 14 09:59:30 2007
;; MSG SIZE rcvd: 31

---------------------------------------------------------------------------

$ dig agencia21.com @200.255.253.241

; <<>> DiG 9.3.3rc2 <<>> agencia21.com @200.255.253.241
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12110
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;agencia21.com. IN A

;; AUTHORITY SECTION:
com. 17931 IN NS L.GTLD-SERVERS.NET.
com. 17931 IN NS C.GTLD-SERVERS.NET.
com. 17931 IN NS K.GTLD-SERVERS.NET.
com. 17931 IN NS B.GTLD-SERVERS.NET.
com. 17931 IN NS M.GTLD-SERVERS.NET.
com. 17931 IN NS F.GTLD-SERVERS.NET.
com. 17931 IN NS J.GTLD-SERVERS.NET.
com. 17931 IN NS H.GTLD-SERVERS.NET.
com. 17931 IN NS E.GTLD-SERVERS.NET.
com. 17931 IN NS G.GTLD-SERVERS.NET.
com. 17931 IN NS D.GTLD-SERVERS.NET.
com. 17931 IN NS I.GTLD-SERVERS.NET.
com. 17931 IN NS A.GTLD-SERVERS.NET.

;; Query time: 19 msec
;; SERVER: 200.255.253.241#53(200.255.253.241)
;; WHEN: Tue Aug 14 09:57:39 2007
;; MSG SIZE rcvd: 255

------------------------------------------------------------------------

bind >> SERVFAIL

by Chris Buxton » Wed, 15 Aug 2007 01:20:08 GMT

No, the second server did not find the answer. Instead, it gave you a
referral - note the lack of an "ra" flag in the header. The second
server is not willing to do recursion for you, and therefore did not
try to resolve the final answer to your request, whereas the first
server did, failed due to lame delegations, and returned a failure
message.

Chris Buxton
Men & Mice

bind >> SERVFAIL

by bsfinkel » Wed, 10 Sep 2008 02:54:45 GMT

n response to a posting "Re: Two DNS Servers inside a firewall"
Mark Andrews wrote on September 5:



I have a user who cannot resolve

www.flickr.com

The name server I am querying is 9.5.0-P1 (to be updated to a patched
P2 tomorrow). When I query at one of the autoritative name servers,
I get:

oberon% dig www.flickr.com @ns1.yahoo.com.

; <<>> DiG 8.3 <<>> www.flickr.com @ns1.yahoo.com.
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 5
;; QUERY SECTION:
;; www.flickr.com, type = A, class = IN

;; ANSWER SECTION:
www.flickr.com. 5M IN CNAME www.flickr.vip.mud.yahoo.com.
www.flickr.vip.mud.yahoo.com. 15M IN A 68.142.214.24

;; AUTHORITY SECTION:
mud.yahoo.com. 2D IN NS ns1.yahoo.com.
mud.yahoo.com. 2D IN NS ns2.yahoo.com.
mud.yahoo.com. 2D IN NS ns3.yahoo.com.
mud.yahoo.com. 2D IN NS ns4.yahoo.com.
mud.yahoo.com. 2D IN NS ns5.yahoo.com.

;; ADDITIONAL SECTION:
ns1.yahoo.com. 2D IN A 66.218.71.63
ns2.yahoo.com. 2D IN A 68.142.255.16
ns3.yahoo.com. 2D IN A 217.12.4.104
ns4.yahoo.com. 2D IN A 68.142.196.63
ns5.yahoo.com. 30M IN A 119.160.247.124

;; Total query time: 64 msec
;; FROM: oberon.it.anl.gov to SERVER: ns1.yahoo.com. 66.218.71.63
;; WHEN: Tue Sep 9 13:25:03 2008
;; MSG SIZE sent: 32 rcvd: 257

oberon%

but a general query results in SERVFAIL:

oberon% dig www.flickr.com

; <<>> DiG 8.3 <<>> www.flickr.com
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;; www.flickr.com, type = A, class = IN

;; Total query time: 9 msec
;; FROM: oberon.it.anl.gov to SERVER: default -- 146.139.254.5
;; WHEN: Tue Sep 9 13:22:46 2008
;; MSG SIZE sent: 32 rcvd: 32

oberon%

I notice that when I query one of the authoritative name servers I
get

;; ANSWER SECTION:
www.flickr.com. 5M IN CNAME www.flickr.vip.mud.yahoo.com.
www.flickr.vip.mud.yahoo.com. 15M IN A 68.142.214.24

;; AUTHORITY SECTION:
mud.yahoo.com. 2D IN NS ns1.yahoo.com.
mud.yahoo.com. 2D IN NS ns2.yahoo.com.
mud.yahoo.com. 2D IN NS ns3.yahoo.com.
mud.yahoo.com. 2D IN NS ns4.yahoo.com.
mud.yahoo.com. 2D IN NS ns5.yahoo.com.

Is the SERVFAIL because I queried

flickr.com

and the authority is

mud.yahoo.com ?

If not, then why am I getting SERVFAIL? Thanks.
----------------------------------------------------------------------
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone: +1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 222, Room D209 Internet: XXXX@XXXXX.COM
Arg

bind >> SERVFAIL

by Kevin Darcy » Wed, 10 Sep 2008 06:28:45 GMT

XXXX@XXXXX.COM wrote:
No, that's perfectly normal. CNAMEs point to names in other domains all
the time. The only thing slightly unusual here is that the nameservers
for flickr.com also happen to be authoritative for the zone which
contains the target of the alias (www.flickr.vip.mud.yahoo.com) and are
therefore able to provide the A record without any further need for
referral-chasing. But that's _relatively_ normal too.
Does a dig +trace for www.flickr.com work?

If you have port and/or source-address restrictions in named.conf, make
sure you're using the same port and/or source-address for your test
queries. Otherwise it's not really a valid test.

If you're still getting SERVFAIL for your regular queries, but not for
your test queries, dump your cache and see if maybe you're trying to use
some bad/stale/obsolete cached glue/referral data in order to resolve
the name.


- Kevin



bind >> SERVFAIL

by bsfinkel » Wed, 10 Sep 2008 23:02:39 GMT

wrote:


And Kevin Darcy replied:

I did an "rndc dumpdb", and I did not see any stale glue in the cache.
But I am not sure exactly for what to search.

I have no port and/or source-address restrictions in named.conf.
When I do the "dig www.flickr.com" on my two external DNS servers
(both 9.5.0-P2 with Jinmei's dumpdb patch) the queries succeed.
When I issue the command on my two internal DNS servers (one the
patched -P2 and one still 9.5.0-P1), both servers give SERVFAIL.
I looked at the source code (query.c) yesterday, and there are 23
cases for SERVFAIL. Before some of the SERVFAIL lines I see

CTRACE("...");

How do I enable this tracing? Or is there another way to determine
which SERVFAIL code is matching in query.c?
----------------------------------------------------------------------
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone: +1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 222, Room D209 Internet: XXXX@XXXXX.COM
Argonne, IL 60439-4828 IBMMAIL: I1004994


bind >> SERVFAIL

by Paul Vixie » Thu, 11 Sep 2008 00:52:55 GMT

>>> I have a user who cannot resolve
...

<A HREF=" http://www.youtube.com/watch?v=rSBNT5WKizg ">Hairball!</A>
--
Paul Vixie

bind >> SERVFAIL

by Paul Vixie » Thu, 11 Sep 2008 01:04:51 GMT

i believe that the hard part of the traversal for www.flickr.com is:

; <<>> DiG 9.4.1-P1 <<>> @ns3.yahoo.com www.flickr.vip.mud.yahoo.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41226
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.flickr.vip.mud.yahoo.com. IN A

;; ANSWER SECTION:
www.flickr.vip.mud.yahoo.com. 900 IN A 68.142.214.24

;; AUTHORITY SECTION:
mud.yahoo.com. 172800 IN NS ns1.yahoo.com.
mud.yahoo.com. 172800 IN NS ns2.yahoo.com.
mud.yahoo.com. 172800 IN NS ns3.yahoo.com.
mud.yahoo.com. 172800 IN NS ns4.yahoo.com.
mud.yahoo.com. 172800 IN NS ns5.yahoo.com.

;; ADDITIONAL SECTION:
ns1.yahoo.com. 172800 IN A 66.218.71.63
ns2.yahoo.com. 172800 IN A 68.142.255.16
ns3.yahoo.com. 172800 IN A 217.12.4.104
ns4.yahoo.com. 172800 IN A 68.142.196.63
ns5.yahoo.com. 1800 IN A 119.160.247.124

;; Query time: 153 msec
;; SERVER: 217.12.4.104#53(217.12.4.104)
;; WHEN: Wed Sep 10 16:58:43 2008
;; MSG SIZE rcvd: 232

because this is a yahoo.com nameserver which is simultaneously answering
and delegating. this is a sensible thing for it to do since it's
authoritative for both yahoo.com and mud.yahoo.com, but it's also an
insensible thing for it to do since the downward referral trumps the
non-empty answer section. (it would also trump a non-empty answer
section which would otherwise be seen as a NODATA response.) i'm not
throwing stones, since this is ambiguous in the spec, and for all i know
it's what BIND9 would do. but my own toy traversal tool spake thusly:

response from 217.12.4.104 (ns3.yahoo.com) is NOERROR (1 1 5 5) (AA)
down-referral
downward referral trumps nonempty ANSWER
cache modified by AUTHORITY
cache unmodified by ADDITIONAL
upstream transaction complete (tryagain)
requires iteration (#3)

and the complexity thus revealed may behoove yahoo to put the mud.yahoo.com
zone separate nameservers (or separate views) from the yahoo.com zone.
--
Paul Vixie

bind >> SERVFAIL

by Chris Buxton » Thu, 11 Sep 2008 06:38:07 GMT

----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A name server may be authoritative for both a zone and its subzone.
Your traversal tool is wrong - the server is giving an authoritative
answer, not a downward referral. Your tool should consider an
authoritative answer as trumping the authority section, if there is
any conflict.

It is common for an authoritative answer to contain the NS records of
the zone containing the answer, along with any known addresses for
those servers.

Chris Buxton
Professional Services
Men & Mice

On Sep 10, 2008, at 10:04 AM, Paul Vixie wrote:


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjITE8ACgkQ0p/8Jp6Boi3wgQCfQe8ybx0sENKX80aIn2M1k5tL
z7UAoJBGxp/JuR/2xEkTl+hS2SqZT1F5
=bpSG
-----END PGP SIGNATURE-----


bind >> SERVFAIL

by Paul Vixie » Thu, 11 Sep 2008 07:26:02 GMT

> From: Chris Buxton < XXXX@XXXXX.COM >

chris, i'm not sure you read my earlier statement. i will try again,
differently. there are many ambiguities in the dns protocol specification
and this is one of them. the meaning of (AA && ANCOUNT==0) is sometimes
that there are no records of type=QTYPE and sometimes that there is a zone
cut between the zone whose server you queried and the zone that contains
your data, and to disambiguate you have to look at the authority section
to see if there are some NS RRs whose owner names are below the zone whose
server you were querying (in which case you know (AA && ANCOUNT==0) means
it's a delegation) or at the zone you were querying (in which case (AA &&
ANCOUNT==0) means that there are no records of type==QTYPE).

in preparing my traversal tool many things dawned on me since i did it from
memory and without reference to any RFC (except RFC 2671 which i had to refer
to and which i found to be badly written in the extreme). one of the dawnings
was that (AA && ANCOUNT>0) actually presents the same ambiguity, since many
servers will provide an answer if QTYPE=NS even though we all know from the
years spent on DNSSEC that NS RRs are only authoritative in the child zone.
therefore my traversal tool looks first to see if there is a delegation (which
means a non-empty authority section containing NS RRs whose owners are below
the zone whose servers i'm querying, also called "the bailiwick", and if
these are present, then the delegation is followed, and the answer, whether
empty or not, is ignored.

this is not the only possible way to interpret the ambiguities of RFC 1034
and RFC 1035, but i like it since it helps work around various
misconfigurations which have in the past caused me to cache bad data. now,
the server isn't doing the wrong thing, but the server operator had better
be prepared to accept the same query a second time. the real problem, if
there is a problem, is that a server for both a zone and its child, has no
way to know what bailiwick the resolver has iterated down to. there is no
fix for the server absent this important information.


thanks for explaining that.

bind >> SERVFAIL

by Chris Buxton » Thu, 11 Sep 2008 08:38:21 GMT

----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 10, 2008, at 4:26 PM, Paul Vixie wrote:

I thought I had. It appeared to me you had made a mistake. Perhaps I
read it wrong; I'm willing to be corrected. However, I have had
occasion to correct your thinking once before...


an NXRRSet (aka no data) response


Really? I've never seen a referral marked with the aa flag. (But you
obviously have more years of experience than I.) I thought it was
pretty clear in the RFC that a referral does not constitute an
authoritative answer - it's neither authoritative nor an answer.

Can you point to a name server version that gives a pure referral with
the aa flag set?


Again, I thought aa was supposed to be reserved for (final) answers.
Now granted I've seen the aa flag on answers from resolvers when the
answer did not come from cache, but that's a different issue. If you
send an iterative query and the response has aa set, it should be both
authoritative and an answer (not a referral).


Right, the NXRRSet response.


I'll defer to the opinion of the author, but I've seen worse. The
RFC's describing IDNA, ACE, and punycode, for example, are completely
opaque to me.


Can you point to a name server software version that marks delegation
NS records as authoritative even when specifically asked for them? I
would call that a protocol violation. I've seen them go in the answer
section (BIND 8), and I've seen them put in the authority section
(BIND 9), but I've never seen them marked with aa.


Hmm...

If we don't allow below-bailiwick assertions of authority in an
authoritative answer, then the resolver has to consider it a
delegation and (effectively) re-send the query (which then requires
that the NS records be accurate...). If we do, then if a broken name
server sets aa for a referral, we have a problem. However, the damage
is limited to the zones served by that server and the descendants of
those zones.

However, let's suppose that we consider it a delegation and resend the
query - in this case, the query goes to one of the same servers as the
parent zone. You had described this as "the hard part of the
traversal"; I don't see how throwing an extra query into the recursion
process would result in a SERVFAIL response.

In fact, a BIND 9.4.x resolver on my laptop is able to look up www.flickr.com/IN/A
just fine. I don't have 9.5 installed to test with, but unless it's
doing something different in the resolver algorithm, I would guess
this is a configuration, resource, or network/routing/firewall issue
for Barry.


Exactly. The responding server simply sends the best answer it can
make from available data.

This sounds like you're arguing against including NS records in the
authority section of an answer (as opposed to a referral), because it
can confuse the resolver. This is the default behavior of at least one
non-BIND name server - an authoritative positive answer has just an
answer section.

Chris Buxton
Professional Services
Men & Mice

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjIaH0ACgkQ0p/8Jp6Boi2KMgCfVJQnjaOF2bim6VnceggslBIq
J5gAn0cOTSvPwaEKKtGIncxMIo1q3pIT
=RRty
-----END PGP SIGNATURE-----


bind >> SERVFAIL

by Paul Vixie » Thu, 11 Sep 2008 09:40:04 GMT

gt; Really? I've never seen a referral marked with the aa flag. (But you

load balancers do funny things.


not offhand. i ran into them when coding my tool, and coded around them.


it is. supposed to be, that is.


i wish you'd stop calling it that. i added the nxrrset rcode in RFC 2136
but it is only applicable to updates. if you mean ANCOUNT==0, say so.


RFC 2671 seemed perfectly adequate to me as its author. it wasn't until
years later than i tried to implement EDNS0 using that document as my
reference that its many shortcomings flowed in neon.


try bind4.8 i think. or the microsoft NT 3.51 resource kit. or many load
balancers. it's only a protocol "violation" if the other guy can't and also
won't work around it.


yes. which works, by the way.


i don't know that it is the cause of this servfail, only that it's
suspicious based on the output of my toy resolver in "trace" mode.


i am sure that if bind had a problem looking up flickr, it would be on the
front page of every newspaper, etc. so i agree that this is likely to be
some kind of middlebox issue. but possibly a data dependent middlebox issue.


i'm not arguing that the server should do anything differently. i just think
server operators should be prepared for some extra queries when they do this.


bind >> SERVFAIL

by bsfinkel » Thu, 11 Sep 2008 22:12:44 GMT

Chris Buxton < XXXX@XXXXX.COM > wrote in reply:



I am not including the entire thread, as it is long. I have not read
this thread in detail (especially the dialog between Paul Vixie and
Chris Buxton) because it will take me some time to analyze what is
being said about the RFCs. With BIND 9.5.0-P1 the query

dig www.flickr.com

sometimes succeeded and sometimes produced SERVFAIL. I know it
sometimes succeeded because some of my queries returned non-AA info
from the DNS cache. With the 5- and 15-minute TTLs on the "CNAME" and
"A" records, the cache was cleared relatively quickly. When I had
installed 9.5.0-P2 with Jinmei's "rndc dumpdb" patch on three of my
four nameservers, I could not get SERVFAIL on the three running -P2,
but I did get SERVFAIL on the one still running -P1. So, I quickly
updated that fourth server. I ran few queries after that point, as
the query seemed to be working. I just ran queries on my two internal
servers, and I got the answers I expected (one answer from the cache
and one with full TTLs).

I have not looked at the code. Is there anything in the -P2 code
that would explain why the -P2 queries do not fail, based on the
analysis of Paul Vixie? Does -P2 do anything different in deciding
which ADDITIONAL information to trust and cache? Thanks.
----------------------------------------------------------------------
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone: +1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 222, Room D209 Internet: XXXX@XXXXX.COM
Argonne, IL 60439-4828 IBMMAIL: I1004994

Similar Threads

1. [DNSSEC] SERVFAIL when resolving ".gov" through DLV

I get a SERVFAIL when trying to resolve ".gov":

% dig +dnssec @127.0.0.1 SOA gov.

; <<>> DiG 9.5.1-P1 <<>> +dnssec @127.0.0.1 SOA gov.
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54920
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;gov.				IN	SOA

;; Query time: 784 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May  5 20:31:54 2009
;; MSG SIZE  rcvd: 32

This is a BIND 9.5.1-P1, Debian package. It is configured to use ISC's
DLV:

        dnssec-enable yes;
        dnssec-lookaside . trust-anchor dlv.isc.org.; 

Other signed TLD such as ".cz" or ".pr" creates no problems.

With Unbound, which also uses the same DLV, things seem to work so I
suspect a BIND bug. Restarting the name server does not seem to help.

Here is the log:

05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: starting
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: looking for DLV
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: plain DNSSEC returns unsecure (.): looking for DLV
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: looking for DLV gov.dlv.isc.org
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: DLV gov found
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: dlv_validator_start
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: restarting using DLV
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: attempting positive response validation
05-May-2009 20:29:50.425 dnssec: info: validating @0x7ff090d763d0: gov SOA: no valid signature found
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: falling back to insecurity proof
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: insecurity proof failed
05-May-2009 20:29:50.425 dnssec: debug 3: validator @0x7ff090d763d0: dns_validator_destroy
_______________________________________________
bind-users mailing list
 XXXX@XXXXX.COM 
https://lists.isc.org/mailman/listinfo/bind-users

2. 9.5.0-P1: out of memory error - SERVFAIL

3. bad udp cksum ServFail Error

I have Bind 9.5 p1 running RHEL4 running slave. The Slave is configured with
allow-update-forwarding { any; };.
When I do a ipconfig /registerdns, that does not seems to be updating
master. I think the slave is trying to forward the DDNS traffic to master,
but somehow it seems to failing. The same Windows host works when directly
pointed to Master.

The tcpdump shows [bad udp cksum 8426!]  53702 ServFail q: at the bottom.

I am not sure why it creates bad check sum. Could you please help me
resolve?

Thank you very much!!

~LA



4. bind 9 -> unexpected RCODE (SERVFAIL) resolving

5. Frequent SERVFAIL: "nameservers now above QDOMAIN" (BIND 9.5.0-P2)

6. Frequent SERVFAIL: 'nameservers now above QDOMAIN' (BIND 9.5.0-P2)

7. nameserver not responding (servfail)

	I have a standard debian bind9 installation. It is on a 
virtual server, so it is possible ram and disk are a bit tight, but 
the box is doing very little else apart from running bind currently. 
It is serving a bunch of domain names, about 60, a lot of them from 
zone files I've generated with a script.
	It loads all domains fine on startup, and sends and receives 
notifies, but any attempts to lookup domains from the server itself 
seem to fail, returning servfail.
	Nothing in the logs. I've tried turning debugging on, didn't 
seem to help, I might be doing it wrong.
	Every so often I can coax it into temporary life, with 
various voodoo methods, but nothing seems to work consistently or for 
long. I suspect I am running out of some resource, but what?
	Cheers
		David
_______________________________________________
bind-users mailing list
 XXXX@XXXXX.COM 
https://lists.isc.org/mailman/listinfo/bind-users

8. Negative caching SERVFAIL responses