1.1.1.2(DNS)

도메인 이름은 사람이 읽고 기억하기 쉬운 형태의 주소이다. 예를 들어, www.example.com과 같은 형태를 가진다. 반면, IP 주소는 컴퓨터나 네트워크 장비가 서로를 식별하고 통신하기 위해 사용하는 숫자로 이루어진 논리적 주소이다. IPv4 주소는 192.0.2.1과 같은 형태이며, IPv6 주소는 2001:0db8:85a3::8a2e:0370:7334와 같은 더 긴 형태를 가진다.

도메인 이름 시스템(DNS)은 이 두 주소 체계를 연결하는 전화번호부와 같은 역할을 한다. 사용자가 웹 브라우저에 도메인 이름을 입력하면, DNS는 해당 이름을 컴퓨터가 이해할 수 있는 IP 주소로 변환(해석)한다. 이 변환 과정 없이는 사용자가 복잡한 숫자 열인 IP 주소를 직접 입력해야 하기 때문에 인터넷 사용이 매우 불편해진다.

도메인 이름은 계층적 구조를 이루며, 점(.)으로 구분된 여러 부분으로 구성된다. 가장 오른쪽에 위치한 부분(TLD)이 가장 상위 계층을 나타낸다. 예를 들어, example.com에서 .com은 상업 기관을 위한 최상위 도메인이며, example은 그 하위의 2차 도메인이다. www.example.com에서 www는 호스트 이름 또는 서브도메인에 해당한다.

이러한 체계는 인터넷의 확장성과 사용 편의성을 보장하는 핵심 기반이 되었다.

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

네임 서버는 크게 두 가지 유형으로 구분된다. 첫째는 권한 있는 네임 서버이다. 이 서버는 특정 도메인 구간(예: example.com)에 대한 공식적인 정보를 소유하고 관리한다. 해당 도메인의 A 레코드, MX 레코드 등 모든 DNS 레코드의 최종 권위를 가지며, 이 정보를 '영역 파일'에 저장한다. 둘째는 재귀 확인자이다. 이는 일반적으로 인터넷 서비스 제공자나 공개 DNS가 운영하며, 최종 사용자(클라이언트)의 요청을 직접 받아들여 필요한 정보를 찾아주는 역할을 한다. 재귀 확인자는 권한 있는 네임 서버를 차례로 질의하며 최종 답변을 수집하여 사용자에게 반환한다.

네임 서버의 계층 구조는 루트 네임 서버에서 시작한다. 전 세계에 13개의 루트 서버 그룹이 존재하며, 이들은 최상위 도메인(TLD) 서버(예: .com, .kr을 관리하는 서버)의 주소를 알고 있다. 재귀 확인자는 질의를 처리할 때, 루트 서버 → TLD 서버 → 실제 도메인의 권한 있는 네임 서버 순으로 질의를 진행하여 정확한 정보에 도달한다. 이 분산 시스템은 단일 장애점을 피하고 효율적인 질의 처리를 가능하게 한다.

DNS 질의는 크게 재귀적 질의와 반복적 질의 두 가지 방식으로 동작한다. 이 두 방식은 DNS 확인자와 네임 서버 간의 상호작용 방법을 정의하며, 효율적인 도메인 이름 변환 과정의 핵심이다.

재귀적 질의는 클라이언트(예: 사용자의 컴퓨터)가 DNS 확인자(주로 인터넷 서비스 제공자나 공개 DNS가 운영)에게 질의를 보낼 때 사용하는 일반적인 방식이다. 이 방식에서 클라이언트는 확인자에게 최종 답변을 요구한다. 확인자는 클라이언트를 대신하여 필요한 모든 질의를 수행하고, 최종적으로 IP 주소나 오류 메시지를 클라이언트에게 반환한다. 클라이언트는 단일 응답만을 기다리면 되므로 부담이 적다. 반면, 확인자는 여러 네임 서버에 질의를 반복해야 할 수 있어 상대적으로 더 많은 작업을 수행한다.

