[cabfpub] Continuing the discussion on CAA

Ryan Sleevi sleevi at google.com
Tue Oct 25 21:48:21 UTC 2016

On Tue, Oct 25, 2016 at 2:38 PM, Rick Andrews <Rick_Andrews at symantec.com>

> Ryan, I don’t think it makes sense to me, but to be fair, it might be due
> to my limited knowledge of DNS. As for technical complexity, it seems
> simpler than CT ;^)
> I wasn’t proposing re-implementing DNS within our validation
> infrastructure. As far as I know, we already have recursive resolvers in
> our infrastructure (I think they’re also called stub resolvers), and again,
> as far as I know, they implement caching according to the DNS spec. Even if
> we didn’t have recursive resolvers in our infrastructure, and we used, say,
> Google’s, isn’t that also a recursive resolver that caches?
> Consulting my internal recursive resolver will be a bit faster than
> consulting one outside of my infrastructure, but it seems to me that the
> net effect is the same; caching prevents clients from seeing immediate
> changes made at the authoritative name servers.

I was trying to head off the suggestion, that say, within your validation
database, you do an authoritative lookup, see the TTL at some large value
(e.g. 48 hours), and then record that information within your validation

With respect to the distinction between stub and recursive resolver, I was
specifically referring to the notion that some element of the CAs
infrastructure itself would be responsible for the recursive hierarchal
resolution - that is, root servers to authoritative servers, etc. The
implications of the term "stub resolver" would be that, say, you might
trust your ISP - or Google's - to correctly perform that
resolution, which I don't think is the desirable outcome here with respect
to auditability nor the netsec requirements.

In either event, I think we're in agreement that DNS allows caching, and my
point is that I think it's unwise to add *additional* caching.

An example of additional caching which was discussed in the F2F, and which
is practiced by CAs today, but I think is potentially problematic, is that
the CA records in their validation database that they performed the CAA
check on some date (e.g. 1/1/2016), but then ignore DNS TTL and use that
cached result for some indefinite period.

This is not specific to CAA either - we know that CAs rely on cached
validation of domain ownership for up to 39 months after issuance. This is
useful with respect to general DNS cases, as for some TLDs, WHOIS
information simply isn't available, or isn't programatically accessible. So
I can understand the argument for allowing some degree of caching of what
may be a manual process. However, CAA doesn't require that manual
inferrence, and every domain can express CAA records themselves, and the
TTLs can be controlled by the domain administrator, so I was suggesting
that such a form of a caching - admistrative rather than technical - is

> Which concerns of Jacob’s are you’re referring to? The fact that
> LetsEncrypt does CAA checking at validation but not issuance time because
> it’s too expensive?

Jacob didn't suggest that it was too expensive -
https://cabforum.org/pipermail/public/2016-October/008576.html instead
states because it's externally facing, slow, and unreliable. That may have
been what you meant by expensive, but given that it's an overloaded term, I
thought it best to point directly to what Jacob stated.

> It sounds like your ideal case would require everyone to use DNS in a way
> that it wasn’t intended to be used (no caching). That makes me think that
> DNS isn’t the best place to keep this type of info, but I can’t think of a
> better place.

Sorry I wasn't clear, because that's not at all what I was saying. I was
suggesting that the ideal world is no caching *outside* of the methods of
caching defined within DNS. That is, no administrative databases of "Oh
yeah, we checked this via DNS a week ago, so we don't need to" - but
instead, using DNS resolvers (within the CAs control and scope) to perform
the lookup - and, incidentally, supporting caching as defined by DNS.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161025/75a24c8e/attachment-0003.html>

More information about the Public mailing list