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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Tony Finch
Cathy Almond <[hidden email]> 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  <[hidden email]>  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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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 +0000, 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 -- [hidden email]
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Matus UHLAR - fantomas
In reply to this post by Tony Finch
>Cathy Almond <[hidden email]> 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, [hidden email] ; 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> wrote:
Cathy Almond <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Tony Finch
In reply to this post by Evan Hunt
Evan Hunt <[hidden email]> 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  <[hidden email]>  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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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 +0000, 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 -- [hidden email]
Internet Systems Consortium, Inc.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Mark Andrews
In reply to this post by Tony Finch
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 <[hidden email]> wrote:
>
> Evan Hunt <[hidden email]> 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  <[hidden email]>  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
> [hidden email]
> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

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

Tony Finch
Mark Andrews <[hidden email]> 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  <[hidden email]>  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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users