Chapter 2 - 3. 인터넷 전자메일, 4. DNS: 인터넷의 디렉터리 서비스

2.3 인터넷 전자메일

이 절에서는 인터넷 전자메일 구조의 중심에 있는 애플리케이션 계층 프로토콜을 알아본다.

 

아래 그림은 인터넷 메일 시스템의 상위 레벨 개념을 보여준다.

Three major components of Electronic mail:

• User agents
• Mail servers
• SMTP(Simple Mail Transfer Protocol)

사용자 에이전트(User Agent, UA)

• a.k.a. "mail reader"
• 사용자 에이전트는 사용자가 메시지를 읽고, 응답하고, 전달하고, 저장하고, 구성하게 해준다.
• 대표적으로 마이크로 소프트 아웃룩(Outlook), 애플 메일 등이 있다.

메일 서버(mail server)

• 전자 메일 인프라스트럭처의 중심이다.
• 각 수신자는 메일 서버에 메일 박스(mailbox)를 갖고 있다.
  • 메일 박스는 수신자의 메시지를 유지하고 관리한다.
  • 일반 메시지는 송신자의 사용자 에이전트에서 전달이 시작되고, 송신자의 메일 서버를 거친 후에 수신자의 메일 서버로 전달된다.
    거기서 수신자의 메일 박스에 저장된다.
  • 전자메일 박스에 있는 메시지를 보려면 메일 서버는 사용자 계정과 비밀 번호를 이용하여 이용자를 인증하여야 한다.
• 송신자는 메일 서버의 고장에도 대처해야 한다.
  • 만약 메일을 수신자의 메일 서버로 전달할 수 없다면 그 메시지를 메시지 큐(queue)에 보관하고 나중에 그 메시지를 전달하기 위해 다시 시도한다.
  • 재시도는 약 30분마다 일어나고, 계속 실패 시에 서버는 그 메시지를 제거하고 송신자에게 통보한다.

SMTP

💡 인터넷 전자메일을 위한 주요 애플리케이션 계층 프로토콜이다.

• SMTP는 메일을 송신자의 메일 서버로부터 수신자의 메일 서버로 전송하는 데에 TCP의 신뢰적인 데이터 전송 서비스를 이용한다.
• SMTP는 대부분의 애플리케이션 계층 프로토콜처럼, 클라이언트와 서버를 갖고 있다.
• SMTP의 클라이언트와 서버 모두가 모든 메일 서버에서 수행되고, 상대 메일로 송신할 때는 클라이언트가 되고 수신할 때는 서버가 된다.

2.3.1 SMTP

uses TCP to reliably transfer email message from client to server, port 25

direct transfer: sending server to receiving server

 

SMTP에서는 모든 메일 메시지의 몸체는 단순한 7-bit ASCII여야 한다.

이 때문에 전송 용량이 제한되어 커다란 첨부 파일이나 비디오 파일을 보낼 때 문제를 일으킨다.

 

Three phases of transfer

1. handshaking (greeting)
2. transfer of messages (data exchange)
3. closure

 

기본 동작 과정

1. 앨리스는 전자 메일 사용자 에이전트를 수행하고, 밥의 전자 메일 주소를 제공하여 메시지를 보내라고 명령한다.
2. 앨리스의 사용자 에이전트는 메시지를 그녀의 메일 서버에게 보내고, 그곳에서 메시지는 메시지 큐에 놓인다.
3. 앨리스의 메일 서버에서 동작하는 SMTP의 클라이언트 측은 메시지 큐에 있는 메시지를 본다.
   밥의 메일 서버에서 수행되고 있는 SMTP 서버에게 TCP 연결을 설정한다.
4. 초기 SMTP 핸드셰이킹 이후에 SMTP 클라이언트는 앨리스의 메시지를 TCP 연결로 보낸다.
5. 밥의 메일 서버 호스트에서 SMTP의 서버 측은 메시지를 수신한다. 밥의 메일 서버는 그 메시지를 밥의 메일 박스에 놓는다.
6. 밥은 편한 시간에 그 메시지를 읽기 위해 사용자 에이전트를 시동한다.

 

SMTP는 두 메일 서버가 먼 거리에 떨어져 있더라도 중간 메일 서버를 이용하지 않는다.

