DNS (Domain Name System)

1. DNS란?

DNS는 사람이 기억하기 쉬운 도메인 이름(예: www.google.com)을

컴퓨터가 통신에 사용하는 IP 주소(예: 142.250.206.132)로 변환해주는 분산형 데이터베이스 시스템이다.

이 기능은 웹 브라우징, 이메일, 스트리밍 등 거의 모든 인터넷 서비스의 기초가 되며,

인터넷의 핵심 기능 중 하나(core Internet function)로 간주된다.

DNS는 애플리케이션 계층의 프로토콜이며, 네트워크의 Edge에서 동작한다

DNS는 애플리케이션 계층의 프로토콜이다.
호스트(클라이언트)와 DNS 서버가 통신하여 이름을 IP 주소로 변환한다.
DNS는 네트워크의 가장자리(edge) 에서 수행되는 복잡한 기능 중 하나이며, 클라이언트 가까운 위치(사용자 단의 시스템, 로컬 네트워크 등)에서 작동한다.
반대로, 인터넷의 중심(core)은 단순한 구조를 유지하고,이름 해석, 캐싱, 보안 등 복잡한 처리들은 edge에 분산되어 있다.

2. DNS의 주요 특징

이름 해석(name resolution): 도메인 이름을 IP 주소로 변환
분산된 구조(distributed architecture): 전 세계에 걸쳐 DNS 서버들이 분산되어 운영됨
계층적 구조(hierarchical): 루트 → TLD → 권한 있는 네임서버로 나누어짐

DNS가 제공하는 주요 기능:

호스트 이름 ↔ IP 주소 변환
인증(Authentication)
정식 이름(Canonical Name) 제공
메일 서버 식별
로드 밸런싱 (Load Balancing)

Canonical Name과 Alias

DNS는 별칭과 정식 이름 간의 관계도 저장한다.

konkuk.ac.kr → 실제 서버 이름은 relay1.konkuk.ac.kr
naver.com → 내부적으로는 relay1.naver.com, relay2.naver.com, ... 존재

메일 서버와 DNS

우리가 dhjo@konkuk.ac.kr과 같이 이메일 주소를 입력하더라도, 실제 메일 서버는 mail.konkuk.ac.kr 혹은 kmail.konkuk.ac.kr일 수 있다. 이런 메일 서버 이름 역시 DNS를 통해 식별된다.

DNS와 로드 밸런싱

DNS는 단순히 IP 주소를 하나만 반환하는 것이 아니다. 동일한 도메인 이름에 대해 여러 개의 IP 주소를 반환할 수 있다. 이를 통해 복수의 웹 서버에 트래픽을 분산시킬 수 있다.

예시:

www.naver.com 요청 → 내부적으로는 relay1, relay2, ... 중 하나로 연결
이를 DNS 수준의 부하 분산(Load Balancing)이라 부른다

왜 중앙 집중형 DNS는 아닌가?

DNS를 중앙 집중형으로 만들면:

단일 실패 지점(Single Point of Failure)
엄청난 트래픽 집중
지연 시간 증가
확장성 부족

따라서 지역 분산(Local DNS) 방식이 채택된다. Comcast는 하루에 6000억 개의 DNS 쿼리를 처리한다. 이처럼 DNS는 대규모 확장성과 분산 구조가 필수다.

DNS는 인터넷의 핵심 기능

DNS는 HTTP보다 먼저 동작하며, 없으면 웹 서비스 자체가 불가능하다. 그만큼 중추적인 인프라이다. 루트 서버는 그 중요성 때문에 보안적으로도 매우 강하게 보호되며, DNSSEC이라는 보안 프로토콜을 통해 인증(Authentication)과 무결성(Integrity)을 제공한다.

DNS는 HTTP보다 먼저 필요했던 기술

HTTP(웹 브라우징)는 인터넷 브라우저가 등장하며 생겼다.

이보다 앞서 DNS는 인터넷 호스트들이 서로를 식별하기 위해 먼저 필요했다.

HTTP/2는 2015년에 표준화되었지만
SMTP(이메일 전송 프로토콜)는 1980년에 나왔다.
DNS는 그보다도 먼저, 호스트 간 통신을 위해 도입되었다.

