도메인 이름은 어떻게 서버 주소를 찾을까? DNS 질의와 캐시

브라우저에 example.com을 입력해도 TCP는 도메인 이름으로 연결하지 않는다. 먼저 이름에 대응하는 IP 주소를 찾아야 한다. 이 일을 맡는 DNS(Domain Name System: 사람이 쓰는 도메인 이름을 IP 주소와 여러 네트워크 정보로 연결하는 분산 이름 시스템)는 전 세계의 한 서버가 모든 답을 보관하지 않고 영역을 나누어 관리한다.

DNS 흐름을 이해하면 서버 주소를 바꿨는데 일부 사용자만 이전 서버로 가는 이유, DNS 장애가 애플리케이션 연결 실패로 보이는 이유, TTL을 낮추는 것만으로 즉시 전환되지 않는 이유를 설명할 수 있다.

애플리케이션은 보통 재귀 리졸버에 질문한다

운영체제나 애플리케이션의 리졸버(resolver: 도메인 이름에 해당하는 DNS 레코드를 찾아 달라고 요청하는 구성 요소)는 보통 직접 전 세계 DNS 서버를 순회하지 않는다. 네트워크 사업자나 조직, 공개 DNS 서비스가 운영하는 재귀 리졸버(recursive resolver: 최종 답을 찾을 때까지 다른 DNS 서버에 대신 질의하고 결과를 캐시하는 서버)에 요청한다.

브라우저
  → 운영체제 리졸버
    → 재귀 리졸버
      → 필요한 DNS 서버들을 따라가 답을 찾음
    ← IP 주소와 TTL
  ← 연결할 주소

브라우저, 운영체제, 재귀 리졸버가 각각 캐시를 가질 수 있다. 같은 도메인이라도 어느 캐시에서 답을 얻었는지에 따라 새 설정이 보이는 시점이 달라진다.

루트에서 권한 서버까지 위임을 따라간다

재귀 리졸버에 답이 없다고 하자. 루트 DNS 서버(root DNS server: 최상위 도메인을 담당하는 서버 위치를 안내하는 시작점)는 example.com의 IP를 직접 주기보다 .com을 맡는 서버를 알려 준다.

TLD 서버(Top-Level Domain server: .com, .kr 같은 최상위 도메인의 위임 정보를 관리하는 서버)는 다시 example.com의 권한 서버를 알려 준다. 권한 DNS 서버(authoritative DNS server: 특정 도메인의 최종 DNS 레코드를 관리하고 답하는 서버)가 실제 주소 레코드를 돌려준다.

재귀 리졸버 → 루트: example.com은 어디에?
루트 → .com 서버를 물어봐

재귀 리졸버 → .com 서버
.com → example.com 권한 서버를 물어봐

재귀 리졸버 → 권한 서버
권한 서버 → A 레코드 203.0.113.10, TTL 300초

이 위임 구조 덕분에 각 조직이 자기 도메인의 레코드를 관리하면서도 하나의 이름 공간처럼 동작한다.

레코드 종류마다 답의 의미가 다르다

A 레코드(A record: 도메인 이름을 IPv4 주소에 연결하는 DNS 레코드)와 AAAA 레코드(AAAA record: 도메인 이름을 IPv6 주소에 연결하는 DNS 레코드)는 연결할 주소를 준다.

CNAME 레코드(Canonical Name record: 한 이름이 다른 도메인 이름을 별칭으로 가리키게 하는 레코드)는 다시 대상 이름을 해석하게 한다. MX 레코드(Mail Exchange record: 해당 도메인의 이메일을 받을 서버를 지정하는 레코드)는 웹 접속 주소가 아니라 메일 전달 경로를 정한다.

레코드를 모두 “도메인의 IP”라고 부르면 별칭, 메일, 검증용 TXT 레코드의 역할을 구분하기 어렵다. 질의한 레코드 종류와 반환된 의미를 함께 봐야 한다.

TTL은 캐시를 믿을 수 있는 기본 시간을 말한다

TTL(Time To Live: DNS 응답을 새로 묻지 않고 캐시에 보관할 수 있는 시간)은 권한 서버가 응답에 함께 넣는다. 재귀 리졸버는 TTL이 남아 있는 동안 같은 질문에 캐시된 답을 줄 수 있다.

