AI 생성주소창에 도메인을 치면 벌어지는 일 — DNS가 서버를 찾는 8단계

🤖 AI 생성 콘텐츠 — 이 글은 AI가 자료를 수집하고 초안을 작성했으며, 발행 전 누슘 운영자가 검수했습니다.

DNS는 사람이 읽는 도메인 이름을 서버가 쓰는 IP 주소와 연결하는 분산 시스템입니다. 주소창 입력부터 캐시·루트·TLD·권한 서버 조회까지 실제 흐름을 쉽게 설명합니다.

DNS는 인터넷의 전화번호부라는 설명이 유명합니다. 맞지만 반쪽짜리입니다. 전화번호부 한 권을 펼치는 게 아니라, 여러 안내소에 차례로 물어보고 답을 잠시 기억하는 분산 안내 체계에 가깝습니다. 그래서 어떤 날은 새 도메인이 바로 열리고, 어떤 날은 “DNS 전파를 기다리세요”라는 말이 나옵니다.

목차

• DNS는 정확히 무엇인가?
• 도메인 주소는 어떤 8단계로 찾아가나?
• TTL과 캐시는 왜 필요한가?
• DNS 장애를 어떻게 좁혀 찾나?

DNS는 정확히 무엇인가?

DNS는 Domain Name System의 약자입니다. RFC 1034는 DNS의 핵심을 세 부분으로 나눕니다.

• 도메인 이름 공간과 리소스 레코드: www.example.com처럼 점으로 연결된 트리와 그 이름에 붙은 정보입니다.
• 네임서버: 트리 일부의 정답을 보관하거나 다른 서버로 가는 길을 알려줍니다.
• 리졸버: 사용자를 대신해 네임서버에 질문하고 답을 가져오는 프로그램입니다.

A 레코드는 IPv4 주소, AAAA는 IPv6 주소, MX는 메일 서버, CNAME은 다른 이름을 가리킵니다. DNS는 단순히 웹사이트 IP만 저장하지 않습니다. 이름에 여러 종류의 정보를 붙이는 범용 시스템입니다.

도메인 주소는 어떤 8단계로 찾아가나?

처음 방문한 사이트이고 모든 캐시가 비어 있다고 가정해 봅시다.

1. 브라우저가 자기 DNS 캐시를 확인합니다.
2. 운영체제의 캐시와 hosts 설정을 확인합니다.
3. 설정된 재귀 리졸버에 “이 도메인의 주소를 찾아줘”라고 요청합니다.
4. 리졸버가 루트 네임서버에 묻습니다.
5. 루트 서버는 정답 대신 .com 담당 TLD 네임서버를 알려줍니다.
6. 리졸버가 .com 서버에 묻고, example.com의 권한 네임서버를 안내받습니다.
7. 권한 네임서버가 www.example.com의 실제 레코드를 답합니다.
8. 리졸버가 답을 캐시에 저장해 운영체제와 브라우저로 돌려줍니다.

여기서 재귀와 반복을 구분하면 좋습니다. 사용자는 재귀 리졸버에게 완성된 답을 부탁합니다. 리졸버는 루트와 TLD, 권한 서버에서 다음 목적지를 안내받으며 반복적으로 따라갑니다. 식당 직원에게 주문을 맡기면 직원이 주방·창고를 오가며 재료를 찾는 모습과 비슷합니다.

TTL과 캐시는 왜 필요한가?

인터넷의 모든 클릭이 매번 루트 서버부터 출발하면 너무 느리고 비쌉니다. DNS가 처음부터 캐시를 설계의 핵심으로 둔 이유입니다. RFC 1034는 데이터베이스 규모와 업데이트 빈도 때문에 분산 관리와 로컬 캐시가 필요하다고 설명합니다.

TTL(Time To Live)은 답을 얼마나 오래 믿어도 되는지 정하는 시간입니다. TTL이 남아 있으면 캐시는 권한 서버에 다시 묻지 않고 기존 답을 돌려줍니다.

“DNS 전파”는 새 정보가 파도처럼 모든 서버에 동시에 복사되는 단일 과정이 아닙니다. 각 캐시에 남은 기존 답이 TTL 만료 후 새 답으로 교체되는 현상이 크게 보이는 것입니다.

DNS 장애를 어떻게 좁혀 찾나?

사이트가 안 열린다고 무조건 서버가 죽은 건 아닙니다. 다음 순서로 보면 빠릅니다.

1. dig 도메인 A로 현재 리졸버의 답을 확인합니다.
2. dig @권한서버 도메인 A로 원본 답과 비교합니다.
3. dig +trace 도메인으로 위임 경로가 끊기는 지점을 봅니다.
4. NXDOMAIN이면 이름 자체가 없다는 뜻인지, 잘못된 리졸버 캐시인지 나눕니다.
5. 주소가 맞다면 그다음에 HTTP, TLS, 방화벽을 확인합니다.

DNS는 “이름을 주소로 바꾸는 단계”일 뿐입니다. 주소를 찾았다고 웹 서버가 정상이라는 뜻은 아닙니다. 반대로 웹 서버가 멀쩡해도 DNS 위임이 깨지면 사용자는 그 서버를 찾지 못합니다.

자주 묻는 질문 (FAQ)

Q. DNS 변경은 왜 바로 적용되지 않나요? A. 이전 답을 보관한 브라우저·운영체제·재귀 리졸버의 TTL이 아직 끝나지 않았기 때문입니다. 권한 서버의 값이 바뀌어도 기존 캐시는 만료 전까지 예전 답을 사용할 수 있습니다.

Q. 루트 서버가 모든 도메인의 IP를 알고 있나요? A. 아닙니다. 루트는 주로 .com, .kr 같은 최상위 도메인의 담당 서버를 안내합니다. 실제 호스트 레코드는 아래 단계의 권한 네임서버가 답합니다.

Q. DNS는 보통 UDP만 사용하나요? A. 전통적인 표준 질의는 UDP와 TCP를 모두 고려합니다. 응답 크기, 영역 전송, 암호화된 DNS 같은 조건에 따라 전송 방식이 달라질 수 있으므로 “항상 UDP 53번”으로 외우면 부족합니다.

Q. CNAME과 A 레코드는 무엇이 다른가요? A. A 레코드는 이름을 IPv4 주소에 직접 연결합니다. CNAME은 이름을 다른 정규 이름으로 연결하며, 리졸버가 그 이름의 레코드를 추가로 찾아야 합니다.

마치며

DNS는 한 대의 거대한 전화번호부가 아닙니다. 책임을 나눈 서버들이 안내를 이어주고, 캐시가 반복 질문을 줄이는 시스템입니다. 이 구조를 알면 “서버는 살아 있는데 왜 접속이 안 되지?”라는 문제를 훨씬 빨리 분리할 수 있습니다.

직접 겪은 가장 당황스러운 DNS 장애가 있다면 누슘 댓글에서 공유해 주세요. 다음에는 HTTPS 인증서가 도메인 신원을 어떻게 확인하는지 이어서 살펴보겠습니다.

참고자료

• IETF RFC 1034 — Domain Names: Concepts and Facilities
• IETF RFC 1035 — Domain Names: Implementation and Specification
• ICANN — DNS and how it works

태그: #DNS #도메인 #리졸버 #루트서버 #네임서버 #TTL #캐시 #RFC1034