DNS가 작동하는 방식

브라우저에 도메인 이름을 입력해도, 컴퓨터는 그 이름을 직접 사용해 인터넷을 통해 데이터를 보낼 수 없습니다. 라우터는 단어를 이해하지 못하며, 숫자 IP 주소를 기준으로 패킷을 전달합니다.

예를 들어 google.com을 입력하면 결국 142.250.190.14 같은 주소로 해석되어야 합니다. 그 IP 주소는 전 세계 네트워크에서 목적지 서버를 식별합니다.

변환 시스템이 없다면, 모든 사용자는 자신이 사용하는 모든 서비스의 IP 주소를 외워야 합니다. 이는 인터넷 규모에서는 분명히 현실적이지 않습니다.

도메인 이름 시스템(DNS)은 인터넷의 분산 전화번호부처럼 동작합니다. 사람이 읽을 수 있는 이름을 기계가 읽을 수 있는 IP 주소로 매핑하여 실제 통신이 시작될 수 있게 합니다.

브라우저에 URL을 입력하면, 시스템은 즉시 HTTP 요청을 보낼 수 없습니다. 먼저 그 요청을 어디로 보낼지 알아야 합니다.

DNS 해석은 가장 첫 번째 네트워크 단계입니다. 브라우저는 “이 도메인 이름에 해당하는 IP 주소는 무엇인가?”라고 묻습니다. IP 주소를 받은 뒤에야 시스템은 대상 서버와 TCP 핸드셰이크를 시작할 수 있습니다.

순서는 엄격합니다:
DNS 조회 → TCP 연결 → HTTP 요청 → 서버 응답

DNS가 실패하면 전체 과정은 즉시 중단됩니다. 연결 시도도 없고, 암호화 협상도 없으며, 애플리케이션 계층 통신도 없습니다. DNS는 요청 라이프사이클의 나머지 모든 과정을 가능하게 하는 관문입니다.

도메인 이름을 요청하면 브라우저는 즉시 전 세계 DNS 인프라에 접속하지 않습니다. 먼저 로컬 소스를 확인합니다:

1. 브라우저 캐시
2. 운영 체제 캐시
3. 라우터 캐시

캐시된 결과가 없으면 요청은 보통 ISP가 운영하거나 8.8.8.8 같은 공용 제공업체가 운영하는 재귀적 DNS 리졸버로 전송됩니다.

그다음 resolver는 계층적 조회를 수행합니다:

• 루트 서버에 묻습니다: ".com은 어디에서 찾을 수 있나요?"
• 루트는 적절한 TLD (최상위 도메인) 서버의 주소를 응답합니다.
• resolver는 TLD 서버에 묻습니다: "example.com은 어디에 있나요?"
• TLD는 해당 도메인의 권한 있는 네임 서버를 응답합니다.
• resolver는 권한 있는 서버에 실제 IP 주소를 요청합니다.

권한 있는 서버가 IP를 반환하면, resolver는 이를 클라이언트에 다시 보내고 향후 사용을 위해 캐시에 저장합니다.

이 전체 과정은 보통 밀리초 단위로 끝나지만, 구조적으로는 하나의 도메인 이름을 해석하기 위해 여러 개의 전 세계 분산 서버가 함께 동작하는 과정입니다.

모든 도메인 조회마다 루트 서버, TLD 서버, 권한 있는 서버에 매번 연락해야 한다면, DNS는 금방 전 세계적인 병목 지점이 될 것입니다.

이를 방지하기 위해 DNS 응답은 브라우저, 운영 체제, 라우터, 재귀 리졸버 등 여러 지점에서 캐시됩니다. 도메인이 한 번 해석되면 결과가 일시적으로 저장되어 이후 요청은 전체 재귀 과정을 건너뛸 수 있습니다.

각 DNS 레코드에는 초 단위로 측정되는 TTL (Time To Live) 값이 포함됩니다. TTL은 리졸버가 권한 있는 소스에서 새로 갱신하기 전까지 해당 레코드를 얼마나 오래 보관할 수 있는지 알려줍니다.

