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

[Mark Andrews]

> On 7 Jun 2023, at 09:42, Michael Sinatra <michael at brokendns.net> wrote:
> 
> 
> 
> 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.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

This has more to do with cache acceptance rules around NS RRsets and not
increasing the TTL when RRsets are updated (see ghost domains).  Named
doesn’t query for RRSIGs.

This would have been an issue for chained validating servers if the server
had an NS RRset with trust answer/auth answer vs trust secure as that would
have been returned without the RRSIGs to the client server until the RRset
timed out.  If the client had learnt about the DS RRset then NS queries would
have failed.

"rndc flushname pagerduty.com” on the intermediate server would have corrected
this.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org