Ch2-4) Domane Name System : DNS

 

 

2.4 Domane Name System : DNS

• 보통, 인터넷 호스트에서 호스트를 식별할 때 www.facebook.com과 같은 호스트이름(hostname)을 주로 사용한다.
• 그러나, 이러한 hostname은 호스트의 위치정보를 거의 제공하지 않으므로, 라우터가 데이터를 전송하는데 어려움을 가지고 있다.
• 또한, 가변 길이의 알파뉴메릭으로 구성되므로, 라우터가 인식하기 어렵다.

→ 이러한 이유로 호스트들은 IP address라는 개념으로 식별된다.

• IP 주소란
  • 32bit으로 이루어진, hierarchical 위치정보이다. (4장에서 자세히 설명)

Services that DNS Provide

그렇다면, DNS란 무엇일까?

앞서, 호스트들을 식별하기 위해 호스트이름 대신 IP address를 이용한다고 했다.

이 차이를 절충하기 위해, 우리는 호스트이름을 IP address로 변환해주는 directory service가 필요하다

→ 이것이 바로 DNS의 주요 임무이다.

• DNS
  • Name server들의 계층구조로 표현된 Distributed Database이다.
  • Application layer protocol으로, 호스트가 distributed Database로 질의하도록 하는 protocol이다
    • 브라우저나 이메일 클라이언트가 DNS를 호출하면, 호스트와 name server가 통신해 name을 IP address로 바꾼다. (
  • DNS는 core internet Function이다.
    • 도메인 이름과 IP 주소를 변환해야 서버에 연결할 수 있다.
  • DNS는 사용자와 직접 상호작용해야하는 Network edge에 위치해있기에 복잡성을 지닌다.

⇒ 그럼, 이 DNS는 어떤 서비스를 제공할 수 있을지 알아보자.

• Hostname to IP address translation
• host aliasing
  • canonical, alias names
  • 하나의 서버에, 여러개의 alias를 제공할 수 있다.
  • Ex) Canonical 서버 이름은 serverserver.ibm.com인데 www.ibm.com과 www.ibmibm.com에 접속하면 모두 severserver.ibm.com에 접속하게 할 수 있음.
• Mail server aliasing
  • 메일 서버에도 alias 활용해 복잡한 서버 이름 간소화 및 도메인 기반 서버이름 사용 가능
  • ex) mail.google.com
• Load Distribution
  • 하나의 도메인에 여러 IP 주소를 매핑해, 부하를 줄인다
  • 예를들어, www.google.com이 여러 복제된 서버를 가리키면, 요청이 여러 서버에 분산되어 처리된다.

⇒ 앞서, DNS는 계층 구조를 띈다고 했다. 그렇다면, DNS는 왜 centralize 되지 않았는가?

• single point of failure
  • 하나로 합쳤다가 에러뜨면 큰일남.
• Traffic Volume
  • 트래픽 몰리면 큰일남
• Distant Centralized DB
  • 멀리 있으면 느려져서 큰일남
• Maintenance
  • 모든 데이터 하나에 모여있으면 유지보수할 떄 큰일남

또한, 확장성 문제도 존재한다. 예를들어 COMCAST DNS 서버는 하루에 6000억개 DNS쿼리 처리함. 확장 가능?

 

 

Heirarchical Architerture of DNS

 

DNS 서버의 종류에는, 크게 4가지 정도가 있다.

• Root DNS Server
  • 루트 서버는 하위 서버가 IP 주소를 알아낼 수 없을때 최후의 보루로 사용하는 서버이다.
  • 루트 서버는 인터넷이 동작하기 위해 매우 필수적이다.
    • 이를 위해 DNSSEC이라는 보안 기능을 사용한다.
      • Authentication, integrity 보장
  • 전 세계적으로, A~M까지의 13개의 Root server가 존재한다.
    • 하지만 실제로는 이러한 서버들이 여러대의 물리적 서버로 복제되어 운영된다.
    • 미국에만 200개의 물리적 서버가 있음 ㄷㄷ 역시 미국
  • ICANN (Internet Corporation for Assigned Name and Numbers)라는 단체에서 루트 DNS domain을 관리함.

• TLD server ( Top Level Domain )
  • .com, .org, .net, .edu와 같은 특정 상위 도메인이나, .jp, .kr등 국가 도메인을 관리한다.
  • 최상위 레벨에 해당하는 정보를 관리하며, 하위 도메인으로의 경로를 제공한다.
    • 예: www.example.com을 질의할 때, .com TLD 서버는 해당 도메인에 대한 권한 있는 DNS 서버로 연결한다.
  • Authoritative DNS server에 대한 IP 주소를 관리한다.
