DNS (도메인 이름 시스템) 사람이 읽을 수 있는 도메인 이름을 IP 주소로 변환하여 인터넷 통신을 가능하게 하는 중요한 서비스입니다. DNS 쿼리의 주요 프로토콜은 전통적으로 UDP(User Datagram Protocol)였지만, TCP(Transmission Control Protocol)도 지원됩니다. RFC 5966은 UDP를 보완하기 위해 DNS에서 TCP를 사용하는 데 대한 사양과 설명을 제공합니다. 이 문서에서는 RFC 5966을 자세히 살펴보고 DNS 클라이언트와 서버 간의 통신 프로세스와 UDP 및 TCP 트래픽 모두에 대한 부하 분산을 구현하는 방법을 설명합니다.

DNS 통신에서의 UDP 대 TCP #

DNS를 위한 UDP: 기본 접근 방식 #

DNS 쿼리는 일반적으로 UDP(53번 포트)를 통해 전송됩니다. UDP는 연결 없이 동작하는 경량 프로토콜로, 최소한의 오버헤드로 소량의 데이터 패킷을 전송하는 데 탁월합니다. 일반적인 DNS 요청은 클라이언트가 DNS 서버에 쿼리를 전송하고, 서버가 해당 IP 주소로 응답하는 방식으로 이루어집니다.

UDP가 DNS의 기본값인 이유는 효율성 때문입니다.

• 낮은 대기 시간: UDP는 데이터 전송 전에 연결을 설정할 필요가 없으므로 지연이 최소화됩니다.
• 무국적 통신: 각 요청은 독립적이어서 빠르고 간단합니다.
• 소형 탑재물: DNS 요청은 대개 매우 작으며 UDP는 혼잡 없이 이를 효과적으로 처리할 수 있습니다.

하지만 UDP는 특히 안정성 측면에서 한계가 있습니다. 패킷이 손실되거나 순서가 뒤바뀌어 도착할 수 있습니다. 또한, DNS 응답이 일반적인 UDP 크기 제한(기존 DNS의 경우 512바이트, EDNS4096의 경우 0바이트까지 확장)을 초과하여 잘림 현상이 발생할 수 있습니다.

DNS를 위한 TCP: 안정적인 대안 #

TCP는 UDP와 달리 연결 지향 프로토콜로, 핸드셰이크를 설정하고 패킷의 순차적 전달을 보장함으로써 안정적인 데이터 전송을 제공합니다. 전통적으로 DNS over TCP는 DNS 서버 간의 영역 전송(AXFR/IXFR 작업)과 UDP로 처리하기에 너무 큰 DNS 응답을 처리하는 대체 시나리오에만 사용되었습니다.

RFC 5966은 DNS 서버가 예외적인 경우뿐만 아니라 모든 쿼리에 대해 DNS over TCP를 지원해야 함을 명시합니다. DNS에서 TCP를 사용하는 주요 이유는 다음과 같습니다.

• 대규모 응답: DNSSEC(DNS 보안 확장) 및 기타 향상된 기능으로 인해 DNS 메시지 크기가 커졌습니다. 응답이 UDP 크기 제한을 초과하면 클라이언트는 TCP로 전환하여 전체 응답을 수신합니다.
• 신뢰성: TCP는 모든 패킷이 올바른 순서로 수신되도록 보장하여 UDP에서 발견되는 안정성 문제를 해결합니다.

UDP 및 TCP를 통한 DNS 통신 작동 방식 #

UDP 통신 #

• 클라이언트는 UDP를 통해 서버에 DNS 쿼리를 보냅니다.
• 서버는 쿼리를 처리하고 일반적으로 512바이트 제한 내에서 응답을 보냅니다.
• 서버의 응답이 이 한도를 초과하고 잘림이 발생하면 클라이언트는 TCP를 통해 쿼리를 다시 보냅니다.

TCP 통신 #

• 클라이언트는 3방향 핸드셰이크를 통해 TCP 연결을 시작합니다.
• 쿼리가 전송되고, 서버는 전체 DNS 답변으로 응답합니다.
• 통신이 끝나면 연결은 닫히지만, 오버헤드를 줄이기 위해 여러 쿼리에 대해 지속적인 연결을 유지할 수 있습니다.

DNS의 UDP 및 TCP에 대한 부하 분산 #

부하 분산은 특히 트래픽이 많은 환경에서 DNS 서비스의 안정성, 가용성 및 확장성을 보장하는 데 중요한 역할을 합니다. DNS 요청을 여러 서버에 분산하고, 리소스 사용을 최적화하며, 응답 시간을 개선할 수 있습니다. DNS 트래픽의 경우 UDP와 TCP 부하 분산 모두 중요하지만, 두 방법 모두 약간 다릅니다.

UDP DNS 트래픽 부하 분산 #

