DNS와 IP 주소 체계

도메인 이름 시스템(Domain Name System)은 사람이 읽을 수 있는 도메인 이름(예: www.example.com)을 컴퓨터가 통신에 사용하는 IP 주소(예: 192.0.2.1)로 변환하는 분산형 데이터베이스 시스템이다. 인터넷의 전화번호부에 비유되며, 사용자가 복잡한 숫자 주소를 외울 필요 없이 직관적인 이름으로 웹사이트나 서비스에 접근할 수 있게 한다.

이 시스템은 1983년 폴 모카페트리스(Paul Mockapetris)와 존 포스텔(Jon Postel)에 의해 제안되었으며, 기존의 단일 호스트 파일(HOSTS.TXT) 관리 방식의 비효율성과 확장성 문제를 해결하기 위해 개발되었다[1]. DNS는 클라이언트-서버 모델을 기반으로 하여, 전 세계에 분산된 서버들이 계층 구조를 이루며 도메인 이름과 IP 주소의 매핑 정보를 저장하고 관리한다.

도메인 이름 시스템의 핵심은 이름 공간(namespace)을 계층적 트리 구조로 구성하는 것이다. 트리의 각 노드는 0개 이상의 리소스 레코드(Resource Record)를 보유하며, 최상위에는 루트 도메인(.)이 위치한다. 그 아래로 최상위 도메인(TLD, 예: .com, .org, .kr), 두 번째 수준 도메인(SLD, 예: example), 그리고 하위 호스트 이름(예: www) 등이 계층을 형성한다. 이 구조는 관리의 분권화와 책임 소재의 명확화를 가능하게 한다.

도메인 이름 시스템(DNS)의 핵심 기능은 사람이 읽을 수 있는 도메인 이름(예: www.example.com)을 컴퓨터가 통신에 사용하는 IP 주소(예: 192.0.2.1)로 변환하는 것이다. 이 변환 과정을 '이름 해석' 또는 '리졸루션'이라고 한다. 사용자가 웹 브라우저에 도메인 이름을 입력하면, DNS는 이를 해당 서버의 실제 숫자 형식의 IP 주소로 변환하여 통신이 가능하게 한다. 이는 전화번호부에서 이름을 검색하여 해당 전화번호를 찾는 과정에 비유할 수 있다.

DNS의 필요성은 사용 편의성과 시스템 유연성에서 비롯된다. 사람은 www.google.com과 같은 문자 주소를 기억하기 쉽지만, 142.250.206.238과 같은 숫자 조합을 일일이 기억하는 것은 거의 불가능하다. DNS는 이러한 기억 부담을 덜어준다. 더 중요한 것은, DNS는 물리적인 IP 주소가 변경되더라도 사용자가 동일한 도메인 이름을 계속 사용할 수 있게 한다는 점이다. 예를 들어, 웹사이트 서버의 IP 주소가 바뀌어도 DNS 기록만 업데이트하면 사용자는 아무런 변화를 느끼지 못하고 같은 도메인 이름으로 접속할 수 있다.

DNS는 단순한 변환기를 넘어 인터넷 인프라의 핵심 조정자 역할을 한다. 주요 기능은 다음과 같이 요약할 수 있다.

이러한 기능 덕분에 DNS는 현대 인터넷이 단순성, 확장성, 유연성을 유지하며 작동할 수 있는 기반을 제공한다. DNS가 없다면, 인터넷은 모든 서비스 접근에 복잡한 숫자 주소를 직접 입력해야 하는 불편하고 경직된 공간이 될 것이다.

IPv4 주소는 인터넷 프로토콜 버전 4에서 사용되는 32비트 길이의 논리적 주소이다. 이 주소는 네트워크 상의 각 장치를 고유하게 식별하는 역할을 한다. 주소는 일반적으로 사람이 읽기 쉽도록 점으로 구분된 네 개의 10진수로 표현되며, 각 10진수는 0부터 255 사이의 값을 가진 8비트 옥텟을 나타낸다. 예를 들어, 192.168.1.1과 같은 형태이다.

