재귀 DNS 조회, 단계별로 살펴보기
브라우저
example.com 요청
리졸버
내 ISP / 1.1.1.1
루트 + TLD
.com 운영 주체는?
권한 네임서버
실제 응답
체인의 각 단계도 DNS 조회이며 이후 캐시됩니다
DNSSEC 설명: DNS 응답을 인증하는 방법
DNS 보안 확장(DNS Security Extensions, DNSSEC)은 DNS 데이터에 암호학적 인증을 더합니다. 검증 리졸버가 응답이 의도한 존과 연결되어 있고 전송 중에 변조되지 않았음을 확인할 수 있도록 돕습니다. DNSSEC은 DNS 쿼리를 암호화하지 않고, 요청한 도메인을 숨기지 않으며, 웹사이트를 안전하게 만들어 주지도 않습니다. 대신 서명과 키의 체인을 제공하여, 리졸버가 서명된 데이터를 신뢰하는 루트까지 거슬러 올라가며 검증할 수 있게 합니다. 체인이 올바르게 구성되어 있으면 리졸버는 응답이 진본이라는 더 강력한 근거를 얻고, 체인이 끊어져 있으면 검증 때문에 평소와 다름없던 조회가 실패할 수 있습니다.
DNSSEC 체인을 이루는 레코드
서명된 존은 서명을 검증하는 데 쓰는 공개 키가 담긴 DNSKEY 레코드를 게시합니다. RRSIG 레코드는 레코드 집합에 대한 서명을 담고, 상위 존의 DS 레코드는 하위 존의 키를 상위의 신뢰 체인에 연결합니다. NSEC 또는 NSEC3 데이터는 이름이나 레코드가 존재하지 않을 때 이를 인증된 방식으로 증명하는 데 쓰입니다. 운영자는 대개 이 값들을 DNS 제공업체나 레지스트라가 생성하고 관리하도록 맡기지만, 책임이 나뉘어 있을 수 있습니다. 하위 존은 DNS 호스트가 서명하고, 상위의 DS 레코드는 레지스트라를 통해 게시됩니다. 둘이 서로 맞지 않는 것이 검증 문제의 흔한 원인입니다.
| 레코드 | DNSSEC에서의 역할 |
|---|---|
| DNSKEY | 존의 공개 서명 키를 게시함 |
| RRSIG | DNS 레코드 집합에 대한 서명을 전달함 |
| DS | 하위 존의 키를 상위 신뢰 체인에 연결함 |
| NSEC / NSEC3 | 존재하지 않음을 알리는 일부 DNS 응답을 인증함 |
검증 리졸버는 설정된 신뢰 앵커(보통 루트)에서 시작하여 상위 존과 하위 존을 거치며 신뢰 체인을 따라갑니다. 서명이 유효한지, 레코드가 키 및 위임 데이터와 일치하는지 확인합니다. 일반 사용자는 이 과정을 볼 일이 없지만 결과에서는 그 효과가 드러납니다. 유효하게 서명된 응답은 받아들여지고, 서명 체인이 깨지면 SERVFAIL이 발생할 수 있습니다. 검증하지 않는 리졸버는 검증 리졸버가 거부하는 값을 반환할 수도 있어서, DNSSEC 실패가 특정 네트워크에서만 발생하는 것처럼 보일 수 있습니다. 호스트 이름에 레코드가 없다고 단정하기보다 리졸버를 비교하고 검증 상태를 확인하는 편이 훨씬 많은 정보를 줍니다.
DNSSEC 장애가 발생하는 경우
흔한 실패 사례로는 DNS 제공업체를 바꾼 뒤 레지스트라에 오래된 DS 레코드를 그대로 두는 경우, 서명된 존과 맞지 않는 키를 게시하는 경우, 서명이 중단되어 서명이 만료되는 경우, 상위와 하위를 조율하지 않고 위임을 변경하는 경우가 있습니다. DNSSEC 도입이나 키 롤오버는 제공업체가 문서화한 절차를 따르고, 독립적인 검증 리졸버에서 확인해야 합니다. DNSSEC을 비활성화했을 때 오래된 DS 데이터가 남아 있으면 DS 레코드가 아예 없는 것보다 더 해로울 수 있습니다. 검증기는 하위 존이 더 이상 제공하지 않는 체인을 계속 기대할 수 있기 때문입니다. 레지스트라와 DNS 호스트를 하나의 과정으로 연결된 부분으로 취급하세요.
- DNS 제공업체가 존에 서명하고 키 교체를 관리하는지 문의하세요.
- 레지스트라의 DS 값이 제공업체의 최신 안내와 일치하는지 확인하세요.
- DNSSEC을 활성화, 비활성화, 이전한 후에는 검증 리졸버로 테스트하세요.
- 키 변경은 신중하게 일정을 잡고 롤백 경로를 확보해 두세요.
- DNSSEC 인증을 암호화된 DNS 전송과 혼동하지 마세요.
검증 실패 문제 해결하기
검증 리졸버에서 도메인이 SERVFAIL을 반환한다면, 관련 없는 A나 MX 레코드를 바꾸기 전에 DNSSEC 체인부터 점검하세요. 권한 존의 DNSKEY와 서명을 확인한 다음, 상위에서 게시한 DS와 비교합니다. 서명 유효 기간과 최근 제공업체의 변경 내역도 살펴보세요. 일반적인 도메인-IP 조회는 확인에 실패했다는 사실은 알려 주겠지만, DNSSEC 체인의 어느 고리가 끊어졌는지는 반드시 설명해 주지 않습니다. 더 깊은 질문에는 DNSSEC을 지원하는 진단 도구를 사용하세요. 제공업체가 재현 가능한 사례를 조사할 수 있도록 리졸버, 검증 결과, 질의 시각을 인시던트 메모로 남기세요.
DNSSEC은 데이터의 진본성을 강화하지만 운영상의 정확성도 여전히 중요합니다. 도메인 소유자의 계정이 탈취되는 것을 막지도, 잘못된 레코드를 올바르게 만들어 주지도 못하며, 구성된 키에 따라 게시된 데이터를 인증할 뿐입니다. 기초 개념은 DNS 확인 과정 설명과 DNS 레코드 유형을 참고하세요. 갱신과 마이그레이션 과정에서도 체인을 유지하고 모니터링할 수 있을 때 DNSSEC을 활성화하세요. 한 번 켜 두면 언제까지나 올바르다고 가정할 수 있는 일회성 스위치로 취급해서는 안 됩니다.
키 롤오버는 조율된 변경으로 다루세요
DNSSEC 키 롤오버는 검증 리졸버가 의존하는 암호 자료를 변경합니다. 안전한 정확한 순서는 서명 제공업체와 롤오버가 관리형인지 수동인지에 따라 다릅니다. 문서화된 절차를 따라 이전 키와 새 키가 필요한 만큼 겹치고, 서명이 계속 유효하며, 상위 DS 데이터가 올바른 단계에서 게시된 키와 일치하도록 하세요. 오래된 대시보드 스크린샷에서 DS 값을 복사하거나, 관련 없는 조회가 타임아웃되었다는 이유만으로 DS를 삭제하지 마세요. 롤오버 후에는 두 개 이상의 DNSSEC 검증 리졸버로 확인하고 제공업체 이벤트 로그를 보관하세요. 검증이 실패하면 도메인, 리졸버, 응답 코드, 시각을 기록한 다음, 애플리케이션 레코드를 건드리기 전에 서명과 DS 연결을 먼저 확인하세요. 모니터링을 곁들인 통제된 롤오버가, 브라우저와 메일 시스템에 장애가 시작된 뒤 체인을 수습하려는 긴급 시도보다 훨씬 안전합니다.
도메인의 공개 DNS 주소를 확인해야 하나요? Domain IP Lookup 도구를 사용해 보세요.
관련 글
모든 IPv4 대역에는 대응하는 IPv6 대역이 있습니다
놓치면 안 되는 IPv6 보안 고려 사항
보안 관점에서 IPv6는 단순히 주소가 더 많은 IPv4가 아닙니다. 몇 가지 차이가 위협 모델을 실제로 바꿉니다.
위조된 응답으로 경쟁에서 이기기
공격자
진짜 응답과 경쟁
위조된 응답
먼저 도착
리졸버 캐시
공유하는 모두에게 오염됨
DNS 스푸핑과 캐시 포이즈닝: 실무 개요
트래픽을 우회시키기 위해 DNS 응답을 위조하는 것은 네트워킹에서 가장 오래된 수법 중 하나이며, DNSSEC와 최신 리졸버 방어가 존재하는 이유입니다.
공개 주소 공간과 사설 주소 공간
공개 IP
192.0.2.10
전역에서 고유, 어디서나 라우팅 가능
사설 대역
공개 인터넷에서는 라우팅 불가
사설 IP 대역이 공개적으로 확인되어서는 안 되는 이유
10.0.0.0/8, 192.168.0.0/16과 그 이웃 대역은 전 세계에서 고유하지 않도록 만들어졌습니다. 이것이 DNS에서 왜 중요한지 설명합니다.