DNS(Domain name Service)
도메인 이름 시스템은 사람이 읽을 수 있는 도메인 이름을 머신이 읽을 수 있는 IP 주소로 변환합니다.
DNS : 사람이 읽을 수 있는 문자열과 internet 프로토콜 기반 정보를 매칭시켜주는 시스템
Internet Corporation for Assigned Names and Numbers (ICANN)에서 관리
도메인(Domain) : 대상의 IP 주소 등의 정보와 맵핑되는 사람이 알아 볼 수 있는 문자열
서브 도메인 : 도메인 중 스트링 앞에 추가 문자열이 붙은 도메인
예 : text.example.com
APEX 도메인 : 도메인 중 앞에 추가 문자열이 없는 최상위 도메인
예 : example.com
레코드 (DNS Record) : 도메인이 어떤 방식으로 데이터와 매칭되는지 정의하는 기록
다양한 레코드 종류가 있으며 각각 다른 정보와 매칭
예 : A 레코드는 IPv4 주소, MX 레코드는 메일 서버
Domain Zone : 도메인의 정보를 담은 레코드의 집합
예 : www.awsclassroom.kr/ lecture.awsclassroom.kr
Zone File : Domain Zone 정보를 저장한 텍스트 파일
DNS Query : 주어진 도메인에 해당하는 정보를 요청하는 쿼리
Name Server(NS): DNS Query를 Zone FIle을 기반으로 응답할 수 있는 서버
Authoritative : DNS 정보의 원본을 가지고 있는 최상위 NS 서버
None-Authoritative : Authoritative NS 서버를 조회하여 정보를 보관하고 있거나 응답하는 서버(캐시)
DNS Resolver : 사용자와 NS 서버 사이에 위치한 서버로 실제 유저의 요청에 따라 IP 주소 등의 정보를 확보하는 서버
유저의 클라이언트가 제일 먼저 쿼리를 요청하는 대상이며 보통 ISP가 관리
DNS의 규모
2024 7월 기준 약 3억 6천만개의 도메인 존재
그리고 거의 모든 HTTP 통신에 매번 활용
매우 큰 규모이며 이를 호스팅하기 위한 서버 구조에 큰 고민 필요
DNS의 구성
DNS는 계층 구조
즉 최상위 도메인부터 차례대로 계층구조로 구성되어 있음
실제 레코드는 가장 마지막 계층에서 보관 및 처리
맨 마지막에 도달해서야 Record를 얻을 수 있는 계층형 구조이다.
DNS Root
DNS 계층 구조의 최상위 레벨
즉 DNS Query 수행 시 최초로 조회하는 거점
다음 단계인 TLDs(Top Level Domain)의 Zone File을 가진 NS서버의 주소 정보 보유
IANA (Internet Assigned Numbers Authority) 에서 조율하는 13개의 주체에서 관리
A~M까지 각 관리 주체별로 다른 서버 주소
Root Hints File
DNS Root의 주소를 담은 파일
각 DNS Resolver에 하드코딩
TLD의 Zone File을 준다.
Top Level Domains
DNS 계층 구조의 두 번째 레벨
실질적으로 정보를 가지고 있는 최 상위 레벨
예 : .com/ .org / .net / .info 등
종류
Country Code TLDs : 각 나라에 할당된 두 자리 코드
예 : .kr / .jp / .uk / .ai
Sponsered TLDs : 사설 조직이나 기관에 할당된 TLDs
예 : .edu / .gov / .mil 등
관리 주체 : TLDs Registry
예:
.com / .net -> Verisign
.org -> Public Interest Registry
.kr -> Korea Internet & Security Agency (KISA)
실제 도메인의 레코드를 관리하는 NS 서버의 주소 정보를 담은 Zone File 보유
NS 서버
실제 도메인의 레코드를 가지고 있는 서버
이 NS 서버의 주소를 TLDs에 등록해두면 클라이언트에서 DNS 쿼리에 따라 이쪽으로 도착
해당 도메인 및 서브도메인들이 어떤 프로토콜의 어떤 주소로 맵핑되는지(레코드)에 관한 Zone File 보유
lecture. 어디로 가면 될까?
203.8.113.14로 가면 돼
도메인 등록
도메인 등록 대행 (Domain Registrar)을 통해 등록
도메인 등록 대행 (DomainTegistrar) : ICANN 에게 인증받고 TLDs Registry와 협의하여 도메인 등록의 권한을 가진 주체
예 : 가비아 , GoDaddy, Cafe24, AWS Route 53
등록할 때 TLDs Regisrty에 자신이 원하는 NS 서버 주소를 등록
일종의 남은 슬롯에 자신의 NS 서버를 예치하는 개념
NS서버는 자신의 개인 NS 서버를 사용하거나 , DNS Hosting Service 업체에서 대여 가능
DNS Hosting Service : DNS 기능을 제공하는 주체체
DNS 질의 기본 흐름
클라이언트가
www.google.com에 접속하고 싶을 때 → "이 도메인이 어떤 IP 주소를 갖고 있는지 알려줘!"라고 DNS 서버에 묻는 과정입니다.
🧭 전체 흐름 요약
1. 사용자가 브라우저에 도메인 입력
2. 로컬 캐시 확인 (hosts 파일, DNS 캐시 등)
3. DNS 리졸버(로컬 DNS 클라이언트)가 DNS 서버에 질의 전송
4. DNS 서버(보통 ISP의 서버)가 응답 (있으면 바로)
└ 없으면 루트 → TLD → 권한 서버 순서로 재귀적으로 조회
5. IP 주소 응답 받음 → 브라우저가 해당 IP에 TCP 연결 시도🔢 세부 단계: 클라이언트 중심으로 본 요청 과정
1️⃣ 도메인 이름 입력
사용자가 브라우저에
www.google.com입력
2️⃣ 로컬 캐시 확인
먼저 운영체제의 DNS 캐시,
hosts파일 등을 확인이미 IP 주소가 있다면 DNS 서버에 요청할 필요 없음
3️⃣ DNS 요청 전송
DNS 리졸버(운영체제 내부 클라이언트)가 DNS 요청 생성
보통 UDP 포트 53 사용 (응답 크기가 크면 TCP도 사용 가능)
요청 내용:
질의 타입:
A(IPv4 주소 요청),AAAA(IPv6),MX,CNAME등질의 대상:
www.google.com
4️⃣ 지정된 DNS 서버에게 질의
보통 DHCP로 자동 설정된 ISP의 DNS 서버 (또는 8.8.8.8 같은 공개 DNS 서버)
이 서버가 응답을 알고 있으면 바로 응답
5️⃣ 재귀 질의 (필요시)
만약 DNS 서버가 IP 주소를 모르면, 대신 루트 DNS부터 질의 시작
루트 서버 →
.com서버 →google.com권한 서버
6️⃣ 클라이언트가 응답 받음
응답 메시지에 다음 포함:
www.google.com→142.250.206.196같은 IPTTL (유효 시간), 응답 타입 등
7️⃣ 브라우저가 IP로 TCP 연결 시도
TCP 3-way 핸드셰이크 후 HTTP 요청 전송
✉️ 실제 DNS 질의 메시지 구성 (요약)
Transaction ID
요청/응답 매칭용 식별자
Flags
요청/응답 여부, 재귀 여부 등
Questions
질의 도메인 이름 (www.google.com)
Answer RRs
(응답 시) IP 주소 포함
Authority RRs
관련 권한 서버 정보
Additional RRs
캐시 정보 등 부가 데이터
📦 실제 예시 (Wireshark 캡처)
Frame 1: 74 bytes on wire
DNS Query:
Transaction ID: 0x1a2b
Flags: Standard query (0x0000)
Questions: 1
Query: www.google.com, Type: A, Class: INFrame 2: 90 bytes on wire
DNS Response:
Transaction ID: 0x1a2b
Answers: 1
Name: www.google.com
Type: A
Address: 142.250.206.196✅ 정리표
1. 도메인 입력
사용자가 웹사이트 주소 입력
2. 캐시 확인
로컬 DNS 캐시/hosts 확인
3. DNS 요청 전송
UDP 53 포트로 질의 메시지 생성
4. DNS 서버 응답
직접 응답 또는 재귀 질의
5. 응답 수신
IP 주소 받아서 TCP 연결 시도
✅ 한 줄 요약
DNS는 사람이 기억하기 쉬운 도메인 이름을 실제 IP 주소로 변환해주는 서비스이며, 클라이언트는 DNS 서버에 UDP 53 포트로 질의하여 IP를 받아옵니다.
Last updated