क्या DNSSEC की वजह से .de TLD ऑफलाइन है?

 (dnssec-analyzer.verisignlabs.com)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • nic.de DNSSEC Debugger का परिणाम 2026-05-06 00:38:26 UTC के आधार पर है, और यह रूट से .de होते हुए nic.de तक जाने वाली trust chain को चरण-दर-चरण सत्यापित करता है
  • रूट ज़ोन में DS=20326/SHA-256 और DS=38696/SHA-256 शामिल हैं, और .de delegation का DS keytag 26755 रूट के DNSKEY=54393 signature से सत्यापित होता है
  • .de ज़ोन में DNSKEY=26755/SEP और DNSKEY=32911 शामिल हैं, और DS=26755/SHA-256 .de के DNSKEY RRset को सत्यापित करता है
  • nic.de delegation में nameserver ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net शामिल हैं, और DS=26155/SHA-256 .de के DNSKEY=32911 से सत्यापित होता है
  • nic.de का A record सभी authoritative nameserver queries में 81.91.170.12 के रूप में पुष्टि हुआ, और RRSIG=36463 तथा DNSKEY=36463 उस RRset को सत्यापित करते हैं

nic.de DNSSEC सत्यापन प्रवाह

  • जाँच का लक्ष्य nic.de है, और DNSSEC Debugger स्क्रीन में Detail नियंत्रण विकल्प के रूप में more(+) और less(-) दिखते हैं
  • प्रदर्शित समय 2026-05-06 00:38:26 UTC है
  • nic.de की DNSSEC स्थिति dnsviz.net पर भी टेस्ट की जा सकती है

रूट से .de तक की trust chain

  • रूट ज़ोन DNSKEY सत्यापन

    • रूट(.) के DS=20326/SHA-256 और DS=38696/SHA-256 trust chain में शामिल हैं
    • j.root-servers.net पर ./DNSKEY query भेजी गई, 192.58.128.30 से 1139-byte response मिला, और response code NOERROR था
    • रूट ज़ोन में 3 DNSKEY records की पुष्टि हुई
      • DNSKEY keytag 54393, flags 256, algorithm 8
      • DNSKEY keytag 20326, flags 257, algorithm 8
      • DNSKEY keytag 38696, flags 257, algorithm 8
    • DNSKEY=20326/SEP और DNSKEY=38696/SEP trust chain में शामिल हुए, और क्रमशः DS=20326/SHA-256, DS=38696/SHA-256 से सत्यापित हुए
    • रूट DNSKEY RRset में 1 RRSIG है, और RRSIG=20326 तथा DNSKEY=20326/SEP उस DNSKEY RRset को सत्यापित करते हैं
    • DNSKEY=54393 भी trust chain में शामिल है

  • रूट से .de delegation की पुष्टि

    • k.root-servers.net पर nic.de/A query भेजी गई, 193.0.14.129 से 742-byte response मिला, answer section खाली था और authority section में .de delegation जानकारी शामिल थी
    • .de nameserver के रूप में a.nic.de, f.nic.de, l.de.net, n.de.net, s.de.net, z.nic.de लौटे
    • .de का DS record keytag 26755, algorithm 8, digest type 2, SHA-256 digest f341357809a5954311ccb82ade114c6c1d724a75c0395137aa3978035425e78d के साथ लौटा
    • .de DS RRset में RRSIG शामिल था, और signer रूट का DNSKEY=54393 था
    • additional section में .de nameserver के IPv4/IPv6 पते शामिल थे
      • a.nic.de: 194.0.0.53, 2001:678:2::53
      • f.nic.de: 81.91.164.5, 2a02:568:0:2::53
      • z.nic.de: 194.246.96.1, 2a02:568:fe02::de
      • l.de.net: 77.67.63.105, 2001:668:1f:11::105
      • n.de.net: 194.146.107.6, 2001:67c:1011:1::53
      • s.de.net: 195.243.137.26, 2003:8:14::53

  • .de DS RRset सत्यापन

    • b.root-servers.net पर de/DS query भेजी गई, 170.247.170.2 से 366-byte response मिला, और response code NOERROR था
    • रूट ज़ोन में .de के लिए 1 DS record की पुष्टि हुई
    • DS=26755/SHA-256 RSASHA256 algorithm का उपयोग करता है
    • .de DS RRset में 1 RRSIG है, और RRSIG=54393 तथा DNSKEY=54393 उस DS RRset को सत्यापित करते हैं
    • DS=26755/SHA-256 trust chain में शामिल है

  • .de DNSKEY RRset सत्यापन

    • f.nic.de पर de/DNSKEY query भेजी गई, 81.91.164.5 से 745-byte response मिला, और response code NOERROR था
    • .de में 2 DNSKEY records की पुष्टि हुई
      • DNSKEY keytag 32911, flags 256, algorithm 8, TTL 3600
      • DNSKEY keytag 26755, flags 257, algorithm 8, TTL 3600
    • DNSKEY=26755/SEP trust chain में शामिल हुआ, और DS=26755/SHA-256 DNSKEY=26755/SEP को सत्यापित करता है
    • .de DNSKEY RRset में 1 RRSIG है, और RRSIG=26755 तथा DNSKEY=26755/SEP उस RRset को सत्यापित करते हैं
    • DNSKEY=32911 trust chain में शामिल है