반복적 질의는 DNS 확인자가 루트 네임 서버, TLD 네임 서버, 권한 있는 네임 서버와 통신할 때 사용하는 방식이다. 확인자가 한 네임 서버에 질의를 보내면, 해당 서버는 자신이 알고 있는 최선의 정보(예: 다음에 질의해야 할 네임 서버의 주소)를 즉시 응답한다. 확인자는 이 정보를 바탕으로 다시 다음 서버에게 질의를 보내는 과정을 최종 답변을 얻을 때까지 반복한다. 이 과정을 요약하면 다음과 같다.

실제 DNS 해석 과정은 이 두 방식을 조합하여 사용한다. 클라이언트는 확인자에게 재귀적 질의를 보내고, 확인자는 다른 네임 서버들에게 반복적 질의를 수행하여 답을 찾아낸 후, 그 결과를 클라이언트에게 재귀적으로 응답한다. 이 구조는 DNS 계층 구조의 부하를 분산시키고, 확인자가 DNS 캐싱을 통해 이후 같은 질의에 빠르게 응답할 수 있게 한다.

DNS 캐싱은 DNS 질의 응답을 임시로 저장하여 이후 동일한 질의에 대한 응답 속도를 높이고, 루트 DNS 서버 및 상위 네임 서버의 부하를 줄이는 메커니즘이다. 이 과정은 재귀 확인자와 최종 사용자의 운영 체제 모두에서 발생할 수 있다.

캐싱의 동작은 TTL 값에 의해 관리된다. 네임 서버는 응답에 포함된 각 DNS 레코드에 대한 TTL을 설정하며, 이는 초 단위로 캐시에 유효하게 보관될 시간을 지정한다. 캐시를 보유한 서버나 클라이언트는 TTL이 만료되기 전까지 저장된 정보를 재사용하여 즉시 응답한다. TTL이 만료되면 캐시는 해당 레코드를 삭제하고, 다음 요청 시에는 다시 원격 네임 서버에 질의를 수행한다.

캐싱은 네트워크 효율성을 극대화하지만, 도메인 이름에 대한 IP 주소 변경이 발생했을 때 TTL이 만료될 때까지 오래된 정보가 제공될 수 있다는 단점도 있다. 이를 해결하기 위해 도메인 관리자는 변경 전에 TTL 값을 일시적으로 줄이는 전략을 사용하기도 한다.

DNS 레코드는 도메인 이름을 다양한 목적에 맞게 다른 데이터에 연결하는 지시사항이다. 가장 기본적이고 일반적인 레코드 유형은 A 레코드와 AAAA 레코드, CNAME 레코드이다.

A 레코드는 호스트 이름을 IPv4 주소에 매핑한다. 예를 들어, example.com이라는 도메인의 A 레코드가 93.184.216.34라는 값을 가지면, 사용자가 해당 도메인을 브라우저에 입력했을 때 컴퓨터는 이 IPv4 주소로 연결을 시도한다. AAAA 레코드는 동일한 기능을 하지만, 더 최신의 IPv6 주소 체계를 위해 사용된다. IPv6 주소는 콜론으로 구분된 16진수로 표현된다(예: 2001:0db8:85a3:0000:0000:8a2e:0370:7334). 인터넷이 IPv4 주소 고갈 문제를 겪으면서 IPv6로의 전환이 진행됨에 따라 AAAA 레코드의 중요성이 증가하고 있다.

CNAME 레코드는 한 도메인 이름을 다른 도메인 이름에 대한 별칭으로 만든다. 이는 "정식 이름"을 가리키는 레코드이다. 예를 들어, www.example.com에 대한 CNAME 레코드 값이 example.com이라면, www.example.com에 대한 조회는 실제로 example.com의 IP 주소를 찾기 위한 추가 조회를 트리거한다. 이는 여러 하위 도메인이 동일한 IP 주소를 공유하도록 관리 효율성을 높이는 데 유용하다. 단, CNAME 레코드는 다른 레코드와 동일한 이름으로 공존할 수 없으며, MX 레코드나 NS 레코드와 같은 특정 레코드 유형이 필요한 루트 도메인에는 일반적으로 사용하지 않는 것이 좋다.

다음 표는 세 가지 레코드 유형의 핵심 차이를 보여준다.

