DNS편집자 확인

DNS 질의는 크게 재귀적 질의와 반복적 질의 두 가지 방식으로 구분된다. 이 두 방식은 DNS 클라이언트와 DNS 서버 간의 상호작용 방식에 차이가 있다.

재귀적 질의에서 클라이언트는 자신이 연결한 DNS 리졸버에게 완전한 답변을 요청한다. 리졸버는 클라이언트를 대신하여 필요한 모든 질의를 수행하고, 최종 IP 주소를 찾아내어 클라이언트에게 단일 응답으로 돌려준다. 이 과정에서 리졸버는 필요한 경우 루트 서버, TLD 서버, 권한 있는 네임서버에 차례로 질의를 진행한다. 일반적인 최종 사용자(예: 웹 브라우저)는 재귀적 질의를 사용한다.

반면, 반복적 질의에서는 서버가 자신이 알고 있는 최선의 정보를 제공하며, 추가 정보가 필요하면 다른 서버의 주소를 안내한다. 클라이언트(또는 리졸버)는 이 안내를 받아 직접 다음 서버에게 질의를 반복한다. 예를 들어, 로컬 DNS 캐시 서버가 루트 서버에 example.com의 주소를 물으면, 루트 서버는 .com TLD 서버의 주소만 알려준다. 그러면 로컬 서버는 .com TLD 서버에게 다시 질의하고, TLD 서버는 example.com을 관리하는 권한 있는 네임서버의 주소를 알려준다. 최종 답변은 권한 있는 네임서버로부터 얻는다.

실제 DNS 조회 과정은 이 두 방식을 혼합하여 사용한다. 최종 사용자의 클라이언트는 재귀 리졸버에게 재귀적 질의를 보내고, 재귀 리졸버는 루트 서버, TLD 서버, 권한 있는 서버에게 반복적 질의를 수행하며 답변을 찾아간다. 이 구조는 서버 부하를 분산시키고 효율적인 질의 처리를 가능하게 한다.

DNS 캐싱은 DNS 질의 응답을 임시로 저장하여, 동일한 질의에 대한 응답 속도를 높이고 상위 DNS 서버의 부하를 줄이는 핵심적인 성능 최적화 기법이다. DNS 클라이언트(스텁 리졸버)와 재귀 리졸버 서버 모두 캐싱을 수행한다.

캐싱의 작동 과정은 다음과 같다. 사용자가 처음으로 example.com을 방문하면, 재귀 리졸버는 필요한 루트 DNS 서버, TLD 서버, 권한 있는 네임서버를 차례로 질의하여 최종 IP 주소를 얻는다. 이 과정에서 얻은 모든 응답(예: .com TLD 서버의 주소, example.com의 권한 있는 서버 주소, 최종 A 레코드 값)은 재귀 리졸버의 캐시에 저장된다. 이후 다른 사용자가 동일한 도메인을 질의하면, 리졸버는 권한 있는 서버에 다시 질의하지 않고 캐시에 저장된 정보를 즉시 반환한다. 이는 응답 시간을 크게 단축시킨다.

캐시에 저장된 정보는 영구적이지 않으며, 각 리소스 레코드에 함께 전달되는 TTL 값에 의해 관리된다. TTL은 초 단위로 지정되며, 해당 시간이 지나면 캐시 항목은 만료되어 삭제된다. 이후 동일한 질의가 들어오면 리졸버는 다시 권한 있는 서버로부터 최신 정보를 조회한다. TTL 설정은 도메인 관리자의 정책에 따라 다르며, 빠른 변경이 필요한 경우 짧게(예: 300초), 안정적인 서비스는 길게(예: 86400초) 설정하는 것이 일반적이다.

캐싱은 네트워크 효율성을 극대화하지만, 도메인 정보가 변경되었을 때 TTL이 만료되기 전까지는 오래된 정보가 제공될 수 있다는 단점도 있다. 이를 'DNS 전파 지연'이라고 부른다. 또한, 악의적인 공격자가 조작된 데이터를 캐시에 주입하는 DNS 캐시 포이즈닝 공격의 표적이 되기도 한다.

DNS 시스템은 계층적 구조로 이루어져 있으며, 각 계층을 담당하는 특정 유형의 서버가 협력하여 질의를 처리한다. 주요 서버 유형으로는 루트 DNS 서버, 최상위 도메인 서버, 권한 있는 네임 서버가 있다. 이들은 질의가 최종 IP 주소를 찾아가는 과정에서 순차적으로 참여한다.

가장 상위 계층에 위치하는 루트 DNS 서버는 전 세계에 13개의 루트 서버 그룹(A부터 M)으로 분산 운영된다[2]] 기술로 분산 배치됨]. 이 서버들은 도메인 이름 질의에서 가장 먼저 접근하며, 해당 도메인의 최상위 도메인(TLD)을 관리하는 서버의 주소를 안내하는 역할을 한다. 예를 들어, "example.com"에 대한 질의가 들어오면, 루트 서버는 ".com" 도메인을 관리하는 TLD 서버의 주소를 응답한다.