.de से nic.de तक जाने वाली delegation और DS सत्यापन

  • nic.de subzone की पुष्टि

    • l.de.net पर nic.de/A query भेजी गई, 77.67.63.105 से 464-byte response मिला, answer section खाली था और authority section में nic.de delegation जानकारी शामिल थी
    • nic.de nameserver के रूप में ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net लौटे
    • nic.de DS record keytag 26155, algorithm 8, digest type 2, SHA-256 digest 2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565d के साथ लौटा
    • nic.de DS RRset में RRSIG शामिल था, और signer .de का DNSKEY=32911 था
    • additional section में कुछ nic.de nameserver पते शामिल थे
      • ns1.denic.de: 77.67.63.106, 2001:668:1f:11::106
      • ns2.denic.de: 81.91.164.6, 2a02:568:0:2::54
      • ns3.denic.de: 195.243.137.27, 2003:8:14::106
    • l.de.net पर nic.de/DNSKEY query भेजने पर भी वही nic.de delegation, DS, RRSIG, और additional address जानकारी लौटी, और subzone nic.de की पुष्टि हुई

  • nic.de DS RRset सत्यापन

    • a.nic.de पर nic.de/DS query भेजी गई, 194.0.0.53 से 245-byte response मिला, और response code NOERROR था
    • de ज़ोन में nic.de के लिए 1 DS record की पुष्टि हुई
    • पुष्टि किया गया DS keytag 26155, algorithm 8, digest type 2 है, और SHA-256 आधारित रूप में दिखाया गया है
    • DS RRset में 1 RRSIG है, और RRSIG=32911 तथा DNSKEY=32911 DS RRset को सत्यापित करते हैं
    • DS=26155/SHA-256 trust chain में शामिल है
nic.de. 86400 IN DS (
  26155 8 2 2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565d
)

nic.de DNSKEY और record सत्यापन

  • nic.de DNSKEY सत्यापन

    • ns4.denic.net पर nic.de/DNSKEY query भेजी गई, 194.246.96.28 से 625-byte response मिला, और response code NOERROR था
    • nic.de में 2 DNSKEY records की पुष्टि हुई
    • keytag 26155 257 3 8 फ़ॉर्मेट का DNSKEY है, और DNSKEY=26155/SEP trust chain में शामिल है
    • DS=26155/SHA-256 DNSKEY=26155/SEP को सत्यापित करता है
    • DNSKEY RRset में 1 RRSIG है, और RRSIG=26155 तथा DNSKEY=26155/SEP DNSKEY RRset को सत्यापित करते हैं
    • DNSKEY=36463 भी trust chain में शामिल है