초기 네트워크 설계에서는 주소 공간을 효율적으로 할당하고, 네트워크 규모에 따라 구분하기 위해 클래스 기반 주소 체계(Classful Addressing)를 도입했다. 이 체계는 주소의 첫 번째 옥텟의 상위 비트 패턴에 따라 A, B, C, D, E 다섯 개의 클래스로 나뉜다.

클래스 A는 최대 1600만 개 이상의 호스트를 수용할 수 있는 대형 네트워크에, 클래스 B는 약 6만 5천 개의 호스트를 위한 중형 네트워크에, 클래스 C는 254개의 호스트를 위한 소형 네트워크에 할당되었다. 클래스 D는 멀티캐스트 그룹 통신에, 클래스 E는 미래 사용을 위해 예약되었다.

그러나 이 클래스 기반 체계는 주소 공간의 낭비가 심하고 유연성이 부족하다는 단점이 있었다. 예를 들어, 클래스 B 네트워크 하나를 할당받은 조직이 수만 개의 주소 중 일부만 사용하면 나머지 주소는 사용되지 못하고 낭비되었다. 이러한 비효율성은 IPv4 주소의 고갈을 가속화하는 요인 중 하나가 되었다. 이 문제를 해결하기 위해 이후 CIDR(Classless Inter-Domain Routing)과 서브넷 마스크를 활용한 클래스리스 주소 체계가 표준으로 자리 잡았다.

IPv6 주소는 128비트 길이를 가지며, 16비트씩 8개의 그룹으로 나뉘어 콜론(:)으로 구분하여 표기한다. 각 그룹은 4개의 16진수로 표현된다. 예를 들어, 2001:0db8:85a3:0000:0000:8a2e:0370:7334와 같은 형태를 가진다. 선행하는 0은 생략할 수 있으며, 연속된 0으로만 이루어진 하나의 그룹은 ::로 압축하여 표기할 수 있다. 그러나 이러한 압축은 주소당 한 번만 사용할 수 있다[4].

IPv6의 가장 두드러진 특징은 거의 무한에 가까운 주소 공간을 제공한다는 점이다. 이는 IPv4 주소 고갈 문제를 근본적으로 해결한다. 또한, 주소 자동 구성 기능이 강화되어, 장비가 네트워크에 연결되면 라우터로부터 접두어 정보를 받아 자동으로 IP 주소를 생성할 수 있다. 보안 측면에서는 IPsec 프로토콜의 사용이 표준 사양에 포함되어, 데이터 인증과 암호화를 기본적으로 지원한다.

IPv4와 비교했을 때 IPv6의 주요 구조적 차이점은 다음과 같다.

이러한 변화로 인해 IPv6는 향상된 성능, 간소화된 라우팅, 그리고 모바일 장치 지원의 용이성을 제공한다. 그러나 기존 IPv4 인프라와의 호환성 문제로 인해 전 세계적인 전환은 점진적으로 이루어지고 있다.

DNS 질의는 사용자가 웹 브라우저에 도메인 이름을 입력할 때 시작된다. 이 과정은 일반적으로 재귀적 질의와 반복적 질의의 조합으로 이루어진다. 사용자의 컴퓨터(호스트)는 먼저 로컬 DNS 캐시를 확인하고, 정보가 없으면 설정된 로컬 DNS 서버(보통 ISP가 제공)에 재귀적 질의를 보낸다.

로컬 DNS 서버는 이 요청을 받고, 자신의 캐시에 해당 정보가 없으면 루트 DNS 서버에 반복적 질의를 시작한다. 루트 서버는 질의된 도메인 이름의 최상위 도메인(TLD)을 관리하는 서버(예: .com, .net 서버)의 주소를 알려준다. 로컬 DNS 서버는 그 TLD 서버에 다시 질의하고, TLD 서버는 해당 도메인의 권한 있는 네임 서버(Authoritative Name Server)의 주소를 응답한다.

