DoT(DNS over TLS) (r1)

DNS는 설계 당시 암호화나 인증 메커니즘을 고려하지 않았기 때문에, 여러 보안 취약점을 내포하고 있다. 기본적으로 UDP 또는 TCP 53번 포트를 사용하는 평문 통신은 네트워크 경로상의 공격자에게 취약하다.

주요 취약점은 다음과 같다.

* 스푸핑(Spoofing): 공격자가 합법적인 DNS 서버를 가장하여 위조된 응답을 클라이언트에 보낼 수 있다.

* 중간자 공격(Man-in-the-Middle): 공격자가 클라이언트와 리졸버 사이의 통신을 가로채어 질의 내용을 엿보거나 변조할 수 있다.

* 재전송 공격(Replay Attack): 이전에 캡처한 합법적인 DNS 응답 패킷을 나중에 재전송하여 클라이언트를 속일 수 있다.

이러한 취약점을 이용한 대표적인 공격으로는 DNS 캐시 포이즈닝이 있다. 공격자는 권한 없는 서버로부터 위조된 DNS 응답을 보내, 리졸버의 캐시에 잘못된 IP 주소 정보를 저장하게 만든다. 이로 인해 사용자는 악성 사이트로 유도될 수 있다. 또한, 평문 DNS 쿼리는 사용자의 방문하는 웹사이트나 서비스의 도메인 이름을 그대로 노출시켜, 프라이버시 침해와 트래픽 분석의 위험을 초래한다.

기존 DNS 쿼리는 일반적으로 평문 UDP 패킷을 통해 전송된다. 이는 네트워크 경로상의 중간자(예: ISP, 공공 와이파이 운영자)가 사용자가 방문하려는 웹사이트의 도메인 이름을 쉽게 감시하고 기록할 수 있음을 의미한다. 이러한 도메인 이름 수집 행위는 심층적인 패킷 분석 없이도 가능하며, 사용자의 인터넷 활동 프로필을 구축하는 데 악용될 수 있다.

수집된 도메인 질의 기록은 단순히 웹사이트 방문 목록을 넘어서 사용자의 관심사, 건강 상태, 정치적 성향, 위치 정보 등 민감한 개인정보를 유추하는 데 사용될 수 있다. 예를 들어, 특정 질병 관련 정보 사이트나 정치 단체의 도메인을 반복적으로 조회하는 패턴은 강력한 개인 식별 정보가 될 수 있다. 이러한 감시는 사용자에 대한 타겟팅 광고, 차별적 가격 정책, 또는 더 극단적인 경우 정부의 감시 활동으로 이어질 수 있다.

DoT는 이러한 프라이버시 문제를 해결하기 위해 DNS 질의와 응답 전체를 TLS 암호화 터널 안에 넣는다. 이를 통해 네트워크 중간자는 패킷의 존재 자체는 인지할 수 있지만, 그 내용이 어떤 도메인에 대한 질의인지 알 수 없게 된다. 암호화는 도메인 이름 자체의 기밀성을 보호하여, 사용자의 탐색 행위가 외부에 노출되는 것을 근본적으로 차단한다.

그러나 DoT는 완벽한 프라이버시 솔루션이 아니다. 암호화된 채널을 통해 통신하는 DoT 서버의 IP 주소는 여전히 외부에 노출된다. 또한, 패킷의 크기와 타이밍 같은 메타데이터를 분석하면 특정 대형 서비스(예: 특정 소셜 미디어 플랫폼)에 연결하려는 의도를 추론할 가능성이 일부 남아 있다[1].

DoT 연결은 표준 TLS 핸드셰이크 절차를 통해 암호화된 채널을 먼저 구축한 후, 그 안에서 평문 DNS 쿼리와 응답을 교환하는 방식으로 작동한다. 클라이언트(예: 스터브 리졸버)는 DoT 서버의 표준 포트 853에 TCP 연결을 시도한다. 연결이 수립되면, 클라이언트는 서버와 TLS 핸드셰이크를 수행하여 암호화 매개변수를 협상하고, 서버의 신원을 인증서를 통해 확인한다.

핸드셰이크 과정에서 사용되는 주요 암호 스위트와 프로토콜 버전은 다음과 같은 표로 요약할 수 있다.

