DNS-PERSIST-01: DNS-आधारित challenge verification के लिए एक नया मॉडल

• Let's Encrypt का DNS-PERSIST-01 पारंपरिक DNS-01 के दोहराए जाने वाले verification को बदलकर persistent authentication records का उपयोग करने वाला एक नया ACME challenge मॉडल है
• यह तरीका विशिष्ट ACME account और CA से बंधे TXT records के ज़रिए डोमेन नियंत्रण को लंबे समय तक प्रमाणित करता है
• DNS बदलाव और API credentials deployment के बोझ को कम करके, यह operational efficiency और security दोनों को मजबूत करता है
• policy options (policy=wildcard), expiry point (persistUntil), और multiple CA support जैसे सूक्ष्म control features को support करता है
• 2026 की Q1 के अंत में staging और Q2 में full rollout की योजना है, जिससे large-scale और automated environments में certificate management को सरल बनाने की उम्मीद है

---

DNS-01 तरीके की सीमाएँ

• मौजूदा DNS-01 challenge में हर certificate issuance पर एक नया token बनाना और _acme-challenge. में TXT record जोड़ना पड़ता है
  • हर verification के लिए DNS update चाहिए होता है, जिससे propagation delay और automation complexity पैदा होती है
• बड़े पैमाने की deployments में DNS API credentials कई systems में फैल जाते हैं, जिससे security risk बढ़ता है
• कुछ subscribers ऐसे बार-बार के DNS बदलावों से बचना चाहते हैं

DNS-PERSIST-01 की संरचना और काम करने का तरीका

• नया तरीका persistent authorization की अवधारणा लाता है
  • _validation-persist. पर CA और ACME account URI शामिल करने वाला TXT record केवल एक बार सेट किया जाता है
  • उसके बाद issuance और renewal के समय उसी record का दोबारा उपयोग किया जा सकता है
• उदाहरण:

  _validation-persist.example.com. IN TXT (  
    "letsencrypt.org;"  
    " accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"  
  )  
  

• इससे issuance path से DNS changes हट जाते हैं, और operational efficiency बेहतर होती है

सुरक्षा और संचालन के बीच संतुलन

• DNS-01 में DNS write permissions मुख्य asset थे, जबकि DNS-PERSIST-01 में ACME account key की सुरक्षा केंद्रीय तत्व बन जाती है
• शुरुआती setup के बाद DNS write access को सीमित किया जा सकता है, जिससे attack surface घटता है
• लेकिन persistent authentication structure के कारण account key leak होने पर जोखिम बढ़ जाता है, इसलिए account security management को मजबूत करना ज़रूरी है

स्कोप और lifespan control features

• डिफ़ॉल्ट रूप से यह verified FQDN के लिए ही अनिश्चित अवधि तक वैध रहता है
• policy=wildcard option से इसे wildcard और subdomains तक बढ़ाया जा सकता है

  "policy=wildcard"  
  

• persistUntil attribute के ज़रिए expiry point (UTC epoch seconds) सेट किया जा सकता है
  • expiry से पहले renewal ज़रूरी है, और monitoring system अनिवार्य है

  "persistUntil=1767225600"  
  

• कई CA को एक साथ अनुमति देने के लिए _validation-persist. में प्रत्येक CA के लिए TXT records जोड़े जा सकते हैं

अपनाने की समयरेखा और implementation status

• CA/Browser Forum SC-088v3 वोट 2025 के अक्टूबर में सर्वसम्मति से पास हुआ, और IETF ACME Working Group ने draft अपना लिया
• Pebble (Boulder का compact version) में इसका support पहले से मौजूद है, और lego-cli client implementation भी जारी है
• 2026 Q1 के अंत में staging और Q2 में full deployment की योजना है
• यह मॉडल IoT, multi-tenant, और high-volume certificate issuance environments जैसे उन क्षेत्रों के लिए उपयुक्त है जहाँ मौजूदा तरीका अप्रभावी है

Let's Encrypt और ISRG की पृष्ठभूमि