로컬 DNS 서버는 최종적으로 권한 있는 네임 서버로부터 얻은 IP 주소를 사용자 컴퓨터에 응답하고, 이 정보를 자신의 캐시에 일정 시간(TTL) 동안 저장한다. 사용자 컴퓨터는 받은 IP 주소를 사용하여 해당 웹 서버에 직접 연결한다. 이 전체 과정은 밀리초 단위로 매우 빠르게 이루어지며, 대부분의 단계는 캐싱 덕분에 생략된다.

DNS 서버는 단일 중앙 집중식 구조가 아닌, 전 세계적으로 분산된 계층적 구조로 운영된다. 이 계층 구조는 크게 루트 DNS 서버, 최상위 도메인 서버, 권한 있는 네임 서버로 구분된다. 각 계층은 자신이 담당하는 도메인 정보의 일부만을 관리하며, 질의 요청을 하위 계층으로 전달하거나 최종 응답을 제공하는 역할을 한다.

루트 DNS 서버는 계층 구조의 최상위에 위치한다. 전 세계에 13개의 루트 서버 그룹(A부터 M)이 존재하며, 각 그룹은 Anycast 기술을 통해 여러 물리적 서버로 구성되어 가용성을 높인다. 루트 서버는 최상위 도메인 목록(예: .com, .net, .kr 등)을 관리하는 서버들의 주소 정보만을 알고 있다. 클라이언트의 질의가 루트 서버에 도달하면, 해당 질의의 TLD를 담당하는 서버의 주소를 안내한다.

TLD 서버는 .com, .org, .kr 같은 최상위 도메인을 관리하는 서버이다. 이 서버들은 해당 TLD 아래에 등록된 모든 2차 도메인의 권한 있는 네임 서버 주소 정보를 보유한다. 예를 들어, example.com에 대한 질의가 .com TLD 서버에 전달되면, example.com 영역을 실제로 관리하는 권한 있는 네임 서버의 주소를 응답한다.

권한 있는 네임 서버는 특정 도메인 이름 영역(예: example.com)에 대한 최종 책임을 지는 서버이다. 이 서버는 해당 도메인에 속하는 호스트 이름과 IP 주소 매핑 정보를 담은 DNS 레코드를 직접 저장하고 관리한다. 최종적으로 이 서버가 www.example.com에 대한 A 레코드나 AAAA 레코드와 같은 실제 IP 주소 정보를 응답한다. 하나의 도메인 영역에는 보통 주 서버와 보조 서버가 쌍을 이루어 운영되어 신뢰성을 확보한다.

DNS 레코드는 도메인 이름을 다양한 정보에 매핑하는 데 사용되는 지시문입니다. 이 중 가장 기본적이고 필수적인 레코드 유형은 A 레코드와 AAAA 레코드, 그리고 별칭을 지정하는 CNAME 레코드입니다.

A 레코드는 "Address"의 약자로, 도메인 이름을 IPv4 주소로 직접 연결합니다. 이는 호스트 이름을 32비트 숫자로 구성된 IPv4 주소로 변환하는 가장 일반적인 방법입니다. 예를 들어, example.com이라는 도메인이 192.0.2.1이라는 IP 주소를 가리키도록 설정하는 데 사용됩니다. 하나의 도메인 이름은 여러 개의 A 레코드를 가질 수 있으며, 이를 통해 로드 밸런싱이나 리던던시를 구현할 수 있습니다.

AAAA 레코드는 "Quad-A"라고 불리며, 도메인 이름을 IPv6 주소로 연결합니다. IPv4 주소 고갈 문제를 해결하기 위해 도입된 128비트 주소 체계인 IPv6를 지원하기 위한 레코드입니다. A 레코드가 IPv4를 처리한다면, AAAA 레코드는 IPv6를 처리합니다. 동일한 도메인 이름에 대해 A 레코드(IPv4)와 AAAA 레코드(IPv6)를 모두 설정하여 이중 스택 환경을 구성할 수 있습니다.

