[dns-operations] Looping wildcard CNAMEs can be an obstacle for DANE, (googledomains.com-hosted example)
Viktor Dukhovni
ietf-dane at dukhovni.org
Mon Apr 16 16:04:12 UTC 2018
> On Apr 16, 2018, at 11:21 AM, Randy Bush <randy at psg.com> wrote:
>
> features, complexity, mops, ...; we're making a mess. if we could
> measure breakage, i suspect db/dt would be worrisome.
Left unattended, the problems would indeed proliferate. I've had
a fairly good run at reducing the incidence. Many providers have
removed firewall rules that block unexpected RR types, upgraded
nameservers to do denial of existence correctly, etc. Some have
fixed excessive NSEC3PARAM iterations, and the biggest cluster of
512-bit RSA is gone. One domain with a nameserver returning slightly
mangled SOA signatures with DoE, but not when asked for the SOA
directly, took 3.5 years to act, but recently disabled DNSSEC
resolving the issue.
So overall, the DANE survey is having a positive effect on DNS hygiene
among signed domains. It does not look at all closely at either unsigned
domains, or "dead" signed domains with no SEP. So the 5.86 million domains
covered are improving, with just ~100 domains with DNS-related errors, some
of them "partial" (at least one working nameserver). Back in 2015 the
breakage count was over 4,000 out of a considerably smaller dataset.
As to this particular issue, it seems (from a parallel Twitter thread)
that BIND is an outlier here in returning NOERROR and just the looped
CNAME, while all other resolvers tested returned ServFail.
Quoting Tony:
Good grief. I think Unbound is technically correct, but BIND's
noerror/nodata is probably more useful (since SERVFAIL is such
a lossy response)
The BIND behaviour does reduce some friction for DANE, but can cause some applications to needlessly chase the loopy cname up their recursion limit. The Postfix DNS layer does not look for direct (a -> a) loops and recurses when the answer is a CNAME (in case the resolver did not recurse all the way to the answer). So returning something other than ServFail can cause some extra work in some applications.
So I'm unsure which is better...
--
Viktor.
More information about the dns-operations
mailing list