DNS

2023. 10. 19. 17:53

2.4 DNS: 인터넷의 디렉터리 서비스

우리가 흔히 쓰는 www.naver.com 에서 www는 호스트 네임(hostname) 이름, naver는 도메인 네임 com 은 탑레벨 도메인 이다.

 

하지만 라우터는 www.naver.com 과 같은 문자보단 IP주소로 특정 호스트를 식별한다.

즉 우리가 호스트 네임을 통해 특정 서버로 요청을 보낼때 해당 이름에 해당하는 IP주소를 들고 있는 분산 데이터 베이스 이다.

 

DNS(domain name system) 는 애플리케이션 계층 프로토콜이며, 분산 및 계층 구조로 되어있다. 하나의 서버에 모든 데이터를 담고있다면 여러 문제가 발생할수 있고 트래픽이 한곳으로 집중될수 있기 때문에 DNS는 분산 데이터베이스 구조로 되어있다. 또한 DNS 는 UDP 프로토콜 상에서 수행되며, 포트번호 53을 사용한다.

 

❗️DNS 는 어떻게 보면 통신을 하기위한 준비과정이다(즉 최대한 빠르게 데이터를 얻어오는게 중요하다). 또한 DNS 를 통해 IP 주소를 가져올때 오가는 데이터의 양은 매우작으며, 이는 손실이되더라도 충분히 재요청을 할수있는 정도이다. 즉 TCP가 신뢰있는 통신을 보장한다지만, TCP 를 사용하는것 만으로도 3-way-handShake 등 배보다 배꼽이 더 큰 상황이 올수 있기 때문에, UDP 프로토콜을 사용한다.

 

 

 

2.4.2 DNS 구성 및 동작 과정

KakaoTalk_Photo_2023-10-18-20-39-49

앞서 말했듯 DNS 는 분산 및 계층 구조로 되어있다. 위 그림처럼 루트 DNS 서버 , 최상위 레벨 도메인 네임 DNS 서버 (TLD, top-level domain), 책임 DNS 서버 로 구성되어있다.

 

루트 DNS 서버 : TLD 서버의 IP 주소들을 제공한다.

TLD 서버: com, org, net, edu 와 같은 상위 레벨 도메인과 kr, uk, fr 등과 같은 모든 국가의 상위 레벨 도메인에 대한 서버이다. 책임 DNS 서버에 대한 IP 주소를 제공한다.

책임(authoritative) DNS 서버: 호스트 이름을 IP 주소로 매핑하는 공개적인 DNS 레코드를 갖고 있다.

로컬 DNS 서버: 대학이나 주거지역 ISP들이 갖는 DNS 서버이다.

  • 호스트가 ISP 에 연결될때 그 ISP는 로컬 DNS 서버로부터 IP주소를 호스트에게 제공한다.
  • 로컬 DNS 서버는 캐싱 기능을 하며, 따라서 특정 호스트 네임에 대한 IP 주소를 저장하여, 추후 올수있는 같은 요청에 대해 더 빠르게 응답할수 있도록 한다. (IP 주소는 유동적이기 때문에 네임에 대한 IP 주소를 저장시 TTL(Time to live) 컬럼을 두어 특정 기간이 지나면 소멸되게 한다.)

 

 

 

KakaoTalk_Photo_2023-10-18-21-02-28

위 사진을 통해 특정 호스트로 메세지를 보내고싶을때, 수신 호스트에대한 IP 주소를 DNS 서버를 통해 얻는 과정을 살펴보겠다.

  1. 로컬 DNS 서버 요청: 사용자의 기기는 먼저 로컬 DNS 서버에 웹사이트의 IP 주소를 요청한다.
    • 로컬 DNS 서버에 해당 웹사이트의 IP 주소가 캐싱되어 있다면, 이 주소를 사용자의 기기에게 바로 반환한다. (이 예에서는 해당 정보가 로컬 DNS 서버에 없다고 가정한다).
  2. 루트 DNS 서버 요청: 로컬 DNS 서버는 루트 DNS 서버에 웹사이트의 IP 주소를 요청한다. 루트 DNS 서버는 웹사이트의 IP 주소를 알고 있지 않지만, 해당 도메인의 Top Level Domain (TLD, 예: .com, .org)을 관리하는 TLD 서버의 IP 주소를 로컬 DNS 서버에게 알려준다.
  3. TLD 서버 요청: 이후 로컬 DNS 서버는 TLD 서버에게 웹사이트의 IP 주소를 요청한다. TLD 서버는 해당 도메인을 관리하는 권한있는 (Authoritative) DNS 서버의 IP 주소를 로컬 DNS 서버에게 반환한다.
  4. 권한있는 DNS 서버 요청: 로컬 DNS 서버는 마지막으로 권한있는 DNS 서버에 웹사이트의 IP 주소를 요청한다. 권한있는 DNS 서버는 웹사이트의 실제 IP 주소를 로컬 DNS 서버에게 제공하고, 로컬 DNS 서버는 이 IP 주소를 사용자의 기기에게 반환한다.

 