CNAME 레코드는 "Canonical Name"의 약자로, 한 도메인 이름을 다른 '정규' 도메인 이름에 대한 별칭으로 만듭니다. IP 주소를 직접 가리키지 않고, 다른 도메인 이름을 가리키는 포인터 역할을 합니다. 예를 들어, www.example.com에 대한 CNAME 레코드를 example.com으로 설정하면, www.example.com에 대한 조회는 최종적으로 example.com의 A 레코드나 AAAA 레코드가 가리키는 IP 주소를 반환합니다. 서브도메인을 관리하거나 CDN 서비스를 연결할 때 자주 사용되지만, CNAME 레코드는 루트 도메인(example.com)에는 일반적으로 설정할 수 없으며, 다른 CNAME 레코드를 가리키는 순환 참조를 만들지 않도록 주의해야 합니다.

MX 레코드(Mail Exchanger Record)는 도메인의 이메일 수신을 담당하는 메일 서버를 지정하는 데 사용되는 DNS 레코드이다. 이 레코드는 메일 전송 프로토콜인 SMTP가 발신자의 메일을 정확한 수신 서버로 라우팅할 수 있도록 안내하는 역할을 한다. MX 레코드에는 우선순위 값이 포함되어 있으며, 이 값이 낮을수록 높은 우선순위를 가진다. 주 메일 서버가 장애를 일으킬 경우, 우선순위가 더 높은(숫자가 더 큰) 백업 서버로 메일 전송을 시도하게 된다[6].

TXT 레코드(Text Record)는 도메인에 대한 임의의 텍스트 정보를 제공하는 데 사용된다. 초기에는 단순한 메모 용도로 사용되었지만, 현재는 주로 도메인 소유권 확인, 이메일 보안 정책 설정, 스팸 방지 등 다양한 검증 목적으로 활용된다. 가장 대표적인 사용 사례는 SPF(Sender Policy Framework), DKIM(DomainKeys Identified Mail), DMARC(Domain-based Message Authentication, Reporting & Conformance)와 같은 이메일 인증 메커니즘을 구성하는 것이다. 이러한 정책은 TXT 레코드에 특정 형식의 텍스트로 저장되어, 수신 메일 서버가 해당 도메인에서 발송된 메일의 진위를 판별하는 데 도움을 준다.

NS 레코드(Name Server Record)는 특정 도메인이나 서브도메인에 대한 권한 있는 DNS 서버(Authoritative Name Server)가 무엇인지를 지정하는 가장 근본적인 레코드이다. 이 레코드는 DNS 계층 구조에서 특정 도메인 영역의 관리 책임을 어느 서버에게 위임했는지를 정의한다. 일반적으로 도메인 등록 시, 등록 기관(Registrar)의 네임서버가 기본적으로 설정되며, 사용자가 별도의 DNS 호스팅 서비스를 이용할 경우 해당 서비스 제공자의 네임서버 주소로 NS 레코드를 변경한다. NS 레코드는 도메인 자체에 대한 질의를 해결할 수 있는 최종적인 서버의 주소를 가리키므로, DNS 해석 과정의 정상적인 출발점이 된다.

공인 IP 주소는 인터넷 상에서 전 세계적으로 고유하게 식별되는 주소입니다. IANA와 같은 기관이 관리하며, 인터넷 서비스 제공자를 통해 사용자에게 할당됩니다. 이 주소는 인터넷에 직접 연결된 모든 장치(예: 웹 서버, 라우터)에 필요하며, 외부에서 해당 장치를 찾아갈 수 있는 실제 주소 역할을 합니다. 공인 IP 주소의 수는 제한되어 있어, 특히 IPv4 체계에서는 부족 현상이 두드러집니다.

사설 IP 주소는 로컬 영역 네트워크이나 기업망과 같은 폐쇄된 네트워크 내부에서만 사용되는 주소입니다. RFC 1918 표준에 의해 다음의 주소 대역이 사설 IP로 예약되어 있습니다.

