DNS가 조용히 바뀐다 — Quad9 DNSSEC 엄격검증, 6/15부터 SERVFAIL
🤖 AI Summary
DNS는 평소 눈에 잘 안 보이지만, 한 번 어긋나면 서비스 전체가 흔들리는 인터넷의 기반입니다. 퍼블릭 리졸버 Quad9가 2026년 6월 15일부터 9.9.9.10·9.9.9.12 주소에 DNSSEC 엄격 검증을 적용해, 설정 오류든 변조든 검증에 실패한 응답에는 SERVFAIL을 반환한다고 공지했습니다(기존 9.9.9.9는 이미 검증 중). DNSSEC는 DNS 응답이 위·변조되지 않았음을 전자서명으로 확인하는 무결성 기술이고, 표준은 RFC 4033·4034·4035입니다. 이 글에서는 무엇이 바뀌는지, DNSSEC가 정확히 무엇을 보장하고 무엇은 보장하지 않는지, 그리고 운영자가 6/15 전에 점검할 것을 1차 표준 기준으로 정리합니다.
블로그 목차
6/15, 일부 DNS 응답이 갑자기 막힐 수 있다
도메인 이름을 IP로 바꿔주는 DNS는 모든 접속의 첫 단추입니다. 그런데 이 응답이 누군가에 의해 바꿔치기되면, 사용자는 자기도 모르게 가짜 서버로 안내될 수 있죠. 이 위·변조를 막기 위한 장치가 DNSSEC입니다.
2026년 6월 15일, 퍼블릭 DNS 리졸버 Quad9가 이 검증을 더 엄격하게 적용합니다. 평소 9.9.9.10이나 9.9.9.12를 DNS 서버로 쓰던 환경이라면, 검증을 통과하지 못하는 일부 도메인이 그날부터 SERVFAIL로 응답될 수 있습니다. 무엇이 어떻게 바뀌는지, 그리고 그게 왜 "고장"이 아니라 "보호"인지 정리해 봅니다. 참고로 이 변경은 2026년 4월 9일 공지됐고, 시행이 6월 15일이라 지금이 점검에 딱 좋은 시점입니다.
무엇이 바뀌나 — Quad9의 엔드포인트별 변경
Quad9 공지의 핵심 문장을 그대로 옮기면 이렇습니다.
9.9.9.10과 9.9.9.12는 이제 설정 오류든 변조된 응답이든 DNSSEC 검증 실패에 대해 SERVFAIL을 반환한다. ("9.9.9.10 and 9.9.9.12 will now return SERVFAIL for DNSSEC failures, whether caused by misconfiguration or a tampered response.")
Quad9 주소 | 6/15 변경 |
|---|---|
9.9.9.9 | 기존부터 DNSSEC 검증 수행 (변경 없음) |
9.9.9.10 | DNSSEC 엄격 검증·SERVFAIL 신규 적용 |
9.9.9.12 | DNSSEC 엄격 검증·SERVFAIL 신규 적용 |
즉 "모든 주소가 처음으로 DNSSEC를 켠다"가 아니라, 검증하지 않던 일부 주소를 나머지와 같은 기준에 맞추는 변경입니다. Quad9는 그 이유를 이렇게 설명합니다.
엄격한 DNSSEC 검증 없이 리졸버 주소를 남겨두는 것은, 어떤 주소를 고르느냐에 따라 DNS 무결성 검사가 선택사항이 된다는 암묵적 메시지를 준다.
DNSSEC가 뭐길래 — 무결성을 지키는 전자서명
DNSSEC(DNS Security Extensions)는 DNS 응답에 전자서명을 붙여, 그 응답이 권한 있는 출처에서 나왔고 중간에 바뀌지 않았음을 검증하는 기술입니다. 핵심 표준은 RFC 4033·4034·4035 세 문서로, 각각 개요·요구사항, 보안용 리소스 레코드, 프로토콜 수정을 정의합니다.
리졸버가 "나는 DNSSEC 검증을 원한다"고 알리는 신호가 DO(DNSSEC OK) 비트입니다. DO 비트는 RFC 3225에서 정의됐고(이후 DNSSEC 표준이 갱신), 실제로는 DNS 확장 메커니즘인 EDNS(0)/OPT 레코드(RFC 6891)를 통해 전달됩니다. 검증을 지원하는 리졸버는 서명을 확인하고, 서명이 없거나 어긋나면 그 응답을 신뢰하지 않습니다.
여기서 꼭 구분할 점이 있습니다. DNSSEC는 무결성(위·변조 방지)을 위한 기술이지, 응답 내용을 암호화하는 기밀성 기술도, 가용성을 보장하는 기술도 아닙니다. "DNS를 암호화"하는 것은 DoH·DoT 같은 별개 기술의 영역입니다.
SERVFAIL은 고장이 아니다
엄격 검증 환경에서 SERVFAIL은 종종 "고장"이 아니라 의도된 차단입니다. 검증을 통과하지 못한 응답, 즉 변조됐거나 도메인 측 DNSSEC 설정이 잘못된 응답을 사용자에게 그대로 주지 않겠다는 뜻이죠. 보안 관점에서는 잘못된 답을 주느니 막는 편이 안전합니다.
문제는 운영 현장에서 이 SERVFAIL이 "갑자기 사이트가 안 열린다"로 체감된다는 점입니다. 그래서 6/15 이후 특정 도메인이 9.9.9.10·9.9.9.12에서 막힌다면, 리졸버 장애로 단정하기 전에 그 도메인의 DNSSEC 서명 상태부터 확인하는 순서가 중요합니다. 원인이 우리 쪽 도메인의 만료된 서명이나 잘못된 키 롤오버일 수도 있으니까요.
운영자가 6/15 전에 점검할 것
우리가 쓰는 리졸버 파악— 사내·서비스가 어떤 DNS 리졸버를 쓰는지, DNSSEC 검증 정책이 일관적인지 확인합니다.자사 도메인의 DNSSEC 상태— DNSSEC를 적용했다면 서명 갱신·키 롤오버가 정상인지 점검해, 우리 도메인이 남의 SERVFAIL을 유발하지 않게 합니다.SERVFAIL 모니터링— 검증 실패 비율을 관측해 문제를 조기에 발견합니다.한계 인지— DNSSEC는 무결성 보호일 뿐, 기밀성(암호화)·가용성은 DoH/DoT·다중 리졸버 등 별도 수단으로 보완합니다.
DNS는 평소 신경 쓰지 않다가 사고가 나야 들여다보는 영역입니다. 인터넷 신뢰 기반이 조용히 강화되는 흐름은 TLS 인증서 수명 단축 같은 변화와도 맞닿아 있어, 이참에 도메인·인증서·DNS의 신뢰 설정을 함께 점검해두면 좋습니다.
이것만 기억하세요
Quad9가 2026년 6월 15일부터 9.9.9.10·9.9.9.12에 DNSSEC 엄격 검증을 적용해, 검증에 실패한 응답(변조 또는 설정 오류)에는 SERVFAIL을 반환합니다. 9.9.9.9는 이미 검증 중이었고, 이번 변경은 나머지 주소를 같은 기준에 맞추는 것입니다. DNSSEC는 DNS 응답의 위·변조를 막는 무결성 기술(RFC 4033·4034·4035)이며, 리졸버의 검증 의사를 알리는 DO 비트는 RFC 3225에서 정의됩니다. 다만 DNSSEC는 무결성일 뿐 기밀성·가용성을 보장하지는 않습니다. 6/15 전에 우리가 쓰는 리졸버, 자사 도메인의 DNSSEC 서명 상태, SERVFAIL 모니터링 세 가지를 점검해두면 갑작스러운 차단을 예방할 수 있습니다.
자주 묻는 질문 (FAQ)
Q. 6월 15일에 무엇이 바뀌나요?
Quad9가 9.9.9.10·9.9.9.12 주소에 DNSSEC 엄격 검증을 적용해, 설정 오류든 변조든 검증에 실패하면 SERVFAIL을 반환합니다. 9.9.9.9는 이미 검증 중이었고, 이번엔 나머지 주소를 같은 기준에 맞추는 변경이에요.
Q. DNSSEC가 무엇인가요?
DNS 응답이 위·변조되지 않았는지 전자서명으로 검증하는 무결성 기술입니다(RFC 4033·4034·4035). 리졸버의 검증 의사를 알리는 DO 비트는 RFC 3225에서 정의되고 EDNS(0)/OPT(RFC 6891)로 전달돼요. 단 무결성 보호일 뿐 암호화(기밀성)나 가용성 보장은 아닙니다.
Q. SERVFAIL이 뜨면 고장 난 건가요?
꼭 그렇진 않아요. 엄격 검증에서 SERVFAIL은 "검증 못 한 응답은 안 주겠다"는 의도된 차단일 수 있습니다. 원인은 도메인 측 DNSSEC 설정 오류이거나 실제 변조일 수 있으니, 리졸버 장애로 단정하기 전에 해당 도메인의 서명 상태부터 확인하세요.
Q. 우리 회사는 무엇을 점검해야 하나요?
사용하는 리졸버와 DNSSEC 정책을 파악하고, 자사 도메인의 DNSSEC 서명·키 롤오버가 정상인지 확인하고, SERVFAIL 비율을 모니터링하세요. DNSSEC는 무결성 보호이므로 기밀성·가용성은 별도 수단으로 보완합니다.
