Forwarding with permission. Gerv
-------- Forwarded Message -------- Subject: Fwd: [cabfpub] Draft CAA motion (3) Date: Thu, 19 Jan 2017 11:44:55 -0800 From: Simone Carletti <[email protected]> To: Gervase Markham <[email protected]>, Ryan Sleevi <[email protected]> Gerv, Ryan, As I'm not a member, hence I'm forwarding this note to you for consideration. Caching a negative response may lead to several cache invalidation problems. It's common to cache a negative response (e.g. NXDOMAIN), but the length of the case should be *reasonably* limited. The typical scenario to avoid is the case when the user (or resolver) queries the record (e.g. for debugging or testing), then adds it (as it was not present). In that case, if the negative cache is too long, that would cause caching invalidation issues. I can see a similar scenario for certs, especially during testing phases (e.g. security testings, setups, etc). I suggest to take a look at https://tools.ietf.org/html/rfc2308 and specifically section 3 that provides some instructions for determining a possible appropriate TTL for negative caching based on SOA and TTL. https://tools.ietf.org/html/rfc2308#section-5 > Like normal answers negative answers have a time to live (TTL). As > there is no record in the answer section to which this TTL can be > applied, the TTL must be carried by another method. This is done by > including the SOA record from the zone in the authority section of > the reply. When the authoritative server creates this record its TTL > is taken from the minimum of the SOA.MINIMUM field and SOA's TTL. > This TTL decrements in a similar manner to a normal cached answer and > upon reaching zero (0) indicates the cached negative answer MUST NOT > be used again. Long story short, negative caching TTL is generally determined by the last value of the SOA record. That would also allow the domain owner to be in control of the cache. Example (emphasis is mine): ➜ ~ dig missing.simonecarletti.com <http://missing.simonecarletti.com> SOA ; <<>> DiG 9.11.0-P1 <<>> missing.simonecarletti.com <http://missing.simonecarletti.com> SOA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: *NXDOMAIN*, id: 19517 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;missing.simonecarletti.com <http://missing.simonecarletti.com>.INSOA ;; AUTHORITY SECTION: simonecarletti.com <http://simonecarletti.com>.*299*INSOAns1.dnsimple.com <http://ns1.dnsimple.com>. admin.dnsimple.com <http://admin.dnsimple.com>. 2013062714 86400 7200 604800 *300* ;; Query time: 120 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Jan 19 11:43:14 PST 2017 ;; MSG SIZE rcvd: 110 The SOA negative TTL is 300. Therefore the negative lookup is cached for up to 300 seconds. -- Simone ---------- Forwarded message ---------- From: *Gervase Markham via Public* <[email protected] <mailto:[email protected]>> Date: Thu, Jan 19, 2017 at 8:14 AM Subject: Re: [cabfpub] Draft CAA motion (3) To: Steve Medin <[email protected] <mailto:[email protected]>>, CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]>>, Doug Beattie <[email protected] <mailto:[email protected]>> Cc: Gervase Markham <[email protected] <mailto:[email protected]>> On 19/01/17 16:11, Steve Medin wrote: > Gerv, in the event that a domain does not have CAA, would you be > willing to allow CAs to cache that result for longer than one hour? > You presently offer TTL or 1 hour, whichever is greater, when CAA is > present. Might a day be reasonable, since the domain owner has not > yet opted in to CAA? I'd certainly be open to that, unless someone else has a good reason why that's a bad idea. Gerv _______________________________________________ Public mailing list [email protected] <mailto:[email protected]> https://cabforum.org/mailman/listinfo/public <https://cabforum.org/mailman/listinfo/public> -- Simone Carletti Passionate programmer and dive instructor https://simonecarletti.com/ _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
