Re: CNAME at apex, was Re: Issue running "dig txt rs.dns-oarc.net" on 9.12

[Tony Finch]

Mark Andrews  wrote:

> While it will speed up things slightly it won’t avoid the issue as TTLs
> vary.

Oh, duh, I should have thought of that. Thanks for pointing it out :-)

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Fisher, German Bight: Variable, becoming southeast 3 or 4, occasionally 5
later. Slight or moderate. Rain then fair. Good, occasionally poor at first.___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: CNAME at apex, was Re: Issue running "dig txt rs.dns-oarc.net" on 9.12

[Mark Andrews]

While it will speed up things slightly it won’t avoid the issue as TTLs vary. 

-- 
Mark Andrews

> On 11 Mar 2018, at 05:30, Tony Finch  wrote:
> 
> Evan Hunt  wrote:
>> 
>> In 9.12.1 and the other upcoming maintenance releases, we've just reverted
>> the change to validator.c that caused the problems. (That turns out to have
>> the exact same effect as your patch does.)
> 
> Great, that will please my user, and I can use NTAs to work around the
> problem until then.
> 
>> Apex CNAMEs are bogus, of course, but we do need to cope with them when
>> they appear. We're going to revisit this issue in 9.12.2, once we've
>> figured out how to solve the one problem without causing the other one.
> 
> I have said this already so I'm at risk of being a bore, but it would be
> super cool if BIND could make use of the DS records (or PNEs) it gets in
> referrals, instead of re-fetching them during validation. It should
> provide a nice speed-up, as well as allowing the validator to avoid
> looking into insecure subtrees, which will have the side-effect of
> avoiding problems with apex CNAMEs.
> 
> Tony.
> -- 
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
> Fisher: Easterly 6 to gale 8, increasing severe gale 9 for a time in north.
> Moderate or rough, occasionally very rough in north. Rain. Moderate or poor.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

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

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

Re: CNAME at apex, was Re: Issue running "dig txt rs.dns-oarc.net" on 9.12

[Evan Hunt]

On Sat, Mar 10, 2018 at 06:30:41PM +, Tony Finch wrote:
> I have said this already so I'm at risk of being a bore, but it would be
> super cool if BIND could make use of the DS records (or PNEs) it gets in
> referrals, instead of re-fetching them during validation. It should
> provide a nice speed-up, as well as allowing the validator to avoid
> looking into insecure subtrees, which will have the side-effect of
> avoiding problems with apex CNAMEs.

Yep, that's one of the approaches we've discussed.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: CNAME at apex, was Re: Issue running "dig txt rs.dns-oarc.net" on 9.12

[Tony Finch]

Evan Hunt  wrote:
>
> In 9.12.1 and the other upcoming maintenance releases, we've just reverted
> the change to validator.c that caused the problems. (That turns out to have
> the exact same effect as your patch does.)

Great, that will please my user, and I can use NTAs to work around the
problem until then.

> Apex CNAMEs are bogus, of course, but we do need to cope with them when
> they appear. We're going to revisit this issue in 9.12.2, once we've
> figured out how to solve the one problem without causing the other one.

I have said this already so I'm at risk of being a bore, but it would be
super cool if BIND could make use of the DS records (or PNEs) it gets in
referrals, instead of re-fetching them during validation. It should
provide a nice speed-up, as well as allowing the validator to avoid
looking into insecure subtrees, which will have the side-effect of
avoiding problems with apex CNAMEs.

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Fisher: Easterly 6 to gale 8, increasing severe gale 9 for a time in north.
Moderate or rough, occasionally very rough in north. Rain. Moderate or poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: CNAME at apex, was Re: Issue running "dig txt rs.dns-oarc.net" on 9.12

[Matthew Pounsett]

On 10 March 2018 at 04:08, Matus UHLAR - fantomas  wrote:

