호스트를 구별할 수 있는 식별자에는 무엇이 있을까?

1. Hostname

   • 인터넷에서 호스트 위치에 대한 정보는 거의 제공하지 않는다.

2. IP address

   • 4바이트로 구성된 계층 구조
   • 0~255의 십진수로 표현하고 각 바이트는 점으로 구분한다.

A) DNS Service

What is DNS?

Domain Name System

1. DNS 서버들의 계층 구조로 구현된 분산 데이터 베이스

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

2. 호스트가 분산 데이터 베이스로 요청을 보내도록 허락하는 애플리케이션 계층 프로토콜

3. DNS는 Transport Protocol로 UDP를 사용하고 포트 번호 53을 이용한다.

DNS의 임무

다른 애플리케이션 프로토콜들에서(HTTP, SMTP, FTP 등) 사용자가 제공한 호스트 이름을 IP 주소로 변환하는 것

DNS: 호스트 이름 > IP 주소 변환 과정

어떤 호스트에서 수행되는 브라우저가 URL www.someschool.edu/index.ftml을 요청하는 상황을 가정하자. 브라우저가 웹 서버에 HTTP 요청을 보내기 위해선 IP 주소를 얻어야만 한다.

1. 같은 사용자 컴퓨터는 DNS 애플리케이션의 클라이언트라고 볼 수 있다.

2. 브라우저는 URL로부터 호스트 이름 www.someschool.edu를 추출하고 그 호스트 이름을 DNS 애플리케이션의 클라이언트 측에 넘긴다.

3. DNS 클라이언트는 DNS 서버로 호스트 이름을 포함하는 질의를 보낸다.

4. DNS 클라이언트는 결국 호스트 이름에 대한 IP 주소를 가진 응답을 받게 된다.

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

DNS의 추가 서비스

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

   • 예를 들어, relay1.west-coast.enterprise.com의 호스트 이름은 enterprise.com과 www.enterprise.com 같은 2개의 별칭을 가질 수 있다.
   • Canonical Hostname: relay1.west-coast.enterprise.com

2. Mail Server Aliasing

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

3. Load Distribution

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

   • DNS 데이터베이스는 이 IP 주소 집합을 갖고 있다.

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

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

     • 순환식으로 보낸다는 것은 DNS는 같은 도메인에 대해 갖고 있는 IP 주소집합에 대해 클라이언트마다 순차적으로 IP 주소를 제공한다. (클라이언트1 - IP1, 클라이언트2 - IP2 ...)

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

DNS Overview of the Operation

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

DNS Query는 도메인의 뒤에서부터 읽어들인다.

동작 과정

1. 애플리케이션은 변환될 호스트 이름을 명시하여 DNS 클라이언트 라이브러리를 호출하여 해당 호스트 이름의 IP 주소를 요청

   • DNS는 애플리케이션 계층 프로토콜로 구성되어 있다.

2. DNS 클라이언트는 요청한 호스트 이름을 포함하는 DNS 질의 메시지를 생성

3. DNS 클라이언트는 사용자 호스트의 로컬 DNS 서버에 DNS 요청을 전송

   • 이때 질의 메시지는 UDP 데이터그램 형태로 전송되며, DNS 프로토콜의 기본 포트 번호인 포트 53을 사용

4. DNS 서버는 요청한 매핑에 해당하는 DNS 응답 메세지를 사용자 호스트의 DNS로 전송.

   • 이 과정에서 DNS 서버에서 요청한 호스트 이름에 맞는 IP 주소를 찾는데 시간(지연)이 걸린다.

5. DNS 클라이언트는 DNS 서버로부터 온 DNS 응답 메세지를 받고 애플리케이션으로 전달한다.

DNS 방식의 문제점

DNS가 간단한 모든 IP 주소를 가지고 있는 중앙 집중 방식(centralize) 이라면 오늘날의 인터넷에는 수많은 호스트를 가지고 있긴 때문에 문제가 발생한다.

1. 서버의 고장: 이 네임 서버가 고장 나면, 전체 인터넷이 작동하지 않는다. (single point of failure)

2. 트래픽 양의 과부하: 단일 DNS 서버가 모든 질의를 해결해야 한다.