TLD 서버는 ".com", ".org", ".net"과 같은 일반 최상위 도메인(gTLD)이나 ".kr", ".jp"와 같은 국가 코드 최상위 도메인(ccTLD)을 관리한다. 루트 서버로부터 안내받은 리졸버는 이 TLD 서버에 다시 질의를 보낸다. TLD 서버는 해당 도메인의 실제 네임 서버 정보, 즉 권한 있는 네임 서버의 주소를 저장하고 있으며, 이를 질의자에게 응답한다.

최종 단계인 권한 있는 네임 서버는 특정 도메인(예: example.com)과 그 하위 도메인에 대한 완전한 정보를 가지고 있는 서버이다. 도메인 등록기관을 통해 도메인을 등록할 때 설정하며, 실제 IP 주소, 메일 서버 정보 등을 담은 리소스 레코드를 직접 관리하고 최종 응답한다. 이 서버의 응답을 받으면 리졸버는 사용자에게 최종 IP 주소를 전달하여 연결을 완성한다.

리소스 레코드는 DNS 존 파일에 저장되는 데이터 단위로, 도메인 이름과 관련된 특정 유형의 정보를 정의합니다. 각 레코드는 도메인 이름을 IP 주소나 메일 서버 정보 등 다른 형태의 데이터로 매핑하는 역할을 합니다. 모든 리소스 레코드는 공통된 구조를 가지며, TTL, 클래스, 유형, 그리고 레코드 데이터로 구성됩니다.

주요 리소스 레코드 유형은 다음과 같습니다.

이 외에도 SRV 레코드(특정 서비스의 위치 지정), CAA 레코드(인증기관 권한 부여) 등 다양한 특수 목적의 레코드가 존재합니다. 시스템 관리자는 이러한 레코드들을 조합하여 네트워크 서비스를 구성하고, 도메인 이름 체계를 효율적으로 운영합니다.

DoH와 DoT는 기존의 평문 UDP 또는 TCP를 통해 전송되던 DNS 질의와 응답을 암호화하여 사용자의 프라이버시와 보안을 강화하는 기술이다. 두 기술 모두 중간자 공격이나 감청으로부터 DNS 트래픽을 보호하는 것이 목표이지만, 구현 방식과 사용하는 네트워크 포트에서 차이를 보인다.

DNS over TLS는 TLS 암호화 프로토콜을 사용하여 DNS 통신을 보호한다. 기존 DNS 포트(53번) 대신 전용 포트(853번)를 사용하여 암호화된 연결을 수립한다. 이 방식은 네트워크 관리자가 표준 포트를 모니터링하거나 필터링하는 것과 유사하게, DoT 트래픽을 식별하고 관리할 수 있게 한다. 일부 환경에서는 이 특정 포트의 트래픽을 차단함으로써 DoT 사용을 제어할 수도 있다.

반면, DNS over HTTPS는 HTTPS 프로토콜 위에서 DNS 질의와 응답을 전송한다. 모든 통신이 일반적인 웹 트래픽과 동일한 443번 포트를 통해 이루어지므로, 네트워크 수준에서 DNS 트래픽과 다른 웹 트래픽을 구분하기 어렵다. 이는 사용자 프라이버시를 더욱 강력하게 보호하지만, 기업이나 교육 기관과 같은 곳에서 네트워크 정책에 따라 DNS 필터링을 적용하기 어렵게 만들 수 있다. 주요 웹 브라우저들은 사용자 DNS 설정을 무시하고 자체적으로 DoH 리졸버로 트래픽을 전송할 수 있어 논란의 원인이 되기도 했다.

두 프로토콜의 비교는 다음과 같다.

DoT는 네트워크 운영의 투명성과 관리 용이성을, DoH는 최대한의 트래픽 혼합을 통한 프라이버시를 각각의 장점으로 삼는다. 두 기술 모두 DNSSEC이 제공하는 데이터 무결성 검증과는 별개로, 전송 구간의 기밀성을 해결한다는 공통점을 가진다.

EDNS(Extension Mechanisms for DNS)는 기존 DNS 프로토콜의 제한을 극복하기 위해 설계된 확장 메커니즘이다. 1999년 IETF에 의해 RFC 2671로 처음 표준화되었으며, 이후 개정을 거쳐 현재는 RFC 6891이 최신 표준이다. 기본 DNS 프로토콜은 1980년대 설계 당시의 네트워크 환경을 반영하여, UDP 패킷의 최대 크기를 512바이트로 제한하고 확장성을 고려하지 않았다. EDNS는 이러한 한계를 해결하기 위해 DNS 메시지 헤더의 확장 영역을 정의하고, 새로운 플래그와 옵션 코드를 도입하여 프로토콜의 기능을 유연하게 확장할 수 있는 기반을 제공한다.

