네임서버 이전이 모든 관리 화면에서는 성공한 것처럼 보이는데도 웹사이트에 접속할 수 없는 경우가 있습니다. 도메인은 정상적으로 활성화되어 있고, 새로운 권한 네임서버는 예상한 IP 주소를 반환하며, 웹 서버에도 변경 사항이 없습니다. 그런데 DNSSEC 검증을 수행하는 DNS 리졸버에서는 SERVFAIL이 반환됩니다. 원인은 이전 DNS 운영자의 서명 키를 여전히 신뢰하도록 설정된 DNSSEC 위임 정보인 경우가 많습니다.
이번 조사에서 다룬 장애에서는 일반적인 DNS 조회가 실패했지만, DNSSEC 검증을 우회하면 동일한 조회가 성공했습니다. 상위 영역에는 이전 DS 레코드가 남아 있었고, 새로운 권한 DNS 영역은 처음에 서명되지 않은 상태였습니다. 새 영역에 일치하는 키를 게시하고 서명하자 테스트에 사용한 리졸버에서 검증된 응답이 정상적으로 반환되기 시작했습니다. 여기서 얻을 교훈은 DNSSEC를 꺼야 한다는 것이 아닙니다. 네임서버를 이전하는 작업과 DNSSEC 신뢰 체인을 이전하는 작업은 서로 별개라는 점입니다.
A 레코드가 올바른데도 SERVFAIL이 발생하는 이유
DNS는 서로 다른 두 가지 문제를 다룹니다. A 레코드는 이름에 해당하는 IPv4 주소를 알려줍니다. 반면 DNSSEC는 검증 리졸버가 해당 DNS 응답을 신뢰할 수 있는지 판단합니다. 주소 정보가 정확하다고 해서 DNSSEC 신뢰 체인까지 유효한 것은 아닙니다.
DNSSEC로 서명된 도메인의 신뢰 체인은 신뢰할 수 있는 상위 영역에서 시작해 DS(Delegation Signer) 레코드를 거쳐 하위 영역의 DNSKEY로 이어집니다. 하위 영역은 DNS 데이터에 대한 서명인 RRSIG 레코드를 게시합니다. DS 레코드에는 승인된 DNSKEY를 식별하는 다이제스트가 들어 있습니다. DS는 A 레코드도 아니고, 개인 키의 복사본도 아니며, 일반적인 DNS 영역 파일 편집 화면에서 설정하는 단순한 옵션도 아닙니다.
권한 네임서버를 변경한 뒤에도 상위 영역이 이전 서명자의 키에 해당하는 DS 레코드를 계속 게시할 수 있습니다. 새 영역에서 그에 대응하는 DNSKEY와 서명을 제공하지 않으면 검증 리졸버는 신뢰 체인을 완성할 수 없습니다. 일반적으로 리졸버는 해당 응답을 유효하지 않은 것으로 판단하고, 검증되지 않은 주소를 반환하는 대신 SERVFAIL을 반환합니다.
이는 HTTP 장애와는 다릅니다. 요청이 웹 서버에 도달하기도 전에 실패할 수 있기 때문입니다. TLS 인증서 만료와도 별개의 문제입니다. DNSSEC는 DNS 데이터를 검증하고, HTTPS는 그다음 단계에서 이루어지는 브라우저와 서버 간 연결을 보호합니다.
DNSSEC 문제와 레코드 누락을 구분하는 진단 방법
가장 유용한 진단 방법은 동일한 리졸버에 동일한 이름을 두 번 조회하는 것입니다. 먼저 일반적인 조회를 실행하고, 반환된 주소뿐 아니라 응답 상태도 확인합니다.
dig example.com A +noall +comments +answer그다음 DNSSEC Checking Disabled(CD) 비트를 설정한 상태로 같은 조회를 반복합니다.
dig example.com A +cdflag +noall +comments +answer실제로 관찰된 장애에서는 일반 조회가 SERVFAIL을 반환했지만, CD 비트를 설정한 조회에서는 예상한 A 레코드가 반환됐습니다. 이러한 차이는 DNS 레코드 누락이나 애플리케이션 응답 불능보다 DNSSEC 검증 문제를 강하게 시사했습니다. +cdflag 옵션은 이를 지원하는 재귀 리졸버에 해당 요청에 대한 일반적인 DNSSEC 검증을 수행하지 않도록 요청합니다. 이 옵션은 진단 도구일 뿐이며, 브라우저에서 문제를 해결하거나 방문자의 DNSSEC 검증을 비활성화하는 방법이 아닙니다.
+short 결과가 비어 있다는 사실만으로 원인을 단정해서는 안 됩니다. 이 출력 형식에서는 레코드가 없는 경우와 SERVFAIL이 발생한 경우가 모두 빈 결과로 보일 수 있습니다. 진단할 때는 +comments를 유지해 status: SERVFAIL과 status: NOERROR를 구분할 수 있도록 하세요.
CD 비트를 이용한 비교만으로는 DNSSEC의 어느 부분에서 실패했는지 알아낼 수 없습니다. 어디를 조사해야 할지 방향을 제시하는 검사입니다. 리졸버의 상위 시스템에서 일시적인 오류가 발생했을 가능성도 있으므로, 필요하다면 검사를 반복하고 상위 영역의 위임 정보를 확인해야 합니다.
DNS 관리 화면뿐 아니라 상위 영역의 DS 레코드도 확인하기
먼저 도메인의 DS 레코드를 조회합니다.
dig example.com DS +noall +comments +answer위임 경로를 더 자세히 확인하려면 DNS 계층 구조를 직접 따라가며 조회합니다.
dig +trace example.com DS어떤 상위 권한 네임서버를 조회해야 하는지는 최상위 도메인에 따라 달라집니다. 중요한 것은 DNS 호스팅 관리 화면의 요약 정보가 아니라 상위 영역에서 실제로 게시하는 DS 레코드 집합(DS RRset)입니다. 등록기관을 이전해도 네임서버가 그대로 유지될 수 있고, 반대로 등록기관을 변경하지 않고 네임서버만 바꿀 수도 있습니다. 어느 경우든 상위 영역의 DS 레코드는 현재 사용 중인 권한 DNS 영역과 일치해야 합니다.
DS 레코드에는 키 태그, 알고리즘, 다이제스트 유형, 다이제스트라는 네 가지 중요한 필드가 있습니다. 키 태그는 문제를 조사할 때 편리한 식별자이지만, 키 태그가 같다는 사실만으로 DNSKEY가 일치한다고 증명할 수는 없습니다. 다이제스트와 알고리즘 정보도 권한 DNS 영역에서 실제로 제공하는 키와 일치해야 합니다.
이번 사례에서 결정적인 상황은 단순했습니다. 상위 영역은 이전 DNSSEC 신뢰 정보를 계속 게시하고 있었지만, 새 권한 DNS 영역에서는 서명이 비활성화된 것으로 표시됐습니다. A 레코드는 존재했고, 검증을 우회하면 조회할 수 있었습니다. 애플리케이션 설정을 변경하거나 동일한 A 레코드를 반복해서 수정해도 이러한 불일치는 해결되지 않습니다.
잘못된 DNSSEC 위임을 복구하는 두 가지 방법
복구에는 두 가지 적절한 방법이 있습니다. 두 방법 모두 신뢰 체인의 불일치를 해결하지만 운영상 결과는 다릅니다. 상황에 맞는 방법을 의도적으로 선택하고, 뚜렷한 이유 없이 두 방법을 번갈아 적용하지 마세요.
방법 1: 오래된 DS를 제거하고 일시적으로 서명 없이 운영하기
현재 등록기관이나 등록기관에서 지원하는 DNSSEC 관리 기능을 통해 상위 영역의 오래된 DS 레코드를 제거합니다. 상위 영역이 더 이상 보안 위임을 요구하지 않으면, 검증 리졸버는 서명되지 않은 하위 영역을 유효하지 않은 영역이 아니라 DNSSEC로 보호되지 않는 영역으로 처리할 수 있습니다. DNS 조회는 계속 작동하지만, 해당 도메인에 대한 DNSSEC 인증은 일시적으로 제공되지 않습니다.
상위 영역의 DS 레코드 집합을 확실하게 변경할 방법이 있다면, 긴급 상황에서는 이 방법이 더 간단한 경우가 많습니다. 기존 DS 레코드가 재귀 리졸버의 캐시에서 만료될 때까지는 기존 서명 구성을 안정적으로 유지하세요. 관리 화면에서 DS를 제거했다는 표시만으로는 변경이 실제로 반영됐다고 볼 수 없습니다. 외부에서 상위 영역의 레코드를 확인하고 TTL에 따른 캐시 유지 시간도 고려해야 합니다. HTTPS는 DNSSEC 설정과 독립적으로 작동합니다. 이러한 일시적인 비서명 상태로의 전환은 RFC 8078에서도 설명합니다.
방법 2: 새 영역에 서명하고 일치하는 DS 게시하기
다른 방법은 새로운 권한 DNS 운영자에서 DNSSEC를 활성화하고 DNSKEY 키 정보를 생성한 뒤 영역에 서명하고, 이에 대응하는 DS 레코드를 상위 영역에 게시하는 것입니다. 그러면 검증 리졸버가 새로운 DNSKEY까지 이어지는 신뢰 경로를 구성하고 A 레코드를 검증할 수 있습니다.
실제로 관찰된 복구 과정에서는 이 방법을 사용했습니다. DNS 관리 화면에는 키를 생성하고 영역에 서명한 뒤 새로운 DS를 게시했다는 내용이 표시됐습니다. 이후 상위 영역을 조회한 결과, 기존 DS와 새로운 DS가 함께 존재하는 것으로 확인됐습니다. 검증 기능을 사용하는 재귀 리졸버가 예상한 A 레코드를 반환하기 시작했고, 나중에 수행한 검사에서는 ad 플래그가 포함된 NOERROR 응답도 확인됐습니다. 이는 해당 리졸버가 응답 데이터를 인증된 것으로 판단했다는 의미입니다.
작업 순서는 중요합니다. 해당 DS에 대응하는 DNSKEY와 유효한 서명이 권한 DNS 서비스에서 이미 제공되고 있어야 게시된 DS가 의미를 가집니다. 관리 화면에 “published”라고 표시된다고 해서 외부 검증을 생략해도 되는 것은 아닙니다. 캐시에 남아 있는 DS, DNSKEY, RRSIG, NS 레코드 때문에 리졸버마다 복구 시점이 달라질 수 있습니다.
DS 레코드가 두 개였는데도 사이트가 계속 차단되지 않은 이유
이번 사례에서 의외였던 점은 상위 영역에 오래된 DS와 새로운 유효한 DS가 일시적으로 함께 존재했는데도 DNSSEC 검증이 성공했다는 것입니다. 이는 모순이 아닙니다. DS 레코드 집합에는 여러 레코드가 포함될 수 있으며, 키를 전환하는 과정에서 흔히 나타나는 상황입니다. 검증 리졸버는 모든 DS 레코드가 현재 사용 가능한 키를 가리킬 것을 요구하지 않습니다. 적용 가능한 DS 중 하나를 통해 DNSKEY와 유효한 서명까지 이어지는 올바른 인증 경로만 있으면 됩니다. RFC 6840에서는 검증 리졸버가 하나의 유효한 경로를 인정해야 한다는 점을 명확히 설명합니다.
그렇다고 오래된 키를 영구적으로 남겨 두는 것이 바람직하다는 뜻은 아닙니다. 사용하지 않는 DS는 운영상의 혼란을 키우므로 새로운 신뢰 체인이 정상적으로 검증된 후에는 결국 정리해야 합니다. 하지만 이미 검증된 DNS 조회가 성공하는 상황에서 위험한 DNSSEC 초기화를 다시 수행할 이유는 없습니다. 오래된 DS를 제거하는 것은 유지보수 작업으로 다뤄야 합니다.
여기에는 특히 위험한 관리 화면의 함정이 있습니다. “emergency unpublish DS”라는 작업이 오래된 DS만이 아니라 현재 정상 작동하는 새 DS까지 포함해 모든 DS 레코드를 제거하는 동작일 수 있습니다. 마찬가지로 DS가 게시된 상태에서 영역 서명을 비활성화하면 즉시 같은 장애가 다시 발생할 수 있습니다. 두 작업 모두 특정한 오래된 DS 레코드 하나만 삭제하는 것과는 다릅니다. 관리 화면에서 개별 레코드를 지정할 수 없다면 전체 초기화 대신 등록기관에서 지원하는 방법으로 삭제 대상을 정확히 지정해 변경해야 합니다.
권한 네임서버를 안전하게 변경하는 절차
가장 안전한 이전 순서는 기존 DNS 운영자와 새 DNS 운영자가 키를 함께 관리할 수 있는지에 따라 달라집니다. 일시적으로 서명을 사용하지 않는 일반적인 이전 방식에서는 다음 순서를 따르면 이번 장애에서 나타난 불일치를 피할 수 있습니다.
- 먼저 이전할 DNS 영역을 준비합니다. 필요한 A, AAAA, CNAME, MX, TXT 및 기타 관련 레코드를 복사합니다. 위임 정보를 변경하기 전에 새 권한 네임서버에 직접 조회해 정상적으로 응답하는지 확인하세요.
- 상위 영역의 DNSSEC 정보를 확인합니다. DS 레코드가 있는지 조회하고, 누가 해당 레코드를 변경할 수 있는지 파악합니다. DNSSEC를 직접 활성화한 적이 없더라도 확인해야 합니다. 일부 DNS 서비스는 서명을 자동으로 설정하기 때문입니다.
- 기존 서명 영역이 작동 중일 때 오래된 DS를 제거합니다. 권한을 가진 상위 영역에서 변경 사항을 확인한 뒤, 이전에 캐시된 DS 정보가 만료될 때까지 충분히 기다립니다. 대기 시간은 실제로 관찰한 TTL에 따라 결정되며 모든 상황에 적용되는 고정된 시간이 아닙니다.
- 네임서버 위임 정보를 변경합니다. 캐시에 남아 있는 NS 위임 정보가 여전히 기존 네임서버를 가리킬 수 있으므로, 그동안 이전 권한 DNS 서비스를 계속 사용할 수 있도록 유지합니다. 상위 영역 NS 레코드의 TTL을 고려하고 각 리졸버가 실제로 어떤 서버를 이용하는지 확인하세요.
- DNSSEC를 다시 활성화할지 결정합니다. 새 서비스를 서명 없이 운영한다면 DS를 게시하지 마세요. 서명을 사용하려면 일치하는 DS를 게시하기 전에 새로운 DNSKEY와 서명이 올바르게 제공되는지 확인합니다. 기존 NS 정보가 캐시에 남아 있는 동안 새로운 검증 불일치가 발생하지 않도록 전환 시점도 조율해야 합니다.
- 독립적인 방법으로 검증합니다. 상위 영역의 DS, 권한 DNS의 DNSKEY, 일반적인 재귀 DNS 조회 결과, 검증 리졸버의 인증된 응답 여부를 확인합니다.
DNSSEC 보호를 중단 없이 유지해야 한다면 일시적으로 서명을 해제하는 방법보다 명시적으로 조율된 키 롤오버 또는 다중 서명자 방식의 전환이 더 적합합니다. 다만 이를 위해서는 두 DNS 운영자 모두 필요한 키 및 서명 구성 방식을 지원해야 합니다. 이전 DS 다이제스트를 새로운 운영자에게 단순히 복사하는 것만으로는 키 롤오버가 이루어지지 않습니다.
이전 후 확인할 간단한 점검 목록
DNSSEC 관련 설정을 변경한 뒤에는 DNS 레코드 자체뿐 아니라 리졸버가 해당 레코드를 정상적으로 검증하는지도 확인해야 합니다.
dig example.com DS +noall +comments +answer
dig example.com DNSKEY +dnssec +noall +comments +answer
dig example.com A +dnssec +noall +comments +answer
dig example.com A +cdflag +noall +comments +answer인증된 응답을 확인할 때는 DNSSEC 검증을 수행하는 재귀 리졸버를 사용하세요. 응답에 NOERROR와 예상한 A 레코드가 있으면 DNS 조회가 성공했다는 의미입니다. 여기에 ad 플래그까지 있다면 해당 리졸버가 자체 DNSSEC 정책에 따라 응답을 인증했다는 뜻입니다. 다만 ad 플래그가 없다는 사실만으로 검증 실패라고 단정할 수는 없습니다. 리졸버의 기능과 정책, 조회에 사용한 플래그에 따라 결과가 달라지기 때문입니다. 장애 중에 검증 리졸버를 통한 DNSKEY 조회가 실패한다면 조사 과정에서 현재 사용 중인 권한 DNS 서비스에도 직접 조회해야 합니다.
리졸버 하나에서 성공적인 응답을 받았다고 확인을 끝내지 마세요. 서로 다른 캐시에는 각기 다른 위임 정보와 키가 일시적으로 남아 있을 수 있습니다. 또한 진행 중인 운영 지원 요청이 있다면 그 내용도 업데이트해야 합니다. 새로운 정상 DS가 게시된 뒤에는 이전에 전달한 모든 DS 레코드를 제거하라는 지시가 위험해질 수 있습니다. 후속 요청에서는 현재 사용 중인 유효한 키를 유지해야 한다는 점을 명확히 밝히고, 필요하다면 오래된 레코드만 제거해 달라고 요청해야 합니다.
이번 장애의 원인은 잘못된 웹 서버 주소가 아니었습니다. DNS 응답을 제공하는 서버를 변경하면서 리졸버가 어떤 응답을 신뢰해야 하는지 판단하는 신뢰 정보까지 먼저 일치시키지 않았기 때문에 발생했습니다. 따라서 네임서버를 전환하기 전에 반드시 확인해야 할 실무적인 질문은 다음과 같습니다. 상위 영역은 어떤 DS 레코드를 게시하고 있으며, 이전할 DNS 서비스의 DNSKEY와 서명이 그 레코드에 따른 검증을 충족할 수 있는가?