3. 먼 거리의 중앙 집중 데이터베이스: 단일 DNS 서버가 모든 질의 클라이언트로부터 '가까울' 수만은 없다.

   • 즉, 멀면 멀수록 모든 질의가 느려진다.

4. 유지 관리: 단일 네임 서버는 모든 인터넷 호스트에 대한 레코드를 유지해야 한다.

   • 모든 새로운 호스트를 반영하기 위해 자주 갱신되어야 하고, 사용자에게 호스트를 등록할 수 있도록 허용하는 것과 관련된 인증 문제가 있다.

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

Distributed Hierarchical Database (분산 계층 데이터베이스)

어떠한 단일 DNS 서버도 모든 호스트에 대한 매핑을 갖지 않는 대신에 그것은 DNS 서버 사이에 분산된다.

위에서부터 Root DNS 서버, Top-Level Domain DNS 서버, Authoriative 서버이다.

Root DNS Server

• 1000개 이상의 루트 서버 인스턴스가 전 세계에 흩어져있다.
  • 현재 13개의 루트 서버 인스턴스가 존재
• IANA 2020 (인터넷 할당 번호 관리기관)에 의해 관리된다.
• TLD 서버의 IP 주소들을 제공한다.

Top-Level Domain(TLD) Server

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

Authoriative Server

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

Distributed Hierarchical Database에서의 상호작용

어떤 DNS 클라이언트가 호스트 이름(www.amazon.com)의 IP 주소를 결정하기를 원하는 상황을 가정하자.

1. DNS 클라이언트가 Root Server 중 하나에 접속한다.

2. Root Server는 top-level domain "com"을 갖는 TLD Server IP 주소를 DNS 클라이언트에게 보낸다.

3. DNS 클라이언트는 (2) 과정의 TLD Server 중 하나에 접속한다.

4. TLD Server는 amazon.com을 가진 Authoriative Server의 IP 주소를 DNS 클라이언트에게 보낸다.

5. DNS 클라이언트는 (4) 과정의 Authoriative Server 중 하나에 접속한다.

6. Authoriative Server는 www.amazon.com의 IP 주소를 보낸다.

Local DNS Server

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

Local DNS Server가 있을 때의 DNS 계층 구조의 상호작용

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

TLD Server가 Authoriative Server를 직접 알고 있는 경우

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 주소를 응답한다.

TLD Server가 Authoriative Server를 직접 알진 못하고 Authoriative Server를 아는 중간 DNS만 알고 있는 경우

위의 경우보다 일반적인 경우이다.

• 로컬 DNS Server가 중간 DNS로 질의하고 응답받는 2개의 DNS 메세지가 추가된다.

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

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

Recursive Query

클라이언트가 DNS 서버에 질의를 보낼 때, 서버가 요청한 정보를 찾기 위해 필요한 모든 단계의 질의를 처리하는 방식

• 즉, DNS 서버가 자신의 정보가 아닌 다른 DNS 서버에 질의를 보내고, 그 응답을 클라이언트에게 반환합니다.
• puts burden of name resolution on contacted name server
• 상위 DNS 서버가 책임져야할 것이 많다.

Iterative Query

클라이언트가 DNS 서버에 질의를 보낼 때, 서버가 자신의 데이터베이스에서 가능한 한 많은 정보를 찾고, 해당 정보를 기반으로 다음 DNS 서버에 대한 질의를 클라이언트에게 알려주는 방식

이 사진은 위의 예시에서 모두 Recursive Query로 이루어져있을 때의 DNS 질의를 보여준다.

DNS Caching

DNS 서버가 DNS 응답을 받았을 때 로컬 메모리에 응답에 대한 정보를 저장하는 것

• 지연 성능 향상과 네트워크의 DNS 메세지 수를 줄이기 위해서 사용한다.
• 만약 로컬 메모리에 저장된 호스트 이름에 대한 책임이 없을 때조차 원하는 IP 주소를 제공할 수 있다.
• DNS 서버는 어떤 기간(TTL, Time to Live) 이후에 저장된 정보를 제거한다.
• TLD servers typically cached in local name server

C) DNS Record & Message

DNS Resource Record (RR)

호스트 이름을 IP 주소로 매핑하기 위해 저장하는 것

