DNSSEC 검증 실패(SERVFAIL) 해결

Problem

서명된 존이 status: SERVFAIL을 반환하는데, 죽은 네임서버는 이미 배제했습니다 — 권한 서버에 직접 물으면 멀쩡히 답합니다. 레코드도 맞습니다. 그런데도 검증 리졸버를 거치면 이름이 안 풀립니다. DNS에서 가장 잔인한 실패 모드입니다: DNSSEC가 올바른 답을 일부러 거부하고 있습니다. 그 답이 진짜라는 걸 증명하지 못하기 때문입니다.

Symptoms

• dig example.com은 SERVFAIL인데 dig +cd example.com은 레코드를 돌려줍니다.
• 키 롤오버, DNS 공급자 이전, 또는 DNSSEC를 처음 켠 직후 도메인이 죽었습니다.
• 어떤 네트워크(검증 안 하는 리졸버)에선 풀리고 다른 데(1.1.1.1, 8.8.8.8, Quad9)선 SERVFAIL입니다.
• Extended DNS Errors를 지원하는 리졸버가 “DNSSEC Bogus”, “Signature Expired” 같은 구체적 이유를 돌려줍니다.

”검증 실패”가 실제로 뜻하는 것

DNSSEC는 아무것도 암호화하지 않습니다. 받은 답이 존 소유자가 실제로 게시한 답인지 리졸버가 검증할 수 있게 할 뿐입니다. 이걸 서명 체인으로 합니다: 루트 존이 TLD를 보증하고, TLD가 DS 레코드로 당신의 도메인을 보증하고, 당신의 도메인은 DNSKEY로 자기 레코드에 서명해 모든 레코드 셋에 RRSIG 서명을 만듭니다.

검증 리졸버는 그 체인을 루트에서 아래로 따라 내려갑니다. 단 한 고리라도 안 맞으면 — 상위의 DS가 DNSKEY와 불일치, RRSIG 만료, 엉뚱한 키를 덮은 서명 — 리졸버는 우아하게 넘어가지 않습니다. “이번 한 번만” 레코드를 내주지 않습니다. 죽은 서버에서 받는 것과 똑같은 일반적 코드, SERVFAIL을 반환합니다. 프로토콜이 인증 못 한 데이터를 의도적으로 거부하기 때문입니다. 그게 DNSSEC의 전부이고, 레지스트라의 낡은 레코드 하나가 인터넷의 3분의 1에서 당신의 도메인을 지워버릴 수 있는 이유이기도 합니다.

좋은 소식: 요즘 리졸버는 어느 고리가 끊겼는지 알려줄 수 있습니다. RFC 8914가 **Extended DNS Errors(EDE)**를 추가했습니다. SERVFAIL에 실패 원인을 가리키는 코드를 붙이는 겁니다. 실제로 보게 될 것들:

• EDE 6 — DNSSEC Bogus: 검증 실패, 일반적.
• EDE 7 — Signature Expired: RRSIG의 유효 기간이 지남.
• EDE 8 — Signature Not Yet Valid: RRSIG의 시작 시각이 미래(보통 시계 오차나 조기 게시 문제).
• EDE 9 — DNSKEY Missing: 상위에 DS는 있는데 자식 존에 맞는 DNSKEY가 없음.
• EDE 10 — RRSIGs Missing: 서명돼 있어야 할 레코드에 서명이 없음.

리졸버가 이 중 하나를 보고하면, 이미 트리아지를 대신 해준 셈입니다.

Top 3 Causes

