애플리케이션 계층

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

사람들은 여러 가지 방법으로 자신을 식별할 수 있다. 예를 들어 출생증명서에 나타나는 이름, 주민등록번호, 운전면허번호로 식별할 수도 있다. 이러한 식별자는 사람을 구별하는 데 사용할 수 있지만, 환경에 따라서는 어느 한 식별자가 다른 것보다 더 적당할 수 있다. 예를 들어, 국세청 컴퓨터에서는 출생증명서의 이름보다는 고정 길이의 주민등록번호를 더 선호한다. 반면에 일반 사람들은 주민등록번호보다는 기억하기 쉬운 이름을 선호한다.

사람을 여러가지 방법으로 식별할 수 잇는 것처럼, 인터넷 호스트도 마찬가지다. 호스트의 식별자 중 하나는 호스트 이름(hostname) 이다. www.facebook.com, www.google.com, gaia.cs.umass.edu 같은 호스트 이름은 기억하기 쉬워 사용자가 좋아한다. 그러나 호스트 이름은 인터넷에서의 그 호스트 위치에 대한 정보를 거의 제공하지 않는다(www.eurecom.fr 같은 호스트 이름은 fr로 끝나므로 아마도 호스트가 프랑스에 잇을 것이라는 정보 외에 다른 정보를 제공하지 않는다.) 더 나아가, 호스트 이름은 가변 길이의 알파뉴메릭 문자로 구성되므로 라우터가 처리하는 데 어려움이 있다. 이러한 이유로 호스트는 흔히 말하는 IP주소(IP address) 로도 식별된다.

4장에서 IP 주소를 자세히 논의하겠지만 지금은 이에 대한 간략한 설명도 유용할 것이다. IP 주소는 4바이트로 구성되고 계층구조를 갖는다. IP 주소는 121.7.106.83과 같은 형태이고, 0~255의 십진수로 표현하는 각 바이트는 점으로 구분한다. IP 주소는 계층구조여서 주소를 왼쪽에서 오른쪽으로 조사함으로써, 그 호스트가 인터넷의 어디에 위치하는지(네트워크로 연결된 네트워크에서 어느 네트워크 내에 있는지)에 대한 자세한 정보를 얻을 수 있다. 마찬가지로, 메일 주소를 왼쪽에서 오른쪽으로 읽으면서 거주자 위치에 대한 더 자세한 정보를 얻는다.

2.4.1 DNS가 제공하는 서비스

호스트 이름과 IP 주소로 호스트를 식별하는 두 가지 방법을 살펴봤다. 사람은 좀 더 기억하기 쉬운 호스트 이름 식별자를 좋아하지만, 라우터는 고정 길이의 게층구조를 가진 IP 주소를 좋아한다. 이러한 선호 차이를 절충하기 위해, 호스트 이름을 IP 주소로 변환해주는 디렉터리 서비스가 필요하다. 이것이 인터넷 DNS(domain name system)의 주요 임무다. DNS는 (1) DNS서버들의 계층구조로 구현된 분산 데이터베이스이고, (2) 호스트가 분산 데이터베이스로 질의하도록 허락하는 애플리케이션 게층 프로토콜이다. DNS서버는 주로 BIND(Berkeley Internet Name Domain) 소프트웨어를 수행하는 유닉스 컴퓨터다. DNS 프로토콜은 UDP상에서 수행되고 포트번호 43을 이용한다. DNS는 다른 앺ㄹ리케이션 프로토콜들이 HTTP, SMTP, FTP 등 사용자가 제공한 호스트 이름을 IP 주소로 변환하기 위해 이용한다. 예를 들어, 어떤 사용자의 호스트에서 수행되는 브라우저(HTTP 클라이언트)가 URL www.someschool.edu/index.html을 요청할 때 무슨 일이 발생하는지를 생각해보라. 사용자의 호스트가 HTTP 요청 메시지를 웹 서버 www.someschool.edu로 보낼 수 있도록 사용자 호스트는 www.someschool.edu의 IP주소를 얻어야만 한다. 이는 다음과 같이 수행된다.

