[dns-operations] Cloudflare DNS resolver (18.104.22.168): Weird DNSSEC race condition
petr.spacek at nic.cz
Thu Aug 9 07:10:16 UTC 2018
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
Petr Špaček @ CZ.NIC
More information about the dns-operations