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

[NNEX Support]

I'm sure I'm doing something wrong, but for the life of me I can't figure out what. I'm running named 9.12 in a simple recursive setup (built from source on CentOS 7).

In named.conf I've set:
dnssec-enable yes;
dnssec-validation auto;

When I try to run "dig txt rs.dns-oarc.net" I get SERVFAIL. The logs show:

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)
Jan 26 15:06:59 red named[3036]: no valid RRSIG resolving 'rs.dns-oarc.net/TXT/IN': 64.191.0.133#53

However if I run "dig txt rs.dns-oarc.net +trace" and then "dig txt rs.dns-oarc.net" the query completes as expected. It continues to complete as expected until I restart named.

If I alter named.conf to say
dnssec-enable yes;
dnssec-validation yes;

The running "dig txt rs.dns-oarc.net" works immediately, but of course that breaks verification of the root zone, so DNSSEC is worthless.

My named.conf is super simple:

key "rndc-key" {
algorithm hmac-sha256;
secret "$KEY";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
acl "NNEX" {
127.0.0.1;
aaa.bbb.ccc.0/22;
};
options {
listen-on port 53 { 127.0.0.1; };
listen-on port 53 { aaa.bbb.ccc.d; };
directory "/var/named";
dnssec-enable yes;
dnssec-validation auto;
allow-recursion { nnex; };
allow-query { nnex; };
recursion yes;
};
logging {
channel dnssec_log {
file "/var/log/dnssec.log";
severity debug 3;
};
category dnssec { dnssec_log; };
};

Thank you,

-Nick

[Matthew Pounsett]

On 26 January 2018 at 16:23, NNEX Support <sup...@nnex.net> wrote:

I'm sure I'm doing something wrong, but for the life of me I can't figure out what. I'm running named 9.12 in a simple recursive setup (built from source on CentOS 7).

 

[...]

 

When I try to run "dig txt rs.dns-oarc.net" I get SERVFAIL. The logs show:

[...]

 

However if I run "dig txt rs.dns-oarc.net +trace" and then "dig txt rs.dns-oarc.net" the query completes as expected. It continues to complete as expected until I restart named.

There's an insecure delegation (NS set, and NSEC proving the nonexistence of a DS set) from dns-oarc.net to rs.dns-oarc.net.  However, there's disagreement between the parent and child about what name servers actually serve rs.dns-oarc.net, and at least some of them are refusing to answer TCP.  It's likely your recursive server is, for whatever reason, being drawn to the ones failing to respond, and not getting good data elsewhere fast enough to answer your query.

<http://dnsviz.net/d/rs.dns-oarc.net/WbCr7w/dnssec/>

A bad interaction of timeouts would explain why you get SERVFAIL on the first query, and answers on subsequent queries.  Your first one fails to get a response in time and the recursive server responds with SERVFAIL, but the back-end queries continue and eventually the local cache is populated.  When you come back and ask again, the answers are there waiting for you, requiring no upstream queries.

"dig txt rs.dns-oarc.net +trace" goes to your local recursive DNS server to get the NS set for the root zone, and then proceeds to query authoritative servers directly for everything else.  It's probably not having any effect on what you're seeing.  Simply doing "dig txt rs.dns-oarc.net" a second time a few seconds later without the +trace query would probably give you the exact same result.

You can track this if you turn on and examine the 'resolver' logging channel in your recursive name server.  

[NNEX Support]

Good thought but no luck, it doesn’t matter how many times I run “dig txt rs.dns-oarc.net” or how long I wait it continues to SERVFAIL until I run "dig txt rs.dns-oarc.net +trace" Interestingly I've found that running "dig txt dns-oarc.net +trace" isn't enough to fix it, I actually have to run "dig txt rs.dns-oarc.net +trace" before things start working.

[...]

There's an insecure delegation (NS set, and NSEC proving the nonexistence of a DS set) from dns-oarc.net to rs.dns-oarc.net. However, there's disagreement between the parent and child about what name servers actually serve rs.dns-oarc.net, and at least some of them are refusing to answer TCP. It's likely your recursive server is, for whatever reason, being drawn to the ones failing to respond, and not getting good data elsewhere fast enough to answer your query.

[...]

I agree, from my limited understanding this seems to describe what is happening well. The thing I'm wondering is why? I'm running older visions of named (9.9.4, yum provided RPM on CentOS 6) that seem immune to this issue. I've been digging through release notes and can't find any setting that has changed between the versions that might explain it (I know 9.9.4 to 9.12 is a big jump, so I'm sure I'm missing something)

Thank you!

-Nick

[Matthew Pounsett]

On 27 January 2018 at 16:24, NNEX Support <sup...@nnex.net> wrote:

Good thought but no luck, it doesn’t matter how many times I run “dig txt rs.dns-oarc.net” or how long I wait it continues to SERVFAIL until I run "dig txt rs.dns-oarc.net +trace" Interestingly I've found that running "dig txt dns-oarc.net +trace" isn't enough to fix it, I actually have to run "dig txt rs.dns-oarc.net +trace" before things start working.

The reason digging against dns-oarc.net doesn't fix rs.dns-oarc.net is because they're different zones.

I'm not sure why a +trace would have anything to do with what your resolver does, since dig only talks to it to get the root NS set.  Again, I suggest you check the 'resolver' logging channel on your recursive resolver.

I agree, from my limited understanding this seems to describe what is happening well. The thing I'm wondering is why? I'm running older visions of named (9.9.4, yum provided RPM on CentOS 6) that seem immune to this issue. I've been digging through release notes and can't find any setting that has changed between the versions that might explain it (I know 9.9.4 to 9.12 is a big jump, so I'm sure I'm missing something)

The only thing I can think of that has changed in that time, which has ever caused me query issues, is the addition of DNS cookies in the default query.  Some broken authoritative servers will incorrectly respond with things like FORMERR when they see an EDNS option they don't recognize.  I doubt DNS-OARC is running such a name server, but I haven't looked to see.

[Matthew Pounsett]

On 27 January 2018 at 19:11, Matthew Pounsett <ma...@conundrum.com> wrote:

The only thing I can think of that has changed in that time, which has ever caused me query issues, is the addition of DNS cookies in the default query.  Some broken authoritative servers will incorrectly respond with things like FORMERR when they see an EDNS option they don't recognize.  I doubt DNS-OARC is running such a name server, but I haven't looked to see.

Serves me right for not actually going any looking at this sooner.. and for some reason I failed to recognize the name when I saw it.   rs.dns-oarc.net is the DNS-OARC response size tester.  The server synthesizes a series of large responses via a CNAME chain when you look up that TXT record, designed to test your recursive server's ability to handle large responses.  I'm getting similar failure behaviour from Google Public DNS that you're seeing in 9.12, but I'm not seeing it from my 9.11 recursive server (it works on the first try).

; <<>> DiG 9.11.2 <<>> IN TXT rs.dns-oarc.net @8.8.8.8

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63546

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 512

;; QUESTION SECTION:

;rs.dns-oarc.net. IN TXT

;; Query time: 4373 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Sat Jan 27 19:20:21 EST 2018

;; MSG SIZE  rcvd: 44

; <<>> DiG 9.11.2 <<>> IN TXT rs.dns-oarc.net @8.8.8.8

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29585

;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 512

;; QUESTION SECTION:

;rs.dns-oarc.net. IN TXT

;; ANSWER SECTION:

rs.dns-oarc.net. 1 IN CNAME rst.x4090.rs.dns-oarc.net.

rst.x4090.rs.dns-oarc.net. 58 IN CNAME rst.x4058.x4090.rs.dns-oarc.net.

rst.x4058.x4090.rs.dns-oarc.net. 57 IN CNAME rst.x4064.x4058.x4090.rs.dns-oarc.net.

rst.x4064.x4058.x4090.rs.dns-oarc.net. 56 IN TXT "74.125.179.74 DNS reply size limit is at least 4090"

rst.x4064.x4058.x4090.rs.dns-oarc.net. 56 IN TXT "74.125.179.74 sent EDNS buffer size 4096"

rst.x4064.x4058.x4090.rs.dns-oarc.net. 56 IN TXT "Tested at 2018-01-28 00:21:16 UTC"

;; Query time: 857 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Sat Jan 27 19:21:16 EST 2018

;; MSG SIZE  rcvd: 279

If you want to understand why your resolver is failing, again I'd have a look at the 'resolver' log channel.  It should have some detail about what's resulting in the SERVFAIL message. 

[Cathy Almond]

The DNS-OARC reply size tester doesn't work with versions of BIND that
are 9.10 and newer. This is because of the new probing process that we
implemented that should be more resilient. But it does unfortunately
'break' getting sane results from the DNS-OARC reply size tester.

https://www.dns-oarc.net/oarc/services/replysizetest
(which does now contain as link to the article below)

https://kb.isc.org/article/AA-01350/0/Testing-authoritative-server-support-for-EDNS-and-large-UDP-buffer-sizes-in-BIND-9.10.html

But as for why you're not getting responses at all - that'd be something
else.

On 28/01/2018 00:32, Matthew Pounsett wrote:
>
>
> On 27 January 2018 at 19:11, Matthew Pounsett <ma...@conundrum.com

> <mailto:ma...@conundrum.com>> wrote:
>
> The only thing I can think of that has changed in that time, which
> has ever caused me query issues, is the addition of DNS cookies in
> the default query.  Some broken authoritative servers will
> incorrectly respond with things like FORMERR when they see an EDNS
> option they don't recognize.  I doubt DNS-OARC is running such a
> name server, but I haven't looked to see.
>
> Serves me right for not actually going any looking at this sooner.. and
> for some reason I failed to recognize the name when I saw it. 

>  rs.dns-oarc.net <http://rs.dns-oarc.net> is the DNS-OARC response size

> tester.  The server synthesizes a series of large responses via a CNAME
> chain when you look up that TXT record, designed to test your recursive
> server's ability to handle large responses.  I'm getting similar failure
> behaviour from Google Public DNS that you're seeing in 9.12, but I'm not
> seeing it from my 9.11 recursive server (it works on the first try).
>
>

> ; <<>> DiG 9.11.2 <<>> IN TXT rs.dns-oarc.net <http://rs.dns-oarc.net>
> @8.8.8.8 <http://8.8.8.8>

> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63546
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:

> ;rs.dns-oarc.net <http://rs.dns-oarc.net>.INTXT

>
> ;; Query time: 4373 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Sat Jan 27 19:20:21 EST 2018
> ;; MSG SIZE  rcvd: 44
>
>

> ; <<>> DiG 9.11.2 <<>> IN TXT rs.dns-oarc.net <http://rs.dns-oarc.net>
> @8.8.8.8 <http://8.8.8.8>

> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29585
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:

> ;rs.dns-oarc.net <http://rs.dns-oarc.net>.INTXT
>
> ;; ANSWER SECTION:
> rs.dns-oarc.net
> <http://rs.dns-oarc.net>.1INCNAMErst.x4090.rs.dns-oarc.net
> <http://rst.x4090.rs.dns-oarc.net>.
> rst.x4090.rs.dns-oarc.net <http://rst.x4090.rs.dns-oarc.net>.
> 58INCNAMErst.x4058.x4090.rs.dns-oarc.net
> <http://rst.x4058.x4090.rs.dns-oarc.net>.
> rst.x4058.x4090.rs.dns-oarc.net
> <http://rst.x4058.x4090.rs.dns-oarc.net>. 57
> INCNAMErst.x4064.x4058.x4090.rs.dns-oarc.net
> <http://rst.x4064.x4058.x4090.rs.dns-oarc.net>.
> rst.x4064.x4058.x4090.rs.dns-oarc.net
> <http://rst.x4064.x4058.x4090.rs.dns-oarc.net>. 56 IN TXT "74.125.179.74

> DNS reply size limit is at least 4090"
> rst.x4064.x4058.x4090.rs.dns-oarc.net

> <http://rst.x4064.x4058.x4090.rs.dns-oarc.net>. 56 IN TXT "74.125.179.74

> sent EDNS buffer size 4096"
> rst.x4064.x4058.x4090.rs.dns-oarc.net

> <http://rst.x4064.x4058.x4090.rs.dns-oarc.net>. 56 IN TXT "Tested at

> 2018-01-28 00:21:16 UTC"
>
> ;; Query time: 857 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Sat Jan 27 19:21:16 EST 2018
> ;; MSG SIZE  rcvd: 279
>
> If you want to understand why your resolver is failing, again I'd have a
> look at the 'resolver' log channel.  It should have some detail about
> what's resulting in the SERVFAIL message. 
>
>
>

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

[NNEX Support]

[…]

If you want to understand why your resolver is failing, again I'd have a look at the 'resolver' log channel.  It should have some detail about what's resulting in the SERVFAIL message.

[…]

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/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:

Thanks,

-Nick

[NNEX Support]

Just wanted to follow up 9.12.1b1 fixes this issue for me.

Thanks,

-Nick

[NNEX Support]

I apologize, I sent the previous email in error. This is what I get for having so many revisions of named sitting around on one server, I was not running 9.12.1b1 when I tested this. I will be more careful in the future. I just tested this with 9.12.1b1 and it still fails, the same as 9.12.

I do understand that the function of rs.dns-oarc.net is to test things that can no longer be tested in 9.12, but regardless I should still be able to resolve the nameservers for rs.dns-oarc.net, right?

Is anyone on 9.12 able to do this? Is this just my problem?

Thank you again,

-Nick

[NNEX Support]

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/2b51d5874c49ac823890b88824290fbf1c18f2cc

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.

As always thank you for your time!

-Nick

[Cathy Almond]

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

[NNEX Support]

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