사례1건
1건 중 1~1번째
IL-0250slack.com 에 DNSSEC 를 켠 뒤 일부 재귀 리졸버에서 slack.com 이름이 풀리지 않아 일부 사용자가 24시간 동안 Slack 에 접속하지 못했다Slack2021- 증상
2021년 9월 30일 slack.com 의 DS 레코드를 DNS 등록 기관에 올린 직후 Customer Experience 팀에 사용자 신고가 들어왔다. Slack 클라이언트에 "ERR_NAME_NOT_RESOLVED" 오류가 뜬다는 신고였다. 그런데 DNSSEC 검증을 강제하는 이름 해석 모니터링과 DNSSEC 프로브는 모두 정상으로 나왔다.
- 촉발
2021년 9월 30일 Traffic Engineering 팀이 세 번째 시도로 slack.com 의 Route53 영역과 NS1 하위 위임 영역에 DNSSEC 서명을 켜고, 세 시간 뒤 DNS 등록 기관에 slack.com 의 DS 레코드를 올렸다.
- 원인
- 구성 요소
- 기여 요인
- 감지
DS 레코드를 올린 직후 Customer Experience 팀이 ERR_NAME_NOT_RESOLVED 를 본다는 사용자 신고를 받았다. 이때 DNSSEC 프로브는 정상으로 나왔다. 서명을 되돌린 뒤에는 외부 DNS·DNSSEC 해석 프로브가 여러 리졸버의 해석 실패를 알려 Traffic 팀이 호출됐다.
- 조치
- 등록 기관에서 slack.com 의 DS 레코드를 내려 .com 영역에서 지웠다.
- slack.com 권한 영역과 위임 영역의 DNSSEC 서명을 되돌려 마지막 정상 설정으로 돌렸다.
- 주요 ISP 와 공개 DNS 리졸버 운영자에게 연락해 slack.com 의 캐시 레코드를 모두 비워 달라고 요청했다.
- Google 8.8.8.8 과 Cloudflare 1.1.1.1 처럼 캐시 비우기 사이트를 둔 리졸버는 팀이 직접 캐시를 비웠다.
- 교훈
Slack 은 와일드카드 레코드가 있는 도메인을 slack.com 보다 먼저 시험하지 않은 것을 실수로 꼽았다. .com 영역의 DS 레코드는 리졸버에 최대 24시간 캐시되므로, DS 레코드를 내린 뒤에도 그 시간 동안은 권한 영역에서 DNSKEY 를 지우면 안 된다. 영역에 서명을 다시 켜도 DS 레코드의 TTL 에는 영향이 없다. Terraform 으로 DNS 를 관리하면 Route53 콘솔이 서명을 끌 때 띄우는 경고를 보지 못한다. 리졸버마다 NSEC 응답을 다르게 해석해도 규격에 맞을 수 있으므로, 권한 이름 서버가 실제로 있는 레코드 타입을 NSEC 타입 비트맵에 정확히 담는 것만이 이 모호함을 피하는 길이다.
이 사례에서 가장 많이 나오는 구성 요소: DNS 서버와 레코드, 재귀 DNS 리졸버 서비스. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.