Computer Network #02-2. Application Layer : DNS

1. DNS 개요

사람은 여러 식별자를 사용 (ex. 주민 등록 번호, 여권 번호)

인터넷도 마찬가지로 호스트(host)와 라우터(router)에 식별자 필요함

• IP address : 네트워크 상 데이터그램 전송에 사용
  (ex: 192.168.1.1)
• domain name : 사람이 이해하기 쉬운 식별자
  (ex: cs.umass.edu)

Domain Name System (DNS) 역할

IP 주소 ↔ 이름 매핑(mapping)을 해결하기 위한 시스템
(DNS는 관리 차원에서 분산 저장)

• Distributed database (분산 데이터베이스) 구조
  수많은 Name server들이 계층 구조를 이룸
• Application-layer protocol로 동작
  Name server끼리 이름 해석(name resolution)을 위해 통신

2. DNS의 기능과 구조

DNS 기능(역할)

• 호스트 이름 → IP 주소 변환
• Host Aliasing (호스트 별칭 지원)
  (ex. naver.com은 실제 다른 서버 주소를 가짐)
• Load Distribution (부하 분산)
  하나의 도메인 이름에 여러 IP 주소를 연결
  (ex. www.naver.com이 여러 서버에 분산되어 연결됨)

DNS 구조

DNS를 하나의 중앙 집중형 DNS로 만들지 않는 이유

• 하나 고장나면 전체 시스템 다운
• 트래픽 폭증 : 전 세계 요청 한 곳에서 처리 힘듦
• 거리 문제 : 물리적 거리로 인해 응답 속도 느림
• 유지 보수 어려움 : 규모 커서 관리 불가능

3. DNS 계층 구조

• Root DNS Servers
  최상위 서버, 전체 구조의 루트
• Top-Level Domain (TLD) Servers
  .com, .org, .edu 같은 최상위 도메인 담당
• Authoritative DNS Servers
  실제 도메인 (ex: amazon.com) 정보를 가지고 있는 서버

Example. 'www.amazon.com'의 IP 주소를 찾을 때

1) 클라이언트가 Root Server에 문의
Root DNS Server에게 물어보면, .com DNS 서버를 알려줌

2) 클라이언트가 .com 서버에 문의
'.com' DNS 서버에 물어보면, amazon.com DNS 서버를 알려줌

3) 클라이언트가 amazon.com 서버에 문의
'amazon.com DNS 서버'에 최종적으로 물어봐서
www.amazon.com의 실제 IP 주소를 얻음

---

Root Name Servers

다른 네임 서버가 이름을 해결할 수 없을 때, 최종적으로 문의하는 서버

Root 서버 없으면 인터넷 이름 해석 자체가 불가능
(매우 중요한 역할을 함)

• 전 세계에 13개 존재
  (복제본이 수백개 배치되어있는 상황)

---

Top-Level Domain (TLD) servers

TLD 서버는 최상위 도메인(top-level domain)을 담당

• 일반 도메인: .com, .org, .net, .edu, .aero, .jobs
• 국가 도메인: .cn(중국), .uk(영국), .fr(프랑스), .ca(캐나다), .jp(일본), .kr(한국)

---

Authoritative DNS servers

어떠한 조직이 소유하거나, 서비스 제공자가 운영하여
최종 IP Address 매핑 정보를 제공하는 DNS 서버
(서비스 업체가 직접 관리할 수 있음)

• 특정 도메인에 대한 정확한 IP Address 제공
  (ex. amazon.com에 대해 실제 IP를 알고 있는 서버)

---

Local DNS servers

DNS 계층(hierarchy)에 직접 속하지는 않고, ISP(인터넷 제공자), 회사, 학교 등에서 운영
(Root → TLD → Authoritative 구조 안에 없고 별도로 존재)

Local DNS 서버의 역할

• 호스트의 DNS 질의는 Local DNS 서버에 먼저 전송됨
• Local DNS가 캐시를 확인
  (Name-IP 매핑 결과를 저장해놓고, 있으면 바로 응답)
  (없으면, 상위 DNS에 다시 질의)
• 프록시(proxy)처럼 동작
  (요청을 대신 받아서 위쪽 DNS 시스템(hierarchy)으로 전달)

4. DNS 질의 방식

Iterated Query (반복 질의)

문의받은 서버가 "나는 몰라, 대신 이 서버에 물어봐!" 하고 다른 서버를 알려줌

Local DNS 서버가 직접 다음 서버에게 물어보는 방식
(여러 번 물어보기에, 시간이 더 걸릴 수 있음)

1) Host → Local DNS 서버(dns.nyu.edu)에 질의 보냄

2) Local DNS 서버 → Root DNS 서버에 질의
"몰라, .edu TLD 서버에 물어봐"

3) Local DNS 서버 → .edu TLD 서버에 질의
"몰라, umass.edu DNS 서버에 물어봐"

4) Local DNS 서버 → umass.edu DNS 서버에 질의
"몰라, cs.umass.edu DNS 서버에 물어봐"

5) Local DNS 서버 → cs.umass.edu 권한 서버에 최종 질의

6) cs.umass.edu 서버가 최종적으로gaia.cs.umass.edu의 IP 주소를 반환

7) Local DNS 서버가 이 결과를 캐시에 저장

8) Host에게 IP 주소를 반환

Recursive Query (재귀 질의)