1. 같은 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트 측을 수행한다.
2. 브라우저는 URL로부터 호스트 이름 www.someschool.edu 를 추출하고 그 호스트 이름을 DNS 애플리케이션의 클라이언트 측에 넘긴다.
3. DNS 클라이언트는 DNS 서버로 호스트 이름을 포함하는 질의를 보낸다.
4. DNS 클라이언트는 결국 호스트 이름에 대한 IP 주소를 가진 응답을 받게 된다.
5. 브라우저가 DNS로부터 IP 주소를 받으면, 브라우저는 해당 IP 주소와 그 주소의 80번 포트에 위치하는 HTTP 서버 프로세스로 TCP 연결을 초기화한다.

이 예로부터 DNS는 DNS를 사용하는 인터넷 애플리케이션에게 추가 지연을 준다는 것을 볼 수 있다. 다행스럽게도, 다음에 논의하는 것처럼 원하는 IP 주소는 '가까운' DNS 서버에 캐싱되어 있어서 평균 DNS 지연뿐만 아니라 DNS 네트워크 트래픽 감소에 도움을 준다.

DNS는 호스트 이름을 IP 주소로 변환하는 것 외에 다음과 같은 중요한 추가 서비스를 제공한다.

• 호스트 에일리어싱(host aliasing): 복잡한 호스트 이름을 가진 호스트는 하나 이상의 별명을 가질 수 있다. 예를 들어, relay1.west-coast.enterprise.com 같은 호스트 이름은 enterprise.com과 www.enterprise.com 같은 2개의 별칭을 가질 수 있다. 이 경우에 호스트 이름 relay1.west-coast.enterprise.com은 정식 호스트 이름(canonical hostname) 이라고 한다.

• 메일 서버 에일리어싱(mail server aliasing): 전자메일 주소는 기억하기 쉬운 것이 좋다. 예를 들어, 밥이 핫메일에 계정이 있다면 밥의 전자메일 주소는 bob@hotmail.com처럼 간단할 것이다. 그러나 핫메일 서버의 호스트 이름은 더 복잡하며, 간단한 hotmail.com보다 기억하기가 쉽지 않다.(예를 들어, 정식 호스트 이름은 relay1.west-coast.hotmail.com일 수 있다). DNS는 호스트의 IP주소뿐만 아니라 제공된 별칭 호스트 이름에 대한 정식 호스트 이름을 얻기 위해 메일 애플리케이션에 의해 수행된다. 사실 MX 레코드는 기업의 메일 서버와 웹 서버가 같은 호스트 이름(별칭)을 갖는 것을 허용한다. 예를 들어, 기업 웹 서버와 메일 서버 둘 다 enterprise.com이라고 부를 수 있다.

• 부하 분산(load distribution): DNS는 중복 웹 서버 같은 여러 중복 서버 사이에 부하를 분산하기 위해서도 사용되고 있다. cnn.com 같은 인기 있는 사이트는 여러 서버에 중복되어 있어서, 각 서버가 다른 종단 시스템에서 수행되고 다른 IP 주소를 갖는다. 중복 웹 서버의 경우, 여러 IP 주소가 하나의 정식 호스트 이름과 연관되어 있다. DNS 데이터베이스는 이 IP 주소 집합을 갖고 있다. 클라이언트가 주소 집합으로 매핑하는 호스트 이름에 대한 DNS 질의를 하면, 서버는 IP 주소 집합 전체를 가지고 응답한다. 그러나 각 응답에서의 주소는 순환식으로 보낸다. 클라이언트는 대체로 주소 집합 내부의 첫 번째 IP 주소로 HTTP 요청 메시지를 보내므로, DNS의 순환 방식은 여러 중복 서버들 사이에서 트래픽을 분산하는 효과를 낸다. DNS 순환 방식은 전자메일에서도 사용되어 여러 메일 서버가 동일한 별칭을 가질 수 있다. 아카마이 같은 콘텐츠 분배 회사는 웹 콘텐츠 분산을 제공하기 위해 좀 더 세련된 방법으로 DNS를 이용하고 있다.

DNS는 RFC 1034와 RFC 1035에 명시되어 있고 여러 다른 RFC에서 갱신되었다. 그것은 복잡한 시스템이고, 여기서는 운용 관점에서의 주요 면만 취급하겠다. 관심 있는 독자는 해당 RFC와 앨비츠와 류가 지은 책을 참고하기 바란다. 또한 DNS가 무엇이고 왜 존재해야 하는지에 대해 훌륭한 설명을 제공하는 과거를 조명하는 논문 [Mockapetris 1988]과 [Mockapetris 2005]를 참고하라.

