1.1.1.3(DNS) (r1)

도메인 이름은 사람이 읽고 기억하기 쉬운 형태의 주소이며, IP 주소는 컴퓨터와 네트워크 장비가 통신에 사용하는 숫자로 된 고유 식별자이다. 예를 들어, 'www.example.com'과 같은 도메인 이름은 '192.0.2.1'이나 '2001:db8::1'과 같은 IPv4 또는 IPv6 주소에 대응된다. DNS의 핵심 기능은 사용자가 입력한 도메인 이름을 컴퓨터가 이해할 수 있는 IP 주소로 변환하는 것이다.

도메인 이름은 계층적 구조를 가진다. 최상위에는 .com, .net, .org 같은 일반 최상위 도메인(gTLD)이나 국가 코드 최상위 도메인(ccTLD)이 위치한다. 그 아래에 'example'과 같은 2차 도메인, 그리고 'www'와 같은 3차 도메인(서브도메인)이 차례로 구성된다. 이 계층 구조는 점('.')으로 구분되며, 오른쪽에서 왼쪽으로 상위에서 하위로 해석된다.

IP 주소는 네트워크 상의 특정 장치를 정확히 찾아가기 위한 주소 체계이다. IPv4 주소는 32비트로 구성되어 약 43억 개의 고유 주소를 제공하지만, 주소 고갈 문제로 인해 128비트 주소 체계를 사용하는 IPv6로 전환되고 있다. DNS는 도메인 이름과 이 IP 주소 간의 매핑 정보를 전 세계에 분산 저장된 네임 서버에 기록하고 관리한다.

이러한 변환 과정이 없으면 사용자는 웹사이트에 접속할 때마다 길고 복잡한 IP 주소를 직접 입력해야 하므로, DNS는 인터넷 사용의 편의성을 근본적으로 제공하는 핵심 시스템이다.

네임 서버는 도메인 이름과 IP 주소 간의 변환 정보를 저장하고 관리하는 특수한 서버이다. 이 서버들은 전 세계에 분산되어 계층적 구조를 이루며, 사용자의 질의에 응답하여 올바른 IP 주소를 찾아주는 핵심적인 역할을 담당한다.

네임 서버는 크게 두 가지 주요 유형으로 구분된다. 하나는 권한 있는 네임 서버이다. 이 서버는 특정 도메인(예: example.com)에 대한 정확한 정보를 최종적으로 보유하고 책임지는 서버이다. 해당 도메인의 A 레코드, MX 레코드 등 모든 DNS 레코드의 원본 데이터를 관리하며, 외부에서 이 도메인에 대해 질의가 오면 권위 있는 답변을 제공한다. 다른 하나는 재귀 리졸버이다. 이 서버는 일반 사용자나 클라이언트 컴퓨터가 직접 질의를 보내는 첫 번째 접점이다. 재귀 리졸버는 클라이언트를 대신하여 필요한 경우 루트 네임 서버, TLD 네임 서버, 최종적으로 권한 있는 네임 서버에 차례로 질의를 수행하여 답을 찾아오는 역할을 한다.

네임 서버 시스템의 효율성은 DNS 캐싱에 크게 의존한다. 재귀 리졸버는 한 번 조회한 도메인 정보를 일정 시간(TTL) 동안 캐시에 저장한다. 이후 동일한 질의가 들어오면 캐시된 정보를 즉시 응답하여, 매번 전체 계층을 거치는 질의 과정을 생략하고 응답 속도를 크게 향상시킨다. 이 분산 캐싱 메커니즘은 전 세계적인 DNS 트래픽 부하를 줄이는 데 결정적인 역할을 한다.

DNS 질의는 크게 재귀적 질의와 반복적 질의 두 가지 방식으로 구분된다. 이 두 방식은 DNS 리졸버와 네임 서버 간의 상호작용 방법을 정의하며, 최종적으로 사용자가 요청한 도메인 이름에 대한 IP 주소를 찾아내는 과정을 담당한다.