12:00 기존 주소 조회, TTL 300초
12:02 권한 서버에서 새 주소로 변경
12:04 기존 캐시 사용 가능
12:05 이후 다시 질의하면 새 주소를 받을 수 있음

TTL을 낮추면 전환 창을 줄이는 데 도움이 되지만 이미 긴 TTL로 받아 간 캐시의 남은 시간은 없애지 못한다. 변경 전에 미리 TTL을 낮추고 기존 TTL이 지나기를 기다리는 이유다.

일부 애플리케이션이나 중간 장비는 자체 정책으로 더 짧거나 길게 캐시할 수도 있다. TTL은 모든 클라이언트가 정확히 같은 순간에 갱신한다는 명령이 아니다.

실패 응답도 잠시 캐시될 수 있다

존재하지 않는 이름에 대한 NXDOMAIN(Non-Existent Domain: 질의한 도메인 이름이 존재하지 않는다는 DNS 응답)도 음수 캐시(negative caching: 실패 응답을 일정 시간 저장해 반복 질의를 줄이는 방식)의 대상이 될 수 있다.

새 도메인을 만든 직후 일부 환경에서 계속 없다고 나오는 상황은 이전 NXDOMAIN이 남았기 때문일 수 있다. 성공 응답의 TTL만 보고 전환 시간을 예상하면 놓치는 부분이다.

타임아웃과 NXDOMAIN도 구분해야 한다. 타임아웃은 답을 받지 못한 통신 실패이고 NXDOMAIN은 권한 있는 경로에서 이름이 없다는 답을 받은 상태다. 재시도와 오류 메시지도 달라야 한다.

여러 주소가 와도 실제 연결 성공은 따로 확인한다

하나의 이름에 여러 IP 주소가 등록될 수 있다. DNS 응답을 받았다는 사실은 그 주소의 서버가 살아 있고 요청을 처리한다는 보장이 아니다.

DNS 성공 → 주소 목록 획득
TCP 연결 → 각 주소의 포트에 실제 연결 시도
TLS/HTTP → 서버 확인과 요청 처리

DNS는 이름을 주소로 연결하는 단계다. 헬스 체크, 연결 시간 초과, TLS 인증서, HTTP 상태는 다음 계층에서 확인한다. 장애를 “DNS가 된다/안 된다”로만 나누지 말고 어느 단계까지 성공했는지 구분해야 한다.

이해 확인 질문과 답변

재귀 리졸버는 왜 필요한가?

애플리케이션을 대신해 루트, TLD, 권한 서버의 위임을 따라 최종 답을 찾고 결과를 캐시한다. 각 클라이언트가 매번 전체 과정을 반복하지 않게 한다.

DNS 레코드를 바꿨는데 이전 주소가 계속 보이는 이유는 무엇일까?

브라우저, 운영체제, 재귀 리졸버 가운데 하나가 TTL이 남은 이전 응답을 사용할 수 있기 때문이다. 변경 전에 낮춘 TTL이 충분히 퍼졌는지도 확인해야 한다.

TTL을 0에 가깝게 하면 항상 좋을까?

아니다. 변경 반영은 빨라질 수 있지만 질의량과 권한 서버 의존도가 커지고 재귀 리졸버 정책에 따라 기대대로 동작하지 않을 수도 있다. 전환 필요와 안정성을 함께 고려한다.

DNS 조회 성공은 웹 요청 성공을 뜻할까?

아니다. 주소를 얻은 뒤에도 TCP 연결, TLS 서버 인증, HTTP 처리 단계가 남는다. 각 단계의 시간 초과와 오류를 따로 관찰해야 한다.

AI에게 이렇게 요청할 수 있다

example.com의 A 레코드가 로컬 캐시에 없을 때 재귀 리졸버가 루트, TLD, 권한 DNS 서버를 따라가는 질의 흐름을 보여 줘. TTL이 남은 이전 주소와 NXDOMAIN 음수 캐시 때문에 변경이 늦게 보이는 경우도 시간표로 설명해 줘.

DNS는 이름을 한 번에 주소로 바꾸는 전화번호부가 아니다. 위임을 따라 답을 찾고 여러 층의 캐시에 결과를 남기는 분산 시스템이다.