• Let's Encrypt एक free, automated, open certificate authority (CA) है, जिसे non-profit ISRG संचालित करता है
• 2025 की annual report में ISRG ने इंटरनेट सुरक्षा से जुड़ी अपनी गतिविधियों का खुलासा किया

[GN⁺]

Hacker News राय

• यह खबर देखकर सच में बहुत खुशी हुई
  मैं, जब bind को authoritative nameserver के रूप में इस्तेमाल करता हूँ, तो उसे इस तरह configure करता हूँ कि हर webserver सिर्फ अपने हिस्से के TXT records ही update कर सके, इसके लिए hmac-secret को सीमित किया जाता है
  इससे अगर “bob” server compromise भी हो जाए, तब भी वह सिर्फ “bob” domain के लिए certificate जारी करवा सकता है
  configuration का एक उदाहरण update-policy के ज़रिए हर key को सिर्फ _acme-challenge subdomain बदलने तक सीमित करता है

  • अगर आप bind की बजाय अलग DNS server चलाने को तैयार हैं, तो acmedns इसी तरह का feature देता है
    नया account बनाने पर एक unique subdomain दिया जाता है, और challenge domain को उस subdomain पर CNAME कर देने से सिर्फ वही account उस zone को update कर सकता है

• मुझे लगता है कि यह feature operations की बड़ी असुविधा को हल करता है
  लेकिन admin account के identifier के उजागर होने की चिंता है
  username credentials जितना सुरक्षित नहीं रखा जाता, लेकिन यह attacker को target पहचानने का सुराग दे सकता है
  Shodan जैसी services ऐसे IDs को index करके reverse lookup service दे सकती हैं

  • CAA record का accounturi भी पहले से account identifier उजागर करता है, इसलिए कुछ हद तक यह पहले से public ही है
    बल्कि मुझे लगता है कि CAA और persist record format का एक जैसा होना बेहतर है
  • अच्छा होगा अगर users को असली account की जगह UUID जैसी कोई random ID दी जाए जिसे accounturi में इस्तेमाल किया जा सके
  • चूँकि यह वही account है जो ACME client बनाता है, इसलिए reverse lookup का जोखिम बहुत बड़ा नहीं लगता

• यह देखकर हैरानी हुई कि DNSSEC की आवश्यकता नहीं है
  पहले मुझे DNSSEC झंझट लगता था, लेकिन अब CAA, CERT, SSHFP, TXT जैसे root trust को प्रभावित करने वाले records इतने बढ़ गए हैं कि MITM हमलों का जोखिम बढ़ गया है
  खासकर बड़ी कंपनियाँ भी अक्सर DNSSEC ठीक से लागू नहीं करतीं, इसलिए कम से कम recommendation के रूप में तो इसका ज़िक्र होना चाहिए

  • RFC draft में भी DNSSEC के उपयोग को “SHOULD” के रूप में recommend किया गया है (लिंक)
  • DNS शुरू से ही TLS certificate issuance का single point of failure रहा है
    अगर attacker DNS पर कब्ज़ा कर ले, तो HTTP-01, TLS-ALPN-01, DNS-01 किसी भी तरीके से certificate forge किया जा सकता है
  • व्यक्तिगत रूप से मुझे DNSSEC से TLSA बेहतर तरीका लगता है, लेकिन browser support लगभग न होने का अफसोस है

• इस feature की वजह से इंटरनेट पर expose न किए गए LAN server certificates जारी करना बहुत आसान हो जाएगा
  आगे चलकर ज़्यादातर admin UI शायद DNS record में paste करने के लिए string अपने-आप generate कर दें और सीधे Let's Encrypt certificate मिल जाए

  • मैंने भी मिलते-जुलते environment में कोशिश की थी, लेकिन headscale magic DNS setup उम्मीद से ज़्यादा जटिल निकला, इसलिए आखिरकार manual renewal पर लौट आया

• certbot users इस feature के support status को GitHub issue में track कर सकते हैं

