DNS 조회가 단계별로 이루어지는 방식

브라우저에는 문제가 하나 있습니다. "example.com"을 입력했지만, 컴퓨터는 이름으로 트래픽을 보내지 않습니다—IP 주소로 보냅니다. 세계 어딘가, 특정 숫자 주소를 가진 서버에 원하는 웹사이트가 있습니다. 브라우저는 그 주소를 찾아야 합니다.

이것이 DNS 조회입니다: 이름을 숫자로 바꾸는 과정. 보통 100밀리초도 채 걸리지 않지만, 그 짧은 시간 안에는 여러 캐시 계층과 전 세계적 계층 구조를 통한 여정이 담겨 있습니다. 오직 한 가지 질문에 답하기 위해—이 도메인은 어디에 있는가?

브라우저 캐시: 먼저 기억 속에서 찾기

다른 곳에 묻기 전에, 브라우저는 먼저 자체 캐시를 확인합니다. 최신 브라우저는 최근에 조회한 도메인 이름을 IP 주소, TTL(time-to-live) 값과 함께 저장해 둡니다.

최근에 example.com을 방문했고 TTL이 아직 만료되지 않았다면, 브라우저는 이미 답을 알고 있습니다. 전체 조회 과정을 건너뛰고 즉시 연결을 시작합니다.

캐시가 비어 있거나 만료되었다면, 브라우저는 운영 체제에 물어봅니다.

운영 체제 캐시

운영 체제는 브라우저와 별개로 자체 DNS 캐시를 유지합니다. Chrome이 답을 갖고 있지 않더라도, 방금 전 Firefox가 같은 도메인을 조회했을 수도 있습니다—그 답은 운영 체제 캐시에 남아 있습니다.

여기서 찾으면 즉시 IP 주소를 돌려줍니다. 없다면, 쿼리는 기기 밖으로 나갑니다.

재귀 리졸버: 여러분의 대리자

컴퓨터는 전 세계 DNS 시스템에 직접 쿼리하지 않습니다. 재귀 DNS 리졸버에게 질문을 맡깁니다—보통 인터넷 서비스 제공자(ISP)나 Cloudflare(1.1.1.1), Google(8.8.8.8) 같은 서비스가 운영합니다.

재귀 리졸버라는 이름은 하는 일을 그대로 설명합니다: 여러분을 대신해 DNS 계층 구조를 재귀적으로 탐색합니다. 여러분은 한 번만 묻고, 나머지는 리졸버가 전부 처리합니다. 필요한 만큼 서버에 연락하고, 최종 답만 돌려줍니다.

재귀 리졸버는 캐싱도 적극적으로 합니다. 다른 사용자가 얼마 전 example.com을 조회했다면, 리졸버는 캐시에서 바로 답을 돌려줍니다. 인기 있는 사이트가 더 빨리 조회되는 이유가 여기 있습니다—이미 누군가 같은 질문을 했기 때문입니다.

하지만 캐시가 비어 있다면, 리졸버는 계층 구조의 맨 위에서 시작합니다.

루트 네임서버: 출발점

13개의 루트 네임서버 시스템이 DNS 계층 구조의 정점에 있습니다. 이들은 example.com이 어디 있는지 모릅니다. 대신 더 근본적인 것을 알고 있습니다: 각 최상위 도메인(TLD)을 담당하는 곳이 어디인지.

재귀 리졸버가 루트 서버에 묻습니다: "example.com은 어디서 찾을 수 있나요?"

루트 서버는 위임으로 답합니다: "example.com은 모르지만, .com 아래 모든 것을 담당하는 네임서버가 여기 있습니다."

이것이 반복 쿼리입니다. 루트 서버가 직접 답을 찾는 게 아니라, 알 만한 곳을 가리켜 줍니다.

TLD 네임서버: 범위 좁히기

재귀 리졸버는 이제 같은 질문을 .com TLD 네임서버에 합니다.

TLD 서버도 example.com의 IP 주소는 모릅니다. 하지만 그 도메인을 담당하는 권한 네임서버가 어디인지는 알고 있습니다. 답합니다: "example.com을 담당하는 네임서버가 여기 있습니다."

두 번의 쿼리 만에, "인터넷 어딘가"에서 "이 네임서버들이 알고 있다"로 범위가 좁혀졌습니다.

권한 네임서버: 최종 권위자

재귀 리졸버는 example.com의 권한 네임서버에 연락합니다. 이 서버가 도메인의 실제 DNS 레코드를 보유하고 있습니다.

리졸버가 묻습니다: "example.com의 IP 주소가 무엇인가요?"

권한 네임서버가 답합니다: "example.com의 A 레코드는 93.184.216.34이며, 3600초 동안 유효합니다."

응답이 돌아오는 과정

재귀 리졸버는 IP 주소를 운영 체제로 보내고, 운영 체제는 브라우저로 전달합니다. 각 단계에서 TTL에 따라 답이 캐시됩니다.