TLS 핸드셰이크가 성공적으로 완료되면, 양측은 공유된 세션 키를 바탕으로 모든 통신을 암호화한다. 이후의 모든 DNS 패킷은 이 암호화 터널을 통해 전송되므로, 네트워크 경로상의 중간자에 의해 쿼리 내용이 엿들리거나 변조되는 것을 방지할 수 있다. 이 채널은 지속적으로 유지되어 여러 DNS 쿼리와 응답에 재사용될 수 있으며, 이는 매번 새로운 핸드셰이크를 수행하는 오버헤드를 줄여준다.

DoT는 TCP 포트 853을 공식적으로 할당받아 사용한다. 이는 기존의 일반 DNS 쿼리가 사용하는 포트 53(UDP/TCP)과 명확히 구분된다. 표준화된 포트를 사용함으로써 네트워크 관리자가 DoT 트래픽을 쉽게 식별하고 정책을 적용할 수 있으며, 프로토콜 자체의 식별과 차단도 상대적으로 간단해진다.

클라이언트가 포트 853으로의 연결에 실패할 경우, 폴백 메커니즘이 중요해진다. 일반적인 폴백 순서는 다음과 같다.

1. 먼저 표준 포트 853을 통해 TLS 연결을 시도한다.

2. 연결이 실패하면(예: 방화벽 차단), 암호화되지 않은 일반 DNS(포트 53)로 폴백하지 않는 것이 보안상 바람직하다. 대신, 사용자에게 오류를 알리거나 사전에 구성된 대체 DoT 서버로 재시도한다.

이러한 폴백 정책은 보안과 사용성 사이의 균형을 이룬다. 네트워크가 DoT를 지원하지 않을 때 자동으로 평문 DNS로 전환되면, 의도하지 않은 도청이나 변조 위험에 노출될 수 있다. 따라서 많은 구현체에서는 명시적인 사용자 동의 없이 평문으로 폴백하는 것을 피한다. 일부 클라이언트는 "스티키(Sticky)" 폴백을 구현하여, 한 번 DoT 연결에 성공한 네트워크에서는 지속적으로 DoT를 사용하려고 시도한다.

DoT 클라이언트는 일반적으로 사용자 기기의 스터브 리졸버에 해당한다. 스터브 리졸버는 애플리케이션이 도메인 이름을 질의할 때 가장 먼저 접촉하는 소프트웨어 구성 요소로, 로컬 호스트나 라우터에 내장되어 있다. 기존에는 이 리졸버가 암호화되지 않은 UDP 53번 포트를 통해 외부 재귀적 리졸버와 통신했지만, DoT를 지원하는 클라이언트는 TLS 암호화 채널을 통해 DoT 서버와 통신하도록 업데이트된다.

DoT 클라이언트의 주요 역할은 애플리케이션으로부터 받은 평문 DNS 쿼리를 가져와, 사전에 구성된 DoT 서버와의 보안 연결을 통해 전송하는 것이다. 이를 위해 클라이언트는 먼저 서버의 표준 포트인 TCP 853번 포트로 연결을 시도한다. 연결이 성공하면, 서버의 디지털 인증서를 검증하는 TLS 핸드셰이크 절차를 수행하여 신뢰할 수 있는 암호화 채널을 구축한다. 이 인증서 검증은 공개 키 인프라를 기반으로 하며, 클라이언트는 서버가声称하는 신원이 진짜인지 확인한다.

구현 방식에 따라 DoT 클라이언트는 다양한 형태를 가질 수 있다.

사용자가 DoT를 사용하려면, 클라이언트 소프트웨어에 신뢰할 수 있는 DoT 서버의 주소(예: dns.google)를 명시적으로 구성해야 하는 경우가 일반적이다. 이 구성이 완료되면, 이후의 모든 DNS 질의는 자동으로 암호화된 채널을 통해 해당 서버로 전송된다.

DoT 서버는 일반적으로 리커시브 리졸버의 기능을 수행하며, 클라이언트로부터 암호화된 DNS 쿼리를 수신하고 최종 응답을 반환하는 역할을 담당한다. 이 서버는 표준 TCP 포트 853을 통해 TLS 연결을 수신 대기하며, 클라이언트와의 보안 채널을 구축한 후 평문 DNS 쿼리와 응답을 주고받는다. 서버는 클라이언트의 요청을 대신하여 루트 DNS 서버부터 시작해 필요한 권한 있는 네임 서버들을 순차적으로 질의하는 재귀적 해석 과정을 수행한다.

