Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
CAA Lookup Loop Test #3
I don't understand yet why this test should fail implicitly. The CA should not run into the recursion loop, yes. But can't basic.caatestuite.com, caatestsuite.com and .com be checked for CAA records after the recursion has been detected? Since no CAA records are defined for any of those domains, issueing could be allowed, couldn't it?
added a commit
Sep 7, 2017
You raise a good point. If the CA can detect that there is a true loop, then it knows there is no CAA record set at that label and can continue upwards, and ultimately issue.
What the CA must not do is assume that just because there is a long chain of CNAMEs that there must be a loop. This is what the cname-loop test was trying to check. I've removed this test for now and will replace it with a better test.
Thanks for filing this issue!
Detection of a true loop is easily implemented and should not be blocker for any CA. I had some true loops which were simple misconfigurations of peoples DNS or domain/subdomain plan. They exist more often than I thought.
An attacker could write/modify a DNS that returns dynamicly created C/DNAME records pointing to other dynamicly created C/DNAMES which point to ... , and so on, creating an endless lookup-chain without any recursion ever happening. This could result in a potential DoS of the CAA Lookup service if not handled via timeout.
I think this is something erratum 5065 tries to solve. Limiting the length of CNAME chains, however, is only a solution if it'll result in a deny, which is not yet defined. We'll see. :)
Thanks again for your work!