2.4.2 DNS 동작 원리 개요

이제 DNS가 어떻게 동작하는지를 개괄적으로 살펴보자. 여기서는 호스트 이름을 IP 주소로 변환하는 서비스에 초점을 맞춘다.

사용자의 호스트에서 실행되는 어떤 애플리케이션(웹 브라우저나 메일 클라이언트)이 호스트 이름을 IP 주소로 변환하려 한다고 가정하자. 그 애플리케이션은 변환될 호스트 이름을 명시하여 DNS 측의 클라이언트를 호출할 것이다(많은 유닉스 컴퓨터가 그러하듯 gethostbyname()은 변환을 실행하기 위한 애플리케이션을 호출하는 함수다). 그리고 상요자 호스트의 DNS는 네트워크에 질의 메시지를 보낸다. 모든 DNS 질의와 응답 메시지는 포트 53의 UDP 데이터그램으로 보내진다. 수 밀리초에서 수 초의 지연 후에 사용자 호스트의 DNS는 요청한 매핑에 해당하는 DNS 응답 메시지를 받는다. 이제 이 매핑은 호출한 애플리케이션으로 전달된다. 그러므로 사용자 호스트의 호출한 애플리케이션 관점에서 DNS는 간단하고 직접적인 변환 서비스를 제공하는 블랙박스다. 그러나 사실 이러한 서비스를 구현하는 블랙박스는 복잡한데, 이는 전 세계에 분산된 많은 DNS 서버 뿐만 아니라 DNS 서버와 질의를 하는 호스트 사이에서 어떻게 통신하는지를 명시하는 애플리케이션 계층 프로토콜로 구성되어 있다.

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

• 서버의 고장: 만약 이 네임 서버가 고장나면, 전체 인터넷이 작동하지 않는다.
• 트래픽 양: 단일 DNS 서버가 모든 DNS 질의를 처리해야 한다(수 많은 호스트에서 발생한 모든 HTTP 요청과 전자메일 메시지의 처리)
• 먼 거리의 중앙 집중 데이터베이스: 단일 DNS 서버가 모든 질의 클라이언트로부터 '가까울' 수만은 없다. 단일 서버를 뉴욕에 둔다면, 호주로부터의 모든 질의를 느리고 혼잡한 링크를 거쳐 지구 반대편까지 여행해야 한다. 이는 매우 심각한 지연을 일으킬 수 있다.
• 유지관리: 단일 네임 서버는 모든 인터넷 호스트에 대한 레코드를 유지해야 한다. 이 중앙 집중 데이터베이스는 거대해지고 모든 새로운 호스트를 반영하기 위해 자주 갱신해야만 한다. 또한 중앙 집중 데이터베이스에 호스트를 등록할 수 있도록 사용자에게 허용하는 것과 관련된 인증 문제가 있다.

요약하면, 단일 DNS 서버에 있는 중앙 집중 데이터베이스는 확장성이 전혀 없다. 결과적으로 DNS는 분산되도록 설계되었다. 사실 DNS는 분산 데이터베이스가 인터넷에서 어떻게 구현될 수 있는지를 보여주는 훌륭한 사례다.

분산 계층 데이터베이스

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

즉, 루트(root) DNS 서버, 최상위 레벨 도메인 네임(top-level damain, TLD) DNS 서버, 책임(authoritative) DNS 서버다. 이 세 부류의 서버들이 어떻게 상호작용하는지를 알기 위해 어떤 DNS 클라이언트가 호스트 이름 www.amazon.com의 IP 주소를 결정하기 원한다고 가정하자. 먼저 이 클라이언트는 루트 서버 중 하나에 접속한다. 루트 서버는 최상위 레벨 도메인 com을 갖는 TLD 서버 IP 주소를 보낸다. 그런 다음 클라이언트는 이 TLD 서버 중 하나에 접속하고, 서버는 도메인 amazon.com을 가진 책임 서버의 IP 주소를 보낸다. 클라이언트는 amazon.com의 책임 서버 중 하나로 접속한다. 서버는 호스트 이름 www.amazon.com의 IP 주소를 보낸다. 이 DNS 검색 과정을 자세히 살펴보기에 앞서, 먼저 세 가지 DNS 서버에 대해 더 자세히 알아보겠다.