이 주소들은 서로 다른 내부 네트워크에서 중복해서 사용될 수 있지만, 인터넷으로는 직접 라우팅되지 않습니다.

사설 IP를 사용하는 내부 네트워크의 장치가 인터넷과 통신하려면 네트워크 주소 변환 기술이 필요합니다. NAT 장비(보통 라우터나 게이트웨이)는 내부 장치의 사설 IP 주소와 포트를 자신의 공인 IP 주소로 변환하여 외부와 통신합니다. 이를 통해 하나의 공인 IP 주소로 여러 대의 사설 IP 장치가 인터넷에 접속할 수 있어, 공인 IP 주소 고갈 문제를 완화하고 네트워크 보안을 강화하는 효과가 있습니다[8].

IP 주소를 네트워크 장치에 할당하는 방법은 크게 동적 할당과 정적 할당으로 구분된다. 동적 호스트 구성 프로토콜(DHCP)은 네트워크에 접속하는 장치에 IP 주소, 서브넷 마스크, 기본 게이트웨이, DNS 서버 주소 등의 네트워크 설정 정보를 자동으로 할당하는 프로토콜이다. DHCP 서버는 미리 정의된 주소 풀(IP Pool)에서 사용 가능한 주소를 클라이언트에게 임대(Lease)하며, 임대 기간(TTL)이 지나면 해당 주소는 회수되어 풀로 돌아간다. 이 방식은 대규모 네트워크에서 장치의 추가, 이동, 제거가 빈번할 때 관리 부담을 크게 줄여준다.

반면 정적 할당(Static Allocation)은 네트워크 관리자가 각 장치에 고정된 IP 주소를 수동으로 설정하는 방식이다. 주로 서버, 네트워크 프린터, 라우터, 방화벽 등 항상 고정된 주소로 접근해야 하는 중요한 네트워크 장비에 사용된다. 정적 할당은 주소가 변하지 않아 DNS 레코드 설정이나 방화벽 규칙 관리가 용이하지만, 네트워크 규모가 커질수록 주소 충돌을 방지하기 위한 관리 작업이 복잡해질 수 있다.

두 방식의 주요 특징을 비교하면 다음과 같다.

현대 네트워크에서는 이 두 방식을 혼합하여 사용하는 것이 일반적이다. 예를 들어, 대부분의 사용자 단말은 DHCP를 통해 주소를 받고, 중요한 서버나 네트워크 장비는 정적 IP를 할당한다. 또한 DHCP 서버 자체에서 특정 MAC 주소를 가진 장치에게 항상 같은 IP를 할당하는 'DHCP 예약'(Reservation) 기능을 제공하기도 한다. 이는 정적 할당의 관리적 이점과 DHCP의 자동화 이점을 결합한 방식이다.

도메인 이름 해석 과정은 사용자가 웹 브라우저에 도메인 이름을 입력했을 때, 해당 이름에 대응하는 IP 주소를 찾아내는 일련의 절차이다. 이 과정은 DNS 질의를 시작으로 여러 계층의 DNS 서버를 거쳐 최종적인 IP 주소를 얻을 때까지 진행된다.

일반적인 해석 과정은 재귀적 질의와 반복적 질의가 결합된 방식으로 이루어진다. 사용자의 컴퓨터(DNS 리졸버)는 먼저 자신의 로컬 캐시를 확인한다. 캐시에 정보가 없으면, 사전에 설정된 로컬 DNS 서버(대개 ISP가 제공)에 재귀적 질의를 보낸다. 로컬 DNS 서버는 자신의 캐시를 확인한 후, 정보가 없으면 루트부터 탐색을 시작한다. 이때 로컬 DNS 서버는 클라이언트 대신 질의를 수행하는 재귀 리졸버 역할을 한다.

로컬 DNS 서버는 다음과 같은 순서로 반복적 질의를 통해 최종 답변을 찾아낸다.