DNS는 보안 기능도 제공한다 - DNSSEC

DNS는 단순한 이름 해석 외에도 보안(Security) 기능을 갖는다. 그 대표적인 예가 바로 DNSSEC(DNS Security Extensions)이다. 이 프로토콜은 아래와 같은 기능을 제공한다:

인증(Authentication)예를 들어, 비밀번호 대신 “어머니의 결혼 전 성은?”, “초등학교 이름은?” 같은 질문으로 인증한다.
"너 누구야?"라고 묻고, 상대가 신뢰 가능한 사람인지 확인하는 절차.
무결성(Integrity)
데이터가 중간에 변조되지 않았음을 확인하는 것. DNSSEC은 이를 위해 **암호화(encryption)**된 형태로 데이터베이스 레코드를 저장한다.

ICANN과 DNS의 상업화

DNS가 중요한 기술이자 비즈니스 기회가 되자, 미국 상무부(Department of Commerce)는 DNS 관련 이름과 번호를 관리할 조직을 만들었다. 그게 바로 ICANN (Internet Corporation for Assigned Names and Numbers)이다.

ICANN은:

도메인 이름(Name)과
IP 주소(Numbers)를 관리한다.

EDU-TLD 운영과 수익 구조

EDU-TLD를 운영함으로써 매달 수수료를 수집함.
운영자는 실제로 큰 노력을 하지 않아도 되고, 시스템만 유지하면 됨.
한국의 통신사도 비슷한 모델:
- 수백만 가입자를 보유한 기업이 가입자로부터 월 이용료를 징수.
이를 교수님은 "장치 상호"라고 표현.
- 처음 네트워크 설치에는 비용이 많이 들지만, 일단 설치가 완료되면 계속해서 돈이 들어오는 구조.

3. DNS의 계층 구조

Root DNS 서버
- 전 세계에 13개 루트 서버(A~M) 존재 (각 루트 서버는 여러 대로 구성됨)
- .com, .net, .org, .kr 등 최상위 도메인(TLD) 서버의 정보를 알고 있음
TLD(Top-Level Domain) DNS 서버
- .com, .org, .net, .edu, .kr 등 TLD별로 존재
- 예: .com에 대해 google.com의 네임서버 주소를 알려줌
Authoritative DNS 서버
- 실제 도메인(IP 매핑 정보)을 가지고 있는 서버
- 조직이 직접 보유할 수도 있고, 서비스 제공자를 통해 위임 가능.
- 예: www.google.com의 실제 IP 주소를 응답
Local DNS 서버 (Resolver)
- 사용자의 ISP 또는 기관 내에 존재하는 DNS 서버
- 클라이언트는 일반적으로 이 DNS 서버에 요청을 보냄

루트 서버는 TLD를 알려주고, TLD는 해당 도메인의 권한 있는 서버를 알려주며, 마지막으로 그 서버가 IP 주소를 반환한다.

DHCP와 네트워크 설정

과거에는 IP, 게이트웨이, DNS 서버 주소 등을 수동으로 입력해야 했지만,
현재는 DHCP (Dynamic Host Configuration Protocol)이 자동으로 설정해줌.
기본적으로 설정하는 항목:
- Host IP
- Default Gateway (라우터)
- DNS 서버 주소

4. DNS 질의 과정

클라이언트가 www.example.com에 접속하려고 할 때 DNS 질의 과정은 다음과 같다:

클라이언트 → Local DNS 서버에 www.example.com 요청
Local DNS → Root DNS 서버로 질의
Root DNS → .com TLD DNS 주소 응답
Local DNS → .com TLD 서버에 질의
TLD DNS → example.com의 권한 있는 네임서버 주소 응답
Local DNS → 권한 있는 DNS 서버에 www.example.com 질의
권한 있는 DNS → IP 주소 응답
Local DNS → 클라이언트에게 IP 주소 반환

5. DNS 질의 방식

DNS 질의에는 두 가지 방식이 있다:

5.1 재귀적 질의 (Recursive Query)