재귀적 질의는 클라이언트(예: 사용자의 컴퓨터)가 DNS 리졸버에게 질의를 보낼 때 사용하는 일반적인 방식이다. 이때 클라이언트는 리졸버에게 "이 도메인의 IP 주소를 찾아서 결과만 나에게 알려 달라"고 요청한다. 리졸버는 이 요청을 받으면, 필요한 경우 루트 서버부터 TLD 서버, 최종 권한 있는 네임 서버에 이르기까지 스스로 모든 단계의 질의를 수행하여 최종 답변을 찾는다. 클라이언트는 오직 이 리졸버와만 통신하며, 복잡한 조회 과정을 알 필요가 없다. 대부분의 최종 사용자와 인터넷 서비스 제공업체의 로컬 DNS 서버는 이 재귀적 질의 방식을 사용한다.

반면, 반복적 질의는 DNS 서버 간의 상호작용에 주로 사용된다. 재귀적 질의를 받은 리졸버가 다른 네임 서버에게 질의할 때, 해당 네임 서버는 자신이 최종 답변을 알지 못하면 "다음에 물어볼 서버의 주소"만을 알려준다. 예를 들어, 리졸버가 example.com의 IP를 묻기 위해 루트 DNS 서버에 물으면, 루트 서버는 .com TLD 서버의 주소만 반환한다. 그러면 리졸버는 다시 그 .com TLD 서버에게 질의하고, TLD 서버는 example.com을 관리하는 권한 있는 네임 서버의 주소를 알려준다. 리졸버는 최종 답변을 얻을 때까지 이 과정을 반복적으로 수행해야 한다.

전체적인 DNS 조회 과정은 클라이언트의 재귀적 질의로 시작되어, 리졸버가 이를 받아 여러 네임 서버들에게 반복적 질의를 수행함으로써 완료된다. 이 이중 구조는 질의 부하를 분산시키고, DNS 시스템의 계층적 구조를 효율적으로 운용할 수 있게 한다.

DNS 캐싱은 DNS 질의 응답을 임시로 저장하여 이후 동일한 질의에 대한 응답 속도를 높이고 네트워크 트래픽을 줄이는 메커니즘이다. 리졸버나 사용자의 로컬 DNS 서버는 질의 결과를 일정 시간 동안 캐시에 보관한다. 동일한 도메인 이름에 대한 질의가 다시 발생하면, 서버는 캐시에 저장된 정보를 즉시 반환하여 루트 DNS 서버나 TLD 서버까지 거슬러 올라가는 과정을 생략한다. 이는 전반적인 DNS 해석 속도를 획기적으로 개선하고, 상위 서버에 가해지는 부하를 분산시키는 효과가 있다.

캐시에 저장된 정보의 유효 기간은 TTL 값에 의해 결정된다. TTL은 'Time To Live'의 약자로, DNS 레코드에 설정된 초 단위의 숫자 값이다. 이 값은 해당 레코드 정보가 캐시에 얼마나 오래 유효한지를 정의한다. 예를 들어, A 레코드의 TTL이 300으로 설정되어 있다면, 리졸버는 이 IP 주소 정보를 받은 후 300초(5분) 동안 캐시에 보관하고, 그 기간 내에는 캐시된 정보를 사용한다. TTL이 만료되면 캐시는 해당 정보를 삭제하며, 다음 질의 시에는 다시 권한 있는 서버로부터 새로운 정보를 가져와야 한다.

TTL 값의 설정은 도메인 관리의 중요한 요소이다. 짧은 TTL 값(예: 60초)은 DNS 정보 변경이 빠르게 전파되도록 하여, 서버 이전이나 장애 복구 시 유연성을 제공한다. 반면, 긴 TTL 값(예: 86400초, 1일)은 리졸버가 캐시를 더 오래 유지하게 만들어 반복적인 질의를 줄여 성능을 높이고, 원본 DNS 서버의 부하를 감소시킨다. 그러나 정보 변경 시 전파 지연 시간이 길어질 수 있다는 단점이 있다. 일반적으로 안정적인 서비스에는 긴 TTL을, 변경이 빈번하거나 테스트 환경에는 짧은 TTL을 설정하는 것이 권장된다[2].

