Unbound returns invalid response? NODATA without SOA

Unbound
1

Hello.

I use Unbound as a forwarder for BIND and see frequent errors, where
BIND won't accept some answers from Unbound and I wonder which of the
two is at fault. I think it's a bug in Unbound:

named[15751]: DNS format error from 85.10.240.249#53 resolving 73.84.in-addr.arpa/DS for client 127.0.0.1#33864: invalid response
named[15751]: error (FORMERR) resolving '73.84.in-addr.arpa/DS/IN': 85.10.240.249#53
named[15751]: client 127.0.0.1#33864: query failed (SERVFAIL) for 73.84.in-addr.arpa/IN/DS at query.c:4671

The server runs Unbound 1.4.0 with 0x20, harden-glue and
harden-referral-path enabled.

Client is BIND 9.7.0b3 with "edns-udp-size 512". I know, DNSSEC requires
at least EDNS@1200. Unfortunately, packet filters at both my mobile
broadband providers still disagree and drop UDP DNS responses larger
than 512 bytes.

Unbound returns a cached answer containing only one NSEC record and no
SOA, but does not set the truncation bit:

# dig +dnssec +cdflag +bufsize=512 73.84.in-addr.arpa ds @85.10.240.249

; <<>> DiG 9.7.0b3 <<>> +dnssec +cdflag +bufsize=512 73.84.in-addr.arpa ds @85.10.240.249
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22003
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;73.84.in-addr.arpa. IN DS

;; AUTHORITY SECTION:
73.84.in-addr.arpa. 7079 IN NSEC 74.84.in-addr.arpa. NS RRSIG NSEC
73.84.in-addr.arpa. 7079 IN RRSIG NSEC 5 4 7200 20100106163918 20091207163918 11541 84.in-addr.arpa. HxMJQMC0cn3iigPd3f16I0qP0td/pSU9QCgeiJ0IrIY96isdnfpFiDVy NY+HWaiJPhxfCb+X/kT5GHTrLOlfPGeGmcbxJgoeV3xba3tJo2MSamna wbfvR02rbcVmFrB8OAhW0z+JXFUT9hDFJPVGrbszQBM2TFtNWGz6JtDM Q73GowBcnQ8pkhv344G00SuOCnhTTXxF

;; Query time: 50 msec
;; SERVER: 85.10.240.249#53(85.10.240.249)
;; WHEN: Mon Dec 7 21:30:17 2009
;; MSG SIZE rcvd: 284

My first theory was that Unbound for some reason only caches a small
part of the answer because of the client's restriction to 512 byte
responses.

After a restart, though, Unbound sets TC and returns the parent SOA,
even if queried with EDNS@512:

# dig +ignore +dnssec +cdflag +bufsize=512 73.84.in-addr.arpa ds @85.10.240.249

[...]

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3226
;; flags: qr tc rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

[...]

;; AUTHORITY SECTION:
84.in-addr.arpa. 7200 IN SOA ns-pri.ripe.net. dns-help.ripe.net. 2009120781 3600 7200 1209600 7200
84.in-addr.arpa. 7200 IN RRSIG SOA 5 3 172800 20100106183919 20091207183919 11541 84.in-addr.arpa. ujrFsPTsU4CecJXxrPxtPDyzW/7begzfOwgsfMMaYBXwfNkb0k3avBbe +d8NXQNA2VdnBVO5O8tUxcSe7M/ECtYzNll3Yil+5gaDyRcYi9QfSjLD +DzEPZV5eUJv8CjHKxVhRLCvxO4llXYK5FvThLsS91PGbNC5DcW6QfTF ViRe1+QYaYRP/T9ORi/3cy8uqlak3uAU

Is the SOA record required for NODATA responses?

Hauke.

2

Hi Hauke,

Thanks for the report, I can reproduce this behaviour in unbound. I did
not realize that BIND complains so badly about this. It is something
used internally in unbound to speed things up. It seems that other
validators cannot cope with it.

Best regards,
   Wouter

3

Hi Hauke,

Fix is in svn r1932. It paradoxically may speed up unbound as it needs
to allocate less memory during validation of a chain of trust. In your
setup, it may be the opposite as it has to generate network queries to
chase after a SOA record to return to the client.

Best regards,
   Wouter

4

W.C.A. Wijngaards wrote:

Fix is in svn r1932.

Thank you, Wouter. I haven't seen any more errors from BIND after the
update.

In your
setup, it may be the opposite as it has to generate network queries to
chase after a SOA record to return to the client.

That should not be much of a problem. The latencies incurred by TCP
queries over flakey GPRS probably outweigh any additional request done
by the forwarder.

Hauke.