EDNS의 가장 중요한 기능은 UDP를 통한 응답 메시지의 최대 크리를 협상할 수 있게 하는 것이다. 이를 위해 EDNS0 버전에서는 'OPT'라는 가상의 리소스 레코드를 도입한다. 질의자가 OPT 레코드를 포함해 질의하면, 이는 지원하는 최대 UDP 응답 패킷 크기(EDNS 버퍼 크기)를 서버에 알리는 역할을 한다. 이를 통해 512바이트를 초과하는 대용량 응답(예: DNSSEC 서명이 포함된 응답)을 UDP로 전송할 수 있게 되어, 불필요한 TCP 폴백을 줄이고 성능을 향상시킨다.

EDNS는 다양한 확장 옵션을 정의하는 플랫폼 역할도 한다. 대표적인 옵션은 다음과 같다.

이 외에도 DNSSEC를 지원하기 위한 필수 메커니즘이며, 향후 새로운 요구사항에 따라 추가 옵션을 정의할 수 있는 유연한 구조를 가진다. 현대 DNS 인프라에서는 EDNS 지원이 사실상 표준으로 자리 잡아, 보안, 성능, 기능적 측면에서 필수적인 프로토콜 확장이 되었다.

도메인 이름 등록은 특정 도메인을 사용할 권리를 일정 기간 동안 획득하는 과정이다. 등록자는 ICANN이 인증한 도메인 등록 대행자를 통해 원하는 도메인 이름을 선택하고 등록 비용을 지불하여 등록 절차를 완료한다. 등록된 정보는 해당 최상위 도메인의 도메인 등록 기관이 관리하는 데이터베이스에 저장된다.

도메인 위임은 DNS 계층 구조에서 특정 도메인의 관리 책임을 하위 네임서버에게 넘기는 것을 의미한다. 예를 들어, example.com 도메인의 소유자가 자신의 도메인에 대한 권한 있는 네임서버를 지정하면, .com TLD 서버는 해당 도메인에 대한 질의를 더 이상 직접 처리하지 않고 지정된 권한 있는 네임서버로 질의를 전달한다. 이 위임은 TLD 서버가 관리하는 존 파일에 NS 레코드를 등록함으로써 이루어진다.

위임 과정은 다음과 같은 단계로 이루어진다.

1. 도메인 등록자가 자신의 도메인을 관리할 권한 있는 네임서버(예: ns1.myprovider.com, ns2.myprovider.com)를 설정한다.

2. 등록 대행자를 통해 이 네임서버 정보가 TLD의 등록 기관에 전달되고, TLD 존 파일에 NS 레코드로 등록된다.

3. 이후 www.example.com과 같은 하위 호스트 이름에 대한 리소스 레코드(예: A 레코드, MX 레코드)는 전적으로 도메인 소유자가 지정한 권한 있는 네임서버에서 관리하게 된다.

도메인 등록과 위임은 별개의 개념이지만 밀접하게 연관되어 있다. 등록은 도메인 이름 사용 권리를 확보하는 행위라면, 위임은 그 도메인 이름을 실제로 인터넷상에서 작동하도록 DNS 시스템에 연결하는 기술적 절차이다. 등록 정보가 변경되거나 위임된 네임서버 정보가 올바르지 않으면, 해당 도메인에 대한 접속이 불가능해지는 장애가 발생할 수 있다[5].

DNS 서버를 운영하기 위해서는 BIND, PowerDNS, Unbound, dnsmasq 등과 같은 DNS 서버 소프트웨어를 선택하고 적절히 설정해야 한다. 이들 소프트웨어는 권한 있는 네임 서버 또는 재귀 확인자 역할을 수행하도록 구성할 수 있으며, 각각의 설정 파일을 통해 동작 방식을 정의한다. 일반적으로 설정 파일은 존(zone) 정보를 정의하는 존 파일(zone file)과 서버의 전반적인 동작을 제어하는 주 구성 파일(main configuration file)로 나뉜다.

가장 널리 사용되는 BIND (Berkeley Internet Name Domain)의 경우, 주 구성 파일인 named.conf에서 리스닝할 IP 주소와 포트, 재귀 질의 허용 여부, 로깅 옵션, 그리고 참조할 각 존 파일의 경로를 지정한다. 존 파일은 해당 도메인에 대한 리소스 레코드 (예: A 레코드, MX 레코드, CNAME 레코드)를 포함하는 텍스트 파일이다. 반면, PowerDNS는 다양한 백엔드(예: 관계형 데이터베이스, 파일 시스템)를 지원하여 유연한 데이터 저장 방식을 제공하는 것이 특징이다. Unbound는 주로 캐싱 전용 재귀 확인자로서 보안과 성능에 중점을 두고 설계되었다.

설정 시 고려해야 할 주요 사항은 다음과 같다.

서버 설정 후에는 named-checkconf와 named-checkzone (BIND 기준) 같은 도구를 사용하여 구성 파일과 존 파일의 문법 오류를 검증하는 것이 필수적이다. 또한, dig나 nslookup 명령어를 활용해 서버가 정상적으로 응답하는지, 리소스 레코드가 올바르게 조회되는지 반드시 테스트해야 한다. 최종적으로는 보안을 위해 불필요한 서비스는 비활성화하고, 정기적으로 소프트웨어를 최신 상태로 유지하여 알려진 취약점으로부터 시스템을 보호해야 한다.