Issue running "dig txt" on 9.12

NNEX Support support at
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!


-----Original Message-----
From: bind-users [mailto:bind-users-bounces at] On Behalf Of Cathy Almond
Sent: Tuesday, February 27, 2018 4:29 AM
To: bind-users at
Subject: Re: Issue running "dig txt" 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" works.
> I see this commit related to this line of code: 
> 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

validating checking existence of DS at ''
validating continuing validation would lead to
deadlock: aborting validation
validating deadlock found (create_fetch)

The 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

; <<>> DiG 9.11.2 <<>> +norec +dnssec @ 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

; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 47d4eddbbbde6fd18616a25b5a952d35767788ad0b03038f (good) ;; QUESTION SECTION:
;		IN	NS

;; AUTHORITY SECTION:	3600	IN	NS	3600	IN	NSEC NS RRSIG NSEC	3600	IN	RRSIG	NSEC 8 3 3600 20180328101103
20180226091103 12093
ZMwdNPdGxmVLOz1Ou5tByfZV2ZLpueF+hBB12wft+wNCysjMuwtx4U2D a64=

;; ADDITIONAL SECTION:	3600	IN	A	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

; <<>> DiG 9.11.2 <<>> +norec +dnssec @ 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

; EDNS: version: 0, flags:; udp: 4096
;		IN	DS



--- 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?


Please visit to unsubscribe from this list

bind-users mailing list
bind-users at

More information about the bind-users mailing list