DNS 동작 원리: 웹사이트 주소를 입력하면 실제 서버를 찾는 과정

웹사이트 주소와 실제 서버 사이를 잇는 DNS의 역할

사용자는 웹사이트에 접속할 때 보통 브라우저 주소창에 google.com, daum.net 같은 도메인 이름을 입력한다. 그러나 인터넷 내부에서는 이런 문자 주소 대신 223.130.xxx.xxx 같은 IP 주소를 사용하여 실제 서버를 찾는다. 사람이 보기에는 도메인 이름이 훨씬 편리하지만, 네트워크 장비와 서버는 숫자로 된 IP 주소를 기준으로 통신한다.

이때 “도메인 이름 → IP 주소”로 바꿔 주는 중간 단계가 필요하다. 이 기능을 담당하는 시스템이 바로 DNS(Domain Name System)이다. DNS는 인터넷 전체에 분산된 DNS 서버(네임 서버)들의 협력을 통해, 사용자가 입력한 도메인 이름에 대응하는 IP 주소를 찾아 브라우저에 알려 준다.

이 글에서는 DNS, 도메인 이름, IP 주소, DNS 서버, 네임 서버를 핵심 키워드로 삼아,

• DNS가 어떤 개념인지,
• 도메인 이름과 IP 주소를 어떻게 연결하는지,
• 사용자가 웹사이트 주소를 입력했을 때 실제 서버를 찾는 과정이 어떤 단계로 이루어지는지,
• 도메인 설정 변경 후 “어디서는 접속되고 어디서는 안 되는” 현상이 왜 발생하는지
  를 전산학 입문 수준에서 차근차근 설명한다.

---

DNS, 도메인 이름, IP 주소의 기본 개념

1. 도메인 이름과 IP 주소의 관계

인터넷에 연결된 서버나 기기는 각각 IP 주소(IP Address)를 가진다. IP 주소는 네트워크 상에서 해당 기기를 구분하기 위한 숫자 기반 주소이다. 대표적인 형식은 다음과 같다.

• IPv4 주소: A.B.C.D 형태(예: 203.0.113.25)
• IPv6 주소: 16진수와 콜론(:)으로 이루어진 긴 주소(예: 2001:0db8::7334)

네트워크 장비와 서버는 이 IP 주소를 보고 서로를 찾아간다. 그러나 사람이 이 숫자를 직접 외우고 입력하는 것은 매우 불편하다. 이를 해결하기 위해 등장한 것이 도메인 이름(Domain Name)이다.

• 예) 142.250.xxx.xxx → google.com
• 예) 223.130.xxx.xxx → naver.com

도메인 이름은 사람이 읽기 쉽게 설계된 문자열 주소이고, IP 주소는 컴퓨터와 네트워크 장비가 이해하는 숫자 주소이다. 이 둘을 연결해 주는 “전화번호부” 역할을 하는 시스템이 바로 DNS이다.

2. DNS(Domain Name System)의 역할

DNS(Domain Name System)는 전 세계에 분산된 DNS 서버(네임 서버)들을 이용해

• “이 도메인 이름에 해당하는 IP 주소는 무엇인가”를 조회하는 시스템이다.

DNS의 주요 역할은 다음과 같이 정리할 수 있다.

1. 도메인 이름 → IP 주소 변환
   • 사용자가 브라우저에 www.example.com을 입력하면,
   • DNS는 이 도메인 이름을 실제 서버의 IP 주소로 바꾸어 브라우저에 알려 준다.
2. IP 주소 → 도메인 이름 역조회(역방향 DNS)
   • 특정 IP 주소가 어느 도메인으로 등록되어 있는지 확인하는 기능도 지원한다.
   • 보안, 로그 분석, 스팸 메일 필터링 등에서 사용된다.
3. 도메인 구조와 관리 정보 유지
   • 도메인 소유자, 메일 서버 정보, 네임 서버 위치 등을 DNS 레코드 형태로 저장한다.

DNS는 하나의 중앙 서버가 모든 정보를 관리하는 구조가 아니라, 루트 네임 서버, TLD(최상위 도메인) 서버, 권한 DNS 서버(Authoritative DNS) 등 여러 단계의 서버가 협력하는 분산 시스템이다.

 

도메인 이름과 IP 주소를 연결하는 DNS 구조 개념도

3. DNS 서버와 네임 서버의 종류

DNS 동작 원리를 이해하려면, DNS 서버가 어떤 종류로 나뉘는지 알아둘 필요가 있다. 핵심적인 개념은 다음과 같다.

