컴퓨터 네트워크

컴퓨터 네트워크 2장 - DNS: 인터넷의 디렉터리 서비스

으엉어엉 2024. 4. 12. 16:28
728x90

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

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

 

그러나

  1. 호스트의 이름은 인터넷에서의 호스트 위치에 대한 정보를 거의 제공하지 않는다.
  2. 가변 길이의 알파뉴메릭 문자로 구성되므로 라우터가 처리하는 데 어려움이 있다.

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

 

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

  • 사람 : 호스트 이름 식별자 선호
  • 라우터: 고정 길이의 계층구조를 가진 IP주소 선호

-> 절충하기 위해 IP주소를 변환해주는 디렉터리 서비스가 필요 => 이것이 인터넷 DNS 주요 임무

 

DNS

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

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

 

 

사용자의 호스트에서 수행하는 브라우저가 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 네크워크 트래픽 감소에 도움을 준다.

 

 

 

부하 분산 (load distribution)

 

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

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

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

 

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

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

 

2.4.2 DNS 동작 원리 개요

DNS가 어떻게 동작하는지를 살펴본다. -> 여기서 호스트 이름을 IP주소로 변환하는 서비스에 초점

사용자의 Host에서 실행되는 애플리케이션이 Host 이름을 IP주소로 변환 가정.. 그 애플리케이션은 변환될 Host 이름을 명시하여 DNS측의 클라이언트에 요청.

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

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

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

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

 

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

 

계층 DNS 서버

루트(root) DNS 서버

  • 1000개 이상의 루트 서버 인스턴스가 세계에 흩어져 있다.
  • 루트 네임 서버는 TLD 서버의 IP 주소들을 제공한다.

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 주소를 호스트에게 제공한다.
  • 대체로 호스트에 가까이 있기 때문에 지연이 적다.
  • 유효기간이 있다.

DNS name resolution: iterated query

 

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

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

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

DNS name resolution: recursive query

 

 

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

 

DNS 캐싱

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

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

 

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

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

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

Cash로 응답시간이 줄어들 수 있다. 하지만 No Guarantee

캐시된 항목은 오래되었을 수 있다. 최선을 다하지만 최신을 보장하진 않는다.

 

2.4.3 DNS 레코드와 메시지

 

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

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

 

Type = AAddress

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 레코드는 메일 서버의 호스트 이름이 간단한 별칭을 갖는 것을 허용한

 

 

DNS 취약점

DDoS 대역폭 플러딩 공격

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

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

 

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

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

728x90