Strange validation failure for

Tony Finch dot at
Thu Apr 24 17:53:56 UTC 2014

We have a couple of recursive servers running 9.9.5 which are persistently
unable to validate, returning SERVFAIL. With debug logging
turned on we get (amongst lots of other things):

24-Apr-2014 16:41:23.087 client ( query (cache) '' approved
24-Apr-2014 16:41:23.087 client ( replace
24-Apr-2014 16:41:23.127 validating @2e4e75b8: A: starting
24-Apr-2014 16:41:23.127 validating @2e4e75b8: A: attempting insecurity proof
24-Apr-2014 16:41:23.127 validating @2e4e75b8: A: checking existence of DS at 'com'
24-Apr-2014 16:41:23.127 validating @2e4e75b8: A: checking existence of DS at ''
24-Apr-2014 16:41:24.114 validating @252fd3f0: DS: starting
24-Apr-2014 16:41:24.114 validating @252fd3f0: DS: attempting positive response validation
24-Apr-2014 16:41:24.114 validating @252fd3f0: DS: keyset with trust secure
24-Apr-2014 16:41:24.114 validating @252fd3f0: DS: verify rdataset (keyid=56657): success
24-Apr-2014 16:41:24.114 validating @252fd3f0: DS: marking as secure, noqname proof not needed
24-Apr-2014 16:41:24.115 validating @2e4e75b8: A: in dsfetched2: success
24-Apr-2014 16:41:24.115 validating @2e4e75b8: A: resuming proveunsecure
24-Apr-2014 16:41:24.115 validating @2e4e75b8: A: checking existence of DS at ''
24-Apr-2014 16:41:24.115 validating @2e4e75b8: A: bad cache hit (
24-Apr-2014 16:41:24.115 error (broken trust chain) resolving '':
24-Apr-2014 16:41:24.117 client ( query failed (SERVFAIL) for at query.c:7005
24-Apr-2014 16:41:24.117 fetch completed at resolver.c:4173 for in 1.028114: broken trust chain/broken trust chain [,referral:1,restart:1,qrysent:1,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:1]

Questions: Why is it attempting an insecurity proof? Why is there a bad
cache hit for one of the DS queries?

With a bit more debugging turned on we see that named is getting a
response from the authoritative server without EDNS and without DNSSEC
(see below). Is it omitting EDNS from its query, and if so why?

rndc flushname on and and all the name servers for doesn't fix it. (If I understand it correctly, in 9.9 flushname
should clear an entry from the bad cache but flushtree does not. The
latter is improved in 9.10.)

It might be nice at this debugging level to log queries as well as
responses, and the source and destination addresses of packets.

24-Apr-2014 17:55:31.395 resquery 126e5060 (fctx 18262460( response
24-Apr-2014 17:55:31.395 received packet:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  62966
;; flags: qr aa; QUESTION: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 2
;               IN      A

;; ANSWER SECTION:        3600    IN      A

;; AUTHORITY SECTION:                3600    IN      NS                3600    IN      NS                3600    IN      NS                3600    IN      NS

;; ADDITIONAL SECTION:            600     IN      A            600     IN      A

f.anthony.n.finch  <dot at>
Lundy: Variable 4, becoming southeast 5 or 6. Slight or moderate. Showers.
Good, occasionally moderate.

More information about the bind-users mailing list