[네트워크] DNS란?

 

서론

원래 인터넷상의 모든 컴퓨터는 숫자를 사용하여 서로를 찾고 통신합니다. 이러한 숫자를 IP 주소라고 하는데, 우리는 인터넷 사이트에 접속할 때  IP주소보다는 www.naver.com과 같은 네이밍 주소로 접근합니다. 이렇게 도메인 이름을 입력해도 원하는 웹 사이트로 갈 수 있는데 어떤 원리로 가능한 것일까요?

이번 게시글에서는 이러한 DNS(domain name system)에 대해 정리해 보겠습니다.

목차
1. DNS 동작 원리
2. 분산 계층 데이터베이스
3. DNS 캐싱

 

DNS 동작 원리

사용자의 호스트에서 실행되는 어떤 애플리케이션(웹 브라우저나 메일 리더)이 호스트 네임을 IP 주소로 변환시키려 한다고 가정해봅시다. 그 애플리케이션은 변환될 호스트 네임을 명시하여 DNS 측의 클라이언트를 호출할 것입니다. 그리고 사용자 호스트의 DNS는 네트워크에 질의 메시지를 보냅니다. 모든 DNS 질의와 응답 메시지는 포트 53의 UDP 데이터그램으로 보내집니다. 수 msec에서 수 sec의 지연 후에 사용자 호스트의 DNS는 요청한 매핑(mapping)에 해당하는 DNS 응답 메시지를 받습니다. 이제 이 매핑은 호출한 애플리케이션으로 전달됩니다. 

DNS의 간단한 설계로 모든 매핑을 포함하는 하나의 인터넷 네임 서버를 생각할 수 있습니다. 이러한 중앙 집중 방식에서, 클라이언트는 모든 질의를 단일 네임 서버로 보내고, DNS 서버는 질의 클라이언트에게 직접 응답합니다. 이 방식은 간단하지만 수많은 호스트를 가진 오늘날의 인터넷에는 적합하지 않습니다. 이러한 방식의 문제점으로는 아래와 같은 것들이 있습니다.

• 서버의 고장: 만약 네임 서버가 고장난다면, 전체 인터넷이 작동하지 않는다.
• 트래픽 양: 단일 DNS 서버가 모든 DNS 질의를 처리해야 한다.
• 중앙 집중 데이터베이스와 멀리 떨어짐: 만일 단일 서버가 뉴욕에 있다면, 한국으로부터 모든 질의는 느리고 혼잡한 링크를 거치기 때문에, 심각한 지연을 일으킬 수 있다.
• 유지관리: 단일 네임 서버는 모든 인터넷 호스트에 대한 레코드를 유지해야 하기에, 데이터베이스가 거대해지고 새로운 호스트를 반영하기 위해 자주 갱신해야 한다.

요악하면, 단일 DNS 서버에 있는 중앙 집중 데이터베이스는 확장성이 전혀 없습니다. 결과적으로 현재의 DNS는 분산되도록 설계되었고 따라서 아래의 분산된 DNS 동작 원리를 이해하는 게 더 중요합니다.

 

분산 계층 데이터베이스

확장성 문제를 다루기 위해 DNS는 많은 서버를 이용하고 이들을 계층 형태로 구성하며 전 세계에 분산시킵니다. 어떠한 단일 DNS 서버도 인터넷에 있는 모든 호스트에 대한 매핑을 갖지 않는 대신에 그것은 DNS 서버 사이에 분산됩니다. 대체로 아래의 그림처럼 계층으로 구성된 됩니다.

DNS 서버 계층구조의 일부

위 이미지는 세 유형의 DNS 서버로 구성되는데 그 세가지는 아래와 같습니다.

1. 루트(root) DNS 서버
2. 최상위 레벨 도메인(TLD, top-level domain) DNS 서버
3. 책임(authoritative) DNS 서버

이 세 부류들의 서버들이 어떻게 상호 작용을 하는지를 알기 위해서 어떤 DNS 클라이언트가 호스트 네임 www.amazon.com의 IP 주소를 얻기 원한다고 가정합시다. 

1. 먼저 이 클라이언트는 루트 서버 중 하나에 접속합니다.
2. 루트 서버는 최상위 레벨 도메인 com을 갖는 TLD 서버 IP 주소를 보냅니다. 
3. 그다음 클라이언트는 이 TLD 서버 중 하나에 접속하고, 서버는 도메인 amazon.com을 가진 책임 서버의 IP 주소를 보냅니다.
4. 클라이언트는 amazon.com의 책임 서버 중에서 하나로 접속합니다.
5. 서버는 호스트 네임 www.amazon.com의 IP주소를 보냅니다. 