1. 루트 네임 서버(Root Name Server)
   • DNS 계층 구조의 가장 상위에 있는 서버이다.
   • .com, .net, .org, .kr와 같은 최상위 도메인(TLD)에 대한 정보를 알고 있다.
   • 전 세계에 소수의 루트 서버 그룹만 존재하며, 인터넷 주소 체계의 최상위 기준점 역할을 한다.
2. TLD(Top-Level Domain) 네임 서버
   • 각 최상위 도메인에 속한 2단계 도메인 정보를 관리한다.
   • 예를 들어 .com TLD 서버는 example.com, google.com 같은 2단계 도메인에 대한 네임 서버 위치를 알고 있다.
3. 권한 DNS 서버(Authoritative Name Server)
   • 특정 도메인에 대한 최종 IP 주소 정보를 가지고 있는 서버이다.
   • 예를 들어 example.com의 A 레코드, AAAA 레코드, MX 레코드 등을 실제로 저장하고 있는 서버를 말한다.
   • 도메인 소유자가 DNS 설정 화면에서 A 레코드, CNAME 레코드 등을 수정하면, 이 권한 DNS 서버 내용이 변경된다.
4. 리졸버(Resolver, 재귀 DNS 서버)
   • 사용자의 DNS 조회 요청을 받아 대신 여러 네임 서버를 순차적으로 조회해 주는 DNS 서버이다.
   • 보통 통신사(ISP)의 DNS, 기업 내부 DNS, 공용 DNS(예: 8.8.8.8, 1.1.1.1)가 여기에 해당한다.
   • 리졸버는 조회 결과를 일정 시간 캐시에 저장하여, 같은 요청이 반복될 때 더 빠르게 응답한다.

4. DNS 레코드의 기본 종류

DNS 서버에는 도메인에 대한 여러 종류의 정보가 DNS 레코드 형태로 저장된다. 주요 레코드는 다음과 같다.

• A 레코드: 도메인 이름 → IPv4 주소 매핑
• AAAA 레코드: 도메인 이름 → IPv6 주소 매핑
• CNAME 레코드: 한 도메인을 다른 도메인 이름에 별칭으로 연결
• MX 레코드: 해당 도메인의 메일 서버 위치 정보
• NS 레코드: 도메인을 관리하는 권한 DNS 서버 정보

이 중 A 레코드, AAAA 레코드, NS 레코드는 “웹사이트 주소를 입력했을 때 실제 서버를 찾는 과정”과 직접적으로 관련이 있다.

---

브라우저 주소 입력부터 서버 접속까지 DNS 동작 과정

1. 브라우저와 운영체제, 리졸버가 협력하는 단계

사용자가 브라우저 주소창에 www.example.com을 입력하고 엔터를 눌렀다고 가정한다. 이때 DNS와 도메인 이름, IP 주소, DNS 서버는 다음과 같은 순서로 동작한다.

1. 브라우저 DNS 캐시 확인
   • 브라우저는 최근에 접속한 도메인과 IP 주소를 일정 시간 동안 저장한다.
   • www.example.com에 대한 IP 주소가 캐시에 남아 있다면, 새로운 조회 없이 바로 그 IP로 접속을 시도한다.
2. 운영체제(로컬 DNS 캐시) 확인
   • 브라우저 캐시에 정보가 없으면, 운영체제(윈도우, macOS, 리눅스 등)에 “이 도메인의 IP 주소를 알려 달라”고 요청한다.
   • 운영체제 역시 자체 DNS 캐시를 가지고 있으며, 여기에서 해당 도메인의 IP 주소를 찾으려고 시도한다.
3. 리졸버(재귀 DNS 서버) 질의
   • 로컬 캐시 어디에도 정보가 없으면, PC나 라우터에 설정된 리졸버 DNS 서버(예: 통신사 DNS, 8.8.8.8 등)에 질의를 보낸다.
   • 이때 질의 내용은 “www.example.com에 해당하는 A/AAAA 레코드를 알려 달라”이다.
4. 리졸버 내부 캐시 확인
   • 리졸버 역시 많은 사용자의 요청을 처리하기 때문에 자체 캐시를 가지고 있다.
   • 이전에 다른 사용자가 같은 도메인을 조회했다면, 캐시된 결과를 바로 돌려줄 수 있다.