• 루트 DNS 서버: 위 그림에 표기된 것처럼 1000개 이상의 루트 서버 인스턴스가 전 세계에 흩어져 있다. 루트 서버들은 13개의 다른 루트 서버 복사체이고, 12개의 다른 기관에서 관리되며, 인터넷 할당 번호 관리기관[IANA 2020]에 의해 조정된다. 루트 네임 서버들과 이를 관리하는 기관과 그들의 IP 주소 목록은 [Root Servers 2020]에서 볼 수 있다. 루트 네임 서버는 TLD 서버의 IP 주소들은 제공한다.
• 최상위 레벨 도메인(TLD) 서버: com, org, net, edu, gov 같은 상위 레벨 도메인과 kr, uk, fr, ca, jp 같은 모든 국가의 상위 레벨 도메인에 대한 TLD 서버(또는 서버 클러스터)가 있다. 베리사인 글로벌 레지스트리 서비스사(Verisign Gloal Registry Services)는 com TLD에 대한 TLD 서버를 담당하고 있으며, 에듀코즈사(Educause)는 edu TLD에 대한 TLD 서버를 담당하고 있다. TLD를 지원하는 네트워크 인프라는 크고 복잡하다. 베리사인 네트워크의 개괄을 보려면 [Osterweil 2012]를 참고하기 바란다. 상위 레벨 도메인 목록은 [TLD list 2020]을 참고하기 바란다. TLD 서버는 책임 DNS 서버에 대한 IP 주소를 제공한다.
• 책임 DNS 서버: 인터넷에서 접근하기 쉬운 호스트(예: 웹 서버와 메일 서버)를 가진 모든 기관은 호스트 이름을 IP 주소로 매핑하는 공개적인 DNS 레코드를 제공해야 한다. 기관의 책임 DNS 서버는 이 DNS 레코드를 갖고 있다. 또한 기관은 이 레코드를 갖도록 자신의 책임 DNS 서버의 구현을 선택할 수 있고, 일부 서비스 제공자의 책임 DNS 서버에 이 레코드를 저장하도록 비용을 지불한다. 대부분의 대학과 큰 기업들은 자신의 기본 책임 DNS 서버와 보조 책임 DNS 서버를 유지하고 구현한다.

루트, TLD, 책임 DNS 서버들은 모두 DNS 서버들의 계층구조를 갖는다. DNS의 또 다른 중요한 형태는 로컬 DNS 서버다. 로컬 DNS 서버는 서버들의 게층 구조에 엄격하게 속하지는 않지만, DNS 구조의 중심에 있다. (대학이나 주거지역 ISP 같은) ISP들은 로컬 DNS 서버(또는 디폴트 네임 서버)를 갖는다. 호스트가 ISP에 연결될 때, 그 ISP는 로컬 DNS 서버로부터 IP 주소를 호스트에게 제공한다(일반적으로 4장에 기술된 DHCP를 통해). 여러분은 윈도우나 유닉스에서 네트워크 상태 창에 접근하여 로컬 DNS 서버의 IP 주소를 쉽게 결정할 수 있다. 호스트의 로컬 DNS 서버는 대체로 호스트에 '가까이' 있다. 기관 ISP에서 로컬 DNS 서버는 호스트와 같은 LAN상에 있을 수 있다. 주거지역 ISP는 전형적으로 몇 개의 라우터 범위 안에서 호스트로부터 떨어져 있다. 호스트가 DNS 질의를 보내면, 이 질의는 먼저 프록시로 동작하는 로컬 DNS 서버에게 전달되고, 그 로컬 DNS 서버는 이 질의를 DNS 서버 계층으로 전달한다. 이에 대해 아래에서 자세히 논의할 것이다.