짧은 TTL 값은 도메인 소유자가 IP 주소를 더 빠르게 변경할 수 있게 해주고, 긴 TTL 값은 성능을 향상시키고 DNS 트래픽을 줄여줍니다. TTL은 유연성과 효율성 사이의 균형입니다.

캐싱은 DNS 해석이 보통 즉시 끝나는 것처럼 느껴지는 이유입니다. 실제로는 기반 시스템이 전 세계에 분산되어 있음에도 말입니다.

DNS는 이름을 하나의 IP로만 변환하는 것 이상의 일을 합니다. 다양한 서비스가 어떻게 동작해야 하는지 정의하는 구조화된 레코드를 저장합니다.

A 레코드는 도메인 이름을 IPv4 주소에 매핑합니다(예: example.com → 93.184.216.34).
AAAA 레코드는 같은 역할을 하지만 IPv6 주소에 대해 동작합니다.

CNAME(Canonical Name) 레코드는 별칭을 만듭니다. IP 주소를 직접 가리키는 대신, 한 도메인 이름을 다른 도메인 이름으로 가리킵니다. 이는 서비스가 외부 플랫폼에서 호스팅될 때 흔히 사용됩니다.

MX(Mail Exchange) 레코드는 도메인의 이메일을 처리할 책임이 있는 메일 서버를 지정합니다. 백업 메일 서버를 지원하기 위해 우선순위 값도 포함합니다.

이 핵심 레코드 유형을 이해하면 웹사이트가 어떻게 해석되는지, 별칭이 어떻게 동작하는지, 그리고 DNS를 통해 이메일 라우팅이 어떻게 제어되는지 알 수 있습니다.

단일 웹사이트가 하나의 서버에만 호스팅되는 경우는 드뭅니다. 트래픽이 많은 서비스는 성능과 안정성을 위해 여러 지역에 걸쳐 여러 서버를 운영합니다.

DNS는 하나의 도메인을 여러 A 또는 AAAA 레코드와 연결함으로써 기본적인 부하 분산을 가능하게 합니다. 리졸버가 해당 도메인을 조회하면, 번갈아 가며 다른 IP 주소를 받을 수 있습니다. 이를 라운드 로빈 DNS라고 합니다.

더 고급 구성에서는 지리 기반 DNS를 사용하며, 리졸버가 사용자의 대략적인 위치에 따라 IP 주소를 반환합니다. 예를 들어 유럽의 사용자는 북미의 데이터 센터가 아니라 유럽의 데이터 센터로 연결될 수 있습니다.

DNS 기반 로드 밸런싱은 애플리케이션 계층 로드 밸런서에 비해 비교적 단순하지만, 전 세계적으로 확장 가능하며 연결이 성립되기 전 단계에서 동작합니다.

따라서 DNS는 단순한 이름 변환 이상의 역할을 합니다. 인터넷 규모에서 성능, 가용성, 트래픽 분산에 영향을 줄 수 있습니다.

DNS는 인터넷 요청 수명 주기의 진입점입니다. 여기서 실패하면 이후 단계도 모두 자동으로 실패합니다.

일반적인 실패 시나리오는 다음과 같습니다:

• recursive resolver를 사용할 수 없거나 잘못 설정되어 있습니다.
• authoritative name server가 다운되었습니다.
• DNS 레코드가 최근 변경되었지만 아직 완전히 전파되지 않았습니다.
• TTL이 만료되었고, 새 조회로도 유효한 응답을 가져올 수 없습니다.
• 도메인 자체가 잘못 설정되었거나 더 이상 존재하지 않습니다.

사용자 관점에서 DNS 실패는 보통 “DNS_PROBE_FINISHED_NXDOMAIN” 또는 “Server not found.” 같은 메시지로 나타납니다. 이러한 오류는 TCP handshake나 TLS negotiation이 시작되기 전에 발생합니다.

DNS는 연결이 성립되기 전에 동작하므로, DNS가 실패하면 모든 애플리케이션 계층 통신이 차단됩니다. 시스템은 찾을 수 없는 대상에 연결할 수 없습니다.