요청을 받은 서버가 직접 최종 IP 주소를 찾아서 요청자에게 답을 줌

요청자는(Local DNS 서버) 한 번만 요청하고 기다림
(요청받은 서버가 전체 해석을 책임짐)

• 상위 서버들(Root, TLD)에는 부하가 심해질 수 있음

1) Host → Local DNS 서버(dns.nyu.edu)에게 요청

2) Local DNS 서버가 Root 서버에게 요청

3) Root 서버가 .edu TLD 서버에게 요청

4) TLD 서버가 umass.edu 서버에게 요청

5) umass.edu 서버가 cs.umass.edu 권한 서버에게 요청

6) cs.umass.edu 서버가 최종적으로 gaia.cs.umass.edu의 IP 주소를 응답

7) 결과를 거슬러 올라와서 Local DNS 서버까지 전달

8) Local DNS 서버가 Host에게 최종 IP 주소를 응답

5. DNS Caching(캐싱) 및 Updating(갱신)

DNS Caching

네임 서버가 Name-IP Address 매핑을 알게 되면,
캐시(cache)에 저장해놓고 재사용함

저장된 캐시는 일정 시간이 지나면 자동 삭제(timeout) 됨

TTL (Time To Live)

캐시가 유효한 시간을 나타내며, 일정 시간 지나면 무효화됨

TLD 서버 정보는 보통 Local DNS 서버에 저장돼서 Root 서버를 자주 방문할 필요가 없음

• out-of-date
  모든 TTL이 만료되어야 최신 정보로 갱신 가능
  (서버 IP가 변경됐어도 TTL이 남아있다면, 변경 사실 전파 X)

DNS 업데이트/알림 메커니즘

RFC 2136 : DNS 기록 변경 시 서버 간 알림 기능을 표준화
(하지만 기본적으로는 여전히 TTL 중심으로 동작)

6. DNS Records

특정 이름(name)과 그에 대응되는 정보(value)를 저장한 데이터 조각

DNS 레코드는 (name, value, type, ttl) 형태로 저장되며,
여러 종류의 타입(A, NS, CNAME, MX)이 있음

RR format (name, value, type, TTL)

A

• name: hostname
• value: IP 주소

NS

• name: 도메인 이름(e.g., foo.com)
• value: 이 도메인 담당하는 authoritative 서버의 호스트네임

CNAME

• name: 별칭(alias) 이름
• value: 정식(canonical) 이름

MX

• name: 도메인 이름
• value: 메일 서버 이름(mailserver)

7. DNS 메시지 포맷

DNS 메시지는 query (질문), reply (응답)으로 나뉨
(query와 reply 메시지는 같은 포맷을 사용)

메시지 헤더 (Message Header)

Identification

클라이언트는 응답이 어떤 요청에 대한 것인지 알 수 있음
(요청과 응답을 매칭하는 ID 역할)

• 16비트 숫자
• 클라이언트가 질의할 때 ID 부여하고, 서버는 이 ID를 그대로 복사해서 응답에 사용

Flags

여러 가지 세부 정보 들어 있음

• query/reply : 메시지가 질문인지(1) 답변인지(0)
• recursion desired : 클라이언트가 서버에 재귀적 질의를 요청했는지 여부
• recursion available : 서버가 재귀적 질의를 지원하는지 여부
• reply is authoritative : 응답이 권한 있는 서버에서 온 것인지 여부

4개 영역 본문 구성

Questions

질의하고자 하는 이름(name)과 타입(type) 정보

Answers

질의에 대한 실제 응답 RR들 (답변 레코드)

Authority

권한 있는 네임 서버에 대한 정보 제공

Additional

추가적인 유용한 데이터 포함

8. DNS 등록 및 보안

DNS 등록

새로 생긴 회사(ex. Network Utopia)가 DNS 시스템 안에 자기 도메인 정보를 등록하는 과정

1) 도메인 이름 등록
DNS 등록 기관을 이용
(ex. networkuptopia.com)

2) 서버 정보 제공
Primary, Secondary 네임 서버 이름과 IP 주소 제출
(ex. dns1.networkuptopia.com, 212.212.212.1)

3) 등록기관이 TLD 서버에 기록
등록기관이 NS 레코드, A 레코드를 TLD 서버에 삽입

4) 권한 있는 DNS 서버 구축

DNS 보안

DNS를 노리고 공격하는 경우가 존재

DDoS (Distributed Denial of Service) 공격

• 루트 서버 폭격 (Root Servers Bombardment)
  대량 트래픽으로 루트 서버 마비 시키기
  (현재까지 성공한 적 없음)
• TLD 서버 폭격 (TLD Servers Bombardment)
  루트 서버보다 더 위험할 수 있음
  (TLD 서버가 직접 도메인 정보를 관리하기 때문)

Redirect 공격

• Man-in-the-middle (MITM) 공격
  사용자의 DNS 질의를 가로채서 중간에서 위조된 정보를 응답
• DNS Poisoning (DNS 캐시 오염)
  가짜 응답을 DNS 서버에 보내 캐시에 저장시키기
  사용자들이 잘못된 IP로 연결되게 함

---

방어 방법 : DNSSEC (DNS Security Extensions)

DNS 응답에 디지털 서명 추가하여, 데이터가 위조되지 않았음을 확인할 수 있게 해줌
(RFC 4033)