Improve CAA checking to follow the CNAME per the CAA spec

[parkr]

The CAA spec says for CNAMEs that if no CAA records exist for the current domain,
then the CAA records for the CNAME should be used.

https://tools.ietf.org/html/rfc6844#section-4

Am I reading that right? I'm not sure how best to restructure this code to check for this.

/cc @github/pages

[seveas]

Are we sure that Let's Encrypt follows the spec properly, and doesn't have the same bug we have? Because if they do have this bug, then suddenly pages-health-check will say OK even though it still won't work.

I'm guessing their implementation will be correct, but it won't hurt to check :)

[seveas]

Quick test indicates that this PR is not having the desired effect. I'll report mre results in a bit, but wanted to give a heads-up to prevent a merge of this PR as-is.

[seveas]

The reason that this change does not work is that it traverses the domain of the CNAME, which is not according to spec and also not according to Let's Encrypt behaviour. Here's a fictional example of a troublesome domain, where the top-level CAA record forbids let's encrypt:

For this domain, example.example.com, a CNAME to example.github.io, the following CAA records would be queried, in this order, with the results as follows:

example.example.com -> CNAME to example.github.io
example.github.io -> CNAME to sni.github.map.fastly.net
sni.github.map.fastly.net -> No CAA record, so we can now "climb" the DNS to a higher-level domain. But only for the original name, not any cname.
example.com -> CAA record forbidding let's encrypt.

We cannot inject CAA records for example.github.io, as it's a CNAME (CNAME records cannot live next to records of other types for the same name). A CAA record for github.io would be irrelevant, as that's also not looked up.

If we could get fastly to have a CAA record for sni.github.map.fastly.net that allows let's encrypt, that might help a lot with domains that are in this situation, as the CAA record for sni.github.map.fastly.net takes precedence. A test with non-pages domains in this setup show that let's encrypt does the right thing here.

That still wouldn't make this change correct as-is, but would at least allow us to write a correct change for the health check 😄

[snh]

If we could get fastly to have a CAA record for sni.github.map.fastly.net that allows let's encrypt, that might help a lot with domains that are in this situation, as the CAA record for sni.github.map.fastly.net takes precedence. A test with non-pages domains in this setup show that let's encrypt does the right thing here.

I wonder if by doing this we'd end up upsetting any domain administrators who don't want other CA's, such as Let's Encrypt, issuing certificates for one of their subdomains?

In situations where the CAA record for the overarching domain (example.com) doesn't allow Let's Encrypt, could we instead just suggest users configure example.example.com using A records pointing to Pages, so they can then put a different explicit CAA record in place? Now that we have our own block of IPs for Pages, I feel less concerned about A records being used instead of a CNAME.

[snh]

We cannot inject CAA records for example.github.io, as it's a CNAME (CNAME records cannot live next to records of other types for the same name). A CAA record for github.io would be irrelevant, as that's also not looked up.

Thinking about this, regardless of the CAA issue, now that sni.github.map.fastly.net points to the same GitHub owned IPs that users who use A records for apex domains use, could we update our wildcard record for *.github.io to use A records and bypass the CNAME to the fastly.net record completely?

This would cut down the DNS resolution time, remove the dependency on fastly.net DNS (not that I have ever seen them have a problem), and give us the flexibility to add a wildcard CAA record for *.github.io if we so desire.

[parkr]

could we update our wildcard record for *.github.io to use A records and bypass the CNAME to the fastly.net record completely?

@snh Let's give this a shot!

[snh]

As an alternative to this change, if we go ahead and add CAA records to github.io, and therefore know CAA validation will pass in all cases, could we just skip the CAA validation completely if we know that the record is a CNAME to the Pages user domain? Something like:

      # Can an HTTPS certificate be issued for this domain?
      def https_eligible?
        (cname_to_github_user_domain? || pointed_to_github_pages_ip?) &&
          !aaaa_record_present? && !non_github_pages_ip_present? &&
          (cname_to_github_user_domain? || caa.lets_encrypt_allowed?)
      end

That way we can leave the existing CAA logic as is, as it is still relevant where a CNAME isn't in use.

[parkr]

As an alternative to this change, if we go ahead and add CAA records to github.io, and therefore know CAA validation will pass in all cases, could we just skip the CAA validation completely if we know that the record is a CNAME to the Pages user domain?

@snh I really like this approach! For CNAME's, it makes things a lot quicker.

[parkr]

I have a simpler alternative here: #108

[parkr]

Will try to ship v1.15.0 sometime next week!