1. 키 롤오버 후 DS / DNSKEY 불일치 — 가장 흔한 원인. 새 키 서명 키(KSK)는 만들었는데 레지스트라의 DS 레코드는 여전히 옛 키를 가리키고 있습니다(또는 아예 게시 안 됨). 상위 존이 당신 존이 더는 안 쓰는 키를 보증하고 있으니 신뢰 체인이 끊깁니다. EDE 9(DNSKEY Missing) 또는 일반 Bogus가 납니다. 고칠 곳은 레지스트라입니다: 라이브 KSK와 맞는 DS를 게시하고, 새 DS가 TTL을 넘겨 전파될 때까지 옛 키를 폐기하지 마세요.
2. 만료된 RRSIG 서명 — TLS 인증서와 달리 DNSSEC 서명은 유효 기간이 짧고(흔히 2주 안팎) 만료 전에 존을 재서명해야 합니다. 서명 자동화가 깨지거나 수동 존을 제때 재서명 안 하면 모든 서명이 한꺼번에 만료되고, 검증 리졸버가 전 세계에서 EDE 7(Signature Expired)을 반환합니다 — 레코드는 하나도 안 바뀌었는데도요. 신호: 어제까진 됐고 아무도 DNS를 안 건드렸다.
3. 알고리즘 또는 다이제스트 불일치 — DS 레코드는 특정 서명 알고리즘과 다이제스트 타입을 고정합니다. DNS 공급자를 옮기면서 새 공급자가 다른 알고리즘으로 서명하거나, 잘못된 다이제스트로 DS를 게시하면, 검증 리졸버가 상위의 DS와 자식의 키를 맞추지 못합니다. DNSSEC를 DS 재조율 없이 “그대로 가져온” 공급자 이전에서 흔합니다.

DechoNet으로 진단

• DNS 검사는 네트워크 밖에서 이름을 조회해 권한 서버가 실제로 돌려주는 레코드를 보여줍니다. 레코드는 멀쩡하고 정확한데 검증 리졸버를 거치면 여전히 SERVFAIL이면, 레코드는 정상이고 체인이 끊긴 것을 확인한 겁니다 — 존 내용이 아니라 DS와 서명을 보세요.
• 전파 검사는 여러 독립 리졸버에 한꺼번에 묻습니다. 체인이 끊긴 서명 존은 깔끔하게 갈립니다: 검증 리졸버는 SERVFAIL, 검증 안 하는 리졸버는 응답. 그 갈림이 죽은 네임서버(어디서나 실패)가 아니라 DNSSEC 실패라는 지문입니다.

Resolution Checklist

• 검증 문제인지 확인: dig +cd example.com은 답을 돌려주는데 dig example.com은 SERVFAIL. +cd도 실패하면 DNSSEC 문제가 아니니 네임서버를 보세요.
• 리졸버가 제공하면 Extended DNS Error를 읽으세요: dig example.com 출력의 EDE: 줄. 코드 6~10이 각각 다른 해법을 가리킵니다.
• 상위와 자식을 비교: dig DS example.com @<상위-ns> vs dig DNSKEY example.com. DS 다이제스트가 게시된 DNSKEY 중 하나와 맞아야 합니다. 롤오버 후의 불일치가 전형적 사인(死因)입니다.
• 서명 신선도 확인: dig RRSIG example.com으로 만료 필드를 읽으세요. 과거 날짜면 제때 재서명을 안 한 것 — 서명 파이프라인을 고치고 재서명하세요.
• DNSViz나 delv example.com(검증 경로와 정확한 실패 이유를 출력) 같은 체인 분석기로 체인이 어디서 끊기는지 위에서 아래까지 전체를 보세요.
• DS를 제때 못 고치고 장애가 실시간 진행 중이면, 비상 정지는 DNSSEC를 통째로 끄는 것입니다: 레지스트라의 DS 레코드를 삭제하세요. 리졸버가 검증을 멈추고 서명 안 된 존을 내줍니다. 해결이 아니라 롤백이지만, 장애는 끝납니다.

When to Escalate

• DS/DNSKEY 불일치는 레지스트라 계정을 가진 쪽만 고칠 수 있습니다 — DS는 DNS 공급자가 아니라 상위 존이 쥐고 있습니다. 둘이 다른 업체면 양쪽이 다 필요합니다.
• 관리형 DNS 공급자에서 만료된 서명은 그 공급자의 자동화가 실패한 겁니다. 재서명을 직접 트리거하는 게 아니라면 티켓을 여세요 — 반복되는 만료는 그 공급자를 떠날 이유로 보세요.
• delv와 DNSViz 둘 다 깨끗한 검증 체인을 보여주는데 특정 리졸버만 SERVFAIL이면, 그 리졸버 캐시가 낡은 bogus 결과를 쥐고 있는 겁니다. TTL이 지나면 알아서 풀립니다; 당신 쪽에서 빠르게 할 방법은 없습니다.