> Cathy Almond  wrote:
>>
>>> The rs.dns-oarc.net zone is broken because it returns a CNAME for
>>> queries at the apex.
>>>
>>
> On 09.03.18 15:23, Tony Finch wrote:
>
>> I just got a problem report from a user who has a few personal domains
>> with CNAME at apex that used to work (or at least appeared to work) but
>> no longer do.
>>
>> I've said that the domains are misconfigured, but since this is a
>> relatively widespread misconfiguration, I think it's likely to cause
>> more complaints. Tiresome.
>>
>
> it's the very common result of misconfiguration that something sometimes
> does not work, while sometimes it does.
>

Apex CHAMEs, in particular, have nondeterministic failure modes.  In that,
each resolver deals differently with this misconfiguration, since by
definition there is no correct way to deal with it.  Some resolvers find a
way to gloss over the problem, and others fail hard making the domain name
and everything below it unresolvable for the TTL of either the apex NS set
or the TTL of the CNAME itself, depending on which way it breaks.

Best to just stop doing that so that whether the domain works doesn't
depend on which resolver you're trying to use.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: CNAME at apex, was Re: Issue running "dig txt rs.dns-oarc.net" on 9.12

[Matus UHLAR - fantomas]

Cathy Almond  wrote:

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


On 09.03.18 15:23, Tony Finch wrote:

I just got a problem report from a user who has a few personal domains
with CNAME at apex that used to work (or at least appeared to work) but
no longer do.

I've said that the domains are misconfigured, but since this is a
relatively widespread misconfiguration, I think it's likely to cause
more complaints. Tiresome.


it's the very common result of misconfiguration that something sometimes
does not work, while sometimes it does.

I usually advise people to fix things inctead of complaining that something
"misconfigured doesn't work sometimes" - that is the definition of
misconfiguration, isn't it?

especially DNS, with caching, TTLs and DNSSEC - there's not enough room for
making every possible mistake and expecting it to work.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Two words: Windows survives." - Craig Mundie, Microsoft senior strategist
"So does syphillis. Good thing we have penicillin." - Matthew Alton
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: CNAME at apex, was Re: Issue running "dig txt rs.dns-oarc.net" on 9.12

[Evan Hunt]