A 레코드는 가장 기본적인 DNS 레코드로, 도메인 이름을 IPv4 주소(예: 192.0.2.1)로 매핑한다. 호스트 이름을 32비트 주소로 변환하는 역할을 담당하며, 웹사이트나 서버에 접근하기 위한 필수 레코드이다.

AAAA 레코드는 A 레코드의 IPv6 버전이다. IPv6는 128비트 주소 체계를 사용하며, AAAA 레코드는 도메인 이름을 IPv6 주소(예: 2001:0db8:85a3::8a2e:0370:7334)로 연결한다. IPv4 주소 고갈 문제에 대응하여 점차 중요성이 증가하고 있다.

CNAME 레코드는 'Canonical Name'의 약자로, 한 도메인 이름을 다른 도메인 이름(정규 이름)으로 연결하는 별칭(alias)을 만든다. 실제 IP 주소를 직접 지정하는 대신, 이미 A 레코드나 AAAA 레코드가 설정된 다른 도메인을 가리키도록 한다. 주로 여러 서비스가 하나의 IP 주소를 공유하거나, 서비스 제공업체의 도메인을 사용할 때 활용된다.

CNAME 레코드를 설정하면, 원본 도메인(정규 이름)의 IP 주소가 변경되어도 CNAME 레코드는 자동으로 새로운 주소를 따라간다. 그러나 CNAME 레코드는 도메인 이름의 루트(APEX 도메인 또는 네이키드 도메인)에는 일반적으로 사용할 수 없으며, MX 레코드나 NS 레코드와 같은 다른 레코드와 공존할 수 없다는 제약이 있다.

MX 레코드(Mail Exchanger Record)는 도메인 이름으로 전송되는 이메일을 어떤 메일 서버가 수신할지 지정하는 DNS 레코드이다. 이 레코드는 메일 서버의 호스트명과 우선순위 값을 포함한다. 우선순위 값은 숫자가 낮을수록 높은 우선순위를 의미하며, 주 메일 서버가 응답하지 않을 경우 다음 우선순위의 서버로 메일 전송이 시도된다. 일반적으로 SMTP 프로토콜을 사용하는 메일 시스템의 정상적인 운영에 필수적이다.

TXT 레코드(Text Record)는 도메인에 대한 임의의 텍스트 정보를 제공하는 데 사용된다. 초기에는 사람이 읽을 수 있는 메모 용도였으나, 현재는 주로 이메일 보안, 도메인 소유권 확인, 스팸 방지 정책 설정 등 다양한 검증 목적으로 활용된다. 대표적인 예로 SPF(Sender Policy Framework), DKIM(DomainKeys Identified Mail), DMARC(Domain-based Message Authentication, Reporting & Conformance)와 같은 이메일 인증 메커니즘의 설정 정보를 TXT 레코드에 저장한다.

NS 레코드(Name Server Record)는 해당 도메인의 권한 있는 네임 서버(Authoritative Name Server)가 무엇인지를 지정하는 가장 기본적인 레코드이다. 즉, 어떤 DNS 서버가 해당 도메인에 대한 정확한 정보(레코드)를 가지고 있고 질의에 응답할 권한이 있는지를 정의한다. 일반적으로 도메인 등록 시 상위 도메인(TLD 서버)에 등록되며, 도메인의 DNS 존 파일을 관리하는 서버를 가리킨다.

DNS 스푸핑은 공격자가 위조된 DNS 응답을 전송하여 사용자를 악의적인 웹사이트로 유도하는 공격 기법이다. 이 공격의 핵심은 DNS 캐싱 메커니즘을 악용하는 것이다. 공격자는 리졸버나 사용자 장치의 캐시에 저장된 정상적인 IP 주소 정보를 악성 주소로 바꿔치기한다. 사용자는 정상적인 도메인 이름을 입력했음에도 불구하고, 조작된 DNS 응답에 따라 공격자가 운영하는 가짜 사이트에 접속하게 된다.