• Authoritative DNS server
  • 권한이 부여된 특정 DNS server을 관리한다.
  • organization이나 service provider에 의해 유지된다.
  • 인터넷에서 접근하기 쉬운 호스트를 가진 모든 기관은 호스트 이름을 IP 주소로 매핑하는 공개적인 DNS 레코드를 제공해야 한다.
    • 기관의 Authorative DNS 서버는 이 DNS 레코드를 갖고 있다.
    • 기관이 직접 자신의 DNS 서버 구현을 선택할 수 있고, Service provider의 Authoritative DNS 서버에이 레코드를 저장하도록 비용을 지불한다.
• Local DNS server
  • Local DNS server은 엄격하게 계층구조에 속하지는 않지만, DNS system에서 중요하다.
  • ISP는 로컬 DNS server을 가지고, 이 서버로부터 호스트에 IP 주소를 제공한다.
  • 대체로 호스트 근처에 있어 지연이 적다.

→ Root > TLD > Authoritative 순임 !.

이때 Host가 원하는 도메인의 주소를 얻는 과정엔 총 2가지가 존재한다. 예를들어서 ,다음과 같은 상황을 가정해보자.

host at engineering.nyu.edu wants IP address for gaia.cs.umass.edu

 

 

1. Iterated Query 방식

 

1. 호스트는, 자신의 로컬 DNS 서버에 질의를 보내는데, 변환하고 싶은 hostname도 함께 보낸다
2. Local DNS는 Root DNS로 전달한다.
3. Root는 여기서 .edu 확장자를 인식하고, 이를 관리하는 TLD DNS server의 ip 주소를 Local DNS server로 보낸다.
4. Local DNS는 TLD DnS Server로 질의를 전달한다.
5. TLD는 여기서 umass.edu를 인식하고, dns.umass.edu를 가진 authoritative DNS server의 주소를 가르쳐준다
6. Local DNs는 Authoritative DNS Server에 질의를 전달한다
7. 마침내 알아낸다
8. Local DNS는 호스트에게 알아낸 IP 주소를 전달한다.

 

 

 

2. Recursive query

 

 

 

그림을 읽어보면, root DNS server로부터 Recursive하게 하위 계층으로 이동하며 IP address를 탐색하는 것을 확인할 수 있다.

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

• 재귀적 질의에서는 높은 계층에 있는 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 Caching

• Namer server가 한 번 도메인 이름과 IP address를 학습하면, 캐싱해서 정보를 저장한다.
• 캐시된 엔트리는 TTL(Time To Live)기간이 끝날 때 까지 남아있는다.
• 로컬 서버는 TLD 서버로부터 매핑 정보를 가져와 캐싱한다.
  • 루트 서버는 너무 트래픽이 많아 최대한 접근하지 않는 것이 좋음.

→ 그러나, 캐싱된 DNS 정보가 최신 것이 아닐 수 있다는 단점이 있음. (out-of-date problem)

• 호스트가 새로운 IP 주소로 변경될 경우, 기존의 오래된 IP주소가 캐시에 남아있게 됨

→ Cache는 best-effort 방식으로 이름과 주소를 매핑한다 !

캐시 갱신 메커니즘은, RFC 2136에 따름

DNS Records

• DNS 서버는, 호스트 이름을 IP주소로 매핑하기 위한 Resource records를 저장한다.
• Resource record는 4개의 field를 포함하는 tuple 형태이다.

(Name, Value, Type, TTL)

• 이때 TTL은 Time-to-Live이고, Name과 Value는 Type에 따라 semantic이 달라지게 된다.

1. Type = A
   • Address type인 경우
   • Name = hostname / Value = IP address이다.
2. Type = NS (Name Server)
   • Name = domain ( foo.com ) / Value = 도메인 내부의 호스트의 IP 주소를 얻을 수 있는 DNS 서버의 호스트 이름
3. Type = CNAME ( Canonical NAME)
   • Name = Canonical host name 에 대한 alias name / Value = Canonical host name
4. Type = MX (Mail eXchange)
   • Name = alias / Value= Name과 연관된 mailserver의 name 이다.

 

DNS Protocol message

• DNS query와 reply message는 모두 아래와 같은 format을 가지고 있다.
•  

 

 

 