• 각 DNS는 하나 이상의 RR을 가진 메세지로 응답한다.

• RR는 4개의 Tuple로 이루어져 있다.

  	- (Name, Value, Type, TTL)

• Type에 따라 Name, Value가 달라진다.

Type

1. Type = A

   • Name: 호스트 이름
   • Value: 호스트 이름에 대한 IP 주소
   • DNS 서버가 특별한 호스트 이름에 대한 책임 서버인 경우에 포함
   • DNS 서버가 특별한 호스트 이름에 대한 책임 서버가 아닌 경우에도 호스트 이름을 포함하는 DNS 서버의 IP 주소를 제공하는 Type A 레코드가 있을 수 있다.

2. Type = NS

   • Name: 도메인
   • Value: 도메인 내부의 호스트에 대한 IP 주소를 얻을 수 있는 방법을 아는 Authoriative DNS의 호스트 이름
   • 서버가 호스트 이름에 대한 책임 서버가 아닌 경우에 포함

3. Type = CNAME

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

4. Type = MX

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

DNS Message

DNS 요청/응답 메세지 모두 위와 같은 형식을 가지고 있다.

Header Section

처음 12 바이트 부분으로, 여러 필드를 갖고 있다.

첫 번째 필드 (Identification)

질의를 식별하는 16비트의 숫자

• 이 식별자는 질의에 대한 응답 메시지에 복사되어, 클라이언트가 보낸 질의와 수신된 응답 간의 일치를 식별하게 한다.

두 번째 필드 (Flags field)

• 1 비트의 query and reply 플래그는 메시지가 요청(0)인지 응답(1)인지 구분하게 한다.
• 1 비트의 reply is authorizative 플래그는 DNS 서버가 질의 이름에 대해 책임 서버일 때 응답 메시지에 설정된다.
• 1 비트의 recursion desired 플래그는 DNS 서버가 레코드를 갖지 않을 때 재귀적 질의를 수행하기를 클라이언트가 원할 때 설정된다.
• 1 비트로 된 recursion available 필드는 DNS 서버가 재귀 질의를 지원하면 응답에 설정된다.

나머지 필드

나머지 4개의 '개수' 필드는 헤더 다음에 오는 데이터 영역의 네 가지 타입의 발생 횟수를 나타낸다.

Question Section

현재 질의에 대한 정보를 포함한다.

1. Name Field

   • 질의되는 이름 포함한다.

2. Type Field

   • 질의되는 질문 타입을 나타낸다.

Answer Section

원래 질의된 이름에 대한 RR를 포함한다.

• 여러 개의 자원 레코드를 보낼 수 있는데, 하나의 호스트 이름이 여러 개의 IP를 가질 수 있기 때문이다. (중복 웹 서버)

Authority Section

다른 책임 서버의 레코드를 포함한다.

Additional Section

다른 도움이 되는 레코드를 포함하고 있다.

• 예를 들어, MX 질의에 대한 응답에서 응답 필드는 전자메일 서버의 정식 호스트 이름을 제공하는 자원 레코드를 갖고 있고, 추가 영역은 정식 호스트 이름에 대한 IP 주소를 제공하는 A 레코드를 포함한다.

Question, Answer, Authority, Additional Section은 Payload라고도 한다.

D) DNS DB에 Record 삽입

Register

도메인 네임의 유일성을 확인하고, 그 도메인 이름은 DNS DB에 넣고, 그 서비스에 대한 약간의 요금을 요구하는 상업 기관.

ICANN (Internet Corporation for Assingned Names and Numbers)

Register를 승인해주는 기관
Root DNS Server를 관리

과정

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

주책임 서버 : dns1.networkutopia.com / 주책임 서버 IP : 212.2.212.1
부책임 서버 : dns2.networkutopia.com / 부책임 서버 IP : 212.2.212.2
위와 같다고 가정하자.

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

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

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

3. 부책임 서버도 마찬가지로 다음 두 개의 자우너 레코드를 DNS 서버에 삽입한다.

(networkutopia.com, dns2.networkutopia.com, NS)
(dns2.networkutopia.com, 212.2.212.2, A)

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

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

DNS 취약점

DDoS 대역폭 플러딩 공격

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

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

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

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

DNS 중독 공격

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

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

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