DNS 스푸핑의 주요 위협은 피싱과 중간자 공격을 가능하게 한다는 점이다. 예를 들어, 사용자가 온라인 뱅킹 사이트에 접속하려 할 때, DNS 응답이 조작되어 가짜 은행 사이트로 연결될 수 있다. 이 가짜 사이트는 진짜와 똑같이 보이도록 설계되어, 사용자가 입력한 로그인 정보나 금융 정보를 탈취한다. 또한, 합법적인 소프트웨어 업데이트 서버 대신 악성 코드를 배포하는 서버로 연결하여 맬웨어 감염을 유발할 수도 있다.

DNS 스푸핑을 수행하는 일반적인 방법은 다음과 같다.

이러한 위협으로부터 보호하기 위한 기본적인 조치로는 신뢰할 수 있는 DNS 서버를 사용하고, DNSSEC을 활성화하며, 네트워크 암호화를 적용하는 것이 있다.

DNSSEC(DNS Security Extensions)은 DNS 프로토콜의 취약점을 해결하기 위해 설계된 보안 확장 표준이다. 기존 DNS는 데이터의 무결성과 신원 확인을 보장하지 않아, DNS 스푸핑이나 캐시 포이즈닝과 같은 공격에 취약했다. DNSSEC은 공개 키 암호화 기술을 기반으로 DNS 레코드에 디지털 서명을 추가하여, 응답이 신뢰할 수 있는 출처에서 왔으며 전송 중 변조되지 않았음을 검증할 수 있게 한다.

DNSSEC의 핵심 작동 원리는 디지털 서명과 공개 키 인프라(PKI)에 있다. 권한 있는 네임 서버는 존(Zone) 데이터에 개인 키로 서명을 생성하고, 해당 공개 키는 상위 존에 의해 서명되어 신뢰 체인을 형성한다. 최종적으로 이 체인은 루트 DNS 서버까지 이어지며, 리졸버(재귀 DNS 서버)는 이 공개 키들을 사용하여 수신한 응답의 서명을 검증한다. 주요 레코드 종류로는 데이터 서명을 담는 RRSIG, 공개 키를 제공하는 DNSKEY, 그리고 상위 존의 서명된 키 해시를 가리키는 DS(Delegation Signer) 레코드 등이 있다.

DNSSEC의 도입은 보안성을 크게 향상시키지만 몇 가지 제약 사항도 존재한다. 가장 큰 한계는 데이터의 기밀성을 제공하지 않으며, 질의와 응답 내용을 암호화하지 않는다는 점이다[5]]나 DoH와 같은 다른 프로토콜이 담당하는 영역이다]. 또한, 서명 생성과 검증으로 인한 연산 부하가 증가하며, 존 전송(Zone Transfer)과 같은 관리 작업이 더 복잡해질 수 있다. 아래 표는 DNSSEC의 주요 보안 레코드를 정리한 것이다.

전 세계적인 인터넷 인프라의 신뢰성을 높이기 위해, ICANN과 루트 DNS 서버 운영자들은 2010년 루트 존에 DNSSEC 서명을 배포했다. 이로 인해 모든 DNSSEC 검증 리졸버는 루트부터 시작하는 완전한 신뢰 체인을 구축할 수 있게 되었다. 그러나 DNSSEC의 보급률은 아직 완벽하지 않으며, 최종 사용자 측의 리졸버와 도메인 소유자의 존 모두에서 활성화가 필요하다.

루트 DNS 서버는 DNS 계층 구조의 최상위에 위치하는 서버로, 전 세계에 13개의 루트 서버 그룹(A부터 M까지)이 존재합니다. 각 그룹은 Anycast 기술을 통해 전 세계 수백 개의 물리적 서버 인스턴스로 구성되어 있으며, 이는 단일 장애점을 제거하고 전 세계적인 쿼리 부하를 분산시키는 역할을 합니다. 루트 서버는 TLD 서버의 주소 정보를 담고 있으며, 모든 DNS 쿼리는 최초에 이 루트 서버를 참조하는 것으로 시작됩니다.

루트 서버는 IP 주소를 직접 제공하지 않고, 해당 도메인 이름의 최상위 도메인(예: .com, .net, .kr)을 관리하는 TLD 네임 서버의 주소를 안내합니다. 예를 들어, 'example.com'에 대한 질의가 발생하면, 리졸버는 먼저 루트 서버에 '.com' TLD를 관리하는 네임 서버의 주소를 묻습니다. 이후 질의는 해당 TLD 서버로, 그리고 최종적으로 'example.com'을 관리하는 권한 있는 DNS 서버로 이어집니다.

