📡 [Network] 어플리케이션층 - DNS 도메인 네임 시스템 (DNS의 구성, 반복쿼리, 재귀쿼리, DNS 캐싱, DNS 레코드)

본 포스팅은 < 컴퓨터 네트워킹 하향식 접근[8판] James F. Kurose, Keith W. Ross 저/최종원, 강현국, 김기태 > 을 참고하여 작성되었습니다.

Ch02 Application Layer

4. DNS : The Internet’s Directory Service

DNS : 도메인 네임 시스템

• 분산 데이터베이스
• 호스트 네임 (e.g. www.naver.com)을 IP 주소(e.g. 121.32.34.9)로 변환

DNS의 동작

어떤 호스트가 HTTP request 메시지를 웹 서버 www.naver.com/index.html 로 보내려 할 때

➡️ naver 웹 서버 호스트의 IP가 필요

1. 
호스트는 DNS application의 client를 실행

2. 
브라우저는 URL로부터 호스트 이름 [www.naver.com](http://www.naver.com/) 추출하고
그 이름을 DNS application client 로 전달

3. 
DNS client는 DNS server로 호스트 이름을 담은 질의를 송신

4. 
DNS client는 DNS server로부터 호스트 이름에 대한 IP 주소 응답 수신

5. 
브라우저가 DNS로부터 IP 주소를 받으면 브라우저는 해당 IP 주소와 
그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결 초기화

• 원하는 IP 주소는 가까운 DNS server에 캐싱되어 있음

DNS가 제공하는 서비스

DNS는 아래와 같은 서비스를 제공한다.

• 호스트이름을 IP 주소로 변환
• 호스트 에일리어싱(host aliasing)
  • 복잡한 호스트 이름을 가진 호스트는 하나 이상의 별명을 가질 수 있다.
  • 여러개의 도메인을 가질 수 있음
  • 정식 호스트 이름을 canonial hostname이라고 함
• 메일 서버 에일리어싱 (mail server aliasing)
  • 메일서버와 웹서버 모두 같은 호스트 이름을 갖는 것을 허용 (ex. google.com)
• 부하 분산
  • DNS는 중복 웹서버와 같은 여러 중복 서버 사이에 부하를 분산하기 위해 사용
  • 하나의 호스트 이름으로 여러 IP 주소에 상응될 수 있다

🤔 그냥 hostname으로 라우팅하면 안되는가?

• 불가능하다 → 모든 호스트네임에 대한 라우팅이 필요함
• 계층화 되어있지 않으므로 수십억개의 라우팅테이블 필요할 것

DNS의 분산, 계층화 데이터베이스

확장성 문제를 다루기 위해 DNS는 많은 서버를 이용하고 이들을 계층형태로 구성하며 전 세계로 분산시킨다.

위 그림 처럼 계층으로 구성된 세 유형의 DNS 서버가 존재한다.

• 루트 DNS 서버
  • 전세계적으로 1000개 이상, 이들은 13개의 root 서버의 사본
  • 12개의 기관에서 관리
  • TLD 서버의 IP 주소들을 제공
• TLD (Top-Level Domain) 최상위 레벨 도메인 서버
  • com, org, net, edu, gov, kr, uk, fr 와 같은 상위 레벨 도메인
  • 책임 DNS 서버에 대한 IP 주소를 제공
• Authoritative 책임 DNS 서버
  • 인터넷에 접근하기 쉬운 호스트 (웹 서버, 메일 서버 등)를 가진 기관은 공개적인 DNS 레코드를 제공
  • 기관의 DNS 서버는 DNS 레코드를 가지고 있음

• Local 로컬 DNS 네임 서버
  • DNS 계층에 속하지 않으며, 대신 IP 주소를 제공하거나 질의
  • 웹 캐시와 비슷한 역할을 한다

Iterated 반복 쿼리와 Recursive 재귀 쿼리

1. 호스트는 로컬 DNS 서버에서 쿼리를 보낸다
2. 로컬 DNS는 Root DNS에게 쿼리를 보낸다.
3. 이는 .edu 를 인식하고 해당하는 TLD서버 주소를 로컬 DNS 서버로 다시 보내준다
4. 로컬 DNS는 다시 해당하는 TLD 서버로 쿼리를 보낸다
5. 이는 umass.edu를 인식하고 해당하는 책임DNS 서버의 IP 주소를 로컬 DNS로 보내준다
6. 로컬 DNS 다시 해당하는 책임 DNS 서버로 쿼리를 보낸다
7. 책임 DNS 서버에서 해당 호스트 네임인 gaia.cs.umass.edu 의 IP 주소로 응답한다.
8. 로컬 DNS는 이 주소를 요청 호스트에게 응답해준다

• 총 4번의 질의, 4번의 응답으로 DNS 메세지가 보내졌다.
• 반복적 쿼리(iterated)와 재귀적 (recursive) 방법이 혼용되었다
  • 요청하는 호스트로부터 로컬 DNS 서버는 재귀적 쿼리
  • 나머지 부분은 반복적 쿼리
• 일반적인 쿼리는 위 방법을 따른다

• 모든 질의가 재귀적인 DNS 쿼리 사슬의 모습이다
• 마찬가지로 4번의 질의, 4번의 응답으로 DNS 메세지가 보내졌다

DNS 캐싱

DNS는 서버로부터 응답을 받을 때 마다 응답에 포함된 정보를 저장할 수 있다.

만약 다른 호스트로 부터 같은 쿼리가 도착한다면 DNS 서버는 자신의 책임이 아니더라도 원하는 IP주소를 제공해 줄 수 있다.

DNS 레코드

DNS 서버들은 호스트 이름을 IP 주소로 맵핑하기 위해 자원 레코드(resource record, RR)를 저장한다.

자원레코드는 아래와 같은 필드를 포함하는 4개의 튜플로 구성된다

➡️ (Name, Value, Type, TTL)

(TTL은 레코드가 캐시에서 제거되는 시간은 결정하는 생존 기간)

Name과 Value의 의미는 Type에 따라 다르다.

• type = A (address mapping)
  • Name : 호스트 네임
  • Value : 호스트 네임에 대한 IP주소
• type = NS (name server)
  • Name : 도메인 (e.g. foo.com)
  • Value : 도메인 내부의 호스트에 대한 IP주소를 아는 책임 DNS 서버의 호스트 이름
• type = CNAME (canonical name)
  • Name : 별칭 alias 호스트 네임
  • Value : 별칭 alias 호스트 네임에 대한 정식 canonial 호스트 이름
• type = MX (mail exchanger)
  • Value : alias 호스트 네임을 갖는 메일 서버의 canonial 이름

DNS 프로토콜 메세지 형식

• 쿼리와 응답이 모두 같은 형식의 메세지를 보낸다

DNS DB에 레코드 삽입

지금까지 DNS 데이터 베이스에서 정보를 어떻게 추출해내는지를 알아봤다면 이번엔 정보를 어떻게 넣는지 알아보도록 한다.

먼저 당신이 네트워크 유토피아 라는 새로운 스타트업을 세웠다고 가정한다. 가장 먼저 해야할 일은 도메인 네임을 등록기관에 등록하는 것이다. (등록 기관 register은 도메인 네임의 유효성을 확인하고, 그 도메인 이름을 DNS 데이터 베이스에 넣고 서비스에 대한 요금을 받는 상업기관이다.)

• 주서버와 부서버의 이름, IP주소가 필요하다
• 책임 서버별로 NS, A 레코드가 TLD 서버에 등록되도록 함

• 해당 IP주소로 책임 서버를 만든다