간단한 예를 살펴보자. 호스트 cse.nyu.edu가 gaia.cs.umass.edu의 IP 주소를 원한다고 가정하자. 또한 cse.nyu.edu에 대한 NYU의 로컬 DNS 서버가 dns.nyu.edu이고, gaia.cs.umass.edu에 대한 책임 DNS 서버는 dns.umass.edu라고 가정하자. 아래 그림처럼 호스트 cse.nyu.edu가 먼저 자신의 로컬 DNS 서버 dns.nyu.edu에게 DNS 질의 메시지를 보낸다.

질의에는 변환되어야하는 호스트 이름, 즉 gaia.cs.umass.edu가 포함된다. 로컬 DNS 서버는 그 질의 메시지를 루트 DNS 서버에게 전달한다. 루트 DNS 서버는 edu를 인식하고, edu에 대한 책임을 가진 TLD 서버의 IP 주소 목록을 로컬 DNS 서버에게 보낸다. 로컬 DNS 서버는 질의 메시지를 TLD 서버로 보낸다. 그런 다음 TLD 서버는 umass.edu를 인식하고 dns.umass.edu로 이름 지어진 메사추세츠대학교의 책임 DNS 서버의 IP 주소로 응답한다. 마지막으로, 로컬 DNS 서버는 직접 dns.umass.edu로 질의 메시지를 다시 보내고, gaia.cs.umass.edu의 IP 주소로 응답한다. 이 예에서 하나의 호스트 이름 매핑을 얻기 위해 질의 메시지 네 번 응답 메시지 네 번, 총 8번의 DNS 메시지가 보내졌음에 주목하라. 우리는 곧 질의 전송을 줄이기 위해 DNS 캐싱 방법을 살펴볼 것이다.

이전 예에서 TLD 서버는 호스트 이름에 대한 책임 서버를 안다고 가정했다. 그러나 일반적으로는 그렇지 않다. 대신에 TLD 서버는 호스트 이름에 대한 책임 DNS를 아는 중간 DNS 서버만 알고 있다. 예를 들어, 매사추세츠대학교가 대학에 대한 DNS 서버, 즉 dns.umass.edu를 갖고 있다고 가정하자. 그리고 매사추세츠대학교의 각 학과도 자신의 DNS 서버를 갖고 있고, 각 학과 DNS 서버가 학과 안의 모든 호스트를 책임진다고 가정하자. 그리고 메사추세츠대학교의 각 학과도 자신의 DNS 서버를 갖고 있고, 각 학과 DNS 서버가 학과 안의 모든 호스트를 책임진다고 가정하자. 이 경우에 중간 DNS 서버 dns.umass.edu가 cs.umass.edu로 끝나는 호스트 이름을 가진 호스트에 대한 질의를 받으면, cs.mass.edu로 끝나는 모든 호스트에 대한 책임을 가진 dns.cs.umass.edu의 IP 주소를 dns.nyu.edu로 전달한다. 로컬 DNS 서버 dns.nyu.edu는 로컬 DNS 서버에게 원하는 매핑 결과를 돌려주는 책임 DNS 서버에게 질의를 보낸다. 그런 다음 로컬 DNS 서버는 요청한 호스트에게 그 매핑 결과를 전달한다. 이 경우에 전체 10번의 메시지를 보내게 된다.

위 그림의 예는 재귀적 질의(recursive query)와 반복적 질의(iterative query) 를 사용한다. cse.nyu.edu로부터 dns.nyu.edu로 보내는 질의는 자신을 대신하여 필요한 매핑을 얻도록 dns.nyu.edu에게 요구하므로 재귀적 질의다. 그러나 다른 세 가지 질의는 모든 응답이 dns.nyu.edu에 직접 보내지므로 반복적 질의다. 이론상, DNS 질의는 반복적이고 재귀적일 수 있다. 아래 그림의 예에서 모든 질의가 재귀적인 DNS 질의 사슬을 보여준다.

DNS 캐싱

지금까지의 논의에서 DNS의 중요한 특성인 DNS 캐싱(caching) 은 다루지 않았다. 실제로 DNS는 지연 성능 향상과 네트워크의 DNS 메시지 수를 줄이기 위해 캐싱을 사용한다. DNS 캐싱의 아이디어는 매우 간단하다. 질의 사슬에서 DNS 서버가 DNS 응답을 받았을 때(예: 호스트 이름을 IP 주소로 매핑하기) 그것은 로컬 메모리에 응답에 대한 정보를 저장할 수 있다. 예를 들어, 위로 2번째 그림에서 로컬 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 서버는 두 번째로 질의한 호스트에게 다른 DNS 서버로의 질의 없이 즉시 cnn.com의 IP 주소를 보낼 수 있다. 로컬 DNS 서버는 또한 TLD 서버의 IP 주소를 저장할 수 있다. 그러므로 로컬 DNS 서버가 질의 사슬에서 루트 DNS 서버를 우회하게 한다.