루트 DNS 서버의 운영은 ICANN이 관리하며, 다양한 기관이 서로 다른 루트 서버 글자를 운영합니다. 예를 들어, A 루트 서버는 Verisign이, J 루트 서버는 ICANN 자체가 운영합니다. 루트 존 파일은 정기적으로 갱신되며, 전 세계의 모든 루트 서버 인스턴스는 동일한 데이터를 제공합니다.

이 서버들은 DNS 프로토콜의 근간을 이루며, 인터넷의 정상적인 작동을 위해 필수적인 인프라입니다. 루트 서버에 대한 대규모 DDoS 공격 시도가 있었으나, Anycast와 같은 분산 기술 덕분에 서비스 중단 없이 견뎌냈습니다.

TLD(최상위 도메인) 서버는 .com, .net, .org와 같은 일반 최상위 도메인(gTLD)이나 .kr, .jp와 같은 국가 코드 최상위 도메인(ccTLD)에 대한 정보를 관리하는 서버입니다. 이 서버들은 해당 TLD를 관리하는 레지스트리 조직에 의해 운영되며, 특정 도메인의 권한 있는 네임 서버(Authoritative Name Server)의 주소를 알고 있습니다. 예를 들어, 'example.com'에 대한 질의가 들어오면 루트 DNS 서버는 '.com' TLD 서버의 주소를 알려주고, 이후 질의는 '.com' TLD 서버로 전달됩니다.

권한 있는 DNS 서버는 특정 도메인 이름(예: 'example.com')에 대한 최종적인 정보를 소유하고 제공하는 서버입니다. 이 서버는 해당 도메인의 A 레코드, AAAA 레코드, MX 레코드 등 모든 DNS 레코드의 정확한 데이터를 저장하고 있습니다. TLD 서버로부터 질의를 받으면, 권한 있는 서버는 저장된 레코드 정보를 응답하여 최종적인 IP 주소나 기타 정보를 제공합니다. 하나의 도메인은 보통 두 개 이상의 권한 있는 서버를 설정하여 가용성과 안정성을 높입니다.

TLD 서버와 권한 있는 서버의 관계는 다음과 같은 계층 구조로 설명할 수 있습니다.

이 두 계층의 서버는 DNS 질의 과정에서 핵심적인 역할을 수행합니다. 리졸버는 루트 DNS 서버에서 시작하여 TLD 서버를 거쳐, 최종적으로 권한 있는 서버에 도달함으로써 사용자가 요청한 도메인 이름에 대한 정확한 정보를 얻을 수 있습니다.

리졸버는 클라이언트의 요청을 대신 받아 DNS 질의 과정을 완료하는 서버이다. 재귀적 질의를 수행한다는 특징 때문에 재귀 DNS 서버라고도 불린다. 일반 사용자의 컴퓨터나 라우터에 설정된 DNS 서버 주소는 바로 이 리졸버를 가리킨다. 리졸버의 주요 임무는 클라이언트로부터 받은 도메인 이름을 최종적으로 IP 주소로 변환해 답변하는 것이다.

리졸버는 클라이언트에게서 질의를 받으면, 필요한 경우 루트 DNS 서버부터 시작해 TLD 서버, 그리고 최종적으로 해당 도메인의 권한 있는 네임 서버에 차례대로 반복적 질의를 수행한다. 이 과정에서 리졸버는 각 단계에서 얻은 정보를 DNS 캐싱하여, 동일한 질의가 다시 들어올 경우 더 빠르게 응답할 수 있다. 대부분의 인터넷 서비스 제공자는 자체 리졸버를 운영하여 사용자에게 제공한다.

