[dns-operations] Enabling DNSSEC signing for pagerduty.com

[Michael Sinatra]

On 6/6/23 2:26 PM, Matt Nordhoff via dns-operations wrote:
> Hold on, did y'all skip a step?
> 
> <https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec-enable-signing.html>:
> 
>> 2. Wait for at least the previous zone’s maximum TTL.
>>
>>     Wait for resolvers to flush all unsigned records from their cache. To achieve this you should wait for at least the previous zone’s maximum TTL. In the example.com zone above, the wait time would be 1 day.
> I think the zone was signed and then the DS record was added within no
> more than about 2 hours?
> 
> But the pagerduty.com./NS record set TTL is 172,000.
> 
> But most or all other records have TTLs of no more than 300?
> 
> It's probably fine but maybe not? Clients don't normally look up NS
> records, but I don't know if there are cases where a recursive
> resolver's internal logic could notice or care?
> 
> [ABSOLUTELY DO NOT PANIC AND UNSIGN THE ZONE. YOU CAN PANIC AND DELETE
> THE DS RECORD BUT FOR THE LOVE OF GOD DO NOT UNSIGN THE ZONE.]

Most implementations have figured that out.  For example, here's a BIND 
resolver that has clearly had the old NS records cached for more than a 
day, but you can see that it just recently picked up the RRSIG:

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: c44a7851f66125f401000000647fbc7a9d4deb808b32618e (good)
;; QUESTION SECTION:
;pagerduty.com.			IN	NS

;; ANSWER SECTION:
pagerduty.com.		75161	IN	NS	ns-474.awsdns-59.com.
pagerduty.com.		75161	IN	NS	ns-1285.awsdns-32.org.
pagerduty.com.		75161	IN	NS	ns-963.awsdns-56.net.
pagerduty.com.		75161	IN	NS	ns-1659.awsdns-15.co.uk.
pagerduty.com.		172785	IN	RRSIG	NS 13 2 172800 20230609000827 
20230606220827 54499 pagerduty.com. 
uuPtvUfpsyZaXgCL0PtnTJHCNliXmVdLXEIv02sMAB+Gv5ObkaQNRWJ3 
S/lrMjIm8LQio3aoVYs3lY/WGIc6tw==

;; ADDITIONAL SECTION:
ns-474.awsdns-59.com.	75161	IN	A	205.251.193.218

I was going to write a message to Andy saying the following:

"My summary feeling is that DNSSEC signing has gotten substantially 
easier, partly because of robust automation built into signing 
implementations (including F/OSS), and partly because the guidance** to 
resolver implementers has been to make an effort to find a path toward 
validation rather than bogusity."  The re-fetching of RRSIGs in this 
particular case is an example of that.  (The other big example being the 
infamous "conservative" algorithm rollover method, which is no longer 
necessary.)

I have tried validating pagerduty.com on BIND (with old data)--see the 
ad flag above, plus unbound, knot-resolver, and powerdns-resolver and 
it's validating correctly on all of them.  Nice job (so far, at least), 
folks (note the $dayjob is a pagerduty customer).

michael

**I can't find a document example of such guidance other than hints from 
RFC 6781, mostly in the context of alg rollovers.  I am hoping marka can 
chime in and correct any hallucinations I may be recounting here.