1. 루트 DNS 서버에 질의하여 해당 최상위 도메인(TLD, 예: .com)을 관리하는 서버의 주소를 얻는다.

2. 획득한 TLD 네임서버에 질의하여 해당 도메인(예: example.com)의 권한 있는 네임서버 주소를 얻는다.

3. 마지막으로 해당 권한 있는 네임서버에 질의하여 원하는 호스트(예: www.example.com)에 대한 A 레코드 또는 AAAA 레코드(IP 주소)를 최종적으로 받아온다.

로컬 DNS 서버는 이 최종 IP 주소를 클라이언트에게 응답하고, 동시에 자신의 캐시에 저장하여 향후 같은 질의에 빠르게 응답할 수 있도록 한다. 클라이언트는 받은 IP 주소를 사용하여 해당 웹 서버와 직접 TCP/IP 연결을 수립하고 데이터를 주고받는다. 이 전체 과정은 대부분 수 밀리초 내에 완료되며, TTL(Time To Live) 값은 캐시에 저장된 정보의 유효 기간을 제어하여 네트워크 효율성과 정보의 신선도를 유지하는 데 기여한다.

DNS 캐싱은 네트워크 효율성을 극대화하기 위한 핵심 메커니즘이다. 사용자가 도메인 이름을 입력하면, 해당 질의는 최종 권한 있는 네임 서버에 도달하기 전에 여러 단계의 서버를 거친다. 이 과정에서 각 DNS 서버(재귀 리졸버, ISP의 서버 등)는 받은 응답을 일정 시간 동안 임시로 저장한다. 이후 동일한 도메인 이름에 대한 질의가 들어오면, 서버는 저장된 정보를 즉시 응답하여 불필요한 외부 질의를 생략한다. 이는 네트워크 트래픽을 줄이고, 사용자에게 더 빠른 응답 시간을 제공한다.

캐싱의 지속 시간은 TTL 값에 의해 제어된다. TTL은 'Time To Live'의 약자로, DNS 레코드에 설정된 초 단위의 숫자 값이다. 이 값은 해당 레코드 정보가 캐시에 유효하게 보관될 수 있는 최대 시간을 정의한다. TTL이 만료되면, 캐시에 저장된 정보는 폐기되며, 다음 동일 질의 시에는 권한 있는 네임 서버로부터 새로운 정보를 다시 조회해야 한다.

TTL 값은 도메인 관리자가 DNS 레코드를 설정할 때 정의한다. 값의 설정은 상황에 따라 전략적으로 이루어진다. 예를 들어, 자주 변경되지 않는 안정적인 서비스의 A 레코드는 긴 TTL(예: 86400초, 24시간)을 설정하여 캐시 효율을 높인다. 반면, 서버 IP 주소를 자주 변경해야 하거나, 긴급한 장애 조치가 필요한 경우에는 짧은 TTL(예: 300초, 5분)을 설정하여 변경 내용이 빠르게 전 세계 캐시에 반영되도록 한다.

캐싱과 TTL은 DNS 시스템의 확장성과 안정성의 기반이지만, 설정값이 부적절할 경우 문제를 일으킬 수 있다. 너무 긴 TTL은 정보 변경 시 전파 지연을 유발하여 서비스 중단 시간을 길게 만들 수 있다. 반대로, 너무 짧은 TTL은 권한 있는 서버에 대한 질의 빈도를 과도하게 높여 서버 부하를 증가시킨다. 따라서 도메인 관리자는 서비스 특성과 운영 요구사항에 맞춰 최적의 TTL 값을 결정해야 한다.

DNS 스푸핑은 공격자가 위조된 DNS 응답을 사용자에게 전달하여, 정상적인 도메인 이름(예: www.example.com)을 공격자가 통제하는 악성 서버의 IP 주소로 연결되도록 조작하는 공격 기법이다. 사용자는 자신이 접속하려는 합법적인 사이트에 들어갔다고 믿지만, 실제로는 외관이 유사한 피싱 사이트나 악성 코드를 배포하는 서버에 접속하게 된다. 이 공격은 주로 로컬 네트워크에서 ARP 스푸핑과 결합하거나, 취약한 DNS 서버를 대상으로 수행된다.