서버 구현에는 BIND, Unbound, Knot Resolver와 같은 오픈소스 리졸버 소프트웨어가 널리 사용된다. 이러한 소프트웨어는 DoT 지원을 위한 모듈이나 설정 옵션을 제공하며, 기존의 평문 DNS 서비스(포트 53)와 함께 병행 운영되는 경우가 많다. 서버 운영자는 적절한 TLS 인증서를 구성하고, 필요한 암호화 스위트를 설정하며, 서버의 성능과 확장성을 고려해야 한다.

다음은 주요 오픈소스 DoT 서버 소프트웨어의 예시이다.

서버의 성능과 보안은 인증서 관리에 크게 의존한다. 대부분의 공개 DoT 서비스는 Let's Encrypt와 같은 공인 인증 기관(CA)에서 발급한 인증서를 사용하여 클라이언트의 신뢰를 확보한다. 사내망 등 폐쇄적 환경에서는 사설 인증 기관을 구성할 수도 있다. 서버는 또한 DNS 캐싱을 통해 반복적인 쿼리에 대한 응답 속도를 높이고, 업스트림 서버에 가하는 부하를 줄이는 역할을 한다.

DoT 연결의 보안은 TLS 인증서를 통한 서버 신원 확인에 기반합니다. 클라이언트는 연결을 시도할 DoT 서버의 호스트명을 사전에 알고 있어야 하며, 서버가 제시하는 인증서의 주체 대체 이름(SAN) 필드가 해당 호스트명과 일치하는지 검증합니다.

인증서 검증은 공개 키 기반 구조(PKI)에 의존합니다. DoT 서버는 신뢰할 수 있는 인증 기관(CA)으로부터 서명받은 인증서를 운영합니다. 클라이언트는 내장된 또는 시스템의 신뢰할 수 있는 루트 인증서 저장소를 사용하여 서버 인증서의 서명 체인을 검증합니다. 이 과정을 통해 클라이언트는 중간자 공격(MITM)을 방지하고, 의도한 정당한 서버와 통신하고 있음을 보장받습니다.

일부 구현에서는 인증서 고정(Certificate Pinning)이나 DANE(DNS-Based Authentication of Named Entities)과 같은 추가적인 검증 메커니즘을 사용할 수 있습니다. DANE은 DNSSEC을 통해 서버의 TLS 인증서 해시값을 DNS 레코드(TLSA 레코드)에 게시하여, CA 체인에만 의존하지 않는 대체 인증 경로를 제공합니다.

DoT는 DNS 질의와 응답을 TLS 암호화 터널을 통해 전송함으로써, 네트워크 경로상의 제3자가 통신 내용을 엿보거나 조작하는 것을 방지합니다. 이는 기존의 평문 DNS 프로토콜이 가진 주요 보안 취약점을 해결하는 핵심 메커니즘입니다.

첫째, 중간자 공격을 통한 변조를 효과적으로 차단합니다. 공격자가 사용자의 DNS 질의를 가로채 악성 사이트의 IP 주소로 응답을 변조하는 것은 일반적인 공격 수법입니다. DoT는 TLS 핸드셰이크 과정에서 서버의 신원을 인증서로 확인하고, 이후 모든 통신을 암호화합니다. 따라서 중간에서 패킷을 가로채더라도 내용을 해독하거나 합법적인 응답처럼 위조하는 것이 사실상 불가능해집니다.

둘째, 네트워크 감시 및 탐지로부터의 보호를 제공합니다. DoT는 표준 TCP 포트 853을 사용하며, 암호화된 트래픽은 다른 TLS 연결과 구분하기 어렵습니다. 이는 네트워크 관리자가 특정 도메인에 대한 사용자의 질의를 쉽게 모니터링하거나, DNS 기반의 콘텐츠 필터링을 적용하는 것을 어렵게 만듭니다. 다음 표는 기존 DNS와 DoT의 주요 보안 특성을 비교한 것입니다.

결론적으로, DoT의 탐지 및 변조 방지 기능은 사용자의 온라인 활동에 대한 사생활 보호를 강화하고, 신뢰할 수 없는 네트워크 환경에서도 DNS 조회의 신뢰성을 보장하는 데 기여합니다. 이는 피싱 사이트로의 리다이렉션과 같은 공격을 예방하는 실질적인 보안 이점으로 이어집니다.

