Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: Content-Disposition: inline X-RT-Interface: Web Subject: Issue resolving "dig txt rs.dns-oarc.net" on BIND 9.12.0rc3 (doesn't exist on 9.12.0rc1) X-Mailer: MIME-tools 5.508 (Entity 5.508) Date: Wed, 07 Feb 2018 21:46:57 +0000 From: cathya@isc.org Content-Transfer-Encoding: binary To: bind9-confidential@isc.org X-RT-Original-Encoding: utf-8 Content-Length: 8079 This is the end of a thread on bind-users regarding problems using the DNS-OARC reply size tester. https://lists.isc.org/pipermail/bind-users/2018-February/099585.html Irrespective of whether the tool will work effectively with newer versions of BIND or not, it is unexpected that a resolver fails to get any answer. Further research suggests that this problem was introduced between 9.12.0rc1 and 9.12.0rc3. -- pasted from bind-users -- I took a look at the ‘resolver’ log channel. I didn’t find any useful information there, just: fetch: rs.dns-oarc.net/TXT fetch: sns-pb.isc.org/A fetch: ns.isc.afilias-nst.info/A fetch: net/DS fetch: dns-oarc.net/DS fetch: net/DNSKEY I started trying different releases and found this query works consistently for me all the way up to bind-9.12.0rc1. As soon as I try bind-9.12.0rc3 the queries start failing. I’m using the exact same config and server for both the working rc1 and not working rc3 (both complied from source). Any thoughts on any differences between RC1 and RC3 that might explain this or any other logs I should be checking? The ‘resolver’ log channel on rc1 (which works) shows: fetch: rs.dns-oarc.net/TXT fetch: sns-pb.isc.org/A fetch: ns.isc.afilias-nst.info/A fetch: net/DS fetch: dns-oarc.net/DS fetch: net/DNSKEY fetch: rs.dns-oarc.net/DS fetch: dns-oarc.net/DNSKEY fetch: rst.x487.rs.dns-oarc.net/TXT fetch: rst.x461.x487.rs.dns-oarc.net/TXT fetch: rst.x466.x461.x487.rs.dns-oarc.net/TXT Looking at the ‘dnssec’ log channel I see this on RC1: validating rs.dns-oarc.net/CNAME: starting validating rs.dns-oarc.net/CNAME: attempting insecurity proof validating rs.dns-oarc.net/CNAME: checking existence of DS at 'net' validating net/DS: starting validating net/DS: attempting positive response validation validating net/DS: keyset with trust secure validating net/DS: verify rdataset (keyid=41824): success validating net/DS: marking as secure, noqname proof not needed validating rs.dns-oarc.net/CNAME: in dsfetched2: success validating rs.dns-oarc.net/CNAME: resuming proveunsecure validating rs.dns-oarc.net/CNAME: checking existence of DS at 'dns-oarc.net' validating dns-oarc.net/DS: starting validating dns-oarc.net/DS: attempting positive response validation validating net/DNSKEY: starting validating net/DNSKEY: attempting positive response validation validating net/DNSKEY: verify rdataset (keyid=35886): success validating net/DNSKEY: marking as secure (DS) validating dns-oarc.net/DS: in fetch_callback_validator validating dns-oarc.net/DS: keyset with trust secure validating dns-oarc.net/DS: resuming validate validating dns-oarc.net/DS: verify rdataset (keyid=25733): success validating dns-oarc.net/DS: marking as secure, noqname proof not needed validating rs.dns-oarc.net/CNAME: in dsfetched2: success validating rs.dns-oarc.net/CNAME: resuming proveunsecure validating rs.dns-oarc.net/CNAME: checking existence of DS at 'rs.dns-oarc.net' validating rs.dns-oarc.net/DS: starting validating rs.dns-oarc.net/DS: attempting negative response validation validating dns-oarc.net/SOA: starting validating dns-oarc.net/SOA: attempting positive response validation validating dns-oarc.net/DNSKEY: starting validating dns-oarc.net/DNSKEY: attempting positive response validation validating dns-oarc.net/DNSKEY: verify rdataset (keyid=20899): success validating dns-oarc.net/DNSKEY: marking as secure (DS) validating dns-oarc.net/SOA: in fetch_callback_validator validating dns-oarc.net/SOA: keyset with trust secure validating dns-oarc.net/SOA: resuming validate validating dns-oarc.net/SOA: verify rdataset (keyid=12093): success validating dns-oarc.net/SOA: marking as secure, noqname proof not needed validating rs.dns-oarc.net/DS: in authvalidated validating rs.dns-oarc.net/DS: resuming nsecvalidate validating rs.dns-oarc.net/NSEC: starting validating rs.dns-oarc.net/NSEC: attempting positive response validation validating rs.dns-oarc.net/NSEC: keyset with trust secure validating rs.dns-oarc.net/NSEC: verify rdataset (keyid=12093): success validating rs.dns-oarc.net/NSEC: marking as secure, noqname proof not needed validating rs.dns-oarc.net/DS: in authvalidated validating rs.dns-oarc.net/DS: looking for relevant NSEC validating rs.dns-oarc.net/DS: nsec proves name exists (owner) data=0 validating rs.dns-oarc.net/DS: resuming nsecvalidate validating rs.dns-oarc.net/DS: nonexistence proof(s) found validating rs.dns-oarc.net/CNAME: in dsfetched2: ncache nxrrset validating rs.dns-oarc.net/CNAME: marking as answer (dsfetched2) validating rst.x476.rs.dns-oarc.net/CNAME: starting validating rst.x476.rs.dns-oarc.net/CNAME: attempting insecurity proof validating rst.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 'net' validating rst.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 'dns-oarc.net' validating rst.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 'rs.dns-oarc.net' validating rst.x476.rs.dns-oarc.net/CNAME: marking as answer (proveunsecure (4)) validating rst.x461.x476.rs.dns-oarc.net/CNAME: starting validating rst.x461.x476.rs.dns-oarc.net/CNAME: attempting insecurity proof validating rst.x461.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 'net' validating rst.x461.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 'dns-oarc.net' validating rst.x461.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 'rs.dns-oarc.net' validating rst.x461.x476.rs.dns-oarc.net/CNAME: marking as answer (proveunsecure (4)) validating rst.x466.x461.x476.rs.dns-oarc.net/TXT: starting validating rst.x466.x461.x476.rs.dns-oarc.net/TXT: attempting insecurity proof validating rst.x466.x461.x476.rs.dns-oarc.net/TXT: checking existence of DS at 'net' validating rst.x466.x461.x476.rs.dns-oarc.net/TXT: checking existence of DS at 'dns-oarc.net' validating rst.x466.x461.x476.rs.dns-oarc.net/TXT: checking existence of DS at 'rs.dns-oarc.net' validating rst.x466.x461.x476.rs.dns-oarc.net/TXT: marking as answer (proveunsecure (4)) And this on RC3: validating rs.dns-oarc.net/CNAME: starting validating rs.dns-oarc.net/CNAME: attempting insecurity proof validating rs.dns-oarc.net/CNAME: checking existence of DS at 'net' validating net/DS: starting validating net/DS: attempting positive response validation validating net/DS: keyset with trust secure validating net/DS: verify rdataset (keyid=41824): success validating net/DS: marking as secure, noqname proof not needed validating rs.dns-oarc.net/CNAME: in dsfetched2: success validating rs.dns-oarc.net/CNAME: resuming proveunsecure validating rs.dns-oarc.net/CNAME: checking existence of DS at 'dns-oarc.net' validating dns-oarc.net/DS: starting validating dns-oarc.net/DS: attempting positive response validation validating net/DNSKEY: starting validating net/DNSKEY: attempting positive response validation validating net/DNSKEY: verify rdataset (keyid=35886): success validating net/DNSKEY: marking as secure (DS) validating dns-oarc.net/DS: in fetch_callback_validator validating dns-oarc.net/DS: keyset with trust secure validating dns-oarc.net/DS: resuming validate validating dns-oarc.net/DS: verify rdataset (keyid=25733): success validating dns-oarc.net/DS: marking as secure, noqname proof not needed validating rs.dns-oarc.net/CNAME: in dsfetched2: success validating rs.dns-oarc.net/CNAME: resuming proveunsecure validating rs.dns-oarc.net/CNAME: checking existence of DS at 'rs.dns-oarc.net' validating rs.dns-oarc.net/CNAME: continuing validation would lead to deadlock: aborting validation validating rs.dns-oarc.net/CNAME: deadlock found (create_fetch) -- /pasted from bind-users -- Might this be due to the following change introduced in BIND 9.12.0rc2: 4859. [bug] A loop was possible when attempting to validate unsigned CNAME responses from secure zones; this caused a delay in returning SERVFAIL and also increased the chances of encountering CVE-2017-3145. [RT #46839] Under the circumstances that we know that the CNAME chain is tool-generated, is the outcome a regression, or something to be expected?