DNS 캐시 포이즈닝은 DNS 스푸핑의 한 유형으로, 공격 대상이 최종 사용자보다는 DNS 서버의 캐시에 초점을 맞춘다. 공격자는 권한 없는 서버임에도 불구하고, DNS 서버가 특정 도메인에 대한 질의를 했을 때 위조된 권한 응답을 보내어 서버의 캐시를 오염시킨다. 성공하면, 해당 DNS 서버를 이용하는 모든 사용자들이 오염된 캐시 기록을 조회하게 되어 장기간에 걸쳐 악성 사이트로 유도될 수 있다. 이 공격은 DNS 프로토콜의 설계적 취약점, 특히 트랜잭션 ID와 포트 번호의 예측 가능성을 이용한다.

두 공격의 주요 차이점과 영향을 비교하면 다음과 같다.

이러한 공격을 방어하기 위한 기본적인 조치로는 DNS 쿼리에 대한 예측 불가능한 트랜잭션 ID와 출발 포트 번호 사용, DNSCurve 같은 암호화 프로토콜 도입, 그리고 가장 근본적인 해결책으로 DNSSEC의 채택이 있다.

DNSSEC(DNS 보안 확장)은 도메인 이름 시스템의 취약점을 해결하기 위해 설계된 보안 확장 기능 세트이다. 기존 DNS 프로토콜은 데이터의 무결성과 출처 인증을 보장하지 않아, DNS 스푸핑이나 캐시 포이즈닝과 같은 공격에 취약했다. DNSSEC은 공개 키 암호 방식을 사용하여 DNS 응답에 디지털 서명을 추가함으로써, 클라이언트가 받은 응답이 신뢰할 수 있는 권한 있는 서버로부터 왔으며 전송 중 변조되지 않았음을 검증할 수 있게 한다.

DNSSEC의 핵심 작동 원리는 암호화된 서명과 공개 키의 계층적 신뢰 체인에 있다. 각 권한 있는 네임 서버는 자신이 관리하는 DNS 존의 레코드 집합(예: RRset)에 대해 디지털 서명을 생성한다. 이 서명은 해당 존의 개인 키로 생성되며, 응답과 함께 전송된다. 수신자는 존의 공개 키를 사용하여 이 서명의 유효성을 확인할 수 있다. 공개 키의 신뢰성은 상위 계층으로부터의 서명을 통해 검증되며, 최상위인 루트 존의 공개 키는 신뢰의 근원(Trust Anchor)으로 사전에 알려져 있다.

주요 구성 요소와 레코드 유형은 다음과 같다.

DNSSEC의 도입은 보안성을 크게 향상시켰지만, 몇 가지 제약 사항도 존재한다. 첫째, DNSSEC은 DNS 데이터의 기밀성을 보호하지 않으며, 오직 무결성과 인증만을 제공한다. 둘째, 서명 생성과 검증으로 인해 DNS 응답 패킷의 크기가 증가하고, 서버와 리졸버의 계산 부하가 늘어난다. 마지막으로, DNSSEC의 성공적인 배포는 루트 존부터 최종 권한 서버까지의 전체 계층 구조가 일관되게 지원해야 하므로, 복잡한 운영과 조정이 필요하다.

DNS over HTTPS(DoH)와 DNS over TLS(DoT)는 기존의 평문 DNS 질의를 암호화하여 사용자의 프라이버시와 보안을 강화하는 프로토콜이다. 두 기술 모두 전송 계층 보안(TLS)을 기반으로 하여, 제3자가 DNS 질의 내용을 엿보거나 변조하는 것을 방지한다. 그러나 구현 방식과 사용하는 네트워크 포트에서 차이를 보인다.