DoT는 TCP 포트 853을 전용 포트로 사용하여 DNS 트래픽을 식별하고 전송한다. 이는 IETF의 RFC 7858에서 표준으로 정의되었다. 전용 포트를 사용함으로써 네트워크 관리자는 DoT 트래픽을 쉽게 식별하고, 필요한 경우 정책에 따라 허용하거나 차단할 수 있다.

표준 포트를 통한 프로토콜 사용은 네트워크 운영의 예측 가능성과 간편한 관리성을 제공한다. 기존의 일반 DNS(포트 53) 트래픽과 명확히 구분되므로, 방화벽 규칙 설정이나 트래픽 모니터링, 품질 관리(QoS)를 적용하기가 상대적으로 용이하다. 이는 기업 환경이나 ISP 수준에서 네트워크 정책을 구현할 때 중요한 장점이 된다.

다음은 DoT와 기타 주요 DNS 프로토콜의 전송 특성을 비교한 표이다.

표준화된 접근 방식은 상호운용성을 보장한다. 다른 암호화 DNS 프로토콜과 달리, DoT는 DNS 메시지 형식 자체를 변경하지 않고 기존 DNS 패킷을 TLS 터널 안에 캡슐화한다. 따라서 DoT 서버의 백엔드에서는 표준 DNS 프로토콜을 그대로 사용할 수 있으며, 기존 DNS 인프라와의 통합이 비교적 간단하다.

DoT는 DNS 쿼리와 응답을 암호화하여 내용을 보호하지만, 통신 자체가 발생하는 네트워크 포트는 표준화되어 있다. DoT는 TCP 포트 853을 사용하도록 명시적으로 정의되어 있으며, 이는 네트워크 관리자나 인터넷 서비스 제공자가 해당 포트의 트래픽을 쉽게 식별하고 차단할 수 있음을 의미한다.

이러한 명시성은 네트워크 수준에서의 검열을 용이하게 한다. 방화벽이나 DPI 장비는 포트 853으로 향하는 트래픽을 감지하여 차단 정책을 적용할 수 있다. 결과적으로, 사용자가 DoT를 통해 DNS 조회를 시도하더라도, 네트워크 경로 상에서 연결 자체가 차단될 수 있다. 이는 특히 특정 리졸버 서비스나 암호화된 DNS 프로토콜 자체를 차단하려는 환경에서 두드러지는 한계이다.

표와 같이, DoH는 일반적인 HTTPS 웹 트래픽(포트 443)과 동일한 포트와 프로토콜을 사용하여 혼합되기 때문에 네트워크 수준에서 식별하고 차단하는 것이 상대적으로 어렵다. 반면 DoT의 트래픽은 고유 포트를 사용하기 때문에 차단 대상으로 명확하게 구분된다. 따라서 검열을 우회하는 데는 DoT보다 DoH가 더 효과적인 경우가 많다. 이는 DoT가 보안과 프라이버시를 강화했지만, 네트워크 중립성이나 검열 저항성 측면에서는 명확한 기술적 한계를 가짐을 보여준다.

DoT는 DNS 질의와 응답의 내용 자체를 TLS 터널로 암호화하여 도청과 변조를 방지한다. 그러나 통신의 존재 여부, 통신 시점, 통신량, 그리고 참여하는 IP 주소와 같은 메타데이터는 여전히 네트워크 관찰자에게 노출될 수 있다.

패킷의 크기와 타이밍을 분석하면 특정 웹사이트 방문을 추론할 수 있다. 예를 들어, 한 번의 DNS 질의와 그에 따른 응답은 특정한 크기와 시간적 패턴을 생성한다. 공격자는 이러한 패턴을 미리 수집한 데이터베이스와 비교하여 사용자가 접속하려는 서비스를 식별할 수 있다[6]. 또한, DoT는 표준 TCP 포트 853을 사용하므로, 해당 포트를 통한 암호화된 트래픽이 DNS 통신임을 네트워크 관리자나 제3자가 쉽게 식별할 수 있다.

이러한 메타데이터 노출 문제를 완화하기 위한 방법이 연구되고 있다. 한 가지 접근법은 더미 트래픽을 주입하거나 여러 질의를 묶어 전송하여 실제 통신 패턴을 흐리게 하는 것이다. 또 다른 방법은 DoH와 같이 일반적인 HTTPS 트래픽(포트 443)에 DNS 질의를 혼합하여, 다른 웹 트래픽과 구분하기 어렵게 만드는 것이다. 그러나 이러한 방법들도 대역폭 오버헤드를 증가시키거나 구현 복잡성을 키우는 한계가 있다.

