DNSSEC 적용 시 패킷 크기 증가에 따른 네트워크 단편화 대응 기술

DNSSEC 응답 패킷 크기 증가의 근본 원인과 네트워크 영향 분석

DNSSEC(Domain Name System Security Extensions)는 DNS 쿼리에 디지털 서명을 추가하여 응답의 무결성과 인증을 보장하는 보안 프로토콜입니다. 기존 DNS 응답에 RSA 또는 ECDSA 알고리즘 기반의 서명(RRSIG 레코드), 공개 키(DNSKEY 레코드), 위임 서명자(DS 레코드) 등의 새로운 리소스 레코드가 추가됩니다. 이로 인해 UDP(User Datagram Protocol) 기반의 표준 DNS 응답 패킷 크기가 512바이트에서 종종 1500바이트를 초과하게 됩니다. 이는 이더넷의 표준 최대 전송 단위(MTU, Maximum Transmission Unit)인 1500바이트를 넘어설 수 있으며, 그래서 IP 단편화(IP Fragmentation)를 유발합니다. 단편화된 패킷은 방화벽이나 라우터에서 차단되거나 재조합 실패 가능성이 높아, 클라이언트의 DNS 해석 실패(Resolution Failure)로 직결됩니다. 이는 DNSSEC 도입의 가장 실질적인 운영상 장애물로 작용합니다.

핵심 대응 기술 1: EDNS0와 버퍼 크기 협상(EDNS0 Buffer Size Negotiation)

이 문제를 해결하기 위한 최초의 표준적 접근법은 확장 메커니즘 DNS(EDNS0, Extension Mechanisms for DNS)입니다. EDNS0는 DNS 메시지에 OPT 가상 레코드를 도입하여, 클라이언트가 자신이 수용할 수 있는 최대 UDP 응답 패킷 크기(UDP Payload Size)를 서버에 알릴 수 있게 합니다. 이는 기존 512바이트 제한을 공식적으로 확장하는 계기가 되었습니다.

운영 관점에서, 권장되는 최소 UDP 페이로드 크기는 1232바이트입니다. 이 크기는 IPv6 경로에서 최소 MTU(1280바이트)를 고려한 안전한 값으로, 대부분의 DNSSEC 응답을 단편화 없이 전송할 수 있습니다. 네임서버(BIND, PowerDNS, Knot DNS 등)와 리졸버(Unbound, systemd-resolved, 공급자 리졸버) 양측에서 이 값을 적절히 설정하는 것이 필수적입니다. 클라이언트가 작은 버퍼 크기(예: 512바이트)를 알리고, 서버 응답이 이를 초과할 경우, 서버는 응답을 자르지(Truncate) 않고 TC(Truncated) 비트를 설정하여 클라이언트에게 TCP 폴백을 유도합니다.

주요 DNS 소프트웨어의 EDNS0 버퍼 크기 설정 예시

BIND 네임서버의 경우, ‘options’ 섹션에서 ‘edns-udp-size’와 ‘max-udp-size’ 지시어를 통해 제어합니다. 리졸버 측에서는 쿼리를 보낼 때 사용할 EDNS 버퍼 크기를 설정해야 합니다. 시스템 호환성을 위해, 네트워크 장비(일례로 방화벽)가 512바이트 이상의 큰 DNS UDP 패킷과 관련 ICMP 패킷(패스 MTU 발견에 필요)을 차단하지 않도록 정책을 점검하는 선행 작업이 반드시 필요합니다.

핵심 대응 기술 2: TCP 폴백(TCP Fallback)의 의무화와 효율화

역사적으로 DNS는 신속성을 위해 UDP를 우선 사용해 왔으나, DNSSEC 환경에서는 TCP 사용이 사실상 표준화되었습니다. IETF 표준(RFC 7766)은 이제 DNS over TCP를 “첫 번째 클래스 시민”으로 규정하며, 모든 DNS 구현이 TCP 포트 53을 지원해야 함을 명시합니다. 응답 크기가 클라이언트가 알린 UDP 버퍼 크기나 경로 MTU를 초과하면, 서버는 TC 비트를 설정한 UDP 응답을 보내고, 클라이언트는 동일한 쿼리를 TCP로 재시도합니다.

TCP는 연결 설정(3-way handshake)과 헤더 오버헤드로 인해 초기 지연이 발생할 수 있으나, 대용량 응답의 신뢰성 있는 전송을 보장합니다. 최신 구현에서는 TCP 연결 재사용(TCP Connection Reuse) 및 파이프라이닝(Pipelining) 기술을 적용하여, 하나의 TCP 연결 내에서 여러 DNS 쿼리와 응답을 순서대로 교환함으로써 오버헤드를 줄이고 효율성을 높입니다. 운영자는 방화벽에서 인바운드/아웃바운드 TCP 53 포트를 열어두고, 네임서버가 TCP 연결을 적절히 처리할 수 있는 충분한 리소스(메모리, 파일 디스크립터)를 할당했는지 확인해야 합니다.

