루트 DNS 키 교체 당일, 통신 3사 공용 DNS는 DNSSEC 검증을 하지 않았습니다

핵심 요약

무엇이 바뀌나

KSK(키 서명 키)는 루트 영역의 공개 키 목록에 서명하는 키입니다. 검증 리졸버(DNSSEC 서명을 따라가며 검사하는 리졸버)는 이 키를 "신뢰 앵커"로 미리 갖고 있다가, 루트에서 시작해 .kr, 각 도메인 순으로 서명을 따라 내려갑니다.

2026-10-11부터 루트의 공개 키 목록에는 KSK-2024(38696)의 서명만 붙습니다(IANA 일정). 측정 시점에는 루트 서버 다섯 곳(a·b·f·j·k) 모두 아직 KSK-2017(20326)로 서명하고 있었습니다.

1. 안내 문구와 측정 결과

ICANN·IANA·Cloudflare의 안내를 한 줄씩 적고, 같은 날 측정한 결과와 맞춰 보았습니다.

조치가 필요한 경우는 표의 마지막 줄, 직접 운영하는 검증 리졸버입니다. ICANN은 자동 갱신이 켜져 있는지와 리졸버가 신뢰 앵커 파일을 쓸 권한이 있는지 보라고 안내했습니다.

2. 새 키는 2년 3개월 전부터 유효했습니다

KSK-2024는 갑자기 나온 키가 아닙니다. IANA 신뢰 앵커 파일(root-anchors.xml)에는 2024-07-18부터 유효하다고 적혀 있고, 루트 영역에는 2025-01-11부터 게시돼 있었습니다.

자동 갱신(RFC 5011)은 새 키를 처음 본 날부터 30일 동안 계속 게시되는지 지켜본 뒤 신뢰 앵커에 넣습니다. 2025-02-10 이후 한 번도 멈추지 않은 리졸버라면 이미 새 키를 갖고 있어야 합니다. 반대로 오늘 처음 새 키를 본 리졸버는 30일을 채우지 못해 자동으로 신뢰할 수 없으므로, 새 키를 직접 넣어야 합니다.

3. 측정 방법

Cloudflare 점검 페이지(dnstest.dev)가 쓰는 시험용 이름 다섯 개를 리졸버마다 dig로 질의했습니다. 응답 코드만 기록했고, 4초 안에 응답이 없는 경우는 시간 초과로 기록했습니다.

뒤의 세 이름은 RFC 8509 「DNSSEC Trusted Key Sentinel」이 정한 방식입니다. 이 방식을 구현한 검증 리졸버는 이름에 들어 있는 키 번호가 자기 신뢰 앵커에 있는지에 따라 다르게 응답합니다. 이 방식을 구현하지 않은 리졸버는 세 이름 모두에 주소를 주므로, 외부 질의만으로는 어떤 키를 믿는지 알 수 없습니다.

• 대상 선정: 통신사 3사가 가입자에게 안내하는 공용 DNS 주소 각 2개와, 국내에서 많이 쓰는 공용 리졸버 4곳. 휴대전화 통신망의 DNS는 통신망 밖에서 질의할 수 없어 넣지 않았습니다
• 측정 위치: KT 회선에 연결한 맥북 한 대입니다. 이 컴퓨터의 기본 리졸버는 KT 공용 DNS와 같은 주소였습니다
• 반복: 결과가 RFC 표와 맞지 않은 Quad9에만 10번 반복 질의했고, 10번 모두 같은 응답이 나왔습니다. 약 10분 뒤 전체 12개 주소에 한 번 더 질의했고, 결과가 달라진 Quad9에는 9.9.9.9로 8번, 149.112.112.112로 2번 더 질의했습니다(4절)
• 제외한 것: 전 세계 자원봉사 측정망(Globalping)의 통신사별 장비 7대에서 각 장비의 기본 리졸버로도 질의했지만, 장비마다 기본 리졸버가 공유기 내부 리졸버·8.8.8.8·1.1.1.1로 제각각이라 통신사 사용자 환경으로 볼 수 없어 결과에서 뺐습니다. SKB 공용 DNS를 그대로 쓰는 장비 한 대에서는 아래 표와 같은 결과가 나왔습니다

4. 통신사 DNS는 검증하지 않았고, 공용 리졸버는 모두 검증했습니다

리졸버별 응답과 RFC 8509의 분류입니다. 분류 이름은 RFC 8509의 것을 그대로 썼습니다. nonV는 검증하지 않는 리졸버, Vnew는 새 키를 믿는 검증 리졸버, Vind는 검증은 하지만 sentinel을 구현하지 않아 어떤 키를 믿는지 알 수 없는 리졸버입니다.