리졸버는 공개적으로 사용 가능한 서비스로도 존재한다. 대표적인 공개 DNS 리졸버로는 구글 퍼블릭 DNS(8.8.8.8), 클라우드플레어 DNS(1.1.1.1) 등이 있다. 이러한 공개 리졸버는 종종 응답 속도 개선, 개인정보 보호 강화, 보안 필터링 추가 등의 기능을 내세운다. 모든 DNS 질의는 최종적으로 리졸버를 통해 해석되므로, 그 신뢰성과 성능은 전체 인터넷 사용 경험에 직접적인 영향을 미친다.

도메인 등록은 인터넷 상에서 특정 도메인 이름을 소유하고 사용할 수 있는 권리를 얻는 과정이다. 일반적으로 도메인 등록기관을 통해 이루어지며, 등록자는 원하는 도메인 이름의 사용 가능 여부를 확인한 후 일정 기간(보통 1년 단위) 등록 비용을 지불하고 등록한다. 등록 과정에서 등록자는 자신의 연락처 정보와 도메인을 관리할 네임 서버 정보를 제공해야 한다.

도메인 설정의 핵심은 DNS 레코드를 올바르게 구성하는 것이다. 가장 기본적인 설정은 A 레코드나 AAAA 레코드를 통해 도메인 이름을 서버의 IP 주소에 연결하는 것이다. 예를 들어, 웹사이트를 운영하려면 'example.com'을 호스팅 서버의 IP 주소를 가리키는 A 레코드로 설정한다. 이메일 수신을 위해서는 해당 도메인의 메일 교환 서버를 지정하는 MX 레코드 설정이 필수적이다.

다른 서비스나 도메인으로의 리디렉션을 설정할 때는 CNAME 레코드가 자주 사용된다. 이 레코드는 한 도메인 이름을 다른 도메인 이름에 별칭으로 연결한다. 예를 들어, 'www.example.com'을 'example.com'으로 연결하는 데 사용될 수 있다. 또한, 도메인의 소유권을 증명하거나 이메일 보안 정책(SPF, DKIM)을 설정하기 위해 TXT 레코드가 추가되기도 한다.

도메인 설정 변경은 DNS 전파 시간이 소요된다. 이는 전 세계의 DNS 캐시 서버가 변경된 정보를 갱신하는 데 필요한 시간으로, TTL 값에 영향을 받는다. 설정 오류는 웹사이트 접속 불가 또는 이메일 수신 실패로 이어질 수 있으므로, 변경 후에는 온라인 DNS 조회 도구를 이용해 정상적으로 적용되었는지 반드시 확인해야 한다.

DNS 성능 최적화는 웹사이트와 애플리케이션의 응답 속도를 높이고, 사용자 경험을 개선하며, 시스템의 신뢰성을 강화하는 중요한 과정이다. 주요 전략으로는 TTL 값의 적절한 설정, DNS 캐싱의 효율적 활용, 지리적 분산을 통한 로드 밸런싱, 그리고 최신 DNS 프로토콜의 도입이 포함된다.

TTL 값을 설정하는 것은 핵심적인 최적화 요소이다. 짧은 TTL(예: 300초)은 레코드 변경이 빠르게 전파되도록 하지만, 리졸버 서버의 캐시 적중률을 낮추고 원본 서버에 대한 질의 부하를 증가시킨다. 반면, 자주 변경되지 않는 정적 리소스에 대해 긴 TTL(예: 86400초)을 설정하면 캐시 효율이 극대화되어 응답 시간이 단축되고 상위 서버의 부하가 감소한다. 변경이 예정된 경우, 롤링 업데이트를 위해 TTL을 사전에 낮추는 방법도 일반적으로 사용된다.

지리적 위치에 따른 서비스 제공은 CDN과 지리적 DNS를 통해 구현된다. 이 방법은 사용자의 위치를 기반으로 가장 가까운 또는 부하가 적은 서버의 IP 주소를 반환한다. 이는 네트워크 지연 시간을 최소화하고 트래픽을 분산시킨다. 또한, Anycast 라우팅 기술을 DNS 서버 자체에 적용하면, 전 세계에 분산된 동일한 IP 주소의 서버들 중 가장 가까운 서버가 요청을 처리하게 되어 DNS 질의 자체의 성능과 내결함성이 향상된다.