UDP는 상태 비저장(Stateless)이므로, UDP 부하 분산은 연결 상태를 추적하지 않고 개별 요청의 부하를 분산하는 것을 포함합니다. UDP 부하 분산에는 여러 가지 기술이 있습니다.

• 라운드 로빈 DNS: DNS 리졸버는 여러 DNS 서버에 쿼리를 무작위로 분산하여 트래픽을 분산하는 간단한 방법을 제공합니다.
• 애니캐스트 라우팅: 애니캐스트를 사용하면 서로 다른 위치에 있는 여러 DNS 서버가 동일한 IP 주소를 광고합니다. 네트워크는 클라이언트의 쿼리를 가장 가까운 서버로 라우팅하여 지연 시간을 줄입니다.
• IP 해싱: 일부 로드 밸런서는 소스 IP 주소를 사용하여 트래픽을 동일한 DNS 서버로 일관되게 라우팅합니다. 이를 통해 동일한 클라이언트가 일정 기간 동안 동일한 서버로 라우팅되도록 할 수 있습니다.

TCP DNS 트래픽 부하 분산 #

TCP는 연결 지향형이므로, 로드 밸런서는 각 연결의 상태를 추적하여 세션의 모든 패킷이 동일한 DNS 서버로 라우팅되도록 해야 합니다. TCP 로드 밸런싱 기술은 다음과 같습니다.

• 세션 지속성: "스티키 세션"이라고도 하는 이 방법은 동일한 TCP 세션의 모든 패킷이 동일한 서버로 라우팅되도록 합니다. 이는 TCP 연결의 무결성을 유지하는 데 매우 중요합니다.
• 레이어 4 로드 밸런싱: 4계층(전송 계층)의 로드 밸런서는 IP 주소와 TCP/UDP 포트 번호를 기반으로 트래픽을 분산하여 각 연결이나 세션이 동일한 서버에서 처리되도록 보장합니다.
• 레이어 7 로드 밸런싱: 7계층(애플리케이션 계층)에서 로드 밸런서는 DNS 쿼리를 직접 검사하고 요청된 도메인 이름과 같은 쿼리 내용에 따라 지능적인 라우팅 결정을 내릴 수 있습니다.

DNS에 대한 부하 분산 구현의 장점 #

• 중복성 및 장애 조치: 부하 분산을 통해 한 서버에 장애가 발생하더라도 다른 서버가 원활하게 작동하여 지속적인 DNS 확인이 가능합니다.
• 확장성: 수요가 증가하면 클라이언트 측 구성을 변경하지 않고도 로드 밸런서 뒤에 추가 서버를 추가할 수 있습니다.
• 지리적 분포: 애니캐스트 라우팅을 사용하면 DNS 서버를 여러 지리적 위치에 분산시킬 수 있어 클라이언트가 가장 가까운 서버에 접근하여 더 빠르게 문제를 해결할 수 있습니다.

DNS-over-UDP 및 DNS-over-TCP 부하 분산 구성 #

Relianoid Load Balancer를 사용하여 DNS 트래픽의 부하를 효과적으로 분산하려면 포트 53에서 DNS-over-UDP 및 DNS-over-TCP용으로 두 개의 별도 팜을 구성할 수 있습니다. DNS-over-UDP 팜은 일반적으로 크기가 작고 연결이 없는 표준 DNS 쿼리를 처리하여 속도와 리소스 사용량을 최적화합니다. 반면, DNS-over-TCP 팜은 일반적인 UDP 패킷 크기(512바이트)를 초과하거나 영역 전송과 같이 더 안정적인 전송이 필요한 DNS 쿼리를 처리하도록 설정됩니다. 프로토콜을 기반으로 이러한 팜을 분할하면 포트 53에서 각 트래픽 유형을 효율적으로 처리하고, 프로토콜별 부하 분산을 활용하면서 복원력을 향상시키고 병목 현상을 줄일 수 있습니다.

그렇게 하려면 섹션에 Farms를 만드세요. LSLB > 농장 과 L4xNAT 프로필 및 NAT 아래와 같이 모드가 표시됩니다.

맺음말 #

RFC 5966은 기존 UDP 기반 요청 외에도 DNS 쿼리에 TCP를 지원하는 것의 중요성을 강조합니다. UDP는 효율성 덕분에 여전히 주요 프로토콜이지만, TCP는 대용량 응답 및 DNSSEC 쿼리에 대한 안정성을 제공합니다. DNS 서비스가 확장성과 복원력을 갖추려면, 특히 트래픽이 많은 상황에서는 UDP 및 TCP 트래픽 모두에 대한 부하 분산 전략을 구현하는 것이 필수적입니다. 이러한 부하 분산 기술은 DNS 서비스의 응답성과 보안을 유지하고 증가하는 수요를 처리할 수 있도록 보장합니다.

두 프로토콜을 이해하고 활용하고 적절한 부하 분산을 통해 네트워크 관리자는 최신 인터넷 요구 사항을 충족하는 강력한 DNS 인프라를 구축할 수 있습니다.