Issue running "dig txt rs.dns-oarc.net" on 9.12

Wed Feb 28 15:01:13 UTC 2018

Thanks for the information Cathy. I've always run the Red Hat provided packages in the past, this is the first time I've ever tried running the newest release direct. Mostly I'm just feeling extra cautious since this is something I've never done before and admittedly I don't know as much about DNS as I should so I really appreciate you taking the time to break down what is happening.

Based on your explanation it sounds like this isn't something I'll ever run into other than this one special case so I'll stop worrying about it.

Thank you!

-Nick

-----Original Message-----
From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Cathy Almond
Sent: Tuesday, February 27, 2018 4:29 AM
To: bind-users at lists.isc.org
Subject: Re: Issue running "dig txt rs.dns-oarc.net" on 9.12

On 22/02/2018 16:44, NNEX Support wrote:
> I'm sorry to keep replying to myself but I believe I've found the line of code that is causing this issue. Looking at validator.c, in the check_deadlock function, 9.12.0rc1 says:
> 
> ...
> 
>                 if (parent->event != NULL &&
>                     parent->event->type == type &&
>                     dns_name_equal(parent->event->name, name) &&
> 
> ...
> 
> 9.12.0rc3 and above says:
> 
> ...
> 
>                 if (parent->event != NULL &&
>                     (parent->event->type == type ||
>                      parent->event->type == dns_rdatatype_cname) &&
>                     dns_name_equal(parent->event->name, name) &&
> 
> ...
> 
> By removing  "parent->event->type == dns_rdatatype_cname)" (and adjusting the rest of the if statement appropriately) the query "dig ns rs.dns-oarc.net" works.
> 
> I see this commit related to this line of code: 
> https://gitlab.isc.org/isc-projects/bind9/commit/2b51d5874c49ac823890b
> 88824290fbf1c18f2cc
> 
> I'm sure this line of code is important, otherwise it wouldn't be there and I don't know enough to be removing random bits of code, so of course I'd never run this in production. Still I want to understand why this is happening and if it’s a bug or me not understanding DNS properly. 

Good sleuthing - though apart from understanding why the query now fails, I don't think there's any code defect that needs to be addressed.
 This line of code belongs with these changes between RC1 and RC3.  They are kinda important (note the CVE reference):

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]

4858.	[security]	Addresses could be referenced after being freed
			in resolver.c, causing an assertion failure.
			(CVE-2017-3145) [RT #46839]

The debug log you pointed to was also specific about why the validation
stopped:

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)

The rs.dns-oarc.net zone is broken because it returns a CNAME for queries at the apex.

Observe the delegation (I'm querying one of the servers auth for
dns-oarc.net):

; <<>> DiG 9.11.2 <<>> +norec +dnssec @64.191.0.65 rs.dns-oarc.net NS ; (1 server found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43571 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 47d4eddbbbde6fd18616a25b5a952d35767788ad0b03038f (good) ;; QUESTION SECTION:
;rs.dns-oarc.net.		IN	NS

;; AUTHORITY SECTION:
rs.dns-oarc.net.	3600	IN	NS	ns00.rs.dns-oarc.net.
rs.dns-oarc.net.	3600	IN	NSEC	rs4.dns-oarc.net. NS RRSIG NSEC
rs.dns-oarc.net.	3600	IN	RRSIG	NSEC 8 3 3600 20180328101103
20180226091103 12093 dns-oarc.net.
floDmByYaxmh+QQWou7PtICj4tnpW6/ea1WzatUfAEMvPOSmm54CJ467
KWpnf5XADFgFrcHOr0gYLlbFVJrwEB5n6R+SvXOTx9zwgva3SY37Vgq8
ZMwdNPdGxmVLOz1Ou5tByfZV2ZLpueF+hBB12wft+wNCysjMuwtx4U2D a64=

;; ADDITIONAL SECTION:
ns00.rs.dns-oarc.net.	3600	IN	A	64.191.0.133
ns00.rs.dns-oarc.net.	3600	IN	AAAA	2620:ff:c000:0:2::133

Then look at the query response for a DS RRset that the BIND validator is receiving from ns00.rs.dns-oarc.net:

; <<>> DiG 9.11.2 <<>> +norec +dnssec @64.191.0.133 rs.dns-oarc.net DS ; (1 server found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61119 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 27, ADDITIONAL: 28

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rs.dns-oarc.net.		IN	DS

;; ANSWER SECTION:
rs.dns-oarc.net.	60	IN	CNAME	rst.x1013.rs.dns-oarc.net.

;; AUTHORITY SECTION:
x1013.rs.dns-oarc.net.	60	IN	NS	ns00.x1013.rs.dns-oarc.net.
x1013.rs.dns-oarc.net.	60	IN	NS	ns01.x1013.rs.dns-oarc.net.
x1013.rs.dns-oarc.net.	60	IN	NS	ns02.x1013.rs.dns-oarc.net.

--- snip (lots of NS RRs) ---

This is a CNAME at the apex of the delegated zone - I can't get NS or SOA RRs either, and that's what the updated validator is unhappy about.

Prior to the changes to stop the potential validation loop (which probably wasn't going to be a loop in this specific instance, but BIND didn't know that), clients using validating BIND to send a reply-size-test query would have 'got away with it'

But no longer.

But since the reply-size tester doesn't work any more anyway with modern BIND, does this matter?

Cathy

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users