❗️일반적으로 TLD 서버가 책임 DNS 서버에 대한 주소를 알지 못한다. 대신 TLD 서버는 호스트 이름에 대한 책임 DNS 서버를 아는 중간 DNS 서버를 알고 있으며, 이러한 중간 DNS 서버를 거쳐 최종적으로 책임 DNS 서버의 IP 주소를 얻게 된다.

 

 

 

2.4.3 DNS 레코드와 메시지

DNS 서버는 호스트 이름을 IP 주소로 매핑하기 위한 레코드를 저장한다.

 

레코드의 형태는 다음과 같다. (Name, value, Type, TTL)

TTL 은 위에서 말한 Time to Live 이며, 여기서 핵심은 Type 이다. 어떤 타입인지에 따라 name 과 value 에 저장하는 값들이 다르다.

 

Type 에는 4가지 종류 A Type, NS Type, CNAME Type, MX Type 이있다. 지금은 A, NS 타입에 대해서만 알아보겠다.

 

A타입

  • Name : 호스트이름
  • Value: 호스트 이름에 대한 IP 주소

NS타입

  • Name: 도메인
  • Value: 도메인 내부의 호스트에 대한 IP 주소를 얻을 수 있는 방법을 아는 책임 DNS 서버

 

KakaoTalk_Photo_2023-10-18-21-02-28

이사진을 기반으로 각 서버가 어떤 형태로 레코드를 저장하고 있는지 알아보자. 이때 TLD DNS 의 도메인명은 dns.edu, IP 주소는 2.2.2.2 로가정한다. (편의상 TTL 은 쓰지않았다)

 

루트 DNS 서버

name value Type
.edu dns.edu NS
dns.edu 2.2.2.2 A

NS 와 A 타입 데이터는 항상 같이 다닌다. 즉 위 레코드는 .edu 를 처리할수 있는 서버의 도메인명은 dns.edu 라는 것을 알려주며, A 타입 레코드를 통해 dns.edu 서버의 IP 주소를 알려준다.

 

로컬 DNS 서버는 위와 같은 데이터를 통해 TLD DNS 서버(2.2.2.2) 에 요청을 하면 TLD 서버는 위와 같은 레코드를 통해 IP 주소를 응답으로 준다.

 

이때 책임 DNS 서버는 NS 타입 레코드를 저장하지 않는데, 그이유는 책임서버에 결국 요청 호스트가 원하는 IP 주소가 있기 때문이다. NS 레코드 라는것 자체가 우리가 원하는 도메인을 찾으려면 어떤 도메인으로 요청을 하면 될까? 에대한 레코드 이기때문에 최종적인 책임 DNS 서버에는 NS 레코드가 없는 것이다.

 

ChatGpt 한테 그렇다면 TLD 서버는 항상 책임서버에 대한 IP주소를 가지고 있냐 물어보니 다음과 같이 대답했다.

 

답변: 루트 DNS 서버는 일반적으로 TLD DNS 서버에 대한 A 레코드를 저장하지 않습니다.

대신 NS 레코드로 해당 TLD를 처리할 수 있는 TLD 서버의 이름을 알려줍니다.

로컬 DNS 서버가 초기 DNS 쿼리를 시작할 때, 기본적으로 루트 서버의 IP 주소는 이미 알고 있습니다.

루트 서버에서는 요청받은 도메인 이름에 대한 적절한 TLD 서버의 NS 레코드를 반환합니다.

그럼 로컬 DNS는 어떻게 해당 TLD 서버의 IP 주소를 알게 될까요?

로컬 DNS 서버는 일반적으로 "root hints"라고 하는 파일을 가지고 있습니다.

이 파일은 모든 루트 DNS 서버와 주요 TLD 서버의 IP 주소를 포함하고 있습니다.

이 정보를 사용하여 로컬 DNS 서버는 TLD 서버에 직접 쿼리를 보낼 수 있습니다.

즉, 루트 DNS 서버는 TLD 서버의 IP 주소를 직접 제공하지 않습니다.

대신, 로컬 DNS 서버가 루트 힌트나 이전에 캐싱된 정보를 사용하여 해당 TLD 서버의 IP 주소를 알아낼 수 있게 됩니다.

 

현실에선 우리가 이론적으로 배운 내용과 100% 같게 돌아가진 않는것 같다.

 

결론적으로 만약 우리가 어떤 네트워크를 만들고, 책임서버를 만들었다면 우리가 해야할일은 TLD 서버에 우리의 책임서버 네임과 IP 를 등록하여 다른사람들로 하여금 접속할수 있게 만들면 된다.!

'네트워크' 카테고리의 다른 글

RDT(Reliable Data Transfer)  (1) 2023.11.21
Multiplexing, deMultiplexing  (0) 2023.10.25
소켓  (0) 2023.10.23
HTTP1/HTTP2/HTTP3  (0) 2023.10.19
HTTP) TCP 및 3-way handshake  (1) 2023.05.09

+ Recent posts