On Fri, Mar 09, 2018 at 03:23:33PM +, Tony Finch wrote:
> Alternatively, maybe the patch below is OK? (Based on Nick @ NNEX's
> observation.) My idea is that if we have been chasing a CNAME (so are at
> risk of deadlock) but we are looking for a DS (so we will query the
> parent) we can go ahead. I tested it briefly and it works around the
> breakage for iterative resolution; dunno if it is unsafe.
> 
> diff --git a/lib/dns/validator.c b/lib/dns/validator.c
> index 8b63c98..92fc6dc 100644
> --- a/lib/dns/validator.c
> +++ b/lib/dns/validator.c
> @@ -1101,7 +1101,8 @@ check_deadlock(dns_validator_t *val, dns_name_t *name, 
> dns_rdatatype_t type,
>   for (parent = val; parent != NULL; parent = parent->parent) {
>   if (parent->event != NULL &&
>   (parent->event->type == type ||
> -  parent->event->type == dns_rdatatype_cname) &&
> +  (parent->event->type == dns_rdatatype_cname &&
> +   type != dns_rdatatype_ds)) &&
>   dns_name_equal(parent->event->name, name) &&
>   /*
>* As NSEC3 records are meta data you sometimes

In 9.12.1 and the other upcoming maintenance releases, we've just reverted
the change to validator.c that caused the problems. (That turns out to have
the exact same effect as your patch does.)

The problem we were trying to address was that apex CNAMEs in domains
that are supposed to be signed cause the validator to get stuck, and
eventually time out.  But the fix made it so apex CNAMEs in domains
that *aren't* supposed to be signed fail validation.  Putting in the
patch above got rid of the second problem, but brought back the first
one.

Apex CNAMEs are bogus, of course, but we do need to cope with them when
they appear. We're going to revisit this issue in 9.12.2, once we've
figured out how to solve the one problem without causing the other one.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

CNAME at apex, was Re: Issue running "dig txt rs.dns-oarc.net" on 9.12

[Tony Finch]

Cathy Almond  wrote:
>
> [snip]
>
> 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.
>
> [snip]
>
> 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?

I just got a problem report from a user who has a few personal domains
with CNAME at apex that used to work (or at least appeared to work) but
no longer do.

I've said that the domains are misconfigured, but since this is a
relatively widespread misconfiguration, I think it's likely to cause
more complaints. Tiresome.

My preferred way to fix this would be for BIND to make use of the NSEC
denial of DS that it received in the referral, so that it doesn't need to
call create_fetch(), and therefore does not trip over the CNAME deadlock.
(If I explicitly `dig DS` for a problem domain, so that the absence of DS
record is cached with a higher level of RFC 2181 trust, resolution
subsequently works.)

Alternatively, maybe the patch below is OK? (Based on Nick @ NNEX's
observation.) My idea is that if we have been chasing a CNAME (so are at
risk of deadlock) but we are looking for a DS (so we will query the
parent) we can go ahead. I tested it briefly and it works around the
breakage for iterative resolution; dunno if it is unsafe.

diff --git a/lib/dns/validator.c b/lib/dns/validator.c
index 8b63c98..92fc6dc 100644
--- a/lib/dns/validator.c
+++ b/lib/dns/validator.c
@@ -1101,7 +1101,8 @@ check_deadlock(dns_validator_t *val, dns_name_t *name, 
dns_rdatatype_t type,
for (parent = val; parent != NULL; parent = parent->parent) {
if (parent->event != NULL &&
(parent->event->type == type ||
-parent->event->type == dns_rdatatype_cname) &&
+(parent->event->type == dns_rdatatype_cname &&
+ type != dns_rdatatype_ds)) &&
dns_name_equal(parent->event->name, name) &&
/*
 * As NSEC3 records are meta data you sometimes

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames, Dover, Wight: South or southeast 4 or 5, occasionally 6 in
Humber and Wight. Slight or moderate. Occasional rain, fog patches developing.
Moderate or good, occasionally very poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

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

[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

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Cathy 
Almond
Sent: Tuesday, February 27, 2018 4:29 AM
To: bind-users@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.3600IN  NS  ns00.rs.dns-oarc.net.
rs.dns-oarc.net.3600IN  NSECrs4.dns-oarc.net. NS RRSIG NSEC
rs.dns-oarc.net.3600IN  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.   3600IN  A   64.191.0.133
ns00.rs.dns-oarc.net.   3600IN  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 a

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

[Cathy Almond]

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

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.3600IN  NS  ns00.rs.dns-oarc.net.
rs.dns-oarc.net.3600IN  NSECrs4.dns-oarc.net. NS RRSIG NSEC
rs.dns-oarc.net.3600IN  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.   3600IN  A   64.191.0.133
ns00.rs.dns-oarc.net.   3600IN  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 

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

[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



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

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

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

[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


-Original Message-
From: NNEX Support 
Sent: Thursday, February 22, 2018 8:21 AM
To: 'bind-users@lists.isc.org'
Subject: RE: Issue running "dig txt rs.dns-oarc.net" on 9.12

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

Thanks,

-Nick

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

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

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

[NNEX Support]

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

Thanks,

-Nick

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

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

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

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

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

[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  > 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 .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 
> @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 .INTXT
> 
> ;; ANSWER SECTION:
> rs.dns-oarc.net
> .1INCNAMErst.x4090.rs.dns-oarc.net
> .
> rst.x4090.rs.dns-oarc.net .
> 58INCNAMErst.x4058.x4090.rs.dns-oarc.net
> .
> rst.x4058.x4090.rs.dns-oarc.net
> . 57
> INCNAMErst.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. 
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 

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

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

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

[Matthew Pounsett]

On 27 January 2018 at 19:11, Matthew Pounsett  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.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

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

[Matthew Pounsett]

On 27 January 2018 at 16:24, NNEX Support  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.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

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

[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

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

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

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

[Matthew Pounsett]

On 26 January 2018 at 16:23, NNEX Support  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.



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.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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