DNS란? 실제로 어떻게 동작할까

인터넷에 연결된 모든 기기는 숫자 주소, 즉 IP 주소로 찾아갈 수 있습니다. 172.64.80.1을 외우고 싶은 사람은 없으므로 우리는 example.com 같은 이름을 씁니다. 도메인 네임 시스템(DNS)은 입력한 이름을 컴퓨터가 실제로 필요로 하는 주소로 변환해 주는 디렉터리 서비스입니다. 거의 모든 네트워크 요청의 뒤편에서 워낙 안정적으로 동작하기 때문에 그 존재를 당연하게 여기기 쉽습니다.

조회 과정, 단계별로

도메인을 처음 방문하면 기기는 그 IP 주소를 미리 알지 못합니다. 그래서 리졸버(보통 ISP나 Cloudflare, Google 같은 공개 제공업체가 운영하는 것)에게 알아봐 달라고 요청합니다. 리졸버도 반드시 답을 아는 것은 아니므로 권한의 체인을 따라 찾아갑니다.

1. 루트 서버가 도메인의 최상위 도메인(.com, .org, .io 등)을 담당하는 서버를 알려 줍니다.
2. TLD 서버가 해당 도메인의 권한 네임서버, 즉 도메인 소유자가 실제로 설정한 서버를 알려 줍니다.
3. 권한 네임서버가 실제 레코드, 즉 도메인이 현재 가리키는 IP 주소(들)를 반환합니다.

이 체인 전체는 대개 1초도 걸리지 않고 완료되며, 결과는 이후 캐시되어 매 요청마다 반복할 필요가 없습니다. 이에 대해서는 아래 TTL 항목에서 더 설명합니다.

처음부터 끝까지 따라가 보기

캐시가 비어 있는 리졸버에 blog.example.com을 확인하라는 요청이 들어왔다고 해 보겠습니다. 먼저 루트 서버에 물어보면 루트 서버는 답을 알지 못하지만 .com을 담당하는 곳을 알고 있으므로 리졸버를 그쪽으로 안내합니다. .com TLD 서버도 최종 답은 모르지만 example.com 자체가 어느 네임서버에 위임되어 있는지(예를 들어 ns1.dnshost.com과 ns2.dnshost.com)는 알고 있으므로 리졸버를 그쪽으로 보냅니다. 이제야 리졸버는 example.com의 레코드를 실제로 보유한 서버에 묻게 되고, 권한 서버인 그 서버가 실제 답을 돌려줍니다. A 레코드이거나, 한 단계 더 따라가야 하는 CNAME입니다. 이 체인의 각 단계도 그 자체로 DNS 조회이므로, 도메인에 대한 첫 번째(콜드) 조회는 중간 응답이 캐시된 이후의 모든 조회보다 눈에 띄게 느립니다.

캐싱은 리졸버 말고도 여러 계층에서 일어납니다

재귀 리졸버만 응답을 캐시하는 것은 아닙니다. 대부분의 운영 체제가 수명이 짧은 자체 DNS 캐시를 유지하고, 일부 브라우저는 그 위에 별도의 캐시를 하나 더 유지합니다. 이것이 “같은” 도메인을 두 번 조회했는데 결과가 서로 다르게 보이는 두 번째로 흔한 이유입니다. 항상 다른 리졸버가 다른 응답을 주는 것은 아니며, 새로 직접 질의하면 이미 현재 값이 나올 텐데도 내 기기가 약간 오래된 로컬 사본을 제공하고 있는 경우가 있습니다.

실제로 마주치게 될 레코드 유형

“DNS 레코드”는 하나가 아닙니다. 도메인에는 서로 다른 여러 레코드 유형이 나란히 존재하며, 각각 다른 종류의 질문에 답합니다. 도메인의 IP 주소를 조회할 때 실제로 다루는 것은 이 중 두 가지뿐이며, 나머지는 완전히 다른 용도로 존재합니다.

DNS 레코드를 직접 만지지 않더라도 중요한 이유

이 흐름을 이해하면 달리 혼란스러운 여러 현상이 설명됩니다. DNS 변경이 즉시 적용되지 않는 이유, 도메인이 한 네트워크에서는 잘 확인되는데 다른 네트워크에서는 실패하는 이유, “사이트가 다운됐다”는 문제가 때로는 서버가 아니라 DNS 문제로 밝혀지는 이유입니다. 이 도구 같은 서비스는 마지막 단계로 곧바로 건너뜁니다. 권한 서버에 가까운 공개 리졸버에 직접 질의해 그 응답을 그대로 보여 주므로, 추측하지 않고 도메인 DNS의 현재 실제 상태를 확인할 수 있습니다.

또한 일상적인 문제 해결에서 “DNS”와 “인터넷”이 그토록 자주 혼동되는 이유도 설명해 줍니다. DNS는 트래픽을 나르지도, 콘텐츠를 호스팅하지도, 애플리케이션을 실행하지도 않습니다. “이 이름이 지금 어떤 주소를 가리키는가”라는 단 하나의 질문에만 답합니다. 그 이후에 일어나는 모든 일(실제 연결, 페이지 로드, API 응답)은 완전히 별개의 시스템이며, 훨씬 더 큰 문제가 있다고 단정하기 전에 DNS를 독립적으로 점검할 수 있는 별도의 단계로 분리해서 확인해 볼 가치가 있는 것도 바로 이 때문입니다.