DNSSEC की बदौलत सिर्फ़ एक ख़राब पैकेट एक असुरक्षित DNS सर्वर को डाउन कर सकता है

मूल लेख ↗ Hacker News चर्चा ↗

हाल ही में उजागर हुई DNSSEC standard की “KeyTrap” खामी एक crafted packet से validating resolvers का CPU exhaust कर सकती है, जिससे प्रमुख DNS software patch होने तक offline हो सकता है। Commenters का तर्क है कि यह DNSSEC की गहरी design समस्याएँ उजागर करता है—उच्च operational complexity, self‑DoS risks, low signing rates के कारण सीमित वास्तविक लाभ, और key management के लिए intermediaries पर निर्भरता—खासकर जब HTTPS, DoH/DoT, और CT पहले से ही अधिकांश user-facing security संभाल लेते हैं। अन्य लोग कहते हैं कि resolver और authoritative servers के बीच tamper detection तथा DANE जैसे mechanisms के लिए DNSSEC अभी भी महत्वपूर्ण है, लेकिन मानते हैं कि deployment असमान और अक्सर fragile है।

कमज़ोरी का दायरा

  • हमला केवल DNSSEC-validating recursive resolvers को प्रभावित करता है, सामान्य authoritative servers को नहीं।
  • Exploit (“KeyTrap”) DNSSEC में 20+ साल पुरानी एक design choice का दुरुपयोग करता है: validators multiple bad keys/signatures को chase और check करने में अनियंत्रित समय खर्च कर सकते हैं।
  • सभी प्रमुख validators (BIND, Unbound, dnsmasq, PowerDNS, आदि) प्रभावित थे क्योंकि वे spec का पालन कर रहे थे।
  • Patches ज़्यादातर validation work/time पर limits जोड़ते हैं; तकनीकी रूप से इससे implementations spec-noncompliant हो जाती हैं, जो classic memory bug के बजाय spec flaw को उजागर करता है।

DNSSEC का design और operational problems

  • DNSSEC को 1990 के दशक में offline signing को ध्यान में रखकर design किया गया था, क्योंकि crypto cost अधिक मानी गई थी; कुछ लोग इस architectural choice को “original sin” कहते हैं।
  • Key rollover और expiry को adoption में बड़ी बाधा बताया गया है: self‑DoS करना आसान, automate करना कठिन; CDS/CDNSKEY मदद करते हैं लेकिन उनका समर्थन कम है।
  • Misconfigurations और broken zones अस्पष्ट failures (“Internet is broken”) पैदा करते हैं, जिससे operators व्यवहार में validation disable कर देते हैं।
  • कुछ लोग DNSSEC को “footgun,” “infrastructure tax,” कहते हैं, और सुझाव देते हैं कि DNSSEC को ही high-severity liability माना जाए।

Security value बनाम WebPKI / DoH

  • DNSSEC समर्थक पक्ष:
    • resolver और authoritative servers के बीच tampering detection देता है; किसी zone की content पर “trust” करने का यही तरीका है।
    • DANE और DNS-based SSHFP/PGPKEY verification जैसे protocols को सक्षम करता है।
  • संदेहवादी पक्ष:
    • DNSSEC privacy या encryption नहीं देता; DoH/DoT/ODoH last mile को अधिक प्रभावी ढंग से protect करते हैं और deploy करना आसान है।
    • Web के लिए, TLS + CA + Certificate Transparency integrity को पहले ही संभालते हैं; गलत DNS answers आम तौर पर silent compromise के बजाय DoS बनते हैं।
    • DNSSEC downgrade/stripping attacks मौजूद हैं; validation ज़्यादातर recursive resolvers में होता है, end clients में नहीं।

Adoption और वास्तविक उपयोग

  • बड़े TLDs (.com, .net) की global DNSSEC signing बहुत कम बताई जाती है (लगभग कुछ प्रतिशत), जबकि कुछ ccTLDs (.nl, .se, .ch) कहीं अधिक हैं।
  • resolvers पर measured validation rates globally ~30–40% रिपोर्ट की जाती हैं, लेकिन आलोचकों का कहना है कि यह end-to-end client security के बराबर नहीं है।
  • इस पर बहस कि कई domains के लिए registrar-managed DNSSEC को “meaningful” adoption माना जाए या नहीं।

Alternatives और future directions

  • कुछ लोग DNSCurve या DNSCrypt को proper transport security वाले बेहतर designs के रूप में बढ़ावा देते हैं, लेकिन मानते हैं कि DoH ने उस niche को effectively “जीत” लिया है।
  • कई लोग तर्क देते हैं कि DNSSEC के WebPKI को replace करने की संभावना नहीं है; browsers में DANE experiments आज़माए गए और हटा दिए गए।
  • नए memory-safe DNS implementations (जैसे Rust-based resolvers) में रुचि है, लेकिन कई commenters ज़ोर देते हैं कि यह specific issue protocol design का है, memory safety का नहीं।