즉, 메시지를 보낼 때 보내는데 실패하더라도 중간 메일 서버에 저장되는 것이 아니라 송신자의 메일 서버에 남아있다.

기본 동작 과정 Detail

1. 클라이언트 SMTP는 서버의 SMTP의 25번 포트로 TCP 연결을 설정한다. 서버가 죽어있다면 나중에 시도한다.
2. 연결이 설정되면, 애플리케이션 계층 핸드셰이킹을 수행한다.
   이때 SMTP 클라이언트는 송신자의 전자메일 주소와 수신자의 전자메일 주소를 제공한다.
3. 이후 클라이언트는 메시지를 보낸다. (TCP의 신뢰적인 데이터 전송 서비스에 의존)
4. 보낼 다른 메시지가 있다면 같은 TCP 연결 상에서 반복하며, 그렇지 않으면 TCP를 닫는다. (지속 연결(persistent connection))

SMTP 클라이언트(C)와 SMTP 서버(S) 사이의 메시지 전달 과정 예시

S:  220 hamburger.edu
C:  HELO crepes.fr
S:  250 Hello crepes.fr, pleased to meet you
C:  MAIL FROM: <alice@crepes.fr>
S:  250 alice@crepes.fr ... Sender ok
C:  RCPT TO: <bob@hamburger.edu>
S:  250 bob@hamburger.edu ... Recipient ok
C:  DATA
S:  354 Enter mail, end with ”.” on a line by itself
C:  Do you like ketchup?
C:  How about pickles?
C:  .
S:  250 Message accepted for delivery
C:  QUIT
S:  221 hamburger.edu closing connection

 

• 클라이언트는 5개의 HELO, MAIL FROM, RCPT TO, DATA, QUIT 명령을 내린다.
• 클라이언트는 하나의 점(.)으로 된 라인을 송신하며, 그것은 서버에서 메시지의 끝을 나타낸다.
• 서버는 각 명령에 응답하며, 각 응답에는 응답 코드와 영문 설명이 있다.

 

SMTP는 지속 연결(persistent connection)을 사용한다.

즉, 같은 수신 메일 서버로 보내는 여러 메시지를 갖고 있다면, 같은 TCP 연결을 통해 모든 메시지를 전달할 수 있다.

 

telnet 명령어를 사용하면 원격 메일 서버와 위와 같은 대화를 할 수 있다.

2.3.2 메일 메시지 포맷

전자메일을 보낼 때 주변 정보가 포함된 헤더(header)가 메시지 몸체(body) 앞에 오게 된다.

• 이 헤더는 RFC 5322에 정의되어 있으며, 헤더와 몸체는 CRLF로 분리된다.
• 모든 헤더는 From: 헤더라인과 To: 헤더 라인을 반드시 가져야 한다. (나머지 헤더는 선택사항이다.)

 

일반 메시지 헤더는 다음과 같다.

From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Searching for the meaning of life.

Message

2.3.3 메일 접속 프로토콜(Mail access protocols)

• SMTP : delivery / storage to receiver's server
• Mail access protocol : retrieval from server

 

메일 서버가 메일 박스를 관리하고, SMTP의 클라이언트와 서버 측 모두를 수행한다.

 

메일 서버가 로컬 호스트에 있다면, 호스트는 언제든 도착할 수 있는 전자 메일을 수신하기 위해 항상 켜져 있어야 하고 인터넷에 연결되어 있어야 한다.

이는 대부분의 인터넷 사용자에게는 비현실적이다.

 

대신에 일반 사용자는 로컬 호스트에서 사용자 에이전트를 수행하고 늘 켜져 있는 공유 메일 서버에 저장된 메일박스에 접근한다.

메일 서버는 보통 사용자들과 공유한다.

 

송신자 사용자 에이전트에서 수신자 메일 서버까지

클라이언트의 사용자 에이전트는 수신자의 메일 서버로 직접 대화하지 않는다.

대신에 그림처럼 (1) 클라이언트의 사용자 에이전트는 클라이언트의 메일 서버로 전자메일 메시지를 SMTP 또는 HTTP를 이용하여 보낸다.