nic.de. 3600 IN DNSKEY (
  257 3 8 AwEAAb/xrM2MD+xm84YNYby6TxkMaC6PtzF2bB9WBB7ux7iqzhViob4GKvQ6L7CkXjyAxfKbTzrd
  vXoAPpsAPW4pkThReDAVp3QxvUKrkBM8/uWRF3wpaUoPsAHm1dbcL9aiW3lqlLMZjDEwDfU6lxLc
  Pg9d14fq4dc44FvPx6aYcymkgJoYvR6P1wECpxqlEAR2K1cvMtqCqvVESBQV/EUtWiALNuwR2Pbh
  wtBWJd+e8BdFI7OLkit4uYYux6Yu35uyGQ==
) ; keytag 26155

nic.de. 3600 IN DNSKEY (
  256 3 8 AwEAAdkJ06nJ8Cutng7f9HACMUhuYnF0CX7uCZ06CyauTxQIpOQpQBKI03/EPn8fI518pvOqxAO7
  XWaGsSovRyI3UPd963JZpYrEOcVDFPA2Qrz5eFj8MIBKH6HcQGnum0UFxmIRVaKT5K5WM+xeUeP5
  Xr4P54Jkyo18rz0LwzDp9gjj
) ; keytag 36463

  • nic.de A record और signature सत्यापन

    • ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net पर की गई सभी nic.de/A queries का response NOERROR था
    • nameserver-वार response source यह थे: ns1.denic.de से 77.67.63.106, ns2.denic.de से 81.91.164.6, ns3.denic.de से 195.243.137.27, ns4.denic.net से 194.246.96.28
    • सभी A queries में nic.de का A record मान 81.91.170.12 के रूप में पुष्टि हुआ
    • हर response में nic.de ज़ोन द्वारा signed RRSIG शामिल था, और A RRset में 1 RRSIG की पुष्टि हुई
    • RRSIG=36463 और DNSKEY=36463 A RRset को सत्यापित करते हैं
nic.de. 3600 IN A 81.91.170.12

nic.de. 3600 IN RRSIG (
  A 8 2 3600 20260519222346 20260505205346 36463 nic.de.
  VIyuPDO6Bf029ILioOvWPhkPmQctDIepz+bK/7s7GS1hHEIZrs/9pDGblfW19sjmVpJGIslYmiGh
  QUDTgJcv8lcWqrfUK3pTv9QxmYRDOMM/zTZz50hqfcNkvzL7dg/7A/yPoPk3aTMXH3pFNY0N2RnU
  t8THHOfUcu3w19fma4w=
)

  • authoritative nameserver और SOA response

    • nic.de के authoritative nameserver के रूप में ns1.denic.de, ns2.denic.de, ns3.denic.de, ns4.denic.net response में शामिल थे
    • ns3.denic.de, ns4.denic.net, ns2.denic.de पर nic.de/SOA query भेजी गई, और तीनों ने 507-byte response तथा NOERROR लौटाया
    • SOA record में ns1.denic.de. primary nameserver के रूप में और dns-operations.denic.de. responsible party के रूप में दिखता है
    • SOA मान serial 1778019826, refresh 10800, retry 1800, expire 3600000, minimum 1800 के साथ समान है
    • SOA response में भी RRSIG शामिल है, और signer 36463 nic.de. के रूप में दिखता है