MX 레코드(Mail Exchanger Record)는 도메인의 이메일 수신을 담당하는 메일 서버를 지정하는 데 사용된다. 이 레코드는 메일 전송 프로토콜인 SMTP가 발신자의 메일을 어디로 보내야 하는지 결정하는 데 필수적이다. MX 레코드는 우선순위 값을 포함하며, 숫자가 낮을수록 높은 우선순위를 가진다. 주 메일 서버에 장애가 발생하면 다음 우선순위의 서버로 메일 전송이 시도된다. 일반적으로 다음과 같은 형식을 가진다.

TXT 레코드(Text Record)는 도메인에 대한 임의의 텍스트 정보를 제공한다. 초기에는 인간이 읽을 수 있는 메모 용도로 사용되었으나, 현재는 주로 도메인 소유권 확인, 이메일 보안 정책 설정, 스팸 방지 등을 위한 기술적 검증 수단으로 활용된다. 대표적인 사용 사례로는 SPF(Sender Policy Framework), DKIM(DomainKeys Identified Mail), DMARC(Domain-based Message Authentication, Reporting & Conformance)와 같은 이메일 인증 메커니즘을 구성하는 정보를 저장하는 것이다. 예를 들어, SPF 레코드는 해당 도메인에서 메일을 보낼 수 있는 권한이 있는 서버의 IP 주소를 나열한다.

NS 레코드(Name Server Record)는 해당 도메인이나 하위 도메인에 대한 권한 있는 네임 서버(Authoritative Name Server)가 무엇인지를 지정한다. 즉, 특정 도메인 영역에 대한 최종적인 DNS 정보를 가지고 있고 질의에 응답할 수 있는 서버의 호스트명을 가리킨다. 최상위 도메인(TLD)의 네임 서버는 루트 서버에 등록되어 있으며, 각 도메인의 NS 레코드는 그 하위의 도메인 관리 권한을 위임하는 데 사용된다. 예를 들어, example.com 도메인의 NS 레코드가 ns1.registrar.com과 ns2.registrar.com을 가리키면, 이 두 서버가 example.com 영역에 대한 질의에 권한 있는 응답을 제공한다.

DNS 스푸핑은 공격자가 위조된 DNS 응답을 사용자에게 전달하여, 정상적인 도메인 이름을 악의적인 IP 주소로 연결하도록 조작하는 공격 기법이다. 이 공격의 목표는 사용자를 가짜 웹사이트로 유인하여 개인정보나 계정 정보를 탈취하거나, 악성 소프트웨어를 유포하는 것이다. DNS 스푸핑은 DNS 캐싱 메커니즘을 악용하기도 하여, 한 번 공격에 성공하면 다수의 사용자가 장시간 영향을 받을 수 있다.

DNS 시스템이 직면하는 주요 위협은 다음과 같다.

이러한 위협의 근본 원인은 전통적인 DNS 프로토콜이 질의와 응답의 진위를 확인하는 메커니즘을 갖추지 않았기 때문이다. 공격자는 예측 가능한 트랜잭션 ID와 포트 번호를 이용해 위조 응답을 보낼 수 있다. 또한 DNS 쿼리는 일반적으로 암호화되지 않은 UDP 프로토콜을 사용하므로 패킷 스니핑과 변조가 상대적으로 쉽다.

DNS 스푸핑을 방지하기 위한 기본적인 방법은 신뢰할 수 있는 DNS 서버를 사용하고, 네트워크 보안을 강화하는 것이다. 그러나 근본적인 해결책은 DNSSEC과 같은 보안 프로토콜을 도입하여 DNS 응답에 디지털 서명을 추가하고 데이터의 무결성과 인증을 보장하는 것이다.

DNSSEC(DNS Security Extensions)은 DNS 프로토콜에 데이터 무결성과 인증 기능을 추가하여, DNS 스푸핑이나 캐시 포이즈닝과 같은 공격으로부터 사용자를 보호하기 위해 설계된 일련의 확장 사양이다. 표준 DNS는 응답의 진위를 검증할 수 없어, 공격자가 위조된 응답을 주입할 수 있는 취약점이 존재했다. DNSSEC은 공개 키 암호 방식의 디지털 서명을 이용해 DNS 데이터의 출처를 인증하고 변조 여부를 확인할 수 있게 한다.