(2) 그리고 수신자의 메일 서버는 SMTP를 이용하여 수신자의 메일 서버로 전자메일 메시지를 중계한다.

 

두 단계 절차를 거치는 주요 이유는 수신자의 메일 서버를 통해 중계하지 않으면 수신자의 에이전트는 목적지 메일 서버에 도달할 수 없기 때문이다.

송신자는 전자메일을 자신의 메일 서버에 먼저 저장하고, 수신자의 메일 서버는 그 메시지를 수신자의 메일 서버로 받을 때까지 30분 마다 반복해서 보내려고 한다.

 

수신자 메일 서버에서 수신자 사용자 에이전트까지

수신자는 자신의 ISP 내부의 메일 서버에 메시지를 어떻게 얻을 수 있는가?

SMTP는 push 프로토콜인 반면 메시지를 얻는 것은 pull 동작이기 때문에 다른 프로토콜을 사용하여야 한다.

 

두 가지 대표적인 방법

• HTTP
  • 웹 기반 전자메일이나 스마트폰 앱의 경우에 쓰인다.
  • 당연히 메일 서버는 SMTP 인터페이스와 HTTP 인터페이스 둘 다 가지고 있어야 한다.
• IMAP : RFC 3501에 정의된 인터넷 메일 접근 프로토콜

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

 

호스트 이름(hostname)

인터넷 호스트의 식별자 중 하나는 www.facebook.com, www.google.com 등의 호스트 이름(hostname)이다.

 

그러나 호스트의 이름은 인터넷에서의 호스트 위치에 대한 정보를 거의 제공하지 않는다.

또한, 가변 길이의 알파뉴메릭 문자로 구성되므로 라우터가 처리하는 데 어려움이 있다.

 

이러한 이유로 호스트는 흔히 말하는 IP 주소(IP address)로 식별된다.

IP 주소(IP address)

IP 주소는 4 바이트로 구성되고, 계층구조를 갖는다.

• 121.7.106.83과 같은 형태로 0 ~ 255의 십진수로 표현하는 각 바이트는 점으로 구분한다.
• 계층구조여서 왼쪽에서 오른쪽으로 조사함으로써, 그 호스트가 인터넷의 어디에 위치하는지에 대한 자세한 정보를 얻을 수 있다.
  (더 자세히는 4장에서 논의한다.)

2.4.1 DNS(Domain Name System)가 제공하는 서비스

사람은 호스트 네임을 선호하지만, 라우터는 고정 길이의 계층구조를 가진 IP 주소를 선호한다.

이 차이를 절충하기 위해 호스트 이름을 IP 주소로 변환해주는 디렉터리(directory) 서비스가 필요하다.

이 서비스가 인터넷 DNS(Domain name system)의 주요 임무다. (hostname translations, address resolutions)

 

DNS(Domain Name System)

1. DNS 서버들의 계층구조로 구현된 분산 데이터 베이스이다.
   implemented in hierarchy of many name servers
2. 호스트가 분산 데이터 베이스로 질의하도록 허락하는 애플리케이션 계층 프로토콜이다.

 

DNS 서버는 주로 BIND(Berkeley Internet Name Domain) 소프트웨어를 수행하는 유닉스(UNIX) 컴퓨터다.

DNS 프로토콜은 UDP 상에서 수행되고 포트 번호 53을 이용한다.

[참고] DNS가 UDP를 사용하는 이유

1️⃣ 빠른 속도

TCP의 경우 데이터 전송 시작 전에 3-way-handshaking 과정이 있는 반면, UDP는 연결 설정에 드는 비용이 없다.

DNS는 신뢰성보다 속도가 더 중요한 서비스이기 때문에 TCP보다 UDP가 더 적합하다.

또한, UDP는 512 bytes를 넘어가지 않는 패킷만 전송이 가능하고 오버헤드가 없어서 속도가 빠른데,
DNS가 전송하는 데이터 패킷 사이즈가 매우 작으므로 UDP가 유리하다.

이때 단순히 패킷의 사이즈가 작다고 DNS가 UDP를 채택한 것은 아니고,
전달하는 패킷의 크기가 작기 때문에 신뢰성이 보장되지 않아도 되기 때문이다. (못 받으면 다시 전달하면 된다.)

 