클라이언트(호스트)는 Local DNS 서버에 도메인 이름 해석을 위임한다.
Local DNS 서버는 필요한 모든 DNS 서버(Root, TLD, Authoritative)를 순차적으로 질의하여, 최종 IP 주소를 알아낸 뒤 클라이언트에게 최종 응답을 전달한다.
클라이언트 입장에서는 매우 간단하지만, Local DNS 서버 또는 상위 서버에 부하가 커질 수 있음

📌 재귀적 질의 (Recursive Query) 예시 시나리오

클라이언트 호스트: engineering.nyu.edu

요청 대상 도메인: gaia.cs.umass.edu

Local DNS: dns.nyu.edu

클라이언트 호스트가 Local DNS (dns.nyu.edu)에 gaia.cs.umass.edu의 IP 주소 요청
Local DNS가 Root DNS 서버에 재귀적 질의 요청
Root DNS 서버가 TLD DNS 서버에 직접 질의
TLD DNS 서버가 권한 있는 DNS 서버(dns.cs.umass.edu)에 직접 질의
권한 DNS가 gaia.cs.umass.edu의 IP 주소를 응답
TLD DNS → Root DNS → Local DNS로 응답이 역방향 전달됨
Local DNS가 클라이언트에게 최종 IP 주소를 응답

질의를 받은 DNS 서버(Root, TLD)가 그 아래 DNS 서버에 직접 질의함
클라이언트(Local DNS)는 단 한 번만 요청하고 모든 처리를 위임
→ 이것이 재귀적 질의(Recursive Query)

5.2 반복적 질의 (Iterative Query)

클라이언트(또는 Local DNS 서버)가 DNS 서버로부터 다음 서버의 위치만 전달받고, 직접 다음 서버에 질의한다.
각 DNS 서버는 "I don't know this name, but ask this server" 식으로 다음 주소를 안내하는 방식이다.
질의 부담이 각 계층 DNS 서버에 분산되므로, 전체 부하를 줄이고 트래픽을 분산하는 데 유리하다.

📌 반복적 질의 (Iterative Query) 예시 시나리오

클라이언트 호스트: engineering.nyu.edu

요청 대상 도메인: gaia.cs.umass.edu

Local DNS: dns.nyu.edu

클라이언트 호스트가 Local DNS (dns.nyu.edu)에 gaia.cs.umass.edu의 IP 주소 요청
Local DNS가 Root DNS 서버에 질의
Root DNS 서버가 .edu TLD DNS 서버의 IP 주소를 응답
Local DNS가 .edu TLD DNS 서버에 질의
TLD DNS 서버가 cs.umass.edu의 권한 있는 DNS 서버(dns.cs.umass.edu)의 주소를 응답
Local DNS가 dns.cs.umass.edu에 질의
권한 있는 DNS가 gaia.cs.umass.edu의 IP 주소를 응답
Local DNS가 클라이언트에게 최종 IP 주소를 응답

모든 질의는 Local DNS가 직접 각 DNS 서버에 요청함
각 DNS 서버는 "난 몰라, 이 서버에 물어봐" 식으로 다음 단계 서버 주소만 전달
→ 이것이 반복적 질의(Iterative Query)

5.3 비교 요약

항목	Recursive Query	Iterative Query
질의 방식	질의 받은 DNS 서버가 전체 탐색을 대행	DNS 서버는 다음 서버 정보만 전달하고 클라이언트가 질의
클라이언트 역할	단일 요청만 보내면 됨	여러 서버에 직접 질의 필요
서버 부담	Local DNS 서버에 부하 집중	각 계층 DNS 서버로 부하 분산
응답 구조	최종 IP 주소 응답	최종 IP 주소 응답 (과정은 더 분산되어 있음)
일반적 사용 예	클라이언트 ↔ Local DNS 간 사용	Local DNS ↔ Root/TLD/Authoritative 간 사용

→ 일반적으로 클라이언트는 재귀적 질의, DNS 서버끼리는 반복적 질의를 사용한다.

6. DNS 캐싱 (DNS Caching)

이미 질의한 도메인의 IP 주소는 Local DNS 서버나 브라우저 내부에 캐시됨
이후 동일한 요청은 캐시된 정보를 사용하여 빠르게 처리됨
TTL(Time To Live) 값이 만료되면 다시 질의 필요

DNS 캐시는 전체 DNS 트래픽을 줄이고 응답 속도를 높이는 데 매우 중요하다.

