SERVFAIL then proper reply

Unbound
1

I have "often" (I'm not sure how often) a SERVFAIL at the first reply,
then a normal answer immediately after. For instance:

~ % dig -x 216.66.84.42

; <<>> DiG 9.5.1-P2 <<>> -x 216.66.84.42
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18528
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;42.84.66.216.in-addr.arpa. IN PTR

;; Query time: 411 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Jul 3 14:56:28 2009
;; MSG SIZE rcvd: 54

~ % dig -x 216.66.84.42

; <<>> DiG 9.5.1-P2 <<>> -x 216.66.84.42
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34991
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;42.84.66.216.in-addr.arpa. IN PTR

;; ANSWER SECTION:
42.84.66.216.in-addr.arpa. 86392 IN PTR tserv10.par1.ipv6.he.net.

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Jul 3 14:56:36 2009
;; MSG SIZE rcvd: 92

Unbound 1.3.0 on Debian/Linux, no forwarder, using dlv.isc.org.

The log is attached. The first request is at 14:56:28, the second at
14:56:36.

(attachments)

unbound.log.gz (1.6 KB)

2

Hi Stephane,

I think this is a result of a bug I already fixed, which barfed the
security status after taking a query from the cache a second time.

In your logs this seems to happen for in-addr.arpa.dlv.isc.org, which
loses the secure status for its DLV answer, which in turn makes the
DLV lookup error, which generates the servfail. Why the second lookup
then succeeds I do not understand.

I hope the bug is fixed in 1.3.1 (just with release candidate), otherwise I'd like to look at a higher verbosity log for it.

Best regards and thanks for reporting,
    Wouter

3

this worked for me on the first go. Using unbound 1.3.0 with some svn patches.
No forwarder, with dlv.isc.org.

Paul

4

I think this is a result of a bug I already fixed, which barfed the
security status after taking a query from the cache a second time.

In your logs this seems to happen for in-addr.arpa.dlv.isc.org, which
loses the secure status for its DLV answer, which in turn makes the
DLV lookup error, which generates the servfail. Why the second lookup
then succeeds I do not understand.

Oh, just realised my resolver uses dnssec-conf, and will load trust anchors for
all the RIPE zones, so they don't go via DLV.

I hope the bug is fixed in 1.3.1 (just with release candidate), otherwise I'd like to look at a higher verbosity log for it.

1.3.0-1 in fedora should also have that fix incorperated.

Paul

5

a message of 12 lines which said:

this worked for me on the first go. Using unbound 1.3.0 with some svn patches.

My Unbound was 1.3.0 pristine, that may be the difference.