[dns-operations] Cloudflare DNS resolver (1.1.1.1): Weird DNSSEC race condition

[Petr Špaček]

On 8.8.2018 23:15, Michael Sinatra wrote:
> On 08/06/18 16:48, Paul Hoffman wrote:
>> On 6 Aug 2018, at 16:07, Michael Sinatra wrote:
> I'll raise it in DNSOP--thanks for suggesting, Paul.
> 
> Are you aware of any other RFC sections which suggest timing of RRSIG
> introduction into the zone?  I know it's a significant issue for
> algorithm rollovers, but for new zones that are about to move from
> insecure to secure, are there good recommendations?  I cited 7583,
> section 3.3.5, but it only explicitly mentions DNSKEY presence.  My rule
> of thumb has been that DNSKEYs *and* RRSIGs should appear for at least
> 1x(Longest-TTL-in-zone), including the negative TTL.  But I don't know
> if that's been codified anywhere in an RFC or operational practice (or
> if that's even the correct rule-of-thumb, so I often do 2x(longest-TTL)
> just in case.
> 
> To Petr's point, I definitely appreciate the attention you're giving
> this, and I do agree that I am assuming correct compliance.  I think the
> balance I am trying to achieve is, how do we compensate for brokenness
> while not punishing those who are trying to do the right thing?  As it
> stands, even if I am doing the right thing with respect to timing, I
> still might break resolution of a zone that I manage for anyone who is
> forwarding to Cloudflare or knot-resolver for up to 3 hours, just by
> adding the DS record.
> 
> I suspect the above trade-off is the precise reason for DNS Flag Day.

Yes, exactly. Workarounds causing troubles elsewhere are not defensible
anymore.

-- 
Petr Špaček  @  CZ.NIC