루트, TLD, 책임 DNS 서버들은 이전의 그림처럼 모두 DNS들의 계층구조를 갖습니다. 추가적으로 DNS의 다른 중요한 형태는 로컬 DNS 서버입니다. 로컬 DNS 서버는 서버들의 계층 구조에 엄격하게 속하지는 않지만, DNS 구조의 중심에 있습니다. ISP들은 로컬 DNS 서버로부터 IP 주소를 호스트에게 제공합니다.

간단한 예를 살펴봅시다.

• 호스트 cse.nyu.edu가 gaia.cs.umass.deu의 IP주소를 얻기 원한다고 가정합시다.
• 또한 cse.nyu.edu에 대한 NYU의 로컬 DNS 서버가 dns.nyu.edu이고, gaia.cs.umass.edu에 대한 책임 DNS 서버는 dns.umass.edu라고 가정합시다.

다양한 DNS 서버들의 상호작용

위 그림을 한번 살펴봅시다.

1. cse.nyu.edu가 먼저 자신의 로컬 DNS 서버 dns.nyu.edu에게 DNS 질의 메시지를 보냅니다.
2. 질의에는 변환되어야 하는 호스트 네임, 즉 gaia.cs.umass.edu가 포함됩니다.
3. 로컬 DNS 서버는 edu를 인식하고, edu에 대한 책임을 가진 TLD 서버의 IP 주소 리스트를 로컬 DNS 서버에게 보냅니다.
4. 로컬 DNS 서버는 질의 메시지를 TLD 서버로 보냅니다.
5. 그다음 TLD 서버는 umass.edu를 인식하고 dns.umass.edu로 이름 지어진 책임 DNS 서버의 IP 주소를 응답합니다.
6. 마지막으로 로컬 DNS 서버는 직접 dns.umass.edu로 질의 메시지를 다시 보내고, gaia.cs.umass.edu의 IP 주소로 응답합니다.

이 예에서 하나의 호스트 네임 매핑을 얻기 위해 질의 메시지 네 번과 응답 메시지 네 번, 총 8번 DNS 메시지가 보내졌음에 주목해야 합니다. 

 

DNS 캐싱

지금 까지의 정리에서 DNS의 중요한 특성인 DNS 캐싱(caching)은 다루지 않았습니다. 실제로 DNS는 지연 성능 향상과 네트워크의 DNS 메시지 수를 줄이기 위해 캐싱을 사용합니다. DNS 캐싱의 아이디어는 매우 간단합니다. 질의 사슬에서 DNS 서버가 DNS 응답을 받았을 때 그것은 로컬 메모리에 응답에 대한 정보를 저장할 수 있습니다. 예를 들어 이전의 그림에서 로컬 DNS 서버 dns.nyu.edu는 임의의 DNS 서버로부터 응답을 받을 때마다 응답에 포함된 정보를 저장할 수 있습니다. 만약 호스트 네임과 IP 주소 쌍이 DNS 서버에 저장되고 다른 호스트 네임으로부터 같은 질의가 DNS 서버로 도착한다면, DNS 서버는 호스트 네임에 대한 책임이 없을 때조차 원하는 IP 주소를 제공할 수 있습니다. 

호스트 DNS와 IP주소 사이의 매핑과 호스트는 영구적인 것이 아니기 때문에 DNS 서버는 어떤 기간(흔히 2일로 설정) 이후에 저장된 정보를 제거합니다.

예를 들어

• 호스트 apricot.nyu.edu가 cnn.com에 대한 IP 주소를 dns.nyu.edu에게 질의한다고 생각해 봅시다.
• 또한 몇 시간 후에 NYU의 다른 호스트 kiwi.nyu.edu가 dns.nyu.edu에게 같은 호스트 네임을 질의한다고 가정해 봅시다.

캐싱으로 인해 로컬 DNS 서버는 두 번째로 질의한 호스트에게 다른 DNS 서버로의 질의 없이 즉시 cnn.com의 IP 주소를 보낼 수 있습니다. 로컬 DNS 서버는 또한 TLD 서버의 IP 주소를 저장할 수 있습니다. 그러므로 로컬 DNS 서버가 질의 사슬에서 루트 DNS 서버를 우회하도록 합니다.