다음에 같은 리졸버에서 example.com을 조회하는 사용자는 바로 답을 받습니다. 한 시간 내에 다시 방문하면, 운영 체제가 네트워크 쿼리 없이 직접 답해줍니다. 브라우저는 마침내 필요한 것을 얻었습니다: IP 주소. 이제 93.184.216.34로 TCP 연결을 시작합니다.

재귀 쿼리 vs. 반복 쿼리: 두 가지 방식

컴퓨터는 리졸버에게 재귀 쿼리를 합니다: "어떻게든 답을 찾아주세요."

리졸버는 DNS 계층 구조에 반복 쿼리를 합니다: "위임이라도 좋으니 아는 것을 알려주세요."

이 역할 분담이 설계의 핵심입니다. 여러분은 한 번 묻고 하나의 답을 받습니다. 복잡한 과정은 리졸버가 처리합니다.

캐싱이 DNS를 가능하게 하는 이유

아무것도 캐시되지 않은 상태에서 처음부터 조회하면 네 번의 네트워크 왕복이 필요합니다: 리졸버, 루트 서버, TLD 서버, 권한 네임서버. 총 80~200ms가 걸립니다.

하지만 캐싱이 이를 크게 줄여줍니다. 재귀 리졸버는 TLD 네임서버 주소를 캐시해 루트 쿼리를 건너뜁니다. 권한 네임서버 주소를 캐시해 TLD 쿼리를 건너뜁니다. TTL이 끝날 때까지 최종 답도 캐시합니다.

인기 있는 도메인은 어디서나 캐시에 살아 있습니다. 잘 알려지지 않은 도메인은 전체 조회 체인이 필요합니다. Google로 돌아가는 게 즉각적으로 느껴지는 반면 처음 방문하는 사이트에서 약간의 지연이 느껴지는 이유가 여기 있습니다.

TTL 값이 이 균형을 조절합니다. TTL이 60초면 권한 서버에 끊임없이 쿼리가 쏟아집니다. TTL이 24시간이면 대부분의 쿼리가 캐시에서 처리되지만, DNS 변경 사항이 전파되는 데 하루가 꼬박 걸립니다.

이 모든 것이 의미하는 것

모든 연결은 DNS로 시작됩니다. 브라우저가 페이지를 불러오거나, 이미지를 내려받거나, 웹소켓을 열기 전에 반드시 IP 주소가 필요합니다.

조회 과정을 이해하면 많은 것이 명쾌해집니다—DNS 전파에 시간이 걸리는 이유(캐시가 만료되어야 하므로), 어떤 사이트가 더 빨리 로드되는 이유(모든 계층에서 캐싱이 일어나므로), DNS 장애가 치명적인 이유(아무것도 어디로 가야 할지 알 수 없게 되므로).

이 시스템은 우아합니다: 수십억 가지 가능성을 하나로 좁혀가는 계층 구조, 그리고 자주 묻는 것은 빠르게 답할 수 있도록 모든 단계에서 작동하는 캐싱. 여러분은 리졸버에게 묻습니다. 리졸버는 세계에 묻습니다. 세계가 답합니다. 그리고 모두가 기억합니다—잠시 동안.

DNS 조회에 관해 자주 묻는 질문

DNS 변경이 전파되는 데 시간이 걸리는 이유는 무엇인가요?

조회 체인의 모든 캐시—브라우저, 운영 체제, 재귀 리졸버—는 TTL이 만료될 때까지 답을 보유합니다. 이전 IP 주소가 24시간 TTL로 캐시되어 있다면, 일부 사용자는 캐시가 갱신될 때까지 이전 서버에 접속하게 됩니다. 전파가 즉각적이지 않은 이유는 바로 캐싱이 DNS를 빠르게 만드는 원리이기 때문입니다.

DNS 서버가 응답하지 않으면 어떻게 되나요?

재귀 리졸버는 타임아웃과 재시도 로직을 갖추고 있습니다. 루트 서버 하나가 응답하지 않으면 다른 것을 시도합니다. 설정된 리졸버 자체가 완전히 실패하면, 운영 체제가 보조 리졸버로 전환할 수 있습니다. 하지만 모든 조회가 실패하면, 브라우저는 "DNS_PROBE_FINISHED_NXDOMAIN" 같은 오류를 표시합니다—말 그대로 어디로 가야 할지 찾을 수 없는 상태입니다.

DNS 조회 과정을 직접 확인할 수 있나요?

네. dig 명령어에 +trace 플래그를 붙이면 각 단계를 볼 수 있습니다: dig +trace example.com. 루트 서버 쿼리, TLD 서버로의 위임, 권한 네임서버로의 위임, 그리고 최종 답까지—전체 여정이 눈앞에 펼쳐집니다.

어떤 웹사이트는 왜 더 빨리 조회되나요?

인기 있는 사이트는 모든 단계에서 캐싱의 혜택을 받습니다. 재귀 리졸버는 오늘만 해도 "google.com이 어디 있나요?"에 수천 번 답했을 것입니다—캐시에서 즉시 반환합니다. 아무도 조회한 적 없는 도메인은 전체 조회 체인을 거쳐야 하므로 100밀리초 이상이 더 걸립니다.

출처