False failure in capsforid fallback due to additional rrset ordering

[Alex Zorin]

Hi Wouter,

Some background: The .pl ccTLD currently has some issues with 0x20[1] that causes Unbound to go into capsforid fallback when it encounters one or two nameservers used by pl.

That's not a problem in itself, but I believe Unbound may be occasionally triggering a false positive failure during capsforid fallback. 

I have attached:
- 0001-capsforid-verbose-logging.patch: a verbose printf-debugging patch affecting comparison routines used during capsforid fallback. (Against Unbound 1.9.0rc1).
- unbound-host.log.gz: the output of the unbound-host invocation below that triggers this failure, with the above patch.
- pl.pcap: the packet capture that correlates directly to the unbound-host invocation.
- unbound.conf: the conf file used for the unbound-host invocation.

This is the command that triggers the issue. Please keep in mind you may need to try as many as 10+ times because due to the unlikely selection of the pl nameserver(s) with the 0x20 issue that triggers the fallback in the first place:

    $ unbound-host pie3aq.pl -t caa -d -vvv -C unbound.conf

My hypothesis for what is happening is that Unbound might not performing a canonical sort of the additional RRs, which then triggers the capsforid fail:

  [1548894424] libunbound[5931:0] info: rrset 3 not equal
  [1548894424] libunbound[5931:0] info: canonical basic compare, dname_len: 16 vs 16
  [1548894424] libunbound[5931:0] info: canonical basic compare, flags: 0 vs 0
  [1548894424] libunbound[5931:0] info: canonical basic compare, type: 256 vs 256
  [1548894424] libunbound[5931:0] info: canonical basic compare, rrset_class: 256 vs 256
  [1548894424] libunbound[5931:0] info: canonical basic compare, ttl: 0 vs 0
  [1548894424] libunbound[5931:0] info: canonical basic compare, count: 1 vs 1
  [1548894424] libunbound[5931:0] info: canonical basic compare, rrsig_count: 0 vs 0
  [1548894424] libunbound[5931:0] info: canonical basic compare, trust: 1 vs 1
  [1548894424] libunbound[5931:0] info: canonical basic compare, security: 0 vs 0
  [1548894424] libunbound[5931:0] info: d vs d
  [1548894424] libunbound[5931:0] info: n vs n
  [1548894424] libunbound[5931:0] info: s vs s
  [1548894424] libunbound[5931:0] info: 2 vs 1
  [1548894424] libunbound[5931:0] info: rrset 3 not canonical equal
  [1548894424] libunbound[5931:0] info: Capsforid fallback: getting different replies, failed

In the above, we see that the label "dns1" being compared to "dns2" is what ultimately triggers the capsforid failure.

In the pcap, I believe this refers to a comparison of DNS response 0x00006547 with DNS response 0x000006bd, where in the latter, the ordering of the additional records is:

  dns2.pie3aq.pl: type A, class IN, addr 5.135.61.93
  dns1.pie3aq.pl: type A, class IN, addr 51.75.34.178

and in the former, dns1 comes first.

My very shoddy reading of Unbound's code is that these additional records should first undergo a canonical sort, in which case these messages should be matching under capsforid.

I might be barking entirely up the wrong tree, but your guidance is very much appreciated.

Thanks,
Alex

--

1. https://lists.dns-oarc.net/pipermail/dns-operations/2019-January/018359.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-capsforid-verbose-logging.patch
Type: text/x-patch
Size: 4025 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190130/f6485b80/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unbound-host.log.gz
Type: application/gzip
Size: 44442 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190130/f6485b80/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pl.pcap
Type: application/vnd.tcpdump.pcap
Size: 51184 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190130/f6485b80/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unbound.conf
Type: application/octet-stream
Size: 35415 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190130/f6485b80/attachment.obj>