2️⃣ 연결 상태를 유지할 필요가 없다.

TCP는 호스트 간의 연결 상태를 유지한다.

이때 TCP의 패킷 안에는 여러 정보가 담겨 있지만, UDP는 어떤 정보도 기록하지 않고 유지할 필요도 없다.

DNS 서버는 TCP보다 많은 클라이언트를 수용할 수 있으므로 연결 상태를 유지하지 않고 정보 기록을 최소화할 수 있는 UDP를 채택하였다.

사용자의 호스트에서 수행하는 브라우저가 URL을 검색했을 때 발생하는 일

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

 

DNS는 위 예시에서 알 수 있듯이 추가 지연을 주지만,
가까운 DNS 서버에 캐싱되어 있어서 평균 DNS 지연 뿐만 아니라 DNS 네크워크 트래픽 감소에 도움을 준다.

호스트 이름을 IP 주소로 변환하는 것 이외의 서비스

호스트 에일리어싱(host aliasing)

복잡한 호스트 이름을 가진 호스트는 하나 이상의 별명을 가질 수 있다.

relay1.west-coast.enterprise.com 같은 호스트 이름은 enterprise.com 같은 별칭을 가질 수 있다.

이 경우에 relay1.west-coast.enterprise.com를 정식 호스트 이름(canonical hostname)이라고 한다.

DNS는 호스트의 IP 주소 뿐만 아니라 제시한 별칭 호스트 이름에 대한 정식 호스트 이름을 얻기 위해 이용될 수 있다.

 

메일 서버 에일리어싱(mail server aliasing)

전자 메일 주소는 간단하지만 그 서버의 호스트 네임은 일반적으로 더 복잡하다.

 

부하 분산 (load distribution)

load balancing among the servers

 

인기 있는 사이트는 여러 서버에 중복되어 있어서, 각 서버가 다른 종단 시스템에서 수행되고 다른 IP 주소를 갖는다.

이때 여러 IP 주소가 하나의 정식 호스트 이름과 연관되어 있다. DNS 데이터베이스는 이 IP 주소 집합을 갖고 있다.

클라이언트가 주소 집합으로 매핑하는 호스트 이름에 대한 DNS 질의를 하면, 서버는 IP 주소 집합 전체를 가지고 응답한다.

 

각 응답에서의 주소는 순환식으로 보낸다.

클라이언트는 대체로 주소 집합 내부의 첫 번째 IP 주소로 HTTP 요청 메시지를 보내므로, DNS의 순환 방식은 트래픽을 분산하는 효과를 낸다.

 

[참고] What is DNS Load Balancing?

2.4.2 DNS 동작 원리 개요

사용자의 호스트에서 실행되는 어떤 애플리케이션이 호스트 이름을 IP 주소로 변환하려 한다고 가정하자.

과정은 다음과 같다.

1. 애플리케이션이 호스트 이름을 명시하여 DNS 클라이언트 호출한다.
2. 사용자 호스트의 DNS는 네트워크에 질의 메시지를 보낸다.
   이때 모든 질의와 응답 메시지는 포트 53의 UDP 데이터그램으로 보내진다.
3. 응답 메시지를 애플리케이션에 전달한다.

 

DNS는 간단해보이지만 매우 복잡한데, 이는 전 세계에 분산된 많은 DNS 서버 뿐만 아니라
DNS 서버와 질의를 하는 호스트 사이에서 어떻게 통신하는지를 명시하는 애플리케이션 계층 프로토콜로 구성되어 있다.

DNS가 중앙 집중 데이터베이스라면?

why not centralize DNS?

만약 DNS가 간단한 설계로 모든 매핑을 포함하는 하나의 인터넷 네임 서버를 갖고 있다면, 수많은 호스트를 가진 오늘날 다음과 같은 문제를 일으킬 수 있다.

• 서버의 고장 : 이 네임 서버가 고장 나면, 전체 인터넷이 작동하지 않는다. (single point of failure)
• 트래픽 양의 과부하 : 단일 DNS 서버가 모든 질의를 해결해야 한다.
• 먼 거리의 중앙 집중 데이터베이스: 단일 DNS 서버가 모든 질의 클라이언트로부터 '가까울' 수만은 없다. 즉, 멀면 멀수록 모든 질의가 느려진다.
• 유지 관리
  • 단일 네임 서버는 모든 인터넷 호스트에 대한 레코드를 유지해야 한다.
  • 모든 새로운 호스트를 반영하기 위해 자주 갱신되어야 하고, 사용자에게 호스트를 등록할 수 있도록 허용하는 것과 관련된 인증 문제가 있다.

 