DNSSEC의 핵심 작동 방식은 DNS 계층 구조의 각 단계에서 디지털 서명을 생성하고 검증하는 것이다. 루트 존부터 시작하여 각 권한 있는 네임 서버는 자신이 관리하는 존 파일에 포함된 DNS 레코드 집합에 대해 서명을 생성한다. 이 서명은 RRSIG(Resource Record Signature) 레코드로 저장된다. 클라이언트(재귀 확인자)는 응답을 받을 때, 해당 도메인 영역의 공개 키를 담은 DNSKEY 레코드를 이용해 RRSIG 서명의 유효성을 검증한다. 공개 키의 신뢰성은 상위 계층의 서명을 통해 연쇄적으로 보장되며, 최종적으로 루트 존의 공개 키에 대한 신뢰가 확립된다.

DNSSEC을 구현하기 위해서는 도메인 등록 기관과 호스팅 제공자가 지원해야 하며, 다음과 같은 몇 가지 새로운 레코드 유형을 사용한다.

DNSSEC은 데이터의 위변조를 방지하지만, 암호화를 제공하지는 않는다. 즉, 질의와 응답 내용을 제3자가 엿들을 수 있는 가능성은 여전히 존재한다. 또한, 키 관리의 복잡성과 추가적인 계산 부하로 인해 완전한 보급에는 시간이 걸리고 있다. 그러나 루트 DNS 서버를 비롯한 많은 최상위 도메인(TLD)이 DNSSEC 서명을 지원하며, 인터넷 인프라의 핵심적인 보안 층으로 자리 잡고 있다.

DNS 시스템은 크게 두 가지 주요 역할을 하는 서버로 구성된다. 바로 권한 있는 네임 서버와 재귀 확인자이다. 이 두 유형의 서버는 질의 처리 방식과 소유하는 정보의 특성에서 근본적인 차이를 보인다.

권한 있는 네임 서버는 특정 도메인에 대한 공식적인 정보를 보유하고 제공하는 서버이다. 이 서버는 해당 도메인 영역(Zone)의 DNS 레코드 원본 데이터를 관리하며, 외부에서 들어오는 질의에 대해 최종적인 답변을 내놓는 책임을 진다. 일반적으로 도메인 등록 시 설정되는 네임 서버가 바로 이 권한 있는 서버이다. 예를 들어, example.com 도메인의 A 레코드나 MX 레코드 정보는 해당 도메인의 권한 있는 네임 서버에 저장된다. 권한 있는 서버는 질의에 대해 자신이 관리하는 영역 내 정보만 답변하며, 알지 못하는 도메인에 대해서는 다른 서버를 추천하거나 오류를 반환한다.

반면, 재귀 확인자(또는 재귀 리졸버)는 사용자(클라이언트)의 요청을 직접 받아 전체 DNS 조회 과정을 수행하는 중개자 역할을 한다. ISP가 제공하는 DNS 서버나 구글 퍼블릭 DNS와 같은 공개 서비스가 대표적인 재귀 확인자이다. 재귀 확인자는 클라이언트로부터 www.example.com의 IP 주소를 묻는 질의를 받으면, 필요한 경우 루트 네임 서버부터 시작하여 순차적으로 .com 네임 서버, 그리고 최종적으로 example.com의 권한 있는 네임 서버에 질의를 진행하여 답을 찾아낸다. 이 과정에서 DNS 캐싱을 통해 자주 접하는 정보를 임시 저장하여 이후 응답 속도를 높인다.

두 서버 유형의 관계와 데이터 흐름을 다음 표를 통해 요약할 수 있다.

이러한 분업 구조는 DNS 시스템의 확장성과 효율성을 보장한다. 재귀 확인자가 대부분의 사용자 질의를 처리함으로써 권한 있는 서버의 부하를 줄이고, 전 세계에 분산된 권한 있는 서버 체계는 도메인 정보의 주권적 관리를 가능하게 한다.