2.4.3 DNS 레코드와 메시지

DNS 분산 데이터베이스를 구현한 DNS 서버들은 호스트 이름을 IP 주소로 매핑하기 위한 자원 레코드(resource record, RR) 을 저장한다. 각 DNS는 하나 이상의 자원 레코드를 가진 메시지로 응답한다. 이 절과 다음 절에서는 DNS 자원 레코드와 메시지에 대한 간단한 개요를 제공한다.

자원 레코드는 다음과 같은 필드를 포함하는 4개의 튜플(tuple)로 되어 있다.

(Name, Value, Type, TTL)

TTL은 자원 레코드의 생존기간(time to live)이다(자원이 캐시에서 제거되는 시간을 결정). 다음에 주어진 예제 레코드에서 TTL 필드는 무시한다. Name과 Value의 의미는 Type에 따른다.

• Type=A이면, name은 호스트 이름이고 Value는 호스트 이름에 대한 IP 주소다. 따라서 Type A 레코드는 표준 호스트 이름의 IP 주소 매핑을 제공한다. 예를 들어, (relay1.bar.foo.com, 145.37.93.126, A)는 Type A 레코드다.
• Type=NS이면, Name은 도메인(예: foo.com)이고 Value는 도메인 내부의 호스트에 대한 IP 주소를 얻을 수 있는 방법을 아는 책임 DNS 서버의 호스트 이름이다. 예를 들어, (foo.com, dns.foo.com, NS)는 type NS 레코드다.
• Type=CNAME이면, Value는 별칭 호스트 이름 Name에 대한 정식 호스트 이름이다. 이 레코드는 질의 호스트에게 호스트 이르에 대한 정식 이름을 제공한다. 예를 들어, (foo.com, relay1.bar.foo.com, CNAME)은 CNAME 레코드다.
• Type=MX이면, Value는 별칭 호스트 이름 Name을 갖는 메일 서버의 정식 이름이다. 예를 들어, (foo.com, mail.bar.foo.com, MX) 는 MX 레코드다. MX 레코드는 메일 서버의 호스트 이름이 간단한 별칭을 갖는 것을 허용한다. 어떤 회사는 한 메일 서버와 다른 서버들(웹 서버와 같은 것)이 같은 별칭을 가질 수 있다. 메일 서버의 정식 이름을 얻기 위해 DNS 클라이언트는 MX 레코드에 대한 질의를 한다. 다른 서버의 정식 이름을 얻기 위해 DNS 클라이언트는 CNAME 레코드에 대한 질의를 한다.

한 DNS 서버가 특별한 호스트 이름에 대한 책임 서버이면, 그 DNS 서버는 그 호스트 이름에 대한 Type A 레코드를 포함한다(비록 그 DNS 서버가 책임 서버가 아니라고 하더라도, 캐시에 Type A 레코드를 포함할 수도 있다). 서버가 호스트 이름에 대한 책임 서버가 아니라면, 그 서버는 호스트 이름을 포함하는 도메인에 대한 Type NS 레코드를 포함할 것이고, NS 레코드의 Value 필드에 DNS 서버의 IP 주소를 제공하는 Type A 레코드도 포함할 것이다. 예를 들어, 호스트 gaia.cs.umass.edu에 대한 책임 서버가 아닌 TLD 서버를 가정하자. 그러면 이 서버는 호스트 gaia.cs.umass.edu를 포함하는 도메인에 대한 레코드, 예를 들면(umass.edu, dns.umass.edu, NS)를 포함할 것이다. TLD 서버는 또한 Type A 레코드를 포함하는데, 이는 DNS 서버 dns.umass.edu를 IP 주소(예: dns.umass.edu, 128.119.40.111, A)로 매핑한다.

DNS 메시지