7. DNS 레코드 유형 (Resource Records, RR)

DNS는 분산 데이터베이스로, 각 도메인에 대한 정보를 리소스 레코드(Resource Record, RR) 형태로 저장한다.

각 RR은 다음과 같은 형식으로 구성된다: (name, value, type, ttl)

name: 질의된 도메인 이름 (예: www.example.com)
value: 그 이름에 해당하는 값 (예: IP 주소, 별칭, 메일서버 등)
type: 레코드 종류 (A, NS, CNAME, MX 등)
ttl: Time To Live – 캐시 유효 시간 (초 단위)

주요 DNS 레코드 타입

타입	설명
A	호스트 이름을 IPv4 주소에 매핑 (예: www.example.com → 93.184.216.34)
AAAA	호스트 이름을 IPv6 주소에 매핑 (예: www.example.com → 2001:0db8::1)
NS	도메인 이름을 권한 있는 네임서버로 매핑 (예: foo.com → dns.foo.com)
CNAME	별칭 이름을 정식 이름(canonical name)으로 매핑 (예: www.ibm.com → servereast.backup2.ibm.com)
MX	도메인 이름에 연결된 메일 서버 지정 (예: example.com → mail.example.com)
TXT	도메인 관련 텍스트 정보 제공 (예: SPF, 도메인 인증 등)
PTR	IP 주소를 도메인 이름으로 역변환 (Reverse DNS Lookup)
SOA	DNS 영역(zone)의 시작 정보 포함 (관리자 정보, TTL, 시리얼 번호 등)
SRV	특정 서비스를 제공하는 서버의 위치 정보 제공 (예: SIP, XMPP 등)

예: www.ibm.com은 별칭이고,
- 실제 서버는 server-east.backup2.ibm.com → CNAME 레코드에 해당

예시: RR 형식 적용

예를 들어 www.example.com의 IP 주소를 지정하는 A 레코드는 다음과 같다:

(www.example.com, 93.184.216.34, A, 3600)

이 뜻은 www.example.com은 A 타입(IP 주소)이고, 값은 93.184.216.34, TTL은 3600초(1시간)이라는 의미이다.

이러한 레코드들은 DNS 질의 응답에 포함되어, 클라이언트가 필요한 리소스를 찾을 수 있게 도와준다.

8. DNS 응답 메시지 구조

DNS 응답은 다음과 같은 필드들로 구성된다:

헤더(Header): ID, 플래그, 질의 수, 응답 수 등
질의(Query): 요청한 도메인 이름 정보
응답(Answer): 실제 IP 주소 정보
권한(Authority): 권한 있는 DNS 정보
추가 정보(Additional): 캐시 목적의 부가 정보

8. DNS 메시지 구조

DNS의 query(질의)와 reply(응답) 메시지는 동일한 포맷을 사용한다.

헤더 필드 설명

Identification (16비트)
- 클라이언트가 생성한 고유 ID
- 응답 시에도 동일한 ID 사용하여 질의-응답 매칭
Flags (16비트)
- QR: 0이면 query, 1이면 response
- RD (Recursion Desired): 클라이언트가 재귀 질의 요청
- RA (Recursion Available): 서버가 재귀 처리 가능 여부 표시
- AA (Authoritative Answer): 응답이 권한 있는 서버로부터 온 경우 1
# of Questions : 질의 섹션에 포함된 질문 개수
# of Answer RRs : 정답 섹션(Answer Section)에 포함된 리소스 레코드 수
# of Authority RRs : 권한 있는 네임서버 정보가 담긴 레코드 수
# of Additional RRs : 추가적인 도움 정보(ex. IP 주소 등)의 레코드 수

DNS 메시지의 섹션 구성

Questions
- 요청된 도메인 이름과 타입 (예: A, MX 등)
- 하나 이상의 질문 가능
Answers
- 질문에 대한 응답 정보 포함
- 예: IP 주소, CNAME 등
Authority
- 권한 있는 네임서버 정보 포함
Additional
- 추가적인 “도움이 될 수 있는” 정보
- 예: 네임서버의 A 레코드(IP 주소)

9. DNS와 보안