캐시에 없을 경우에만, 리졸버는 루트 → TLD → 권한 DNS 서버 순서로 직접 조회를 진행한다.

 

브라우저와 운영체제, 리졸버 DNS 서버가 순서대로 DNS 캐시를 확인하는 구조도

2. 루트 서버, TLD 서버, 권한 DNS 서버를 거치는 과정

리졸버가 캐시에서 답을 찾지 못했다면, 다음과 같은 과정을 거쳐 최종 IP 주소를 알아낸다.

1. 루트 네임 서버에 질의
   • 리졸버는 먼저 루트 네임 서버에 “.com 도메인을 관리하는 TLD 네임 서버는 어디인가”를 묻는다.
   • 루트 서버는 com TLD 서버 목록을 알려 준다.
2. TLD 네임 서버에 질의
   • 리졸버는 com TLD 서버 중 하나에 “example.com을 관리하는 권한 DNS 서버는 어디인가”를 묻는다.
   • TLD 서버는 example.com 도메인에 대한 NS 레코드(권한 DNS 서버 정보)를 응답한다.
3. 권한 DNS 서버에 질의
   • 리졸버는 example.com의 권한 DNS 서버에
     • “www.example.com의 A/AAAA 레코드를 알려 달라”라고 직접 문의한다.
   • 권한 DNS 서버는 해당 도메인의 IP 주소(예: 203.0.113.25)를 응답한다.
4. 결과 캐시 및 최종 응답
   • 리졸버는 받은 IP 주소를 자신이 관리하는 DNS 캐시에 일정 시간 저장한다.
   • 그리고 이 IP 주소를 사용자 PC(운영체제)로 돌려준다.
   • 운영체제도 이 값을 다시 캐시에 저장하고, 브라우저에 넘겨 준다.
5. 브라우저의 실제 서버 접속
   • 이제 브라우저는 www.example.com이라는 도메인 대신
   • DNS가 알려 준 203.0.113.25 같은 IP 주소를 사용해 웹 서버와 TCP/IP 연결을 맺는다.

브라우저 화면에서 사용자가 보는 것은 “주소 입력 → 페이지 열림”이라는 단순한 결과이지만, 내부에서는 DNS 서버와 네임 서버가 여러 단계의 협업을 통해 실제 서버의 IP 주소를 찾아내는 과정이 빠르게 진행되고 있다.

 

3. DNS 캐시와 TTL, 전파 지연의 의미

DNS 동작 과정에서 중요한 개념이 DNS 캐시(Cache)와 TTL(Time To Live)이다.

1. DNS 캐시(Cache)
   • DNS 조회 결과는 브라우저, 운영체제, 리졸버 등 여러 단계에서 일정 시간 동안 저장된다.
   • 같은 도메인에 대해 반복적으로 조회할 때, 캐시 덕분에 훨씬 빠르게 IP 주소를 얻을 수 있다.
   • 그러나 이 때문에 도메인 설정을 바꾸었을 때 예전 정보가 계속 남아 있는 현상도 발생한다.
2. TTL(Time To Live)
   • 각 DNS 레코드에는 얼마 동안 캐시해도 되는지를 나타내는 TTL 값이 있다.
   • 예를 들어 TTL이 3600초라면, 최대 1시간 동안 캐시에 남을 수 있음을 의미한다.
   • TTL이 길수록 조회 부담은 줄지만, 설정 변경이 인터넷 전역에 반영되기까지 시간이 더 오래 걸린다.
3. 전파 지연(Propagation Delay)
   • 도메인의 A 레코드나 NS 레코드를 변경하면,
   • 전 세계 여러 DNS 서버와 캐시에 저장된 기존 정보가 자연스럽게 “만료”되고 새로운 정보로 교체되어야 한다.
   • 이 과정에서 어떤 지역, 어떤 사용자에게는 새 서버로 접속되고,
   • 다른 곳에서는 여전히 옛 서버로 접속되는 기간이 발생할 수 있다.
   • 일반적으로 수 분에서 수 시간, 경우에 따라 수십 시간까지 차이가 날 수 있다.

DNS 캐시와 TTL, 전파 지연 개념을 이해하면,

• “도메인을 새 서버에 연결했는데, 바로 반영되지 않는다”
• “어떤 컴퓨터에서는 접속이 되고, 다른 곳에서는 안 된다”
  와 같은 현상을 더 논리적으로 설명할 수 있다.

4. 실생활에서 자주 마주치는 DNS 관련 문제와 해결 관점

