사례2건

2건 중 1~2번째

1. IL-0363 static.crates.io 의 DNS 레코드가 10~15분 동안 해석되지 않아 crate 를 받지 못했다

   Rust Project2023

   증상

   2023-01-25 09:15 UTC 에 crates.io 운영 인프라에 변경을 배포하는 동안 static.crates.io 의 DNS 레코드가 해석되지 않았다. 사용자는 crate 를 내려받지 못해 빌드가 실패했다.

   DNS 조회 실패

   촉발

   Rust 인프라 팀이 Terraform 으로 운영 환경에 현재 CDN 의 새 TLS 인증서와 바뀐 DNS 레코드를 함께 배포했다. Terraform 은 기존 인증서와 DNS 레코드를 먼저 지운 뒤 새 인증서를 발급했다.

   원인

   설정 변경

   구성 요소

   TerraformDNS 서버와 레코드CDN 과 엣지 네트워크

   기여 요인

   파괴적 변경 보호 장치 부재스테이징 불일치

   조치

   • Terraform 이 배포를 마치고 static.crates.io 의 새 DNS 레코드를 만들자 장애가 저절로 풀렸다.

   후속 조치

   • 운영에 변경을 배포하는 절차, 특히 Git 커밋을 고르는 방법과 변경 내역을 검토하는 방법을 문서로 남긴다. 절차를 정해 두고 계속 고쳐 나가 같은 문제를 피한다.
   • 스테이징에서 따로 만들고 시험한 변경은 운영에도 하나씩 차례대로 배포하고, 이 규칙을 문서에 넣는다.
   • main 브랜치에 병합한 변경은 운영에도 반드시 배포해, Git 에 있는 구성과 실제로 배포된 것이 벌어지지 않게 한다.

   교훈

   TLS 인증서 변경과 DNS 레코드 변경을 따로 배포했다면 이번 장애를 피할 수 있었다. 운영 환경을 master 의 최신 커밋에 고정하면서 여러 변경이 한꺼번에 들어갔고, 병합한 변경을 그때그때 배포하지 않아 운영과 스테이징이 너무 벌어졌다. 팀이 얻은 교훈은 세 가지다. 배포 절차를 문서로 정해야 한다. 스테이징에서 따로 시험한 변경은 운영에도 하나씩 차례로 배포해야 한다. 병합한 변경은 운영에도 배포해야 한다.

   사례 보기
2. IL-0250 slack.com 에 DNSSEC 를 켠 뒤 일부 재귀 리졸버에서 slack.com 이름이 풀리지 않아 일부 사용자가 24시간 동안 Slack 에 접속하지 못했다

   Slack2021

   증상

   2021년 9월 30일 slack.com 의 DS 레코드를 DNS 등록 기관에 올린 직후 Customer Experience 팀에 사용자 신고가 들어왔다. Slack 클라이언트에 "ERR_NAME_NOT_RESOLVED" 오류가 뜬다는 신고였다. 그런데 DNSSEC 검증을 강제하는 이름 해석 모니터링과 DNSSEC 프로브는 모두 정상으로 나왔다.

   DNS 조회 실패

   촉발

   2021년 9월 30일 Traffic Engineering 팀이 세 번째 시도로 slack.com 의 Route53 영역과 NS1 하위 위임 영역에 DNSSEC 서명을 켜고, 세 시간 뒤 DNS 등록 기관에 slack.com 의 DS 레코드를 올렸다.

   원인

   소프트웨어 결함

   구성 요소

   DNS 서버와 레코드재귀 DNS 리졸버 서비스Terraform

   기여 요인

   스테이징 불일치미검증 가정수동 조치 악화롤백 무효디버그 접근 제한

   감지

   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 타입 비트맵에 정확히 담는 것만이 이 모호함을 피하는 길이다.

   사례 보기

원인별2