DNSSEC 신뢰 체인은 DNS 데이터를 어떻게 검증할까
DNSSEC 검증기는 신뢰 앵커에서 시작해 부모 존의 DS와 자식 존의 DNSKEY를 연결하고, 응답 데이터의 서명을 확인한다. DNS 데이터의 출처와 무결성을 검증하지만 질의 내용을 암호화하지 않는다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
DNSSEC는 DNS 응답을 암호화하지 않는다. 서명된 DNS 데이터가 신뢰한 존에 연결되고 서명이 유효한지 검증하는 기술이다. 검증 리졸버는 신뢰 앵커에서 부모 DS와 자식 DNSKEY를 따라 응답 RRset의 서명을 확인한다. 서명되지 않은 위임은 insecure일 수 있으며, 실패만으로 공격을 입증할 수 없다.
개념도이며 실제 DNS 응답을 나타내지 않는다.
신뢰 앵커에서 시작하는 검증
DNSSEC 검증은 루트 네임서버에 매번 접속하는 동작이 아니라 리졸버에 설정된 신뢰 앵커에서 시작한다. 공개 DNS에서는 보통 루트 존의 DNSKEY 정보가 출발점이다. 검증기는 신뢰된 서명을 따라 위임 관계를 확인한다. 루트가 모든 도메인의 내용을 직접 보증한다는 뜻은 아니다. RFC 4033
예를 들어 www.example.com의 주소를 확인한다고 가정하자. 검증기는 이미 신뢰한다고 설정한 루트 키를 기준으로 시작하고, 서명된 위임을 따라 .com과 example.com의 키 관계를 확인한다. 이 이름의 데이터가 실제로 DNSSEC를 적용했는지는 도메인마다 다르다. 따라서 이 경로는 검증 순서를 설명하는 가상 사례이지 특정 도메인의 현재 설정을 확인했다는 뜻은 아니다. RFC 4033
DS와 DNSKEY가 존을 연결한다
자식 존은 DNSKEY를 게시하고 해당 키로 RRset에 서명한다. 부모 존의 DS는 자식 DNSKEY에 대응하는 digest를 담는다. 검증기는 DS와 DNSKEY가 연결되는지 확인한 뒤 DNSKEY로 응답 RRset의 RRSIG를 검사한다. 이는 DNS 데이터에 대한 검증이지 전송 패킷에 대한 암호화가 아니다. RFC 4035 ICANN
DS는 자식 존의 DNSKEY 집합과 부모 존에 게시된 정보를 연결하는 경계다. 검증기는 부모가 서명한 DS를 확인하고, 해당 값이 자식의 DNSKEY와 맞는지 검사한다. 그 뒤 자식 키로 데이터 집합의 서명을 검증한다. 어느 한 단계에서 키가 맞지 않거나 필요한 서명을 검증할 수 없다면, 리졸버는 기대한 인증 경로를 완성할 수 없다. 키 교체 일정은 부모 등록기관과 존 운영자의 절차에 맞춰 조정해야 하며 여기서 특정 알고리즘이나 보편적 일정을 권장하지 않는다. RFC 4035
검증 상태와 실패 원인을 구별한다
서명 경로가 유효한 secure, 정당하게 서명되지 않은 위임의 insecure, 서명 불일치 등의 bogus, 정보 부족에 따른 indeterminate를 구분해야 한다. 이름을 찾지 못하거나 SERVFAIL이 보인다고 공격이 입증되는 것은 아니다. DNSSEC 오류 외에도 설정·배포 문제가 가능하므로 리졸버 로그와 존의 키 연결을 확인한다. RFC 4033
서명은 개별 레코드 하나가 아니라 같은 이름과 유형의 RRset을 대상으로 확인한다. 즉 A 레코드 한 줄만 떼어 진위를 판정하는 대신 응답에 포함된 집합이 서명 범위 및 유효 조건과 일치하는지를 본다. 검증 가능한 부재 증명도 DNSSEC 데이터에 포함될 수 있지만, 이것은 인터넷의 모든 이름을 열거하거나 모든 이름이 존재하지 않음을 주장하는 기능이 아니다. 응답 데이터와 부재 증명이 권한 있는 서명 관계에 속하는지 확인한다. RFC 4033
전문가 관점: DNSSEC의 보안 경계
ICANN은 DNSSEC가 DNS 데이터의 출처 인증과 무결성을 제공한다고 설명한다. 질의의 기밀성, 웹사이트 신원 확인, 가용성은 보장하지 않는다. 서명은 게시된 데이터가 올바르다는 보증도 아니다. 잘못된 값도 권한 있는 존에서 서명되면 서명 검증 자체는 성공할 수 있다. ICANN
운영 측면에서는 부모 존에 DS를 게시하는 일과 자식 존의 DNSKEY·서명을 배포하는 일이 서로 맞아야 한다. 한쪽만 먼저 바뀌거나 오래된 정보가 남으면 정상 도메인도 검증 실패를 겪을 수 있다. 원인을 조사할 때는 어느 이름에서 실패했는지, 부모 DS와 자식 DNSKEY가 대응하는지, 리졸버가 어떤 검증 상태를 기록했는지를 확인한다. 실패 로그는 조사 단서이지 공격을 자동으로 판정하는 증거가 아니다. RFC 4035 ICANN