dns-persist has been adopted by the WG, switch link (#2089)

Link to the rendered html of the current draft, as adopted by the WG, instead of the previous individual draft.

Author: mcpherrinm

content/en/post/2025-12-02-from-90-to-45.md

@@ -1,6 +1,6 @@
 ---
 author: Matthew McPherrin
-date: 2025-12-02T00:00:00Z
+date: 2025-12-03T00:00:00Z
 slug: from-90-to-45
 title: "Decreasing Certificate Lifetimes to 45 Days"
 excerpt: "Improving security for active and revoked certificates."
@@ -44,7 +44,7 @@ For many of our users, the hardest part of automatically issuing certificates is
 
 All validation methods today require that the ACME client have live access to your infrastructure, either to serve the correct HTTP-01 token, perform the right TLS-ALPN-01 handshake, or update the right DNS-01 TXT record. For a long time, people have wanted a way to run an ACME client without granting it access to these sensitive systems.
 
-These challenges are why we are working with our partners at the CA/Browser Forum and IETF to standardize a new validation method called [DNS-PERSIST-01](https://datatracker.ietf.org/doc/html/draft-sheurich-acme-dns-persist-01). The key advantage of this new method is that the DNS TXT entry used to demonstrate control does not have to change every renewal.
+These challenges are why we are working with our partners at the CA/Browser Forum and IETF to standardize a new validation method called [DNS-PERSIST-01](https://www.ietf.org/archive/id/draft-ietf-acme-dns-persist-00.html). The key advantage of this new method is that the DNS TXT entry used to demonstrate control does not have to change every renewal.
 
 This means you can set up the DNS entry once and begin automatically renewing certificates without needing a way to automatically update DNS. This should allow even more people to automate their certificate renewals. It will also reduce reliance on authorization reuse, since the DNS records can stay unchanged without any further ACME client involvement.