DNS 동작 원리를 알면, 다음과 같은 상황을 만났을 때 원인 후보를 좁히는 데 도움이 된다.

1. “사이트에 연결할 수 없음” 오류
   • 해당 도메인의 A 레코드가 잘못 설정되었거나,
   • NS 레코드가 올바르지 않거나,
   • 권한 DNS 서버 자체가 응답하지 않는 경우일 수 있다.
   • nslookup, dig 같은 도구로 DNS 레코드를 조회하여 문제 지점을 찾을 수 있다.
2. 어디서는 접속되고, 어디서는 접속이 안 되는 경우
   • 서로 다른 리졸버 DNS 서버(통신사 DNS, 공용 DNS 등)를 사용하면서,
   • 캐시 정보와 전파 시점이 달라 발생하는 경우가 많다.
   • 이때 공용 DNS 서버로 바꾸어 테스트하거나, 로컬 DNS 캐시를 삭제한 뒤 재시도해 볼 수 있다.
3. 도메인을 다른 서버로 이전했는데, 예전 서버로 접속되는 경우
   • A 레코드 또는 CNAME 레코드 변경 후 TTL이 아직 남아 있어 이전 정보가 사용되는 상황일 수 있다.
   • 서버 이전 전에 TTL 값을 미리 줄여 두면 전파 지연 시간을 줄이는 데 도움이 된다.
4. 사설망과 공용망이 섞인 환경에서의 이름 해석 문제
   • 회사 내부 DNS와 외부 공용 DNS가 서로 다른 IP 주소를 반환하게 구성해 둔 경우,
   • 외부에서는 공인 IP로, 내부에서는 사설 IP로 같은 도메인을 다르게 해석하는 경우도 있다(스플릿 DNS).
   • 이 구조를 이해하면, “회사에서는 잘 되는데 집에서는 안 되는” 상황도 DNS 설계 관점에서 해석할 수 있다.

---

DNS 동작 원리를 알면 인터넷 주소 체계가 보인다

이 글에서는 DNS 동작 원리를 중심으로, 웹사이트 주소를 입력하면 실제 서버를 찾는 과정을 설명하였다. 핵심 내용을 정리하면 다음과 같다.

1. 도메인 이름과 IP 주소는 사람과 컴퓨터를 위한 각각의 주소 형식이다.
   • 도메인 이름은 사람이 읽기 쉬운 문자 주소이고,
   • IP 주소는 네트워크 장비가 이해하는 숫자 주소이다.
2. DNS는 도메인 이름을 IP 주소로 바꾸는 분산 주소록 시스템이다.
   • 루트 네임 서버, TLD 서버, 권한 DNS 서버, 리졸버 DNS 서버가 함께 동작한다.
3. 브라우저 주소 입력부터 서버 접속까지는 여러 단계의 DNS 조회와 캐시 과정이 있다.
   • 브라우저 캐시 → 운영체제 캐시 → 리졸버 → 루트·TLD·권한 DNS 서버 순서로 IP 주소를 찾는다.
4. DNS 캐시와 TTL 때문에 설정 변경 후 전파 지연이 발생한다.
   • 도메인 설정을 바꾸어도, 일정 시간 동안은 예전 정보가 곳곳에 남아 있을 수 있다.
5. DNS 구조를 이해하면 도메인 관련 문제를 더 논리적으로 해결할 수 있다.
   • “사이트에 연결할 수 없음”, “어디서는 되고 어디서는 안 됨” 같은 상황을
   • DNS 레코드 설정, 캐시, 네임 서버 장애 관점에서 분석할 수 있다.

이제 “웹사이트 주소를 입력했을 뿐인데, 어떻게 실제 서버까지 찾아가는가”라는 질문에 대해,

• DNS가 도메인 이름을 IP 주소로 바꾸어 주고,
• 그 결과를 바탕으로 브라우저가 서버와 TCP/IP 연결을 맺는다는 구조를 설명할 수 있을 것이다.

다음 단계에서 함께 살펴볼 만한 주제로는 예를 들어 다음과 같은 것들이 있다.

• HTTPS와 인증서: DNS로 찾은 서버가 진짜 서버인지 검증하는 방법
• CDN과 DNS: 전 세계 여러 서버 중 가장 가까운 서버를 선택하는 구조

이러한 주제를 이어서 학습하면, 전산학에서 중요한 축인 인터넷 주소 체계와 웹 서비스 구조를 더 깊이 이해하는 데 도움이 될 것이다.