• पहले मैं short-lived certificates को लेकर संशय में था, लेकिन IP address certificates और HTTP-01 verification देखकर मेरी राय बदल गई
  अब मैं certificates को disk पर store नहीं करता, और background thread हर 24 घंटे में नया certificate check करता है
  इससे ऐसा self-hosted solution बनाया जा सकता है जिसमें user VM पर software deploy करके 5 मिनट के भीतर production में ला सके
  checkip.amazonaws.com जैसी service के साथ जोड़ने पर पूरी तरह automated deployment संभव है

  • लेकिन Let's Encrypt की issuance limits negotiable नहीं हैं, इसलिए बहुत बार request करने पर इंतज़ार करना पड़ने का जोखिम है
  • अगर certificates बिल्कुल store न किए जाएँ, तो availability LE uptime पर निर्भर हो जाएगी, इसलिए कम से कम थोड़ा storage ज़रूरी है

• आखिरकार internal-only web services के certificates को automate करना आसान होता दिख रहा है
  ऐसा लगता है कि इसने अब तक की सबसे बड़ी operational problem हल कर दी है, इसलिए यह बहुत स्वागतयोग्य है

• यहाँ जो कमी है, वह ACME account ownership verification है
  ज़्यादातर automation tools account खुद बना लेते हैं, इसलिए user आमतौर पर इसे सीधे handle नहीं करता, लेकिन अब ACME provider को account ownership साबित करने वाला credential देना पड़ेगा
  अगर Let's Encrypt domain-specific limited tokens नहीं बना सकता, तो हर domain के लिए अलग account बनाना पड़ सकता है

  • लेकिन ACME accounts में पहले से authentication credentials होते हैं, और DNS या HTTP challenge के ज़रिए domain ownership verify की जाती है, इसलिए
    अगर वे credentials या endpoint compromise हो जाएँ, तो वैसे भी उससे कहीं बड़ी समस्या पहले ही पैदा हो चुकी होगी

• Dynamic DNS users के लिए यह सचमुच शानदार खबर है
  उदाहरण के लिए Namecheap जैसी services में जहाँ change requests सिर्फ fixed IP से ही संभव थीं, अब एक बार setup करने के बाद automatic renewal संभव हो जाएगा
  homelab को modernize करते समय मैं इसे ज़रूर आज़माऊँगा

• अगर मैं गलत नहीं समझ रहा, तो क्या ऐसा नहीं है कि जो व्यक्ति मेरे domain के DNS server को control करता है, या
  Let's Encrypt और DNS server के बीच के traffic को intercept कर सकता है, वह मेरे domain के लिए TLS certificate जारी करवा सकता है?
  DNS-01 में भी यही बात है, लेकिन इस तरीके में तो attacker को बस अपने LE account को DNS response में डालना है, इसलिए यह और आसान लगता है
  क्या बेहतर नहीं होगा कि मैं अपना public certificate सीधे DNS में डाल दूँ?

  • अगर आप DNS provider पर भरोसा नहीं कर सकते, तो वही संबंध अपने-आप में समस्या है
    अगर कोई LE और DNS server के बीच के traffic पर MITM कर सकता है, तो स्थिति पहले से ही बहुत अधिक गंभीर है
  • DNS को control करने वाला व्यक्ति किसी भी CA से certificate जारी करवा सकता है
    अगर DNS बदला जा सकता है, तो certificate issuance रोकने का कोई तरीका नहीं है
  • अगर कोई DNS नियंत्रित कर सकता है, तो वह HTTP challenge भी पूरा कर सकता है, इसलिए व्यवहार में वह domain उसी का है
  • CA इस तरह के network attack mitigation के लिए कई जगहों से DNS lookup करते हैं
    Let's Encrypt कई सालों से ऐसा कर रहा है, और 2024 से यह सभी CAs के लिए अनिवार्य है
    CAB Forum नियम लिंक
  • यह तरीका असल में DANE अपनाता है
    संबंधित सामग्री