왜 지금 포스트 양자 DNSSEC인가
DNS 응답은 기본적으로 인증되지 않습니다. 공격자가 응답을 위조하면 사용자를 원치 않는 주소로 유도할 수 있죠. DNSSEC은 DNS 레코드에 서명을 붙여 이 문제를 막습니다. 1.1.1.1 같은 검증 리졸버는 루트부터 도메인까지 서명 체인을 따라가며 응답이 진짜인지 확인해요.
문제는 현재 쓰이는 대부분의 DNSSEC 알고리즘(RSA, ECDSA)이 미래의 양자 컴퓨터에 취약하다는 점입니다. 2030년쯤 충분히 강력한 양자 컴퓨터가 등장해 개인키를 복구할 수 있다고 가정하면, 공격자는 검증기가 받아들이는 위조 서명을 만들 수 있게 됩니다. DNSSEC은 기밀성이 아니라 진위성 보장이 목적이라 '지금 수집해서 나중에 복호화' 공격에는 해당하지 않지만, 알고리즘 교체에는 권한 서버·레지스트리·레지스트라·검증 리졸버 전체의 합의가 필요하기 때문에 미리 시작해야 합니다. 특히 루트 존 서명 키가 뚫리면 하위 모든 존에 위조 경로를 만들 수 있는 '한 번 뚫으면 전부 위조' 시나리오가 가능해요.
Cloudflare는 2029년까지 완전한 포스트 양자 보안을 목표로 하고 있으며, 이번 1.1.1.1의 ML-DSA-44 검증 기본 활성화는 그 첫걸음입니다. 배경과 전체 로드맵은 근거자료에서 확인할 수 있어요.
핵심 난제: 2,420바이트 서명이 만드는 연쇄 효과
ML-DSA-44 서명은 하나가 2,420바이트입니다. 기존 ECDSA P-256 서명(64바이트)의 약 38배죠. 이 크기가 왜 문제인지 표로 보시죠.
| 알고리즘 | DNSSEC 번호 | 공개키 크기 | 서명 크기 |
|---|---|---|---|
| RSA-2048/SHA-256 | 8 | 260 bytes | 256 bytes |
| ECDSA P-256 | 13 | 64 bytes | 64 bytes |
| ML-DSA-44 | 18 | 1,312 bytes | 2,420 bytes |
DNS over UDP의 실질 상한은 보통 1,232바이트(IPv6 최소 MTU 1,280바이트 고려), 최근 RFC 9715는 1,400바이트를 권장합니다. ML-DSA-44 서명 하나가 이 예산을 혼자 초과해요. 그래서 권한 서버는 잘린 응답(truncated)을 돌려주고, 리졸버는 TCP나 DoT/DoH로 재시도하게 됩니다.
실제로 1.1.1.1에 질의하면 이런 흐름을 볼 수 있습니다.
# UDP로 먼저 시도 → 잘림 → TCP로 재시도
$ dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssec
;; WARNING: truncated reply from 1.1.1.1@53(UDP), retrying over TCP
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 17546
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 3; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR
;; ANSWER SECTION:
valid.mldsa44.dnstest.dev. 0 IN A 188.114.97.0
valid.mldsa44.dnstest.dev. 0 IN A 188.114.96.0
valid.mldsa44.dnstest.dev. 0 IN RRSIG A 18 4 0 20260910114537 20260909104537 23176 valid.mldsa44.dnstest.dev. Qoycouhsc...
;; Received 2563 B
;; From 1.1.1.1@53(TCP) in 20.7 ms
Cloudflare Radar 기준 1.1.1.1 질의의 약 85%가 UDP로 들어오고, Big Pineapple 플랫폼 전체로 보면 약 60%가 UDP입니다. 나머지 40%는 이미 TCP/DoT/DoH를 쓰고 있어서, 전송 계층 다변화 자체는 운영상 낯선 일이 아니에요. 다만 ML-DSA-44 응답은 권한 서버 쪽에서 추가 TCP 재시도를 유발할 수 있다는 점은 비용으로 계산해야 합니다.
다운그레이드 공격이라는 함정
마이그레이션 기간에는 구형 리졸버 호환을 위해 기존 알고리즘과 ML-DSA-44를 함께 게시해야 합니다. 그런데 RFC 6840은 "검증기는 유효한 경로 하나만 받아들이면 된다"고 규정합니다. 즉 ECDSA가 털린 뒤에도 공격자가 ECDSA 전용 위조 응답을 던지면 리졸버가 이를 수용할 수 있는 다운그레이드 경로가 생겨요.
1.1.1.1은 이를 막기 위해 부모 존이 게시한 DS 레코드를 인증 신호로 사용합니다. DS RRset에 지원하는 포스트 양자 알고리즘이 있으면, 로컬 정책으로 "포스트 양자 검증 경로 최소 1개 필수"를 강제하는 식이죠. RFC 4035가 로컬 리졸버 정책으로 추가 서명 검증 여부를 정할 수 있도록 허용하기 때문에 가능한 접근입니다.
전망과 주의사항
생태계 전체가 함께 가야 한다
ML-DSA-44 검증을 리졸버에 넣는 건 첫 단계일 뿐입니다. 완전한 포스트 양자 신뢰 체인을 만들려면 다음이 모두 필요해요.
- 권한 서버: ML-DSA-44로 존 서명
- 레지스트라: 대응하는 DS 레코드 접수·제출
- 레지스트리: 부모 존에 DS 레코드 게시
- 루트 존: ML-DSA-44 채택 및 트러스트 앵커 전환
어느 한 단계라도 포스트 양자 보호가 빠지면 그 지점이 다운그레이드 포인트가 됩니다. 서명을 자주 갱신한다고 해결되지 않아요. 공격자는 체인 상단의 취약한 키 하나만 노리면 되니까요.
실무 관점 주의사항
- UDP 잘림은 정상 동작: ML-DSA-44 응답에서 truncated 응답은 버그가 아니라 설계된 동작입니다. 모니터링에서 TCP 재시도 증가를 이상 징후로 오탐하지 마세요.
- 방화벽/프록시 점검: 53번 TCP, DoT(853), DoH(443) 경로가 실제로 열려 있는지 확인해야 합니다. UDP만 허용된 환경에서는 ML-DSA-44 존 해석이 실패할 수 있어요.
- DS 레코드 배포 순서: 부모 존 DS가 먼저 게시되지 않으면 다운그레이드 보호가 작동하지 않습니다.
- 클라이언트 측 검증: 1.1.1.1 사용자는 별도 설정이 필요 없지만, 사내 리졸버를 운영한다면 ML-DSA-44 지원 여부를 별도로 확인해야 합니다.
다음 단계 학습 방향
dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssec로 직접 테스트해보고 TCP 재시도 흐름을 관찰하세요.- Cloudflare의 "Is your DNS resolver post-quantum ready?" 도구로 현재 쓰는 리졸버를 점검해보세요.
- ML-DSA for DNSSEC 인터넷 드래프트와 RFC 4035의 로컬 정책 조항을 읽어보면 다운그레이드 방지 설계를 더 깊이 이해할 수 있습니다.
- TLS 쪽 포스트 양자 마이그레이션(X25519Kyber768 등)과 비교해보면 "전송 계층 vs 서명 계층"의 차이가 명확해집니다.
정리: 지금 당장 할 일
1.1.1.1을 쓰고 있다면 따로 바꿀 건 없습니다. 존이 필요한 DNSSEC 레코드를 게시하면 ML-DSA-44 검증은 자동으로 이뤄지고, 기존 DNSSEC 존은 예전처럼 검증됩니다. Cloudflare는 다음 단계로 Authoritative DNS의 ML-DSA-44 서명 지원과 Registrar의 DS 레코드 지원을 무료로 제공할 예정이라, 전체 경로(서명 생성 → DNSKEY 게시 → 전송 → 검증)를 실제로 시험해볼 수 있게 됩니다.
양자 컴퓨터가 내일 당장 RSA를 깨뜨리진 않겠지만, DNSSEC 마이그레이션은 수년이 걸리는 조율 작업입니다. 지금 1.1.1.1에서 대규모 테스트를 시작하는 이유가 여기에 있어요.