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 -- each at isc.org
Internet Systems Consortium, Inc.