핵심 대응 기술 3: DNSSEC 응답 최적화 기법

패킷 크기 문제를 근본적으로 완화하기 위해 응답 자체를 최적화하는 기술이 발전했습니다. 가장 효과적인 방법은 다음과 같습니다.

• 알고리즘 선택: ECDSA(P-256) 서명은 동일한 보안 강도를 제공하는 RSA(SHA-256, 2048비트) 서명에 비해 크기가 약 60% 작습니다. 이러한 eCDSA 서명 레코드(RRSIG) 크기는 약 64바이트인 반면, RSA 2048 서명은 약 256바이트입니다. 신규 도메인 등록 시 ECDSA 알고리즘(알고리즘 번호 13 또는 14) 채택이 강력히 권장됩니다.
• NSEC3 대신 NSEC 사용: 영역 거부 존재 증명을 위해 NSEC3는 해시 연산을 추가로 수행하여 레코드 크기가 증가합니다. 보안상 반드시 NSEC3가 필요한 경우(예: 영역 워킹 방지)가 아니라면, 더 간결한 NSEC 레코드 사용을 고려할 수 있습니다.
• 불필요한 레코드 최소화: 권위 서버 응답에 글로벌 힌트(루트 힌트)나 추가 데이터(Aditional Section)를 불필요하게 포함하지 않도록 구성합니다.

차세대 프로토콜: DNS over TLS/HTTPS의 간접적 해결

DNS over TLS(DoT, 포트 853)와 DNS over HTTPS(DoH, 포트 443)는 암호화를 주목적으로 하지만, TCP/TLS 또는 HTTP/2 위에서 동작함으로써 단편화 문제를 자연스럽게 회피합니다. 이 프로토콜들은 본질적으로 스트림 기반 전송을 사용하므로, 응답 크기에 대한 근본적인 제약이 UDP에 비해 훨씬 큽니다. 특히 HTTP/2는 멀티플렉싱을 지원하여 여러 DNS 요청/응답을 병렬로 처리하며 효율적입니다. DoT/DoH의 도입은 네트워크 중간 장치의 간섭을 줄이고 프라이버시를 강화하는 동시에, 대용량 DNSSEC 응답 전송의 신뢰성 문제를 해결하는 부수적 이점을 제공합니다.

종합 대응 전략 및 운영 체크리스트

단일 기술로 모든 문제를 해결하기는 어렵습니다. 다음 표는 설명된 기술들을 종합 비교한 것입니다.

운영을 위한 실질적인 체크리스트는 다음과 같습니다. 첫째, 권위 서버와 재귀 리졸버의 EDNS 버퍼 크기를 1232바이트 이상으로 설정합니다. 둘째, 네임서버와 리졸버의 TCP 53 처리 능력을 테스트하고 방화벽을 개방합니다. 셋째, 가능하다면 ECDSA 알고리즘을 사용한 DNSSEC 키 롤오버를 계획합니다. 넷째, 네트워크 경로상에서 ICMP “패킷 too big” 메시지가 차단되지 않았는지 확인하여 패스 MTU 발견(PMTUD)이 정상 작동하도록 합니다. 다섯째, 모니터링 시스템을 구축하여 TC 비트 설정 응답 빈도, TCP 폴백 비율, 쿼리 실패율을 지속적으로 추적합니다.

주의사항과 잠재적 리스크 관리

DNSSEC 단편화 대응 작업은 신중한 계획과 테스트 없이 진행할 경우 서비스 중단을 초래할 수 있습니다. 가장 큰 리스크는 네트워크 중간 장치(방화벽, IDS/IPS, 라우터)의 비호환성입니다. 이러한 장치들이 512바이트를 초과하는 DNS/UDP 패킷이나 예상치 못한 DNS/TCP 트래픽을 정책상 차단할 수 있습니다. 변경 전 스테이징 환경에서 포괄적인 테스트를 수행하고, 프로덕션 적용 시에는 점진적인 롤아웃과 실시간 모니터링이 필수적입니다. 아울러, ECDSA 알고리즘 전환 시 일부 레거시 DNS 유효성 검사기가 서명을 검증하지 못하여 해당 도메인에 대한 해석 실패가 발생할 수 있으므로, 이중 서명(Dual-signing) 기간을 충분히 두는 것이 안전합니다. 모든 기술적 조치의 궁극적 목표는 보안 강화(DNSSEC)와 서비스 가용성 사이의 최적 균형을 찾는 것임을 명심해야 합니다.