# .de TLD가 DNSSEC 때문에 오프라인인가? > Clean Markdown view of GeekNews topic #29212. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29212](https://news.hada.io/topic?id=29212) - GeekNews Markdown: [https://news.hada.io/topic/29212.md](https://news.hada.io/topic/29212.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-06T10:04:19+09:00 - Updated: 2026-05-06T10:04:19+09:00 - Original source: [dnssec-analyzer.verisignlabs.com](https://dnssec-analyzer.verisignlabs.com/nic.de) - Points: 1 - Comments: 1 ## Topic Body - **nic.de** DNSSEC Debugger 결과는 2026-05-06 00:38:26 UTC 기준이며, 루트에서 `.de`를 거쳐 `nic.de`까지 이어지는 신뢰 체인을 단계별로 검증함 - 루트 영역은 **DS=20326/SHA-256**와 **DS=38696/SHA-256**를 포함하고, `.de` 위임의 DS `keytag 26755`는 루트 `DNSKEY=54393` 서명으로 검증됨 - `.de` 영역은 `DNSKEY=26755/SEP`와 `DNSKEY=32911`을 포함하며, `DS=26755/SHA-256`가 `.de`의 **DNSKEY RRset**을 검증함 - `nic.de` 위임에는 네임서버 `ns1.denic.de`, `ns2.denic.de`, `ns3.denic.de`, `ns4.denic.net`가 포함되고, **DS=26155/SHA-256**가 `.de`의 `DNSKEY=32911`로 검증됨 - `nic.de`의 **A 레코드**는 모든 권한 네임서버 질의에서 `81.91.170.12`로 확인되며, `RRSIG=36463`과 `DNSKEY=36463`이 해당 RRset을 검증함 --- ### [nic.de](https://dnssec-analyzer.verisignlabs.com/nic.de) DNSSEC 검증 흐름 - 검사 대상은 **nic.de**이며, DNSSEC Debugger 화면에는 `Detail` 조절 항목으로 `more(+)`와 `less(-)`가 표시됨 - 표시 시간은 **2026-05-06 00:38:26 UTC**임 - `nic.de`의 DNSSEC 상태는 [dnsviz.net](http://dnsviz.net/d/nic.de/dnssec/)에서도 테스트할 수 있음 ### 루트에서 `.de`까지의 신뢰 체인 - ## 루트 영역 DNSKEY 검증 - 루트(`.`)의 **DS=20326/SHA-256**와 **DS=38696/SHA-256**가 신뢰 체인에 포함됨 - `j.root-servers.net`에 `./DNSKEY`를 질의해 `192.58.128.30`에서 1139바이트 응답을 받았고, 응답 코드는 `NOERROR`였음 - 루트 영역에서 DNSKEY 레코드 3개가 확인됨 - `DNSKEY` keytag `54393`, 플래그 `256`, 알고리듬 `8` - `DNSKEY` keytag `20326`, 플래그 `257`, 알고리듬 `8` - `DNSKEY` keytag `38696`, 플래그 `257`, 알고리듬 `8` - `DNSKEY=20326/SEP`와 `DNSKEY=38696/SEP`가 신뢰 체인에 포함됐고, 각각 `DS=20326/SHA-256`, `DS=38696/SHA-256`로 검증됨 - 루트 `DNSKEY RRset`에는 `RRSIG` 1개가 있으며, `RRSIG=20326`과 `DNSKEY=20326/SEP`가 해당 `DNSKEY RRset`을 검증함 - `DNSKEY=54393`도 신뢰 체인에 포함됨 - ## 루트에서 `.de` 위임 확인 - `k.root-servers.net`에 `nic.de/A`를 질의해 `193.0.14.129`에서 742바이트 응답을 받았고, 답변 섹션은 비어 있으며 권한 섹션에 `.de` 위임 정보가 포함됨 - `.de` 네임서버로 `a.nic.de`, `f.nic.de`, `l.de.net`, `n.de.net`, `s.de.net`, `z.nic.de`가 반환됨 - `.de`의 DS 레코드는 `keytag 26755`, 알고리듬 `8`, digest type `2`, SHA-256 digest `f341357809a5954311ccb82ade114c6c1d724a75c0395137aa3978035425e78d`로 반환됨 - `.de` DS RRset에는 `RRSIG`가 포함됐고, 서명자는 루트의 `DNSKEY=54393`임 - 추가 섹션에는 `.de` 네임서버의 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`를 질의해 `170.247.170.2`에서 366바이트 응답을 받았고, 응답 코드는 `NOERROR`였음 - 루트 영역에서 `.de`에 대한 DS 레코드 1개가 확인됨 - `DS=26755/SHA-256`는 `RSASHA256` 알고리듬을 사용함 - `.de` DS RRset에는 `RRSIG` 1개가 있으며, `RRSIG=54393`과 `DNSKEY=54393`가 해당 DS RRset을 검증함 - `DS=26755/SHA-256`가 신뢰 체인에 포함됨 - ## `.de` DNSKEY RRset 검증 - `f.nic.de`에 `de/DNSKEY`를 질의해 `81.91.164.5`에서 745바이트 응답을 받았고, 응답 코드는 `NOERROR`였음 - `.de`에서 DNSKEY 레코드 2개가 확인됨 - `DNSKEY` keytag `32911`, 플래그 `256`, 알고리듬 `8`, TTL `3600` - `DNSKEY` keytag `26755`, 플래그 `257`, 알고리듬 `8`, TTL `3600` - `DNSKEY=26755/SEP`가 신뢰 체인에 포함됐고, `DS=26755/SHA-256`가 `DNSKEY=26755/SEP`를 검증함 - `.de` `DNSKEY RRset`에는 `RRSIG` 1개가 있으며, `RRSIG=26755`와 `DNSKEY=26755/SEP`가 해당 RRset을 검증함 - `DNSKEY=32911`이 신뢰 체인에 포함됨 ### `.de`에서 `nic.de`로 이어지는 위임과 DS 검증 - ## `nic.de` 하위 영역 확인 - `l.de.net`에 `nic.de/A`를 질의해 `77.67.63.105`에서 464바이트 응답을 받았고, 답변 섹션은 비어 있으며 `nic.de` 위임 정보가 권한 섹션에 포함됨 - `nic.de` 네임서버로 `ns1.denic.de`, `ns2.denic.de`, `ns3.denic.de`, `ns4.denic.net`가 반환됨 - `nic.de` DS 레코드는 `keytag 26155`, 알고리듬 `8`, digest type `2`, SHA-256 digest `2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565d`로 반환됨 - `nic.de` DS RRset에는 `RRSIG`가 포함됐고, 서명자는 `.de`의 `DNSKEY=32911`임 - 추가 섹션에는 일부 `nic.de` 네임서버 주소가 포함됨 - `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`를 질의했을 때도 같은 `nic.de` 위임, DS, `RRSIG`, 추가 주소 정보가 반환됐고, 하위 영역 `nic.de`가 확인됨 - ## `nic.de` DS RRset 검증 - `a.nic.de`에 `nic.de/DS`를 질의해 `194.0.0.53`에서 245바이트 응답을 받았고, 응답 코드는 `NOERROR`였음 - `de` 존에서 `nic.de`에 대한 DS 레코드 1개가 확인됨 - 확인된 DS는 `keytag 26155`, 알고리듬 `8`, digest type `2`이며, `SHA-256` 기반으로 표시됨 - `DS RRset`에는 `RRSIG` 1개가 있으며, `RRSIG=32911`과 `DNSKEY=32911`이 `DS RRset`을 검증함 - `DS=26155/SHA-256`이 신뢰 체인에 포함됨 ```dns nic.de. 86400 IN DS ( 26155 8 2 2f06c8cdf8673a2e98d72c8b7ab6067d9318458b3d9edccde1c5ef793c0c565d ) ``` ### `nic.de` DNSKEY와 레코드 검증 - ## `nic.de` DNSKEY 검증 - `ns4.denic.net`에 `nic.de/DNSKEY`를 질의해 `194.246.96.28`에서 625바이트 응답을 받았고, 응답 코드는 `NOERROR`였음 - `nic.de`에서 DNSKEY 레코드 2개가 확인됨 - `keytag 26155`는 `257 3 8` 형식의 DNSKEY이며, `DNSKEY=26155/SEP`가 신뢰 체인에 포함됨 - `DS=26155/SHA-256`이 `DNSKEY=26155/SEP`를 검증함 - `DNSKEY RRset`에는 `RRSIG` 1개가 있으며, `RRSIG=26155`와 `DNSKEY=26155/SEP`가 `DNSKEY RRset`을 검증함 - `DNSKEY=36463`도 신뢰 체인에 포함됨 ```dns nic.de. 3600 IN DNSKEY ( 257 3 8 AwEAAb/xrM2MD+xm84YNYby6TxkMaC6PtzF2bB9WBB7ux7iqzhViob4GKvQ6L7CkXjyAxfKbTzrd vXoAPpsAPW4pkThReDAVp3QxvUKrkBM8/uWRF3wpaUoPsAHm1dbcL9aiW3lqlLMZjDEwDfU6lxLc Pg9d14fq4dc44FvPx6aYcymkgJoYvR6P1wECpxqlEAR2K1cvMtqCqvVESBQV/EUtWiALNuwR2Pbh wtBWJd+e8BdFI7OLkit4uYYux6Yu35uyGQ== ) ; keytag 26155 ``` ```dns nic.de. 3600 IN DNSKEY ( 256 3 8 AwEAAdkJ06nJ8Cutng7f9HACMUhuYnF0CX7uCZ06CyauTxQIpOQpQBKI03/EPn8fI518pvOqxAO7 XWaGsSovRyI3UPd963JZpYrEOcVDFPA2Qrz5eFj8MIBKH6HcQGnum0UFxmIRVaKT5K5WM+xeUeP5 Xr4P54Jkyo18rz0LwzDp9gjj ) ; keytag 36463 ``` - ## `nic.de` A 레코드와 서명 검증 - `ns1.denic.de`, `ns2.denic.de`, `ns3.denic.de`, `ns4.denic.net`에 대한 `nic.de/A` 질의가 모두 `NOERROR`로 응답됨 - 네임서버별 응답 출처는 `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` 질의에서 `nic.de`의 A 레코드 값은 `81.91.170.12`로 확인됨 - 각 응답은 `nic.de` 존이 서명한 RRSIG를 포함하며, `A RRset`에는 `RRSIG` 1개가 확인됨 - `RRSIG=36463`과 `DNSKEY=36463`이 `A RRset`을 검증함 ```dns nic.de. 3600 IN A 81.91.170.12 ``` ```dns nic.de. 3600 IN RRSIG ( A 8 2 3600 20260519222346 20260505205346 36463 nic.de. VIyuPDO6Bf029ILioOvWPhkPmQctDIepz+bK/7s7GS1hHEIZrs/9pDGblfW19sjmVpJGIslYmiGh QUDTgJcv8lcWqrfUK3pTv9QxmYRDOMM/zTZz50hqfcNkvzL7dg/7A/yPoPk3aTMXH3pFNY0N2RnU t8THHOfUcu3w19fma4w= ) ``` - ## 권한 네임서버와 SOA 응답 - `nic.de`의 권한 네임서버로 `ns1.denic.de`, `ns2.denic.de`, `ns3.denic.de`, `ns4.denic.net`가 응답에 포함됨 - `ns3.denic.de`, `ns4.denic.net`, `ns2.denic.de`에 `nic.de/SOA`를 질의했으며, 모두 507바이트 응답과 `NOERROR`를 반환함 - SOA 레코드는 `ns1.denic.de.`를 주 네임서버로, `dns-operations.denic.de.`를 담당자로 표시함 - SOA 값은 `serial 1778019826`, `refresh 10800`, `retry 1800`, `expire 3600000`, `minimum 1800`으로 동일함 - SOA 응답에도 `RRSIG`가 포함되며, 서명자는 `36463 nic.de.`로 표시됨 ```dns nic.de. 3600 IN SOA ( ns1.denic.de. dns-operations.denic.de. 1778019826 ;serial 10800 ;refresh 1800 ;retry 3600000 ;expire 1800 ;minimum ) ``` ## Comments ### Comment 56908 - Author: neo - Created: 2026-05-06T10:04:20+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48027897) - DNSSEC 문제로 보이고, 네임서버 장애는 아닌 듯함. 검증하는 리졸버들이 모든 `.de` 이름에 대해 EDE와 함께 `SERVFAIL`을 반환하고 있음 `dig +cd amazon.de @8.8.8.8`와 `dig amazon.de @a.nic.de`는 동작하므로 존 데이터는 온전해 보임. DENIC이 ZSK 33834로 검증되지 않는 **NSEC3 레코드의 RRSIG**를 배포했고, 그래서 모든 검증 리졸버가 응답을 거부하는 상황임 간헐적으로 되는 건 애니캐스트와 맞음. 일부 `[a-n].nic.de` 인스턴스가 아직 이전의 정상 서명을 내보내서, 재시도 때 가끔 정상 권한 서버에 닿는 것 같음. DENIC FAQ에 따르면 `.de` ZSK는 5주마다 사전 공개 방식으로 교체되니, **롤오버 실패** 냄새가 남 - 한 곳의 설정 실수 하나로 주요 경제권의 외부 접근성이 날아간 셈임. 현지 시간 저녁에 발생했고, 캐시 TTL을 감안해도 아침까지는 고칠 수 있을 테니 피해 범위는 어느 정도 제한될 듯함 그래도 이 수준에서 **취약한 인프라**는 정치적 위험임. 인터넷이 “손상된 곳을 우회한다”는 유명한 특성이 여기서는 잘 작동하지 않음. 흥미로운 사후 분석이 나올 것 같음 - IT 일을 20년 했는데 여기서 **DNSSEC** 말고는 약어를 하나도 못 알아듣겠음 - DENIC 팀이 오늘 저녁 파티에 있었던 듯함. 신나게 놀되, 너무 과하진 말았어야 함 [https://bsky.app/profile/denic.de/post/3ml4r2lvcjg2h]() - 긴급 상황에서 운영 변경을 커밋하거나, 망친 유지보수를 되돌리거나, 롤백할 만큼 자격·경험·신뢰를 갖춘 사람들이 전부 완전히 맨정신이 아닌 시나리오라니 흥미로운 **버스 팩터**임 - DNSSEC를 써본 적도 없고 구현하려고 애쓴 적도 없는데, 이해한 게 맞다면 원래 탈중앙화된 DNS 위에 **단일 장애점 인증서 계층**을 얹은 셈 아닌가 싶음. 이제 그 인증서를 관리하는 중앙 조직 장애 때문에 사실상 모든 도메인이 같이 깨지는 상황임? - `.de` 최상위 도메인은 본질적으로 단일 조직이 관리하고, 그 네임서버가 내려가도 상황은 크게 낫지 않음. 일부 레코드는 하위 리졸버에 캐시되겠지만 전부는 아니고 오래가지도 않음 DNSSEC는 오히려 DNS를 더 탈중앙화함. DNSSEC가 없으면 신뢰할 수 있는 응답을 보장하려면 권한 네임서버에 직접 물어야 함. DNSSEC가 있으면 제3자 캐싱 리졸버에 질의해도, 정당한 응답만 유효한 서명을 가지므로 신뢰할 수 있음 마찬가지로 DNSSEC가 없으면 도메인 소유자는 권한 네임서버를 절대적으로 신뢰해야 함. 그 서버들이 신뢰된 결과를 쉽게 위조할 수 있기 때문임. DNSSEC가 있으면 권한 네임서버를 훨씬 덜 신뢰해도 되므로 [0], 일부를 제3자에게 안전하게 호스팅할 수 있음 [0]: [https://news.ycombinator.com/item?id=47409728]() - DNSSEC는 DNS의 탈중앙화 정도를 바꾸지 않음. DNS는 원래 **계층 구조**였음. 캐시가 없다면 모든 DNS 질의는 루트 DNS 서버 질의에서 시작함 `foo.com`이나 `foo.de`의 경우 먼저 루트 서버에 질의해 `.com`과 `.de`를 담당하는 네임서버를 알아내고, 그다음 `.com` 또는 `.de` 서버에 `foo.com`과 `foo.de`의 네임서버를 물어봄. DNSSEC가 하는 일은 이 응답들에 서명을 붙이고, 다음 단계 응답을 인증할 수 있도록 공개키를 추가하는 것뿐임 루트 네임서버 IP 목록은 모든 로컬 재귀 DNS 리졸버에 포함되어 있음. 이 목록은 수년에 걸쳐 천천히 바뀜. DNSSEC에서는 이 목록에 루트 서버들의 공개키도 포함되고, 이것도 천천히 교체됨 - 지금 보이는 건 **탈중앙화가 작동하는 모습**임. 문제는 `.de` 최상위 도메인 운영자에게 있고, 그래서 그 최상위 도메인만 영향받음 DNS는 하나의 최상위 도메인 인프라를 여러 조직이 운영하는 식으로 탈중앙화되어 있지 않음. 최상위 도메인은 항상 단일 주체가 운영함. `.com`과 `.net`은 Verisign이 운영함 그러니 운영자에게 생긴 문제가 영향 범위를 바꾸지는 않음 - Cloudflare가 이제 1.1.1.1 리졸버에서 **DNSSEC 검증을 비활성화**함: [https://www.cloudflarestatus.com/incidents/vjrk8c8w37lz]() - 이쯤 되면 DNSSEC는 끝났다고 봐도 될 듯함 - DNSSEC 문제가 위협 행위자 때문에 발생한 것으로 드러난다면, 이런 **하위 영향**을 노린 것일 수도 있음 - Thomas Ptacek의 DNSSEC 관련 명문을 여기 남겨둠 [https://sockpuppet.org/blog/2015/01/15/against-dnssec/]() - 미친 일임. 이런 사고가 전에 있었는지 기억도 안 나는데 아직도 안 고쳐졌나? `.de`는 경제적 관점에서 `.com` 다음으로 중요한 **제한 없는 도메인**일 가능성이 큼. 수백만 개 기업이 “다운”된 셈임 - 1997년 7월에 `.com`이 내려갔던 게 기억남 [https://archive.nytimes.com/www.nytimes.com/library/cyber/we...]() - DENIC은 2010년에 모든 `.de` 도메인을 **NXDOMAIN**으로 해석하게 만든 적이 있는 듯함: [https://www.theregister.com/2010/05/12/germany_top_level_dom...]() - 주요 DNSSEC 장애 목록이 잘 정리된 색인이 여기 있음: [https://ianix.com/pub/dnssec-outages.html]() - 이미 꽤 늦은 시간대였으니, 영향은 그리 크지 않았을 것 같음 - 맞음, DENIC의 DNSSEC 실패 때문에 모든 `.de` 도메인이 내려감 [https://dnsviz.net/d/de/dnssec/]() - [https://i.imgur.com/eAwdKEC.png]() 대체 링크: [https://www.cyberciti.biz/media/new/cms/2017/04/dns.jpg]() - 모두가 DNSSEC를 끌 테니, “모든 `.de` 도메인이 **사칭 가능 상태**가 됐다”고 표현해야 할 듯함 - 너무 일찍 온 듯함. 아직 이 스레드에 tptacek의 **DNSSEC 장광설**이 하나도 없음 - 내가 뭘 길게 떠들 필요가 있겠음? 가끔은 세상이 대신 떠들어 줌 - 이 사건 자체가 이미 말해주는 것 아닌가? - 내 도메인으로 서비스와 앱에 전혀 연결이 안 돼서 엄청 스트레스받고 있었음. 휴대폰 데이터로만 동작했는데, 이번엔 내 잘못이 아니라서 다행임 - 그래도 우리는 독일인이라 탓할 누군가가 필요함 - [https://status.denic.de/]()에서 DNS Nameservice가 이제 “Partial Service Disruption”이라고 표시됨 수정: 이제 “Service Disruption”으로 바뀜 - 세계 3위 경제권의 모든 사이트가 내려가도 여전히 “부분적” 서비스 장애라니 :D - 독일 전체가 오프라인인데 DENIC은 “Partial Service Disruption”이라고 함. 표현 방식 하나는 독특함 - 이제 “Server Not Found”라고 뜸 - “All Systems Operational”