브라우저의 요청이 서버까지 가는 과정 (DNS 요청 과정) - 썸네일 디자인 (1)

0. 들어가며

https://blog.wonyangs.com/29

지난 글에서 티스토리 도메인을 바꾸는 과정을 다루었다.

이번 글에서는 도메인을 바꾸기 전 상황에서 티스토리 서버로 요청이 어떻게 가는지 DNS 요청을 중심으로 살펴본다.

1. 전체 DNS 요청 과정

브라우저의 요청이 서버까지 가는 과정 (DNS 요청 과정) - edited all

gemstoneyang.tistory.com으로 요청을 하는 상황에서 티스토리 서버의 IP를 받아오기까지의 과정이다.

각 과정을 하나씩 살펴보자.

(1) 로컬 DNS 캐시 확인

브라우저의 요청이 서버까지 가는 과정 (DNS 요청 과정) - edited 1

요청을 보내는 주체인 클라이언트는 우선 로컬 DNS 캐시에서 저장된 값이 있는지 확인한다.

로컬 DNS 캐시는 사용자가 이전에 방문한 웹사이트의 도메인 이름 - IP 주소 매핑 정보를 임시로 저장해 둔 데이터이다.

캐시는 일정 시간동안 정보를 매핑하여 동일한 도메인에 대해 DNS 쿼리를 반복하지 않고 더 빠르게 웹사이트를 로딩할 수 있다.

DNS 캐시의 저장 기간은 DNS 서버 레코드에 설정된 TTL(Time To Live) 값을 따른다.

예를 들어 설정된 TTL이 300이라면 5분(300초) 동안만 캐시가 유효하고, 만료된 이후 새 DNS 요청이 이뤄지게 된다.

(2) 로컬 DNS 서버에 쿼리

브라우저의 요청이 서버까지 가는 과정 (DNS 요청 과정) - edited 2

로컬 DNS 캐시에 도메인에 해당하는 정보가 없다면 브라우저는 로컬 DNS 서버에 요청한다.

앞으로 이 로컬 DNS 서버가 gemstoneyang.tistory.com 도메인에 해당하는 IP를 찾아줄 것이다.

로컬 DNS 서버는 보통 **ISP(Internet Service Provider)**에서 제공한다.

ISP는 KT, SK, LG U+ 같이 인터넷을 제공하는 업체라고 생각하면 된다.

로컬 DNS 서버의 주소는 사용자 네트워크 설정에 자동으로 설정되어 있다.

로컬 DNS 서버 IP

로컬 DNS 서버 IP

예를 들어 KT에서 제공하는 스타벅스 Wi-Fi를 이용 중일 때는 168.126.63.1 또는 168.126.63.2라는 IP로 DNS 요청을 하게 된다.

이 두 IP 주소는 대표적인 KT의 DNS 서버의 주소라고 한다.

(3) DNS 서버 캐시 확인

브라우저의 요청이 서버까지 가는 과정 (DNS 요청 과정) - edited 3

로컬 DNS 서버도 마찬가지로 캐시를 확인한다.

캐시에 요청한 도메인에 대한 IP 매핑 정보가 존재하면 바로 응답하고, 존재하지 않으면 IP를 찾기 위해 기나긴 DNS 요청을 시작한다.

(4) 루트 DNS 서버 요청

브라우저의 요청이 서버까지 가는 과정 (DNS 요청 과정) - edited 4

로컬 DNS 서버는 가장 먼저 루트 DNS 서버에 요청을 한다.

출처: https://hwan-shell.tistory.com/320

출처: https://hwan-shell.tistory.com/320

루트 DNS 서버는 DNS 계층 구조의 최상위에 있는 서버이다.

처음으로 도메인 해석을 진행하는 단계로, 도메인의 맨 끝에 있는 .com, .org, .net 등 을 해석한다.

(.com, .org 등을 Top-Level Domain, TLD라 지칭한다.)

이후 TLD에 해당하는 TLD 네임서버의 주소를 반환한다.

https://root-servers.org/

위 사이트에 접속하면 루트 DNS 서버 목록을 확인할 수 있다.

루트 DNS 기존 13개였으나 2020년 이후 1,000개가 넘었다고 한다.

2024년 12월 10일 기준

2024년 12월 10일 기준

한국에는 루트 DNS 서버가 7개 있다고 나온다.

2024년 12월 10일 기준, 전 세계에는 12개의 관리자와 1,917개의 인스턴스가 존재한다.

(5) TLD 네임서버 요청

브라우저의 요청이 서버까지 가는 과정 (DNS 요청 과정) - edited 5

다음으로 루트 DNS 서버로부터 얻은 .com TLD 네임서버 주소로 요청을 한다.

TLD(Top-Level Domain) 네임서버는 TLD에 속한 모든 도메인에 대한 네임서버 정보를 관리한다.

예를 들어 .com TLD 네임서버는 .com으로 끝나는 모든 도메인의 네임서버 정보를 관리한다.

https://ko.wikipedia.org/wiki/%EC%9D%B8%ED%84%B0%EB%84%B7_%EC%B5%9C%EC%83%81%EC%9C%84_%EB%8F%84%EB%A9%94%EC%9D%B8_%EB%AA%A9%EB%A1%9D

위 링크에서 TLD 목록을 확인할 수 있다.

gemstoneyang.tistory.com 도메인에 대한 요청이 오면 .com TLD 네임서버는 tistory.com에 해당하는 NS 레코드를 확인한다.

NS 레코드는 해당하는 도메인을 관리하는 네임서버 주소 정보가 담겨있는 레코드이다.

NS 레코드 예시

NS 레코드 예시

NS 레코드를 살펴보면 해당하는 도메인과 네임서버 목록이 매핑되어 있다.

'도메인에 해당하는 정보가 필요하면 이 서버들에게 물어봐~' 정도로 받아들이면 된다.

(6) Tistory 네임서버 요청

브라우저의 요청이 서버까지 가는 과정 (DNS 요청 과정) - edited 6

TLD 네임서버로부터 받은 tistory.com 도메인을 관리하는 네임서버 주소로 요청을 전달한다.

**네임서버(Name Server)**는 특정 도메인의 DNS 레코드를 관리하는 서버이다.

해당 도메인에 대한 여러 정보(IP 주소 정보, 별칭 정보 등)를 반환한다.

이 중 A 레코드는 해당 도메인에 대한 IPv4 주소 매핑 정보이다.

실제 티스토리 서버의 정확한 동작은 알 수 없기에 IP 주소 정보(A 레코드)를 바로 반환한다고 가정하고 다이어그램을 작성하였다.

(7) IP 주소 반환

브라우저의 요청이 서버까지 가는 과정 (DNS 요청 과정) - edited 7

로컬 DNS 서버는 tistory.com 네임서버로부터 받은 IP 주소 정보를 브라우저에 반환한다.

이제 브라우저는 해당 IP 주소로 HTTP/HTTPS 요청을 보낼 것이다.

2. 마치며

브라우저의 요청이 서버까지 가는 과정 (DNS 요청 과정) - edited all 1

가장 기초적인 DNS 요청 과정을 살펴보았다.

최대한 얕게 살펴봤음에도 관련된 정보가 정말 많았다.

(공부할수록 내용이 끝이 없다는 걸 느꼈다... 깊이 조절하는 게 쉽지 않았다.)

다음에는 티스토리는 도메인을 어떻게 바꿀 수 있는지에 대해 다뤄보려 한다.

3. 참고 자료

https://hwan-shell.tistory.com/320

https://m.blog.naver.com/strongbreeze/221163346549

https://hi-guten-tag.tistory.com/380