DNS는 원래 설계 당시 보안을 고려하지 않았기 때문에 다양한 공격에 노출되어 있다.

DDoS(분산 서비스 거부) 공격

Root 서버를 향한 공격
- 대량의 쿼리를 루트 DNS 서버에 보내 트래픽 과부하 유도
- 현재까지는 성공적인 사례는 없음
- 대응 방식: 트래픽 필터링, 로컬 DNS 서버 캐싱을 통해 루트 서버 우회 가능
TLD 서버를 향한 공격
- .com, .net, .kr 등의 TLD DNS를 공격
- 루트 서버보다 더 위험할 수 있음 (접속 요청 대부분이 TLD 서버 통과)

스푸핑(Spoofing) 및 캐시 중독(Cache Poisoning)

DNS 쿼리를 가로채서 위조된 응답을 반환
클라이언트가 가짜 IP 주소로 접속하게 함 (피싱 등)
DNS 캐시 중독: 로컬 DNS 서버에 잘못된 매핑을 저장시켜 지속적인 피해 유도

보안 강화: DNSSEC (DNS Security Extensions)

RFC 4033에서 정의됨
리소스 레코드에 디지털 서명을 추가
클라이언트가 응답이 위조되지 않았음을 검증 가능
위조 방지 + 데이터 무결성 보장
아직 전 세계 모든 도메인이 DNSSEC을 사용하고 있진 않음

DNS는 인터넷의 필수 인프라이지만, 보안 취약점이 존재하므로 DNSSEC과 같은 대응 기술이 점차 중요해지고 있다.

10. 도메인 등록과 상업화

도메인 이름과 IP 주소는 유한한 자원

ICANN (Internet Corporation for Assigned Names and Numbers): 도메인 이름과 번호를 관리
- 미국 상무부 산하 조직
- 교수님 표현: "이건 돈이 되는 구조다. Limited Resource."
예시: 삼성에서 samsung.com 도메인을 등록하면,
- 연간 300달러를 지불하며 등록 유지
- 이 도메인은 사이버 세계에서의 "영토"

새로운 TLD의 생성과 비즈니스 모델

ICANN 회의에서는 새로운 TLD (.museum, .tv 등)를 생성해 비즈니스 기회를 확장
규제 정책도 함께 논의됨
- 예: 특정 국가(중국 등)에서는 .edu, .com 접근을 차단하여 인터넷 접근을 제한하기도 함

DNS 기록 등록 예시

벤처 회사 networkutopia.com을 만들면 다음 과정을 수행:
1. DNS 등록 기관(registrar)을 통해 도메인 등록
2. .com TLD 서버에 NS 레코드와 A 레코드 등록
3. 예:
  - NS: networkutopia.com → DNS1.networkutopia.com
  - A: DNS1.networkutopia.com → 212.212.212.1
추가적으로:
- MX 레코드: networkutopia.com의 메일 서버 설정

11. 정리

DNS는 도메인 이름을 IP 주소로 변환하는 애플리케이션 계층의 분산 데이터베이스 시스템이다.
루트 → TLD → 권한 있는 DNS로 이어지는 계층 구조를 가진다.
재귀 질의와 반복 질의를 통해 IP 주소를 탐색하며, 캐시를 활용하여 효율을 높인다.
다양한 레코드 유형이 있으며, 보안 취약점을 방지하기 위한 기술도 발전하고 있다.
DNS는 인터넷의 핵심 기능이지만, 복잡한 처리는 네트워크의 가장자리(edge)에서 수행되는 구조를 따른다.

'CS 지식 > 네트워크' 카테고리의 다른 글

[네트워크] 비디오 스트리밍 원리와 DASH, P2P, CDN 소개 (0)	2025.04.10
[네트워크] 이메일 시스템과 프로토콜(SMTP, IMAP, POP, HTTP) (1)	2025.04.04
[네트워크] 웹 캐시와 HTTP framing (1)	2025.04.04
[네트워크] 전송계층과 HTTP와 쿠키(Cookie) (1)	2025.04.01
[네트워크] 응용계층과 프로토콜, P2P, 클라이언트-서버 아키텍처 (0)	2025.04.01

[네트워크] DNS(Domain Name System)와 메세지 포맷, 보안