DNS

MONA·2025년 6월 13일

TIL 네트워크

나혼공

목록 보기

73/92

DNS(Domain Name Server)

도메인 네임을 관리하는 서버
계층적이고 분산된 도메인 네임에 대한 관리 체계이자 이를 관리하는 프로토콜

domain name: 호스트의 IP 주소와 대응되는 문자열 형태의 호스트 특정 정보
domain name과 IP 주소는 name server에서 관리함

Domain name

. 으로 계층적으로 구분됨
root domain: 최상단 도메인
TLD(Top-level-domain): 최상위 도메인
second-level domain: 최상위 도메인의 하부 도메인
일반적으로 도메인은 3~5단계가 있음
FQDN(Fully-Qualified Domain Name)
- 전체 주소 도메인 네임
- 도메인 네임을 모두 포함하는 도메인 네임
- FQDN의 첫 번째 부분을 host name이라 부르기도 함

ex) www.google.com에서
- 루트 도메인: . (제일 끝에 생략되어 있음)
- TLD: com
- 2단계 도메인: example
- 3단계 도메인: www
- FQDN : www.google.com.
- host name: www

서브도메인: 다른 도메인이 포함된 도메인. google.com의 서브도메인으로 mail.google.com, www.google.com 등이 있음

name server

resolving: IP 주소를 모르는 상태에서 도메인 네임에 대응하는 IP 주소를 알아내는 과정. 도메인 네임을 풀이한다고 함

플로우
www.google.com에 접속한다고 가정했을 때, 다음 순서로 네임 서버가 동작함

1. 로컬 네임 서버
2. 루트 네임 서버
3. TLD 네임 서버 (.com)
4. 책임 네임 서버 (google.com)
5. 최종 IP 주소 응답

사용자 PC
   │
   ▼
Local DNS Resolver (ISP 또는 8.8.8.8 등)
   │
   ▼
Root Name Server
   │
   ▼
TLD Server (.com)
   │
   ▼
Authoritative Name Server (google.com)
   │
   ▼
→ IP 주소 반환 (ex: 142.250.206.68)

네임 서버의 유형

로컬 네임 서버(Local DNS Resolver)

클라이언트가 리졸빙할 때 가장 먼저 찾는 네임 서버
로컬 네임 서버 주소는 일반적으로 ISP에서 할당해 주는 경우가 많음
ISP 할당 주소가 아닌 public DNS Server를 이용할 수도 있음
- ex) google: 8.8.8.8, 8.8.4.4, cloudflare: 1.1.1.1

클라이언트가 로컬 네임 서버에 특정 도메인 네임에 대응하는 IP 주소를 질의했을 때,

먼저 캐시에 요청한 도메인의 IP가 있는지 확인, 있으면 바로 응답.
모르고 있다면 루트 네임 서버(상위 네임 서버)로 재귀적으로 요청 보냄
root name server: 도메인을 관장하는 네임 서버. 질의에 대해 TLD 네임 서버의 IP 주소를 반환함
TLD name server: TLD를 관리하는 네임 서버. TLD의 하위 도메인 네임을 관리하는 네임 서버 주소를 반환.

루트 네임 서버(Root Name Server)

DNS 계층 구조의 최상위
전 세계에 13개의 논리적 루트 서버가 존재(A~M). 실제 물리 서버는 수백 개
.com, .net, .org, .kr 등 TLD 네임 서버의 위치 정보를 알려줌
도메인을 직접 해석하진 않고, 대신 .com 등 도메인을 관리하는 TLD 서버의 IP 주소를 반환함

TLD Name Server(Top Level Domain Server)

.com, .net, .org, .kr 등 최상위 도메인(TLD)을 관리
google.com 요청 시 → com TLD 서버가 google.com을 관리하는 책임 네임 서버(authoritative name server)의 위치(IP 주소)를 알려줌

책임 네임 서버(Authoritative Name Server)

특정 도메인에 대해 실제 IP 주소 정보를 갖고 있는 서버
www.google.com에 대한 A 레코드(IPv4), AAAA 레코드(IPv6) 등을 포함
DNS 요청의 최종 응답자
직접 운영할 수도 있고, DNS 위임을 받은 DNS 서비스 업체가 운영할 수도 있음

계층	설명	예시
Local DNS Resolver	사용자 근처 DNS 서버, 캐시 우선	8.8.8.8 (Google DNS)
Root Name Server	최상위 DNS 서버, TLD 서버 알려줌	`.` (점 하나로 표시됨)
TLD Server	`.com`, `.net` 등 도메인별 서버	`.com`, `.kr`
Authoritative Server	실제 IP 정보 보유	google.com 네임 서버

재귀적 질의와 반복적 질의

재귀적 질의(Recursive Query)

사용자가 원하는 IP 주소를 끝까지 찾아서 반환하라는 요청

ex)

사용자가 로컬 DNS server에 www.google.com을 요청할 때:

로컬 DNS server는 직접 IP 주소를 찾아서 사용자에게 전달해야 함
그 과정에서 루트-> TLD -> 책임 네임 서버까지 자기가 대신 질의하고, 결과를 모아서 사용자에게 반환함