nic.de. 3600 IN SOA (
  ns1.denic.de. dns-operations.denic.de.
  1778019826 ;serial
  10800 ;refresh
  1800 ;retry
  3600000 ;expire
  1800 ;minimum
)

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 1 시간 전
Hacker News टिप्पणियाँ

  • यह DNSSEC समस्या लग रही है, नेमसर्वर आउटेज नहीं। validating resolvers सभी .de नामों के लिए EDE के साथ SERVFAIL लौटा रहे हैं
    dig +cd amazon.de @8.8.8.8 और dig amazon.de @a.nic.de काम कर रहे हैं, इसलिए zone data सही-सलामत दिख रहा है। DENIC ने ZSK 33834 के साथ validate न होने वाला NSEC3 record का RRSIG वितरित कर दिया, इसलिए सभी validating resolvers जवाब ठुकरा रहे हैं
    इसका बीच-बीच में काम करना anycast से मेल खाता है। कुछ [a-n].nic.de instances अभी भी पुराने सही signatures दे रहे हैं, इसलिए retry पर कभी-कभी सही authoritative server तक पहुँचा जा रहा होगा। DENIC FAQ के अनुसार .de ZSK हर 5 हफ्ते में pre-publish तरीके से rotate होता है, इसलिए इसमें rollover failure की गंध आ रही है

    • एक ही जगह की एक configuration गलती से एक बड़े आर्थिक क्षेत्र की बाहरी पहुँच ठप हो गई। यह स्थानीय समय के हिसाब से शाम में हुआ, और cache TTL को देखते हुए भी सुबह तक ठीक किया जा सकता है, इसलिए नुकसान का दायरा कुछ हद तक सीमित रहेगा
      फिर भी इस स्तर पर नाज़ुक इन्फ्रास्ट्रक्चर एक राजनीतिक जोखिम है। इंटरनेट की वह मशहूर खासियत कि वह “टूटी हुई जगह को bypass कर लेता है” यहाँ ठीक से काम नहीं करती। इस पर दिलचस्प postmortem आने की संभावना है
    • मैं 20 साल से IT में काम कर रहा हूँ, और यहाँ DNSSEC के अलावा एक भी acronym समझ नहीं आ रहा

  • लगता है DENIC टीम आज शाम पार्टी में थी। मज़े करें, लेकिन ज़्यादा नहीं करना चाहिए था
    https://bsky.app/profile/denic.de/post/3ml4r2lvcjg2h

    • यह दिलचस्प bus factor है कि emergency में ops change commit करने, बिगड़ी हुई maintenance को revert करने, या rollback करने लायक योग्यता, अनुभव और भरोसा रखने वाले लोग अगर सब के सब पूरी तरह होश में न हों तो क्या हो

  • मैंने कभी DNSSEC इस्तेमाल नहीं किया और न ही उसे implement करने की कोशिश की, लेकिन अगर मैं सही समझ रहा हूँ, तो क्या यह मूल रूप से decentralized DNS के ऊपर single point of failure certificate hierarchy चढ़ाने जैसा नहीं है? और अब उस certificate को manage करने वाले central organization की गड़बड़ी की वजह से लगभग सारे domain एक साथ टूट रहे हैं?

    • .de top-level domain स्वभाव से ही एक single organization संभालता है, और उसके nameserver गिर जाएँ तो हालात बहुत बेहतर नहीं होंगे। कुछ records नीचे के resolvers में cache रहेंगे, लेकिन सब नहीं और ज़्यादा देर तक भी नहीं
      DNSSEC उल्टा DNS को और decentralized बनाता है। DNSSEC के बिना भरोसेमंद जवाब सुनिश्चित करने के लिए आपको authoritative nameserver से सीधे पूछना पड़ता है। DNSSEC के साथ आप third-party caching resolver से query कर सकते हैं, और चूँकि केवल वैध signatures वाले जवाब ही सही होंगे, उन पर भरोसा किया जा सकता है
      इसी तरह DNSSEC के बिना domain owner को authoritative nameserver पर पूरी तरह भरोसा करना पड़ता है, क्योंकि वे trusted results को आसानी से fake कर सकते हैं। DNSSEC के साथ authoritative nameserver पर काफ़ी कम भरोसा करना पड़ता है [0], इसलिए उसका कुछ हिस्सा सुरक्षित तरीके से third party पर host किया जा सकता है
      [0]: https://news.ycombinator.com/item?id=47409728
    • DNSSEC, DNS के decentralization की मात्रा नहीं बदलता। DNS मूल रूप से hierarchical structure था। अगर cache न हो, तो हर DNS query root DNS server query से शुरू होती है
      foo.com या foo.de के लिए पहले root server से पूछकर .com और .de को संभालने वाले nameserver पता किए जाते हैं, फिर .com या .de server से foo.com और foo.de के nameserver पूछे जाते हैं। DNSSEC बस इन जवाबों पर signatures जोड़ता है और अगले चरण के जवाबों को authenticate करने के लिए public keys जोड़ता है
      root nameserver IP की सूची हर local recursive DNS resolver में शामिल होती है। यह सूची सालों में धीरे-धीरे बदलती है। DNSSEC में इसी सूची में root servers की public keys भी शामिल होती हैं, और ये भी धीरे-धीरे rotate होती हैं
    • अभी जो दिख रहा है, वह decentralization के काम करने जैसा ही है। समस्या .de top-level domain operator में है, इसलिए असर सिर्फ उसी top-level domain पर है
      DNS इस तरह decentralized नहीं है कि एक top-level domain infrastructure को कई organizations चलाएँ। top-level domain हमेशा एक ही entity चलाती है। .com और .net को Verisign चलाता है
      इसलिए operator की समस्या असर के दायरे को बदलती नहीं है

  • Cloudflare अब 1.1.1.1 resolver पर DNSSEC validation disable कर रहा है: https://www.cloudflarestatus.com/incidents/vjrk8c8w37lz

    • इस बिंदु पर तो DNSSEC को लगभग खत्म मान लेना चाहिए
    • अगर यह DNSSEC समस्या किसी threat actor की वजह से निकली, तो हो सकता है मकसद ऐसे downstream impact पैदा करना रहा हो

  • Thomas Ptacek का DNSSEC पर मशहूर लेख यहाँ छोड़ रहा हूँ
    https://sockpuppet.org/blog/2015/01/15/against-dnssec/

  • यह पागलपन है। याद भी नहीं कि ऐसा पहले कभी हुआ हो, और अभी तक ठीक भी नहीं हुआ? आर्थिक नज़रिए से .de, .com के बाद सबसे महत्वपूर्ण unrestricted domain हो सकता है। लाखों कंपनियाँ मानो “down” हो गई हैं

  • हाँ, DENIC की DNSSEC failure की वजह से सभी .de domains डाउन हो गए
    https://dnsviz.net/d/de/dnssec/

  • शायद मैं बहुत जल्दी आ गया। इस thread में अभी तक tptacek का एक भी DNSSEC भाषण नहीं है

    • मुझे लंबा बोलने की क्या ज़रूरत है? कभी-कभी दुनिया खुद ही मेरी तरफ़ से बोल देती है
    • क्या यह घटना खुद ही सब कुछ नहीं कह रही?

  • मेरे domain की वजह से services और apps से बिल्कुल connect नहीं हो पा रहा था, तो मैं बहुत stress में था। सिर्फ phone data पर काम कर रहा था, लेकिन अच्छा है कि इस बार गलती मेरी नहीं थी

    • फिर भी हम जर्मन हैं, इसलिए दोष देने के लिए किसी न किसी की ज़रूरत है

  • https://status.denic.de/ पर DNS Nameservice अब “Partial Service Disruption” दिखाया जा रहा है
    सुधार: अब यह “Service Disruption” में बदल गया है

    • दुनिया की तीसरी सबसे बड़ी अर्थव्यवस्था की सारी sites डाउन हों और फिर भी यह “partial” service disruption कहलाए :D
    • पूरा जर्मनी ऑफ़लाइन है और DENIC इसे “Partial Service Disruption” कह रहा है। अभिव्यक्ति का अपना ही अंदाज़ है
    • अब “Server Not Found” दिख रहा है
    • “All Systems Operational”