공개 DNS 서비스는 일반 사용자나 조직이 자체적으로 DNS 서버를 운영하지 않고도 이용할 수 있는 재귀 확인자 서비스를 제공한다. 주요 인터넷 서비스 제공업체(ISP)가 할당하는 DNS 서버를 대체하여 사용된다. 이러한 서비스는 전 세계에 분산된 서버 인프라를 통해 빠른 응답 시간, 향상된 개인정보 보호, 추가적인 보안 기능(예: 악성 사이트 차단) 등을 제공하는 경우가 많다.

대표적인 공개 DNS 서비스로는 구글의 8.8.8.8(및 8.8.4.4), 클라우드플레어의 1.1.1.1, 쿼드9 등이 있다. 각 서비스는 다음과 같은 특징을 가진다.

사용자는 컴퓨터나 라우터의 네트워크 설정에서 DNS 서버 주소를 이러한 공개 서비스의 주소로 변경하여 이용한다. 이는 ISP의 기본 DNS 서버보다 더 빠르게 느껴질 수 있으며, 일부 서비스는 DNS 쿼리 로그를 보관하지 않아 사용자의 탐색 기록에 대한 개인정보 보호를 강화한다.

또한, 일부 공개 DNS는 자체적인 필터링 기능을 포함한다. 예를 들어, 악성코드 또는 피싱 사이트로 알려진 도메인에 대한 질의를 차단하여 사용자를 보호한다. 이는 기업이나 가정 네트워크에서 추가적인 보안 계층으로 활용될 수 있다. 그러나 이러한 서비스에 대한 의존도는 해당 제공자의 가용성과 정책에 영향을 받는다는 점을 고려해야 한다.

DNS 서버의 동작을 확인하고 문제를 진단하는 데 널리 사용되는 명령줄 도구로는 nslookup과 dig가 있다. 두 도구 모두 도메인 이름에 대한 DNS 질의를 수행하여 IP 주소, 메일 교환기 정보, 네임 서버 기록 등 다양한 DNS 레코드를 조회할 수 있다. 그러나 사용법과 제공하는 정보의 상세도에서 차이가 있다.

nslookup은 대부분의 운영 체제에 기본적으로 포함된 간단한 도구이다. 대화형 모드와 비대화형 모드로 사용할 수 있으며, 특정 도메인 이름의 A 레코드나 MX 레코드를 빠르게 확인하는 데 유용하다. 예를 들어, nslookup example.com 명령은 해당 도메인의 IP 주소를 조회한다. 특정 DNS 서버를 지정하여 질의하려면 nslookup example.com 8.8.8.8과 같이 사용한다.

반면, dig(Domain Information Groper)은 nslookup보다 더 강력하고 유연한 기능을 제공하며, DNS 문제 해결을 위한 표준 도구로 간주된다. dig는 질의에 대한 상세한 응답을 보여주며, 응답 시간, TTL 값, 권한 있는 서버 정보 등을 포함한 광범위한 메타데이터를 출력한다. 기본 사용법은 dig example.com이며, 특정 레코드 유형을 조회하려면 dig example.com MX와 같이 옵션을 추가한다. dig의 +short 옵션은 nslookup처럼 간결한 결과만 출력하도록 한다.

일반적으로 빠른 확인에는 nslookup을, 정밀한 분석과 문제 해결에는 dig를 사용하는 것이 일반적이다. 두 도구 모두 특정 DNS 서버를 지정하여 로컬 설정과 무관하게 서버 자체의 응답을 테스트할 수 있어, DNS 캐싱으로 인한 오류를 구분하는 데 도움이 된다.

일반적인 DNS 오류는 웹사이트 접속 실패나 네트워크 연결 문제의 주요 원인이다. 대표적인 오류 유형과 그 의미는 다음과 같다.

이러한 오류는 DNS 캐싱에 잘못된 정보가 저장되어 발생하기도 한다. 로컬 캐시를 비우는 것은 기본적인 문제 해결 단계이다. 또한, 클라이언트에 설정된 DNS 서버(예: 재귀 확인자) 자체에 문제가 있거나, 최상위 루트 서버부터 TLD 서버, 권한 있는 서버에 이르는 계층 구조 중 한 단계에서 장애가 발생하면 오류로 이어진다. 네트워크 관리자는 nslookup이나 dig 명령어를 사용해 각 단계별 응답을 확인함으로써 정확한 오류 지점을 파악할 수 있다.