특징

요청자는 하나의 응답만 받음
로컬 DNS server는 모든 계층을 대신 탐색함
사용자 입장에서는 편할 수 있으나 부하가 클 수 있음

[사용자] ──> [로컬 DNS] ──> [루트] ──> [TLD] ──> [책임 DNS] ──> [로컬 DNS] ──> 사용자
                   ↑         ↑         ↑
                 반복적 질의  ← 내부적으로는 반복적으로 조회

반복적 질의(Iterative Query)

사용자에게 IP 주소를 찾을 수 있는 위치를 재귀적으로 알려줌

ex)

로컬 DNS server가 루트 DNS server에 www.google.com을 요청할 때:

루트 서버가 이 주소를 모른다면, .com 서버에 물어보라고 반환
다시 .com TLD server에 요청 -> google.com 서버에 물어보라고 반환
-> 이 과정을 질문자(로컬 DNS)가 반복해서 수행함

특징

상위 DNS server는 답을 직접 주지 않고, 다음 질의 대상을 알려줌
요청자가 스스로 다음 서버를 찾고 질문을 반복
상위 서버는 가벼우나, 요청자가 부하를 부담함

[로컬 DNS] ──> [루트] → .com DNS 알려줌  
            └─> [.com TLD] → google.com DNS 알려줌  
            └─> [google.com DNS] → 최종 IP 주소 알려줌

DNS Cache

최근에 조회한 도메인-IP 매핑 정보를 저장해두는 것

동작 방식

사용자가 www.google.com을 조회하면, 그 IP 주소를 로컬 DNS 서버나 브라우저, OS가 저장
다음에 같은 도메인을 요청하면 다시 DNS 서버에 질의하지 않고 캐시에서 꺼냄
응답 속도 증가, 네트워크 부하 감소

캐시 위치

웹 브라우저
운영체제 (OS) 내부 DNS Resolver
로컬 DNS 서버

TTL

DNS 캐시가 얼마나 오래 유효한지를 결정하는 값

동작 방식

DNS 응답에는 "이 매핑 정보는 몇 초 동안 유효함"이라는 TTL 값이 포함됨
TTL이 만료되면 캐시에서 삭제됨 → 다시 DNS 질의 필요

TTL 길게 설정	TTL 짧게 설정
네트워크 부하 ↓	실시간 변경 반영 ↑
응답 속도 ↑	변경 즉시 적용 가능
변경 사항 반영 늦음	네트워크 부하 ↑

재귀적 DNS 서버의 보안 이슈

DNS Cache Poisoning

DNS server 잘못된 IP 정보(공격자 서버)를 주입하는 공격
ex)
사용자가 www.naver.com을 요청했지만,
공격자가 DNS 응답을 위조 → 피해자가 가짜 사이트로 접속하게 됨
피싱, 악성코드 배포에 활용 가능

방어 방법

DNSSEC (DNS Security Extensions) 사용
-> DNS 응답에 디지털 서명 포함 (위조 방지)
DNS 응답에 대한 검증 절차 강화

Open Resolver 악용

아무나 사용할 수 있는 재귀 DNS server를 악용해 공격
ex)
공격자가 피해자의 IP로 위장해 DNS 요청 -> DNS 응답은 피해자에게 전달 ->DDoS 증폭 공격 가능(대량 응답 전송)

방어 방법

DNS server의 재귀 질의 제한
-> 내부 사용자만 사용하도록 설정

URI(Uniform Resource Identifier)

인터넷 자원을 식별하는 모든 방식을 총칭하는 상위 개념
두 가지 방식으로 나뉨.

URL (Uniform Resource Locator): 자원의 위치를 알려줌
URN (Uniform Resource Name): 자원의 이름을 알려줌 (위치는 알 수 없음)

URL (Uniform Resource Locator)

구성요소

ex) https://www.example.com:443/search?q=test#section2

구성 요소	설명
`https`	프로토콜 (스킴): 어떤 방식으로 접근할지
`www.example.com`	호스트명: 도메인 이름 또는 IP 주소
`:443`	포트 번호 (생략 가능, 기본값 사용 시)
`/search`	경로(path): 서버 내 자원의 위치
`?q=test`	쿼리(query string): 요청에 대한 추가 데이터
`#section2`	프래그먼트(fragment): 문서 내 특정 위치 식별

URN (Uniform Resource Name)

자원의 고유한 이름을 나타내며, 위치와는 무관하게 자원을 식별할 수 있게 해줌

ex) urn:isbn:9783161484100
이 URN은 특정 책의 ISBN을 식별함. 하지만 이 URN만으로는 어디서 이 책을 찾을 수 있는지는 알 수 없음 → 위치는 URL이 제공, 이름은 URN이 제공

구분	URI	URL	URN
목적	자원 식별	자원의 위치 지정	자원의 고유 이름 지정
포함 관계	상위 개념	URI의 하위	URI의 하위
예시	`https://www.example.com`	`https://www.example.com/index.html`	`urn:isbn:9783161484100`
위치 정보 포함	경우에 따라 다름	✅ 있음	❌ 없음