요약하면 중앙 집중 데이터베이스는 확장성(scalability)이 전혀 없고, 결과적으로 DNS는 분산되도록 설계되어있다.

분산(distributed) 계층(hierarchical) 데이터 베이스

DNS는 많은 서버를 이용하고 이들을 계층 형태로 구성하며 전세계에 분산시킨다.

 

계층 DNS 서버의 종류

루트(root) DNS 서버

• 1000개 이상의 루트 서버 인스턴스가 세계에 흩어져 있다.
• 루트 네임 서버는 TLD 서버의 IP 주소들을 제공한다.
• 인터넷 할당 번호 관리기관 ICANN(Internet Corporation for Assigned Names and Numbers)에 의해 조정된다.

 

TLD(최상위 레벨 도메인) DNS 서버

• Top-Level Domain, TLD
• com, org, net 같은 상위 레벨 도메인과 kr, uk 같은 모든 국가의 상위 레벨 도메인에 대한 TLD 서버가 있다.
• Authoritative(책임) DNS 서버에 대한 IP 주소를 제공한다.

 

Authoritative(책임) DNS 서버

• 인터넷에서 접근하기 쉬운 호스트를 가진 모든 기관은 호스트 이름을 IP 주소로 매핑하는 공개적인 DNS 레코드를 제공해야 한다.
  • 기관의 책임 DNS 서버는 이 DNS 레코드를 갖고 있다.
• 기관은 직접 자신의 책임 DNS 서버의 구현을 선택할 수 있고, 일부 서비스 제공자의 책임 DNS 서버에 이 레코드를 저장하도록 비용을 지불한다.

 

로컬(local) DNS 서버

• 로컬 DNS 서버는 서버들의 계층 구조에 엄격하게 속하지는 않지만 DNS 구조의 중심에 있다.
• ISP는 로컬 DNS 서버를 갖고, 로컬 DNS 서버로부터 IP 주소를 호스트에게 제공한다.
• 대체로 호스트에 가까이 있기 때문에 지연이 적다.

예시

위 그림에서 cse.nyu.edu가 gaia.cs.umass.edu의 IP 주소를 원한다고 가정해보자.

1. 자신의 로컬 DNS 서버에 질의를 보낸다. 이때 변환하고 싶은 호스트의 이름을 같이 보낸다.
2. 로컬 DNS 서버는 그 질의 메시지를 루트 DNS 서버에게 전달한다.
3. 루트 DNS 서버는 edu를 인식하고, edu에 대한 책임을 가진 TLD 서버의 IP 주소 목록을 로컬 DNS 서버에 보낸다.
4. 로컬 DNS 서버는 TLD 서버에 질의를 보낸다.
5. TLD 서버는 umass.edu를 인식하고, dns.umass.edu로 이름 지어진 책임 DNS 서버의 IP 주소로 응답한다.
6. 로컬 DNS 서버는 직접 책임 DNS 서버로 질의 메시지를 다시 보낸다.
7. 최종 gaia.cs.umass.edu의 IP 주소를 응답한다.
8. 호스트에 최종 IP 주소를 응답한다.

 

여기서는 총 8번의 DNS 메시지가 보내졌다.

일반적으로 TLD 서버는 위의 예시와 같이 책임 DNS 서버를 알지 않고, 책임 DNS 서버를 아는 중간 DNS 서버를 알고 있다.

즉, 해당 질의 과정 까지 포함되면 전체 10번의 메시지를 보내게 된다.

 

위 예는 재귀적 질의와 반복적 질의를 사용한다.

cse.nyu.edu로부터 dns.nyu.edu로 보내는 질의는 자신을 필요한 매핑을 대신하여 얻도록 dns.nyu.edu에 요구하므로 재귀적 질의이고,
나머지는 반복적 질의다.

