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을 감안해도 아침까지는 고칠 수 있을 테니 피해 범위는 어느 정도 제한될 듯함
그래도 이 수준에서 취약한 인프라는 정치적 위험임. 인터넷이 “손상된 곳을 우회한다”는 유명한 특성이 여기서는 잘 작동하지 않음. 흥미로운 사후 분석이 나올 것 같음
긴급 상황에서 운영 변경을 커밋하거나, 망친 유지보수를 되돌리거나, 롤백할 만큼 자격·경험·신뢰를 갖춘 사람들이 전부 완전히 맨정신이 아닌 시나리오라니 흥미로운 버스 팩터임
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이 운영함
그러니 운영자에게 생긴 문제가 영향 범위를 바꾸지는 않음
Hacker News 의견들
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에 따르면.deZSK는 5주마다 사전 공개 방식으로 교체되니, 롤오버 실패 냄새가 남그래도 이 수준에서 취약한 인프라는 정치적 위험임. 인터넷이 “손상된 곳을 우회한다”는 유명한 특성이 여기서는 잘 작동하지 않음. 흥미로운 사후 분석이 나올 것 같음
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
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
Thomas Ptacek의 DNSSEC 관련 명문을 여기 남겨둠
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
미친 일임. 이런 사고가 전에 있었는지 기억도 안 나는데 아직도 안 고쳐졌나?
.de는 경제적 관점에서.com다음으로 중요한 제한 없는 도메인일 가능성이 큼. 수백만 개 기업이 “다운”된 셈임.com이 내려갔던 게 기억남https://archive.nytimes.com/www.nytimes.com/library/cyber/we...
.de도메인을 NXDOMAIN으로 해석하게 만든 적이 있는 듯함: https://www.theregister.com/2010/05/12/germany_top_level_dom...맞음, DENIC의 DNSSEC 실패 때문에 모든
.de도메인이 내려감https://dnsviz.net/d/de/dnssec/
대체 링크:
https://www.cyberciti.biz/media/new/cms/2017/04/dns.jpg
.de도메인이 사칭 가능 상태가 됐다”고 표현해야 할 듯함너무 일찍 온 듯함. 아직 이 스레드에 tptacek의 DNSSEC 장광설이 하나도 없음
내 도메인으로 서비스와 앱에 전혀 연결이 안 돼서 엄청 스트레스받고 있었음. 휴대폰 데이터로만 동작했는데, 이번엔 내 잘못이 아니라서 다행임
https://status.denic.de/에서 DNS Nameservice가 이제 “Partial Service Disruption”이라고 표시됨
수정: 이제 “Service Disruption”으로 바뀜