이 절의 앞쪽에 DNS 질의와 응답 메시지에 대해 언급했다. 이들은 DNS의 유일한 두 가지 메시지 유형이다. 더 나아가서 요청과 응답 메시지 모두는 다음 그림과 같은 포맷을 갖고 있다.

DNS 메시지 내부의 여러 필드의 의미는 다음과 같다.

• 처음 12바이트는 헤더 영역(header section)으로, 여러 필드를 갖고 있다. 첫 필드는 질의를 식별하는 16비트 숫자다. 이 식별자는 질의에 대한 응답 메시지에 복사되어, 클라이언트가 보낸 질의와 수신된 응답 간의 일치를 식별하게 한다. 플래그 필드에는 여러 개의 플래그가 있다. 1비트의 질의/응답 플래그는 메시지가 질의(0)인지 응답(1)인지를 구별하게 한다. 1비트의 책임 플래그는 DNS 서버가 질의 이름에 대해 책임 서버일 때 응답 메시지에 설정된다. 1비트의 재귀 요구 플래그는 DNS 서버가 레코드를 갖지 않을 때 재귀적 질의를 수행하기를 클라이언트(호스트 혹은 DNS서버)가 원할 때 설정된다. 1비트로 된 재귀 가능 필드는 DNS 서버가 재귀 질의를 지원하면 응답에 설정된다. 헤더에 4개의 '개수' 필드가 있다. 이들 필드는 헤더 다음에 오는 데이터 영역의 네 가지 타입의 발생 횟수를 나타낸다.
• 질문영역(question section)은 현재 질의에 대한 정보를 포함한다. 이 영역은 (1) 질의되는 이름을 포함하는 이름 필드와, (2) 이름에 대해 문의되는 질문 타입을 나타내는 타입 필드를 포함한다(이름과 연관된 호스트 주소(A 타입) 혹은 이름에 대한 메일 서버(MX 타입) 등.)
• DNS 서버로부터의 응답에서 답변 영역(answer section)은 원래 질의된 이름에 대한 자원 레코드를 포함한다. 각 자원 레코드에 Type(예: A, NS CNAME, MX), Value, TTL이 있음을 기억하라. 응답으로 여러 개의 RR을 보낼 수 있다. 왜냐하면 호스트 이름은 여러 개의 IP 주소를 가질 수 있기 때문이다(예: 이 절의 앞에서 논의한 것처럼 중복된 웹 서버와 같은 경우).
• 책임 영역(authority section)은 다른 책임 서버의 레코드를 포함한다.
• 추가 영역(addtional section)은 다른 도움이 되는 레코드를 포함하고 있다. 예를 들어, MX 질의에 대한 응답에서 응답 필드는 전자메일 서버의 정식 호스트 이름을 제공하는 자원 레코드를 갖고 있다. 추가 영역은 메일 서버의 정식 호스트 이름에 대한 IP 주소를 제공하는 Type A 레코드를 포함한다.

어떻게 DNS 질의 메시지가 여러분이 작업하는 호스트로부터 DNS 서버로 곧장 보내질 수 있을까? 이것은 nslookup 프로그램으로 쉽게 할 수 있는데 윈도우와 유닉스에서 이용할 수 있다. 예를 들어, 윈도우 호스트로부터 명령 창을 열고 'nslookup'을 입력하여 nslookup 프로그램을 실행한다. nslookup을 실행한 후에 여러분은 DNS 질의를 어떤 DNS 서버(루트, TLD, 책임 서버)로 보낼 수 있다. DNS 서버로부터 응답 메시지를 받은 후에 nslookup은 응답에 있는 레코드를 화면에 사람이 읽을 수 있는 형태로 보여준다. 여러분의 호스트로부터 nslookup을 실행하는 대신에 nslookup을 원격에서 실행하게 하는 많은 웹사이트 중 하나를 방문할 수도 있다(검색 엔진에서 'nslookup'을 입력하면 이런 사이트를 볼 수 있다).

DNS 데이터베이스에 레코드 삽입