아래 그림은 모든 질의가 재귀적인 DNS 질의 사슬을 보여준다.

일반 질의는 전형적으로 반복적 질의를 따른다.

• 재귀적 질의에서는 높은 계층에 있는 DNS server가 책임져야 하는 것들이 많다.
  • puts burden of name resolutions on contacted name server
  • heavy load at upper levels of hierarchy
• 중요한 infra를 지키는 것이 훨씬 낫기 때문에, 중요한 root name server 보단 default name server가 일을 더 하는 것이 좋다.

DNS 캐싱

실제로는 DNS 지연 성능 향상과 네트워크의 DNS 메시지 수를 줄이기 위해 캐싱(caching)을 사용한다.

질의 사슬에서 DNS 서버는 DNS 응답을 받았을 때 로컬 메모리에 응답에 대한 정보를 저장할 수 있다.

 

만약 호스트의 이름과 IP 주소 쌍이 DNS 서버에 저장되고 다른 호스트 이름으로부터 같은 질의가 DNS 서버로 도착한다면,
DNS 서버는 호스트 이름에 대한 책임이 없을 때조차 원하는 주소를 제공할 수 있다.

호스트 DNS와 IP 사이의 매핑과 호스트는 영구적이지 않기 때문에 어떤 기간(TTL, Time to Live) 이후에 저장된 정보를 제거한다.

로컬 DNS 서버는 구체적인 IP 주소 이외에도 TLD 서버의 IP를 저장하여 루트 DNS 서버를 우회할 수 있게 한다.

2.4.3 DNS 레코드와 메시지

각 DNS는 하나 이상의 자원 레코드를 가진 메시지로 응답한다.

 

DNS 자원 레코드

DNS 서버들은 호스트 이름을 IP 주소로 매핑하기 위한 자원 레코드(Resource Records)를 저장한다.

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

(Name, Value, Type, TTL)

TTL(Time to Live)은 자원 레코드의 생존 기간이다.

Name과 Value는 Type을 따른다. 즉, Type에 따라서 Name과 Value에 대한 semantic(해석법)이 달라진다.

 

Type = A

Address
Type A 레코드는 표준 호스트 이름의 IP 주소 매핑을 제공한다.

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

 

Type = NS

Name Server

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

 

Type = CNAME

Canonical NAME

• Name : 정식 호스트 이름의 alias name
• Value : 별칭 호스트 이름 Name에 대한 정식 호스트 이름

 

Type = MX

Mail eXchange

• Value : 별칭 호스트 이름 Name을 갖는 메일 서버의 정식 이름
• MX 레코드는 메일 서버의 호스트 이름이 간단한 별칭을 갖는 것을 허용한다.

 

메일 서버의 정식 이름을 얻기 위해서는 MX 레코드에 대한 질의를 해야 하고, 다른 서버의 정식 이름을 얻기 위해선 CNAME 레코드에 대한 질의를 한다.

 

DNS 서버가 특별한 호스트 이름에 대한 책임 서버이면, 그 DNS 서버는 호스트 이름에 대한 Type A 레코드를 포함한다.

서버가 호스트 이름에 대한 책임 서버가 아니라면, 그 서버는 호스트 이름을 포함하는 DNS 서버의 IP 주소를 제공하는 Type A 레코드도 포함할 것이다.

DNS 메시지

DNS의 요청과 응답 메시지는 모두 아래 그림과 같은 포맷을 갖고 있다.

header

처음 12 byte의 헤더 영역 : 여러 필드를 갖고 있다.

• 첫 필드는 질의를 식별하는 16 bit의 숫자이다.
  이 식별자는 질의에 대한 응답 메시지에 복사되어, 클라이언트가 보낸 질의와 수신된 응답 간의 일치를 식별하게 한다.
• 플래그(flag) 필드에는 여러 개의 플래그가 있다.
  • 1 비트의 질의/응답 플래그는 메시지가 질의인지 응답인지 구분하게 한다.
  • 1 비트의 책임 플래그는 DNS 서버가 질의 이름에 대해 책임 서버일 때 응답 메시지에 설정된다.
  • 1 비트의 재귀 요구 플래그는 DNS 서버가 레코드를 갖지 않을 때 재귀적 질의를 수행하기를 클라이언트가 원할 때 설정된다.
  • 1 비트로 된 재귀 가능 필드는 DNS 서버가 재귀 질의를 지원하면 응답에 설정된다.