최신 보안 프로토콜의 도입도 간접적으로 성능에 기여한다. DNS over HTTPS나 DNS over TLS는 질의를 암호화하여 중간자 공격을 방지함으로써, 스푸핑으로 인한 리다이렉션 지연이나 보안 사고로 인한 다운타임 가능성을 줄인다. 다만, 암호화 오버헤드와 추가적인 연결 설정 시간은 고려해야 할 요소이다. 성능 모니터링 도구를 이용해 평균 해결 시간, 캐시 적중률, 각 권한 서버의 응답 시간 등을 지속적으로 추적하고 분석하는 것이 최적화의 기초가 된다.

DNS over HTTPS는 기존의 평문 DNS 질의 및 응답을 HTTPS 프로토콜을 통해 암호화하여 전송하는 보안 기술이다. 이는 사용자의 DNS 트래픽을 가로채거나 감청하는 것을 방지하여 개인정보 보호와 보안을 강화하는 것을 목표로 한다. 기존 DNS는 일반적으로 UDP 포트 53을 사용하는 평문 통신이기 때문에, 네트워크 경로 상의 공격자에 의해 질의 내용이 쉽게 노출되거나 조작될 위험이 있었다.

DoH는 표준 HTTPS 포트인 443번 포트를 사용하여 DNS 메시지를 암호화된 HTTP/2 또는 HTTP/3 세션 내에 캡슐화한다. 이를 통해 DNS 트래픽은 일반적인 웹 트래픽과 구분하기 어려워지며, 중간자 공격이나 DNS 스푸핑으로부터 보호받을 수 있다. 클라이언트(예: 웹 브라우저 또는 운영체제)는 특별히 구성된 DoH 리졸버 서버의 URL(예: https://dns.example.com/dns-query)에 JSON 형식 또는 DNS 메시지를 그대로 담은 HTTP 요청을 보내게 된다.

이 기술의 도입은 네트워크 관리 측면에서 논란을 일으키기도 했다. 기업이나 인터넷 서비스 제공자(ISP)가 내부 네트워크의 DNS 트래픽을 모니터링하거나 정책을 적용하기 어려워질 수 있기 때문이다. 또한, DNS over TLS와는 포트와 프로토콜 계층에서 차이를 보인다. 주요 웹 브라우저와 모바일 운영체제는 DoH를 점차 표준 기능으로 채택하고 있으며, Cloudflare나 Google과 같은 공공 DoH 리졸버 서비스를 제공하기도 한다.

DoT(DNS over HTTPS)와 마찬가지로 DNS 쿼리와 응답의 기밀성과 무결성을 보호하기 위해 설계된 프로토콜이다. DoT는 TLS(전송 계층 보안) 암호화 프로토콜을 사용하여 DNS 통신을 보호한다. 기본적으로 853번 포트를 사용하며, 클라이언트(예: 리졸버(재귀 DNS 서버))와 DNS 서버 간에 전용 TLS 터널을 구축하여 모든 DNS 트래픽을 암호화된 채널을 통해 전송한다.

DoT의 주요 동작 방식은 다음과 같다. 먼저 클라이언트는 DNS 서버의 853번 포트에 연결을 시도하고 TLS 핸드셰이크를 수행한다. 성공적으로 암호화된 연결이 수립되면, 모든 DNS 질의와 응답은 이 TLS 터널 내에서 평문이 아닌 암호화된 형태로 교환된다. 이는 네트워크 경로 상의 중간자로부터 도청이나 변조를 방지한다.

DoT와 DoH(DNS over HTTPS)는 암호화를 통한 DNS 보안을 제공한다는 공통점을 가지지만, 몇 가지 차이점이 존재한다. 다음 표는 두 프로토콜의 주요 차이점을 보여준다.

DoT는 네트워크 관리자가 시스템 전체의 DNS 트래픽을 명시적으로 암호화하고 관리하기에 적합한 구조를 제공한다. 그러나 전용 포트를 사용하기 때문에, 일부 제한적인 네트워크 환경에서는 포트 차단으로 인해 사용이 제한될 수 있다는 점이 DoH(DNS over HTTPS)에 비해 가지는 단점으로 지적된다.