DoT와 DoH는 모두 DNS 쿼리와 응답을 암호화하여 도청과 변조를 방지하는 것을 목표로 하는 프로토콜이다. 그러나 기술적 구현 방식, 네트워크 특성, 그리고 이로 인한 운영상의 차이가 존재한다.

가장 근본적인 차이는 사용하는 전송 계층 프로토콜과 포트에 있다. DoT는 DNS 전용 포트인 853번 포트를 사용하여 별도의 TLS 연결을 통해 DNS 트래픽을 전송한다. 이는 네트워크 관리자가 DNS 트래픽을 쉽게 식별하고, 필요에 따라 필터링하거나 우선순위를 관리할 수 있게 한다. 반면, DoH는 HTTPS의 443번 포트를 사용하여 DNS 메시지를 일반적인 웹 트래픽과 구분되지 않는 HTTP/2 또는 HTTP/3 프레임 내에 캡슐화한다. 이는 DNS 트래픽이 다른 웹 트래픽과 혼합되어 네트워크 수준에서 식별하기 어렵게 만든다.

이러한 구현 차이는 운영 및 정책 측면에서 중요한 영향을 미친다. DoT는 전통적인 DNS와 유사하게 운영체제나 네트워크 장비의 시스템 수준 리졸버를 통해 전체 시스템의 모든 애플리케이션에 적용될 수 있다. DoH는 주로 애플리케이션(예: 웹 브라우저) 자체에 구현되어, 특정 애플리케이션의 DNS 요청만 암호화하는 경우가 많다. 이로 인해 DoH는 사용자 애플리케이션의 설정에 의존하며, 시스템 전체의 DNS 정책을 우회할 가능성이 있다는 논란의 중심에 있다. 네트워크 관리 관점에서 DoT는 식별 가능한 별도 포트를 사용하므로 감시와 정책 적용이 상대적으로 명확한 반면, DoH는 암호화된 일반 웹 트래픽에 섞여 탐지 및 차단이 어렵다.

DoT와 DNSSEC은 모두 DNS 시스템의 보안을 강화하기 위한 기술이지만, 그 접근 방식과 해결하려는 문제는 근본적으로 다릅니다. DoT는 DNS 쿼리와 응답의 전송 과정을 TLS 암호화 터널을 통해 보호하여 도청과 중간자 공격을 방지하는 데 초점을 맞춥니다. 반면, DNSSEC은 데이터의 무결성과 신뢰성을 보장하는 데 주력하며, 응답이 신뢰할 수 있는 출처로부터 왔고 전송 중 변조되지 않았음을 디지털 서명을 통해 검증합니다.

두 프로토콜은 상호 보완적일 수 있습니다. DoT는 통신 채널을 암호화하지만, 서버로부터 받은 응답 데이터 자체가 악의적으로 조작된 것인지는 보장하지 않습니다. DNSSEC은 응답 데이터의 진위를 보증하지만, 쿼리와 응답이 제삼자에게 노출되는 것을 막지 못합니다. 따라서 이론적으로 가장 강력한 보안 구성을 위해서는 DoT로 암호화된 채널을 통해 DNSSEC으로 서명된 응답을 주고받는 것이 이상적입니다.

다음 표는 두 기술의 주요 차이점을 요약합니다.

결론적으로, DoT는 통신 경로의 보안을, DNSSEC은 데이터 자체의 신뢰성을 담당합니다. 현대적인 DNS 보안 아키텍처에서는 두 기술을 함께 도입하여 포괄적인 보호 계층을 구축하는 것이 권장됩니다.

DoT 지원은 점차 다양한 운영체제와 네트워킹 소프트웨어에 통합되고 있습니다. 주요 리눅스 배포판에서는 systemd-resolved가 DoT를 네이티브로 지원하며, 설정 파일을 통해 DoT 서버를 지정할 수 있습니다. 안드로이드 9(파이) 이상에서는 "프라이빗 DNS" 기능을 통해 사용자가 DoT 서버 주소를 입력하여 전체 기기의 DNS 트래픽을 암호화할 수 있습니다. 마이크로소프트 윈도우의 경우, 서버 버전에서는 일부 제한적인 지원이 존재하지만, 클라이언트 버전에서는 아직 네이티브 지원이 포함되어 있지 않아 타사 애플리케이션에 의존해야 합니다.