DoH는 DNS 메시지를 HTTP/2 또는 HTTP/3 프로토콜 내에 캡슐화하여, 표준 HTTPS 포트(443)를 통해 전송한다. 이는 일반적인 웹 트래픽과 구분하기 어렵게 만들어, 네트워크 관리자가 DNS 트래픽을 필터링하거나 모니터링하는 것을 어렵게 할 수 있다. 주요 웹 브라우저와 일부 운영체제에서 기본적으로 지원하기 시작했다. 반면, DoT는 DNS 메시지에 TLS 암호화를 적용하지만, 전용 포트(853)를 사용한다. 이는 암호화된 DNS 트래픽을 명확하게 식별할 수 있게 하여, 기업 환경 등에서 정책 기반의 관리가 상대적으로 용이하다.

두 프로토콜의 채택은 보안 향상과 네트워크 관리의 편의성 사이에서 논쟁을 불러일으켰다. DoH는 사용자 수준의 프라이버시를 강력하게 보호하지만, 조직의 보안 정책이나 자녀 보호 필터링을 우회할 가능성이 있다. DoT는 암호화를 제공하면서도 관리 가능성을 일부 유지하는 절충안으로 여겨진다. 표준화 기구인 IETF는 두 프로토콜 모두를 표준으로 승인했다.

이러한 암호화 DNS 기술의 확산은 DNS 스푸핑이나 중간자 공격(MitM)과 같은 기존 위협을 완화하는 데 기여한다. 그러나 모든 DNS 서버가 이를 지원하는 것은 아니며, 사용자는 신뢰할 수 있는 암호화 DNS 확인자 서버(예: Cloudflare 1.1.1.1, Google 8.8.8.8)를 명시적으로 설정해야 한다.

콘텐츠 전송 네트워크(CDN)는 지리적으로 분산된 서버 네트워크를 활용하여 웹 콘텐츠를 사용자에게 더 빠르고 효율적으로 전달하는 기술이다. CDN은 오리진 서버의 부하를 분산시키고, 사용자와 물리적으로 가까운 에지 서버에서 콘텐츠를 제공함으로써 지연 시간을 줄이고 가용성을 높인다. 이 과정에서 DNS는 사용자의 요청을 가장 적합한 CDN 에지 서버로 안내하는 핵심적인 역할을 수행한다. CDN 제공자는 전 세계에 배치된 서버의 상태(부하, 네트워크 정체도 등)와 사용자의 위치 정보를 기반으로 최적의 서버 IP 주소를 DNS 응답으로 제공한다.

애니캐스트(Anycast)는 하나의 IP 주소를 여러 지리적 위치의 서버에 동시에 할당하고, 라우팅 프로토콜을 통해 사용자의 요청을 가장 가까운(일반적으로 라우팅 홉 수가 가장 적은) 서버로 자동으로 연결하는 네트워크 주소 지정 및 라우팅 방법이다. 이는 동일한 서비스를 제공하는 여러 서버가 하나의 IP 주소를 공유하는 방식이다. 애니캐스트는 DDoS 공격에 대한 복원력을 높이고, 지연 시간을 최소화하는 데 효과적이다.

CDN과 애니캐스트는 종결 함께 사용되어 성능과 안정성을 극대화한다. 많은 CDN 업체는 자신의 DNS 서버 인프라나 글로벌 네트워크 내에서 애니캐스트를 구현한다. 예를 들어, CDN의 권한 있는 네임서버 자체에 애니캐스트 IP를 할당하면, 전 세계 어디서나 발생하는 DNS 질의도 가장 가까운 네임서버로 라우팅되어 빠른 응답을 받을 수 있다. 또한, 콘텐츠를 제공하는 에지 서버의 IP 주소를 애니캐스트로 구성하면, 사용자의 최종 콘텐츠 요청 역시 최적의 서버로 연결된다.

이러한 조합은 사용자에게는 단일 도메인 이름(예시: www.example.com)을 요청하더라도, 백엔드에서는 동적으로 최적의 물리적 서버로 연결되는 투명하고 효율적인 서비스 경험을 제공한다.