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

[Matt Nordhoff]

On Tue, Jun 6, 2023 at 5:46 PM Andy Smith via dns-operations
<dns-operations at dns-oarc.net> wrote:
> Hi all,
>
> We (PagerDuty) are in the process of enabling DNSSEC signing across
> our domains, and today (June 6th) we’re planning to enable it for
> pagerduty.com and associated subdomains (e.g. eu.pagerduty.com). Given
> the potential impact and the large number of organizations using our
> services, we thought it would be a good idea to let people know it’s
> happening in case any problems occur. If you do see any issues, feel
> free to contact me directly or support via support at pagerduty.com.
>
> As an aside, we’ve talked with a few other organizations that have
> enabled DNSSEC signing and have gotten a lot of useful information as
> a result. We’d be more than happy to hear from other people who have
> gone through the process and also to share what we’ve learned in the
> future in case it helps anyone else!
>
> Cheers,
>
> Andy.

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.]
-- 
Matt Nordhoff