• 처음 12 byte의 헤더 영역은, 여러 필드를 가지고 있다.
  • identificaiton field는 query를 식별하는 16bit의 숫자이다.
    • 이 식별자는 질의에 대한 응답 메시지에 복사되어, 클라이언트가 보낸 질의와 수신된 응답 간의 일치를 식별하게 한다.
  • Flag 필드에는 여러가지 속성이 존재한다.
    • query or reply : 질의 / 응답인지 구분
    • recursion desired: DNS가 record를 갖지 않을 때 client가 recursion query를 수행하기를 원할 때 설정
    • recursion available : recursion query 가능하면 설정
    • reply is authoritative : 답장 온 DNS 서버가 authoritative server일때 설정
  • 나머지 4개의 '개수' 필드는 헤더 다음에 오는 데이터 영역의 네 가지 타입의 발생 횟수를 나타낸다.
• 밑의 Payload 영역은 다음과 같다.
  • Questions 영역
    • 현재 질의에 대한 정보를 포함한다.
    • 질의되는 name을 포함한 name field와 이 name 에 대한 type을 서술 ( A, NS 등)
  • Answers 영역
    • 원래 요청한 name에 대한 Resource Record 포함 ( 걍 답변 왔다는 소리임)
    • 여러개가 올 수도 있음. (하나의 host name이 여러개의 IP address 가질 수 있기 때문)
  • Authority 영역
    • Authority server에 대한 Resource record 정보 포함
  • Additional info 영역
    • 다른 도움이 되는 Record 포함
• MX 질의에 대한 응답에서 Answer 필드는 전자메일 서버의 정식 호스트 이름을 제공하는 Resource record를 갖고 있고, Additional info 영역은 정식 호스트 이름에 대한 IP 주소를 제공하는 A 레코드를 포함한다.

⇒ 그러면, 이러한 record들은 어떻게 DNS에 넣는 것일까?

Inserting records into DNS

예를들어서, “Network Utopia”라는 스타트업이 “networkutopia.com”이라는 도메인을 등록하려고 하면,

1. DNS registrar를 통해 등록한다.
   • DNS registrar은, domain name의 uniqueness를 확인하고, domain name을 db에 넣은 후 요금을 받는 상업 기관이다.
     • 이전에는 작은 등록기관이 독점했지만, 이제는 많은 기관이 경쟁하고, ICANN이 이 등록기관들을 승인해준다.
   • registrar에 등록할 때에는 primary와 secondary IP address를 입력해야한다.
     • primary authoritative 서버 : dns1.networkutopia.com / 주책임 서버 IP : 212.2.212.1
     • secondary authoritative 서버 : dns2.networkutopia.com / 부책임 서버 IP : 212.2.212.2
2. 이후 두개의 Authoritative DNS 서버에 대해서, 등록기관은 NS와 A type record가 TLD com 서버에 등록되도록 확인한다.
   • 특히 primary authoritative server의 경우, 아래와 같은 Resource Record를 DNS 서버에 넣는다.

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

3. 마지막으로, Type A 레코드와 Type Mx resource record가 Authoratative DNS server에 등록되는 것을 확인한다.

Type = A

• Address type인 경우
• Name = hostname / Value = IP address이다.

1. Type = NS (Name Server)
   • Name = domain ( foo.com ) / Value = 도메인 내부의 호스트의 IP 주소를 얻을 수 있는 DNS 서버의 호스트 이름

 

DNS Security

• 이러한 DNS에도 취약점은 존재한다.
• DDoS attacks
  • Root server에 대량의 트래픽을 보내 다른 DNS request가 응답을 받지 못하도록 한다.
  • 실제로 이 일이 일어났지만, 많은 DNS 루트 서버들은 루트 서버로 향하는 공격자가 사용한 ICMP 핑 메시지를 블록하도록 형상화한 패킷 필터로 보호되었고, 대부분의 로컬 DNS 서버가 최상위 도메인 서버들의 IP 주소들을 캐싱하고 있어서 피해가 거의 없었다.
  • Root가 아닌 TLD에 공격을 하면 더 위험할 수 있는데, TLD 서버가 고갈되면 전체 네트워크가 마비될 확률이 높기 때문이다.
• Redirect attack
  • Man-in-middle 공격
    • DNS query를 intercept해 악의적인 주소로 redirect시키는 방법이다.
  • DNS Poisoning
    • 가짜 응답을 DNS에 제공하고, 서버는 이 정보를 캐싱한다.
    • 이후 해당 가짜 응답을 캐싱하는 호스트들은 잘못된 사이트로 redirect 된다.

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