위의 논의에서는 레코드가 DNS 데이터베이스로부터 어떻게 추출되는지에 초점을 맞추었다. 처음에 어떻게 레코드를 데이터베이스에 넣는지가 궁금할 것이다. 이제 특정 예를 통해 어떻게 이를 수행할 수 있는지 알아보자. 여러분이 막 네트워크 유토피아라고 하는 새로운 벤처 기업을 설립했다고 가정하자. 가장 먼저 하고자 하는 일은 도메인 네임 networkutopia.com을 등록기관에 등록하는 것이다. 등록기관(registrar) 은 도메인 네임의 유일성을 확인하고, 그 도메인 이름을 DNS 데이터베이스에 넣고, 그 서비스에 대한 약간의 요금을 여러분으로부터 받는 상업 기관이다. 1999년 이전에 네트워크 솔루션이라는 작은 등록기관이 com, net, org 도메인에 대한 도메인 이름 등록을 독점했다. 그러나 이제는 고객 유치를 위해 경쟁하는 많은 등록 기관이 있으며, ICANN(Internet Corporation for Assigned names and Numbers)이 이러한 여러 등록기관을 승인해준다. 승인받은 등록기관의 모든 목록은 http://www.internic.net 에서 볼 수 있다.

여러분의 도메인 네임 networkutopia.com 을 어떤 등록기관에 등록할 때 등록기관에 주책임 서버와 부책임 서버의 이름과 IP 주소를 등록기관에 제공해야 한다. 그 이름과 IP 주소가 dns1.networkutopia.com, dns2.networkutopia.com, 212.212.212.1, 212.212.212.1 라고 하자.이 두 책임 DNS 서버 각각에 대해 등록기관은 Type NS와 Type A 레코드가 TLD com 서버에 등록되도록 확인한다. 특히 networkutopia.com에 대한 주책임 서버의 경우, 등록기관은 다음 2개의 자원 레코드를 DNS 시스템에 삽입한다.

(networkutopia.com, dns1.networkutopia.com, NS)
(dns1.networkutopia.com, 212.212.212.1, A)

웹 서버 www.networkutopia.com에 대한 Type A 자원 레코드와 메일 서버 mail.networkutopia.com에 대한 Type MX 자원 레코드가 여러분의 책임 DNS 서버에 등록되는 것을 확인해야만 한다(예: 최근까지 각 DNS 서버의 내용은 시스템 관리자가 생성한 형상 파일로부터 정상적으로 설정되었다. 좀 더 최근에는 DNS 메시지를 통해 데이터베이스에 데이터를 동적으로 추가 혹은 삭제할 수 있도록 DNS 프로토콜에 UPDATE 선택사양이 추가되었다.

이러한 모든 단계가 끝나고 나면, 사람들은 여러분의 웹사이트를 방문할 수 있고 여러분 회사의 직업들에게 전자메일을 보낼 수도 있다. 이 명제가 사실임을 확인하면서 DNS에 대한 논의를 마치겠다. 이 확인은 또한 DNS에 관해 우리가 무엇을 배웠는가를 견고하게 하는 데 도움을 준다. 호주에 있는 앨리스가 www.networkutopia.com 웹 페이지를 보고자 한다고 가정하자. 앞서 논의한 것처럼 그녀의 호스트는 먼저 DNS 질의를 자신의 로컬 DNS 서버로 보내고, 로컬 DNS 서버는 TLD com 서버에 접속할 것이다(또한 로컬 DNS 서버는 TLD com 스타일 서버의 주소가 캐싱되어 있지 않으면 루트 DNS 서버에 접속해야만 한다). 이 TLD 서버는 위에 나열된 Type NS와 Type A 자원 레코드를 갖고 있다. 왜냐하면 등록기관이 이들 자원 레코드를 모든 TLD com 서버에 삽입했기 때문이다. TLD com 서버는 앨리스의 로컬 DNS 서버로 두 자원 레코드를 포함하는 응답을 보낸다. 그러고 나서 로컬 DNS 서버는 www.networkutopia.com 에 대응되는 Typa A 레코드를 요구하는 DNS 질의를 212.212.212.1에게 보내면, 이 레코드는 요구하는 웹 서버, 즉 212.212.71.4의 IP 주소를 제공한다. 그리고 로컬 DNS 서버는 앨리스 호스트에게 이 레코드를 전달한다. 이제 앨리스의 브라우저는 212.212.71.4 호스트로 TCP 연결을 초기화하고 그 연결로 HTTP 요청을 보낸다.