대조군(valid.alg13)은 모든 리졸버가 주소로 답해 시험 자체는 유효했습니다. 통신사 DNS 판정은 다른 두 방법으로도 같았습니다. 서명된 도메인(isc.org, ietf.org)을 질의했을 때 응답에 검증 완료 표시(AD 플래그)가 없었고, 검증 실패 시험용으로 널리 쓰이는 dnssec-failed.org에도 주소를 돌려줬습니다. 공용 리졸버 4곳은 AD 플래그를 붙였고 dnssec-failed.org를 거부했습니다.

RFC 8509의 분류는 키 하나에 대한 세 질의(is-ta, not-ta, 틀린 서명)로 정합니다. Quad9는 처음 측정에서 옛 키를 묻는 not-ta-20326 질의에 "옛 키를 믿는다"는 뜻의 SERVFAIL로 답했고, 10번 반복해도 같았습니다. sentinel을 구현하지 않은 리졸버라면 주소를 줘야 하는 질의입니다. 새 키(38696)를 묻는 두 이름에는 주소를 돌려줬으므로, RFC 표에 없는 서로 맞지 않는 조합이었습니다. 약 10분 뒤 같은 스크립트로 다시 측정하자 9.9.9.9(8번)와 149.112.112.112(2번) 모두 이 질의에 주소를 줬고, 결과는 Google·OpenDNS와 같은 Vind가 됐습니다. 원인은 알 수 없습니다. RFC 8509는 SERVFAIL 응답이 최대 5분 캐시될 수 있고, 한 주소 뒤에 여러 내부 리졸버가 있는 "리졸버 팜"에서는 결과가 엇갈릴 수 있다고 적었습니다. 서버 이름 조회(id.server)에는 두 번의 측정 모두 같은 서버(res700.qhnd2)가 답했습니다. 어느 쪽이든 Quad9가 새 키를 믿는지는 우리 측정으로 말할 수 없습니다.

5. 국내 주요 도메인은 대부분 서명이 없습니다

검증 리졸버를 써도 도메인에 서명이 없으면 그 도메인은 DNSSEC으로 보호받지 못합니다. 부모 영역에 자식 영역의 키를 보증하는 DS 레코드가 있는지와, 검증 리졸버(1.1.1.1)가 AD 플래그를 붙이는지를 같은 날 조회했습니다. 도메인은 자주 쓰는 서비스를 골라 넣은 편의 표본입니다.

국내 12곳 중 서명이 있는 곳은 kr, go.kr, kisa.or.kr 세 곳이었습니다. 다만 이것은 교체의 영향 범위와 별개입니다. 검증 리졸버가 새 루트 키를 갖고 있지 않으면, 서명이 없는 naver.com 같은 도메인도 함께 조회에 실패합니다. 서명이 없다는 사실(DS 레코드 없음)도 루트부터 이어지는 검증으로 증명하므로, 루트 키를 검증하지 못하면 모든 이름이 실패합니다.

6. 내 리졸버를 직접 측정하는 방법

아래 스크립트는 리졸버 주소 하나를 받아 시험용 이름 다섯 개의 응답 코드를 한 줄로 찍습니다. 이 글의 표는 같은 방식으로 얻었습니다.

#!/bin/bash
# 사용법: ./probe.sh 168.126.63.1
names="valid.alg13.dnstest.dev invalid.alg13.dnstest.dev \
  root-key-sentinel-not-ta-20326.dnstest.dev \
  root-key-sentinel-is-ta-38696.dnstest.dev \
  root-key-sentinel-not-ta-38696.dnstest.dev"
out="$1"
for n in $names; do
  r=$(dig +tries=1 +time=4 A "$n" @"$1")
  st=$(printf '%s\n' "$r" | sed -n 's/.*status: \([A-Z]*\).*/\1/p')
  # NOERROR인데 답이 비어 있으면 주소를 준 것이 아니므로 따로 표시합니다
  if [ "$st" = NOERROR ] && ! printf '%s\n' "$r" | grep -q 'ANSWER: [1-9]'; then st=NODATA; fi
  out="$out ${st:-timeout}"
done
echo "$out"

