DNS 루트 키 10월 11일 교체(DNSSEC KSK-2024) — 자체 DNS 서버가 SERVFAIL 나기 전에 점검할 것
인터넷 DNS의 맨 꼭대기인 루트 존(root zone)이 10월 11일(일요일)부터 새 서명 키 KSK-2024(키 태그 38696)로 서명을 바꾼다. 2018년부터 쓰던 KSK-2017(키 태그 20326)은 이날부터 루트 DNSKEY 세트에 서명하지 않는다. IANA 일정표 기준이고, Cloudflare가 10월 6일 블로그 글로 다시 알렸다. 웹사이트를 운영하는 대부분은 할 일이 없다. 하지만 DNSSEC 검증을 직접 하는 리졸버를 돌리는 곳이 새 키를 믿지 않으면, 그날부터 그 리졸버를 쓰는 사용자 전원이 이름 풀이에 실패한다.
용어부터 짧게 짚는다. DNSSEC은 DNS 응답에 전자서명을 붙여, 응답이 중간에 위조되지 않았는지 리졸버가 검증하게 하는 확장 규격이다. 서명은 루트 → .com 같은 최상위 도메인 → 개별 도메인으로 사슬처럼 이어진다. 이 사슬의 출발점이 루트의 **KSK(Key Signing Key)**고, 리졸버가 "이 키만큼은 의심 없이 믿는다"고 미리 넣어 두는 값을 **트러스트 앵커(trust anchor)**라고 부른다. 출발점을 못 믿으면 그 아래 서명은 전부 검증할 수 없다. 그래서 루트 키 교체는 특정 도메인이 아니라 DNSSEC 검증 전체에 영향을 준다.
교체 일정 한눈에 보기
IANA가 공개한 롤오버 일정은 이렇다. 새 키를 2년 가까이 대기 상태로 미리 공개해 두고, 충분히 퍼진 뒤에 서명을 넘기는 방식이다.
| 단계 | 날짜 |
|---|---|
| KSK-2024 루트 존 공개 | 2025년 1월 11일 |
| RFC 5011 기준 자동 신뢰 가능 시점 | 2025년 2월 10일 |
| 서명 키 교체(KSK-2017 → KSK-2024) | 2026년 10월 11일 |
| KSK-2017 폐기(revoke) 표시 | 2027년 1월 11일 |
| KSK-2017 루트 존에서 제거 | 2027년 3월 22일 |
두 번째 줄의 RFC 5011은 리졸버가 트러스트 앵커를 스스로 갱신하는 자동 업데이트 규약이다. 루트 DNSKEY 세트에 새 키가 나타나면 바로 믿지 않고, 최소 30일 동안 계속 보이는지 지켜본 뒤에야 신뢰 목록에 올린다. 1월 11일 공개에 30일을 더한 날짜가 2월 10일인 이유다. Verisign이 7월 28일 공개한 관측 자료에서도 2025년 2월에 KSK-2024 채택이 급격히 늘었고, 공개 후 약 500일이 지난 시점에 새 키 채택률이 95%를 넘었다고 한다. ICANN도 보고 리졸버 기준 채택률 95% 이상이라는 수치를 냈다.
남은 5% 미만이 문제다. 같은 Verisign 자료에 따르면 2019년에 이미 폐기된 KSK-2010을 아직 들고 있는 리졸버가 약 3.5%였다. 한 번 넣은 앵커가 몇 년씩 방치되는 일이 실제로 꽤 있다는 뜻이다.
dig로 직접 확인해 본 결과
실행 환경은 macOS 26.4.1, 기본 내장 dig 9.10.6이다. 10월 9일 오전(KST)에 Cloudflare 1.1.1.1로 루트 DNSKEY를 조회했다.
dig @1.1.1.1 . DNSKEY +dnssec +multiline
응답에는 DNSKEY 4개와 서명(RRSIG) 1개가 들어 있었다. 결과를 정리하면 이렇다.
| 플래그 | 종류 | 키 태그 | 비고 |
|---|---|---|---|
| 257 | KSK | 20326 | KSK-2017, 현재 서명 키 |
| 257 | KSK | 38696 | KSK-2024, 10월 11일부터 서명 |
| 256 | ZSK | 8763 | 존 서명 키 |
| 256 | ZSK | 57780 | 존 서명 키 |
플래그 257은 SEP 비트가 켜진 KSK, 256은 ZSK라는 뜻이다. 두 KSK가 함께 공개돼 있다. DNSKEY 세트에 붙은 RRSIG의 서명 키 태그는 아직 20326이었다 — 교체 이틀 전 모습 그대로다. 응답 헤더에는 검증 성공을 뜻하는 ad 플래그도 붙어 있었다.
다음은 Cloudflare 원문이 안내한 RFC 8509 트러스트 앵커 센티널 검사다. 일부러 이름을 지어 둔 테스트 도메인을 조회해, 리졸버가 특정 키를 앵커로 갖고 있는지 응답 상태로 알아낸다.
dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer
dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer
1.1.1.1에서는 is-ta가 NOERROR와 A 레코드 2개를, not-ta가 SERVFAIL을 돌려줬다. 원문 설명대로 "38696을 신뢰한다"는 정상 판정이다. Cloudflare는 2024년 7월에 KSK-2024를 1.1.1.1의 내장 트러스트 앵커로 넣어 뒀다고 밝혔다.
흥미로운 건 작업용 맥의 기본 DNS 경로다. VPN의 DNS 중계를 거쳐 통신사 기본 DNS로 나가는 경로인데, 같은 센티널 질의에서 is-ta와 not-ta 둘 다 NOERROR가 나왔다. 응답에 ad 플래그가 없었고, 일부러 서명을 깨 둔 테스트 도메인 dnssec-failed.org도 정상 주소가 돌아왔다. 이 경로 어딘가에서 DNSSEC 검증을 하지 않는다는 뜻이다(중계 단계와 통신사 DNS 중 어느 쪽인지는 이 시험만으로 가를 수 없다). 검증을 안 하는 리졸버는 이번 교체로 깨질 일도 없다. 대신 DNSSEC이 막아 주는 위조 응답도 걸러지지 않는다는 건 별개 문제다.
Homebrew로 이미 설치돼 있던 unbound-anchor 1.22.0도 돌려 봤다. unbound-anchor -a ./root.key -v로 새 앵커 파일을 받으니 "success: the anchor is ok"와 함께 파일 안에 id 38696과 20326 두 KSK가 모두 VALID 상태로 기록됐다. 참고로 macOS 기본 delv(9.10.6)는 "no crypto support" 오류로 검증이 되지 않아 이 확인에서는 뺐다.
누가 영향받고, 깨지면 어떻게 보이나
영향받는 쪽은 DNSSEC 검증을 직접 하는 리졸버다. ICANN과 Verisign 자료가 꼽은 대표 소프트웨어와 앵커 파일 위치는 BIND(bind.keys), Unbound·PowerDNS Recursor(root.key), Knot Resolver(root.keys)다. Windows Server DNS처럼 트러스트 앵커를 직접 넣어 검증을 켠 경우도 원리는 같다.
반대로 1.1.1.1이나 Cloudflare Gateway DNS를 쓰는 사용자, 검증을 하지 않는 통신사 DNS를 그대로 쓰는 일반 가정은 따로 할 일이 없다. 도메인에 DNSSEC 서명을 켜 둔 웹사이트 운영자도 루트 키와는 관계가 없다.
실패하면 증상이 꽤 극단적이다. 새 키를 모르는 검증 리졸버는 10월 11일 이후 루트 DNSKEY 세트의 서명을 검증하지 못하고, 그 아래 모든 이름에 SERVFAIL을 돌려준다. Cloudflare 원문 표현을 빌리면 "어떤 최상위 도메인 아래 사이트든" 열리지 않는데, 다른 네트워크에서는 멀쩡하다. 원인을 모르면 "인터넷이 안 된다"는 장애 신고로 들어오기 쉽다.
특히 위험한 건 사람이 잊고 있던 곳이다. Cloudflare는 2018년 롤오버에서 소프트웨어 업그레이드나 서버 이전 과정에서 리졸버가 RFC 5011로 학습해 둔 앵커 상태를 잃어버리는 사례가 있었다고 적었다. 몇 년 전에 빌드한 컨테이너 이미지, 앵커 파일을 이미지 안에 굽고 상태 디렉터리는 영속화하지 않는 구성, 펌웨어 업데이트가 끊긴 네트워크 장비가 여기에 해당한다. 매번 새로 뜨는 컨테이너는 30일을 지켜볼 기회조차 없다.
우리 쪽에서 점검한다면
자체 리졸버가 하나라도 있다면, 일요일 전에 아래 순서로 보는 게 빠르다.
- 우리 리졸버가 검증을 하는지부터 본다. dnssec-failed.org를 조회해 SERVFAIL이 나오면 검증 중이고, 주소가 나오면 검증을 안 하는 리졸버다.
- 센티널 질의로 38696 신뢰 여부를 확인한다. 위 두 dig 명령에서
@1.1.1.1을 우리 리졸버 주소로 바꾼다.is-ta가 NOERROR,not-ta가 SERVFAIL이면 준비된 것이다. - 앵커 파일과 상태를 직접 연다. BIND는
rndc managed-keys status(지원 버전이면rndc secroots도), Unbound는 root.key 안에 38696이 있는지 본다. - 이미지·설정 관리 쪽을 뒤진다. Dockerfile, Ansible 템플릿, 골든 이미지에 박혀 있는 root.key나 trust-anchors 설정을 검색해 20326만 있는 곳을 찾는다.
- 오래된 버전이면 업데이트가 가장 확실하다. 최근 배포판의 리졸버는 KSK-2024가 들어간 채로 나온다.
개인적으로는 2번보다 4번이 더 중요하다고 본다. 지금 돌고 있는 리졸버는 이미 1년 넘게 새 키를 봐 왔으니 대부분 학습을 마쳤다. 문제는 다음 배포 때 옛 앵커를 품은 이미지가 다시 올라오는 경우다. 1월 11일 KSK-2017 폐기 표시와 3월 22일 제거까지 일정이 남아 있으니, 이번에 이미지 쪽 앵커를 정리해 두면 그 단계도 같이 넘어간다.
2018년 첫 교체 때는 어땠나
루트 KSK 교체는 이번이 두 번째다. 첫 교체는 원래 2017년 예정이었는데, 갱신하지 않은 운영자가 많다는 데이터가 나오면서 1년 미뤄져 2018년 10월 11일에 진행됐다. ICANN은 그해 10월 30일 정리 글에서 부정적 영향을 받은 리졸버가 "소수"였고 모두 복구됐으며, 교체 무렵 장애를 겪은 ISP는 두 곳이었다고 밝혔다. 교체 직후 ICANN 발표도 "전 세계 인터넷에 최소한의 혼란만 주고" 끝났다는 평가였다.
이번에도 대규모 사고 가능성은 낮다. 다만 "소수"에 우리 사내 DNS가 들어가면, 그날 아침 장애 대응은 전부 우리 몫이다. 몇 초면 끝나는 dig 두 줄로 그 가능성을 지워 두는 편이 싸다.