네트워크 장비 및 미들웨어 측면에서는 BIND와 Unbound와 같은 널리 사용되는 DNS 서버 소프트웨어가 DoT 서버 및 클라이언트 기능을 제공합니다. 또한, 스터브 리졸버 기능을 가진 애플리케이션들, 예를 들어 1.1.1.1 앱이나 NextDNS 클라이언트 등은 사용자 장치에서 로컬에 설치되어 시스템의 DNS 요청을 가로채 지정된 DoT 서버로 전달하는 방식으로 동작합니다.

주요 공개 DoT 서비스와의 호환성을 보장하기 위해, 소프트웨어는 일반적으로 표준 포트 853을 사용하며 인증서 검증을 수행합니다. 지원 현황은 아래 표와 같이 요약할 수 있습니다.

이러한 지원 확대는 DoT가 실용적인 DNS 프라이버시 및 보안 솔루션으로 자리 잡는 데 기여하고 있습니다.

여러 조직과 기업이 일반 사용자를 위한 공개 DoT 리졸버 서비스를 무료로 운영하고 있다. 이러한 서비스는 사용자가 자신의 인터넷 서비스 제공자가 아닌 제3자의 DNS 인프라를 통해 암호화된 이름 해석을 수행할 수 있게 해준다.

주요 공개 DoT 서비스는 다음과 같다.

이러한 서비스를 사용하려면 사용자의 장치(예: 스마트폰, 라우터, 컴퓨터)의 네트워크 설정에서 기존의 일반 DNS 서버 주소 대신 위의 서버 주소를 DoT 전용 포트(853)와 함께 지정해야 한다. 많은 서비스 제공자는 설정 가이드와 클라이언트 소프트웨어를 제공하여 적용을 용이하게 한다.

공개 DoT 리졸버의 사용은 ISP의 기본 DNS 감시나 로깅을 우회할 수 있는 프라이버시 이점을 제공하지만, 모든 DNS 쿼리가 해당 제3자 서비스 제공자에게 집중된다는 점을 고려해야 한다. 이는 새로운 형태의 중앙화와 데이터 집약을 초래할 수 있다. 또한, 지리적 위치와 거리에 따른 응답 지연이 발생할 수 있으며, 특정 국가에서는 이러한 공개 서비스의 포트나 주소 자체가 차단될 수도 있다.

DoT(DNS over TLS)의 표준화는 주로 두 개의 핵심 RFC 문서를 통해 이루어졌다. 이 문서들은 프로토콜의 초기 정의와 이후의 사용 권고 및 명세를 제공한다.

2016년 5월에 공개된 RFC 7858은 "DNS over Transport Layer Security (TLS)"를 제목으로 하며, DoT 프로토콜의 초기 표준을 정의한 문서이다. 이 RFC는 DNS 쿼리와 응답을 TLS 암호화 채널을 통해 전송하는 기본 방법을 규정한다. 주요 내용으로는 표준 포트 853의 사용, TLS 핸드셰이크를 통한 보안 채널 수립 절차, 그리고 기존의 DNS 메시지 포맷을 암호화된 연결 위에서 전송하는 방식을 다룬다. 이 표준은 DNS 트래픽의 기밀성과 무결성을 보호하는 것을 목표로 한다.

2018년 3월에 발표된 RFC 8310은 "Usage Profiles for DNS over TLS and DNS over DTLS"를 제목으로 하며, RFC 7858을 보완하는 문서이다. 이 문서는 DoT의 실제 배포와 사용을 촉진하기 위한 구체적인 권고 사항과 프로파일을 제시한다. 특히, 초기 연결 지연을 최소화하기 위한 사전 연결(0-RTT) 모드의 사용, 다양한 포트 번호 사용에 대한 지침, 그리고 네트워크 운영자가 DoT 서비스를 제공할 때 따라야 할 모범 사례를 포함한다. 이는 프로토콜의 채택과 상호운용성을 높이는 데 기여했다.

이 두 표준은 IETF를 통해 개발되었으며, 이후 DoT의 광범위한 구현과 DoH(DNS over HTTPS) 같은 다른 암호화 DNS 프로토콜의 표준화에 영향을 미쳤다.