출력의 첫 칸은 리졸버 주소입니다. 대조군(두 번째 칸)이 NOERROR인데 틀린 서명 이름(세 번째 칸)도 NOERROR면 그 리졸버는 검증을 하지 않습니다. 세 번째가 SERVFAIL이고 다섯 번째(is-ta-38696)가 NOERROR, 여섯 번째(not-ta-38696)가 SERVFAIL이면 새 키를 신뢰하는 리졸버입니다. 지금 브라우저가 쓰는 리졸버는 Cloudflare 점검 페이지(dnstest.dev/ksk-2024)로도 볼 수 있습니다.

직접 운영하는 리졸버라면 신뢰 앵커 파일에서 키 번호를 찾는 편이 더 직접적입니다. ICANN이 예로 든 파일 이름은 Unbound·PowerDNS Recursor는 root.key, BIND는 bind.keys, Knot Resolver는 root.keys입니다.

# Unbound: 설정의 auto-trust-anchor-file 경로를 넣습니다
grep -c 38696 /var/lib/unbound/root.key

7. 체크리스트

• 통신사 DNS를 그대로 쓰는 서버·사무실: 이번 교체로 할 일은 없습니다. 다만 그 DNS가 DNSSEC 검증을 하지 않는다는 점은 알아 둡니다
• Unbound·BIND·Knot Resolver를 직접 설치해 검증을 켠 서버: 신뢰 앵커 파일에 38696이 있는지 봅니다. 없으면 ICANN 안내대로 자동 갱신 설정과 파일 쓰기 권한을 보고, 쓰는 소프트웨어의 안내대로 새 키를 넣습니다
• 컨테이너로 리졸버를 돌리는 경우: 신뢰 앵커 파일이 이미지 안에만 있으면 컨테이너를 다시 만들 때 그동안 받아 둔 새 키가 사라집니다. Cloudflare는 2018년 첫 교체 때 업그레이드나 서버 이전 중에 받아 둔 키를 잃은 리졸버가 있었다고 적었습니다
• 공유기·방화벽의 DNSSEC 옵션을 켠 경우: 제조사가 신뢰 앵커를 갱신했는지 펌웨어 공지를 봅니다. 이 경우는 측정하지 않았습니다
• 교체 뒤 증상: 특정 사이트가 아니라 모든 도메인에서 SERVFAIL이 나면 신뢰 앵커부터 의심합니다

8. 아직 결론이 아닌 것

• 교체 뒤에는 아직 측정하지 않았습니다. 측정 시점에 루트는 옛 키로 서명하고 있었습니다. IANA·ICANN 자료에는 교체 날짜만 있고 시각은 없습니다. 루트 서버가 새 키로 서명하는 것을 본 뒤 같은 스크립트로 다시 측정해 이 글을 갱신하겠습니다
• 측정 위치는 KT 회선 한 곳입니다. SKB·LG U+ 공용 DNS도 KT 회선에서 질의했습니다. 각 통신사 가입자가 실제로 받는 리졸버가 이 공용 주소와 같은지는 측정하지 않았습니다
• 휴대전화 통신망(SKT·KT·LG U+ 이동통신)의 DNS는 측정하지 않았습니다. 통신망 밖에서는 질의할 수 없는 주소를 씁니다
• Google·OpenDNS·Quad9가 새 키를 믿는지는 알 수 없습니다. 세 곳 모두 sentinel 질의에 Vind로 답했고, Quad9는 처음 측정에서 엇갈린 조합이 나왔습니다. 세 운영사의 공식 공지는 이번에 찾지 않았습니다
• 각 시험은 주소마다 처음 한 번, 약 10분 뒤 한 번 질의했습니다(Quad9에는 4절처럼 더 많이 질의했습니다). 같은 주소 뒤에서 다른 서버가 다른 답을 줄 가능성은 Quad9 외에는 따로 시험하지 않았습니다
• 판정은 dnstest.dev 영역에 의존합니다. 이 영역의 서명이 잘못돼 있다면 결과가 달라집니다. 대조군이 모든 리졸버에서 정상이었다는 것까지만 보았습니다
• "신뢰 앵커 상태를 보고한 리졸버의 95%"는 다시 측정하지 않았습니다. 그 숫자는 ICANN 블로그를 옮긴 것이고, 블로그는 무엇으로 셌는지 적지 않았습니다

참고자료

모두 2026-10-11에 열어 대조했습니다. 이 글은 다룬 회사·기관과 이해관계가 없습니다(광고·협찬·제공 없음).

국내 통신사 공용 DNS 주소는 각 사가 가입자에게 안내하는 주소를 썼습니다. 측정 원자료(리졸버별 응답 코드)는 위 재현 스크립트로 같은 형식으로 얻을 수 있습니다.