已更新 1个月前
DNS 응답이 리졸버에 도착했을 때, 어떻게 그 답이 진짜인지 알 수 있을까요? 네트워크 경로상의 누구든 쿼리를 가로채고 위조된 응답을 보낼 수 있습니다. 도메인이 정상 서버 대신 공격자의 서버로 연결될 수도 있습니다.
DNSSEC는 이 답할 수 없는 질문—"누가 이것을 보냈는가?"—을 검증 가능한 질문으로 바꿉니다: 누가 이것을 보증하는가?
신뢰 체인
DNS 루트 존은 모든 도메인 이름의 최상위에 있습니다. 리졸버는 루트 존을 무조건 신뢰합니다—이 신뢰는 소프트웨어에 직접 설정되어 있습니다. 이 단 하나의 신뢰 기점에서, 신뢰는 서명을 타고 아래로 이어집니다.
루트는 .com을 보증하는 서명을 합니다. .com은 example.com을 보증하는 서명을 합니다. 그리고 example.com은 자체 레코드에 서명합니다. 각 보증은 개인 키 없이는 위조할 수 없는 암호화 서명입니다.
example.com을 조회할 때, 리졸버는 그냥 답을 받아들이지 않습니다. 체인을 따라갑니다: 루트가 .com을 보증하는가? .com이 example.com을 보증하는가? example.com의 서명이 유효한가? 모든 연결이 맞아떨어지면, 답은 진짜입니다.
서명의 작동 방식
DNSSEC 서명된 존은 두 가지를 공개합니다: 공개 키(DNSKEY 레코드)와 서명(RRSIG 레코드).
존 소유자는 개인 키로 각 레코드 집합에 서명합니다. 이 서명—RRSIG 레코드에 저장됨—은 DNS 데이터와 함께 전달됩니다. 검증할 때, 리졸버는 존의 공개 키를 가져와 서명을 복호화한 뒤, 수신한 레코드의 해시를 직접 계산합니다. 해시가 일치하면 두 가지가 증명됩니다: 개인 키를 가진 누군가가 서명을 만들었고, 레코드는 그 이후 변조되지 않았습니다.
그런데 공개 키 자체는 어떻게 신뢰할 수 있을까요? 영리한 공격자라면 레코드와 그것에 서명할 가짜 키를 함께 위조할 수 있습니다.
DS 레코드: 존 간의 연결 고리
바로 여기서 체인이 형성됩니다. 각 상위 존은 하위 존의 키 해시를 담은 DS(Delegation Signer) 레코드를 공개합니다. 상위 존은 자체 키로 이 DS 레코드에 서명합니다.
example.com 검증은 이렇게 이루어집니다:
example.com의 공개 키로example.com의 서명 확인.com의 DS 레코드에서 해시를 대조해 해당 키 검증- 루트의 DS 레코드에서 해시를 대조해
.com의 키 검증 - 트러스트 앵커—리졸버가 신뢰하도록 설정된 키—에 대해 루트의 키 검증
모든 연결이 암호학적으로 검증됩니다. 어느 연결 하나라도 끊기면 검증이 실패합니다.
리졸버가 실제로 하는 일
DNSSEC 검증 리졸버는 하나 이상의 트러스트 앵커—본질적으로 신뢰하는 공개 키, 보통 루트 존의 키—로 시작합니다. 그 외 모든 것은 검증되어야 합니다.
쿼리가 들어오면, 리졸버는 위에서 아래로 작동합니다. 하위 존으로 넘어가기 전에 각 존의 키를 검증합니다. 전체 체인이 확인된 후에야 최종 답을 받아들입니다.
리졸버는 레코드와 함께 검증 상태를 캐시합니다. .com의 키가 한번 검증되면, 이후 .com 도메인에 대한 쿼리는 캐시된 키가 만료될 때까지 그 단계를 건너뜁니다. 덕분에 DNSSEC가 대부분의 쿼리에 눈에 띄는 지연을 더하지 않습니다.
검증 실패 시
검증은 여러 이유로 실패할 수 있습니다: 만료된 서명, 누락된 레코드, 끊어진 체인, 또는 실제 공격.
DNSSEC 검증 리졸버는 검증되지 않은 데이터를 반환하는 대신 SERVFAIL을 반환합니다. 거짓 정보를 전달하느니 아무것도 주지 않겠다는 뜻입니다. 서명된 존이 검증되지 않으면 뭔가 잘못된 것이며, 리졸버는 그것을 눈감아 주지 않습니다.
이 때문에 잘못된 설정이 도메인을 접근 불가능하게 만들 수 있습니다. 존 운영자가 서명 만료 전에 갱신하는 것을 잊으면 검증이 실패하고, 문제가 해결될 때까지 도메인은 응답 불가 상태가 됩니다. 프로토콜은 "검증할 수 없음"과 "검증 실패"를 동일하게 취급합니다—둘 다 응답 없음으로 이어집니다.
DNSSEC 지원과 DNSSEC 검증
모든 리졸버가 검증을 수행하는 것은 아닙니다. 이 차이는 중요합니다.
DNSSEC 지원 리졸버는 DNSSEC 레코드 유형을 이해하고 전달할 수 있지만, 서명을 검증하지는 않습니다. DNSSEC를 처리할 능력은 있어도 강제하지는 않습니다. 공격자가 위조된 응답을 보내도 이런 리졸버는 아무런 문제 없이 캐시하고 제공합니다.
DNSSEC 검증 리졸버는 모든 서명과 신뢰 체인을 적극적으로 검증합니다. 검증에 실패한 데이터는 제공하지 않습니다. Google(8.8.8.8)과 Cloudflare(1.1.1.1) 같은 주요 공용 리졸버는 검증 리졸버입니다—클라이언트가 DNSSEC를 이해하는지 여부와 관계없이, 이를 사용하는 모든 사람을 보호합니다.
보안 보장은 검증 리졸버에서만 나옵니다. 검증 없이 DNSSEC를 지원하는 것은 문에 자물쇠를 달아놓고 잠그지 않는 것과 같습니다.
DNSSEC 검증에 관해 자주 묻는 질문
DNSSEC가 두 종류의 키(ZSK와 KSK)를 사용하는 이유는 무엇인가요?
ZSK(Zone Signing Key)는 존의 레코드에 서명하며 자주 교체할 수 있습니다. KSK(Key Signing Key)는 DNSKEY 레코드 자체에 서명합니다. 이렇게 역할을 분리하면 상위 존과 조율하지 않고도 ZSK를 변경할 수 있습니다—상위에서 DS 레코드를 업데이트해야 하는 것은 KSK 변경뿐입니다.
DNSSEC 서명이 없는 도메인을 조회하면 어떻게 되나요?
리졸버는 검증 없이 답을 반환합니다. DNSSEC는 적용 여부를 선택하는 방식입니다—서명되지 않은 존은 항상 그랬던 것처럼 정상적으로 작동합니다. 리졸버는 DNSSEC가 배포된 존에 대해서만 검증을 수행합니다.
DNSSEC가 모든 DNS 공격으로부터 보호해 주나요?
DNSSEC는 DNS 응답의 변조와 위조로부터 보호합니다. 쿼리를 암호화하지는 않으며(그것은 DNS-over-HTTPS나 DNS-over-TLS가 담당합니다), 권한 있는 서버 자체에 대한 공격도 막지 못합니다. 방어의 한 레이어일 뿐, 완전한 해결책은 아닙니다.
일부 도메인이 DNSSEC 때문에 접근 불가능해지는 이유는 무엇인가요?
대부분 서명이 만료되었거나 신뢰 체인이 끊어졌기 때문입니다. DNSSEC는 지속적인 관리가 필요합니다—서명은 만료 전에 갱신되어야 하고, 키 변경은 상위 존과 조율되어야 합니다. 운영자가 이를 소홀히 하면 검증이 실패하고, 검증 리졸버에서는 해당 도메인에 접근할 수 없게 됩니다.
此页面对您有帮助吗？