• 나머지 4개의 '개수' 필드는 헤더 다음에 오는 데이터 영역의 네 가지 타입의 발생 횟수를 나타낸다.

payload

• 질문 영역
  • 현재 질의에 대한 정보를 포함한다.
  • 질의되는 이름을 포함하는 이름 필드와, 이름에 대해 문의되는 질문 타임을 나타내는 타입 필드를 나타낸다. (A, NS 등)
• 답변 영역
  • 원래 질의된 이름에 대한 자원 레코드를 포함한다. (value, TTL)
  • 여러 개의 자원 레코드를 보낼 수 있는데, 하나의 호스트 이름이 여러 개의 IP를 가질 수 있기 때문이다. (중복 웹 서버)
• 책임 영역
  • 다른 책임 서버의 레코드를 포함한다.
• 추가 영역
  • 다른 도움이 되는 레코드를 갖고 있다.
  • 예를 들어, MX 질의에 대한 응답에서 응답 필드는 전자메일 서버의 정식 호스트 이름을 제공하는 자원 레코드를 갖고 있고,
    추가 영역은 정식 호스트 이름에 대한 IP 주소를 제공하는 A 레코드를 포함한다.

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

도메인 네임 networkutopia.com을 등록 기관(DNS registrar)에 등록한다고 가정해보자.

등록 기관(DNS registrar)은 도메인 네임의 유일성을 확인하고,
그 도메인 네임을 DNS 데이터베이스에 넣고, 그 서비스에 대한 요금을 받는 상업 기관이다.

이전에는 작은 등록기관이 독점했었지만, 이제는 많은 기관이 경쟁하고 ICANN이 이러한 여러 등록기관을 승인해준다.

 

도메인 네임을 어떤 등록기관에 등록할 때 등록 기관에 주책임 서버와 부책임 서버의 이름과 IP 주소를 등록기관에 제공해야 한다.

• 주책임 서버 : dns1.networkutopia.com / 주책임 서버 IP : 212.2.212.1
• 부책임 서버 : dns2.networkutopia.com / 부책임 서버 IP : 212.2.212.2

위와 같다고 가정하자.

 

이 두 책임 DNS 서버 각각에 대해 등록 기관은 Type NS와 Type A 레코드가 TLD com 서버에 등록되도록 확인한다.

특히 주책임 서버의 경우 다음 두 개의 자원 레코드를 DNS 서버에 삽입한다.

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

 

또한, Type A 레코드와 메일 서버에 대한 Type MX 자원 레코드가 책임 DNS 서버에 등록되는 것을 확인한다.

이러한 모든 단계가 끝나면 여러 사람들이 웹 사이트를 방문할 수 있고, 전자메일을 보낼 수 있게 된다.

DNS 취약점

 

DDoS 대역폭 플러딩 공격

공격자는 DNS 루트 서버로 다량의 패킷을 보내려는 시도를 하여 다른 DNS 질의들이 응답을 받지 못하게 하려 한다.

실제로 이 일이 일어났지만, 많은 DNS 루트 서버들은 루트 서버로 향하는 공격자가 사용한 ICMP 핑 메시지를 블록하도록 형상화한 패킷 필터로 보호되었고,
대부분의 로컬 DNS 서버가 최상위 도메인 서버들의 IP 주소들을 캐싱하고 있어서 피해가 거의 없었다.

 

즉, 더 효과적인 공격은 최상위 도메인 서버를 공격하는 것이고, 실제로 최상위 도메인 서비스 제공자 Dyn에 이러한 일이 발생했다.

이는 유명 애플리케이션들이 무차별 교란되는 결과를 야기했다.

 

DNS 중독 공격

공격자는 DNS 서버로 가짜 응답을 보내어 그 서버가 자신의 캐시에 가짜 레코드를 받아들이도록 속임수를 쓴다.

이러한 공격은 웹 사용자들을 공격자의 웹사이트로 유도하는 데 이용될 수 있다.

이러한 공격을 막기 위해 DNS 보안 확장 프로토콜이 개발되어 사용되고 있다.