Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
CAA logic gets confused if the CNAME is one label above requested #1048
letsencrypt#1138 has exposed an interesting bug in the CAA/CNAME logic.
This is both a bug and an incorrect implementation of the CAA spec. Since the CAA loop is ignorant of if it is doing a CAA query for a domain or a CNAME the chain of labels it is working down can get switched mid-way through, causing the infinite looping behaviour in the case above.
A quick clarification of what is going wrong, if we have a domain
but instead what happens is
Talked some more about this: VA actually won't go into an infinite loop and it will hit a maxCNAMES limit, throwing a 500. Also, this allows a subdomain to work around CAA on a parent domain by CNAME'ing somewhere else.
In general we want to treat any case of a user-triggered 500 as a bug that needs fixing: our 500's count should always be near zero in ideal operation. However, there are a number of similar bugs where we currently allow a user-triggered 500 (largely given
However, I think the bypass of CAA is worth fixing for launch, since we plan on supporting CAA.
RFC6844 s4 says: if domain has CNAME to target, and target has CAA, then R(domain) = R(target) -- where R is the algorithm we're describing, i.e., it includes checking target's parents -- otherwise check domain's parent.
Then it goes on to give an example that doesn't specifically mention whether "search alias(x.y.z)" is meant to imply a search for parent(alias(x.y.z)). But in this context it seems much more reasonable to interpret "search ... in the following order" as "do the following sequence of DNS lookups", i.e., "alias(x.y.z)" just represents a single DNS lookup.
Not checking parent(alias(...)) seems much more in keeping with the way CNAME is handled in the rest of the world: you don't behave differently depending on whether "lookup RR type X" happened to involve following a chain of CNAMEs, so you can let your upstream resolver handle CNAME transparently. Most likely the RFC just has a mistake in the algorithm description.
Agreed, this seems to be the cleanest approach. Unbound will follow CNAME/DNAME records for us and will only require a little extra work to properly support it on our end.
I'm not sure if Unbound can be configured to properly terminate a CNAME/DNAME loop but if it can follow them I'd be surprised if it doesn't have a option somewhere
This issue, plus another temporary issue we had with whitelisting, are
On 11/03/2015 03:59 AM, Niklas Keller wrote: