이것저것 많은 DNS(Domain Name System)

Rosevillage·2024년 6월 21일
network
0

DNS를 간단하게 설명하자면, 웹 서비스에 접근할 때 웹서버의 ip주소를 그대로 사용하는 대신 사람이 읽기 편한 일정 패턴을 지닌 문자열(도메인 네임)을 통해 접근할 수 있도록 해주는 계층적 네이밍 시스템이라 할 수 있다.

간소화 해서 이해하기

도메인 네임

도메인 네임은 label이라는 요소들의 조합으로 이루어졌으며, 특정 네트워크 주소(ip 주소)와 1:1로 매칭되는 이름이다. .(dot)을 기준으로 나누어진 각 문자열을 label이라 하며, 가장 오른쪽의 lebel부터 특정 계층의 도메인에 속한다.
www.example.com을 예시로 들면

  • com: top level domain 계층의 com도메인에 소속
  • example: second level domain 계층의 example.com도메인에 소속
  • www: sub domain 계층의 www.example.com도메인에 소속(호스트 이름)
    이처럼 도메인 네임의 label은 각각 특정 도메인에 소속되고, 특정 도메인 네임 계층에 속한다.

도메인 네임을 통해 네크워크 주소(IP 주소)를 찾아오는 과정

위의 설명만 읽어도 우리가 브라우저를 통해 www.google.com에 접속하면, DNS를 통해서 구글 서버의 IP주소를 가져오고, 가져온 IP주소를 통해 http 통신을 하게 된다는 것은 간단하게 이해할 수 있다.

부가적인 상황은 다 빼고 기본적으로 우리가 www.google.com을 주소창에 검색하면 어떻게 되는지 살펴보면 다음과 같은 과정을 거치게 된다.

www.google.com검색

브라우저 주소창에 원하는 도메인 네임을 검색하면 우리의 컴퓨터는 도메인 네임을 가지고 네트워크 주소를 찾는 요청을 랜선 혹은 와이파이를 통해서 공유기를 거쳐 ISP(인터넷 서비스를 제공하는 회사 ex: kt, skt, lg u+,...)의 DNS 서버에 전달한다. 이러한 서버를 흔히 Local DNS Server라고 부른다.

개념적으로는 Resolver라는 프로그램이 도메인 네임을 가지고 주소를 찾아오는 역할을 하나, 간소화된 과정에서는 도메인 네임의 변환 과정을 이해하기 용이하도록 Local DNS Server를 통해 실제로 도메인 네임이 네트워크로 변환되는 동작 방식을 설명한다.
자세한 설명은 아래 조금 더 자세히 알아보기의 Resolver를 참고하면 된다. 간소화된 과정만 가지고도 맥락상 틀린 부분은 없기에 맞는 과정이라고 이해하면 된다. 다만 부가적인 설명이 덧붙을 수 있을 뿐이다.

Local DNS Server의 네트워크 주소 찾기

Local DNS Server는 들어온 요청을 가지고 도메인 네임의 오른쪽부터 왼쪽으로 네트워크 주소를 찾을 때까지 특정 계층에 속하는 도메인의 관리 서버에 주소가 있는지 물어본다.

이 과정은 마치 관공서의 전화 돌리기와 비슷한 양상을 보인다.
민원(도메인 네임)이 들어온 각 부서(도메인 서버)에 메뉴얼(주소)이 없으면 다른 부서(하위 도메인)로 안내한다.

  1. TLD Server
    • Local DNS Server : www.google.com 주소 있나요?
    • TLD Server: 저희쪽 담당이 아니라 google.com 담당하는 부서로 연결해드릴게요.
  2. SLD Server
    • Local DNS Server : www.google.com 주소 있나요?
    • SLD Server: 저희쪽 담당이 아니라 www.google.com 담당하는 부서로 연결해드릴게요.
  3. Sub Domain Server
    • Local DNS Server : www.google.com 주소 있나요?
    • Sub Domain Server: 네 주소는 123.456.789.012입니다.

이러한 과정이 발신 측에서 재귀적인 모습을 띄기에 재귀 쿼리라 부른다.

찾은 주소를 사용자에게 전달

Local DNS Server가 수집한 네트워크 주소를 요청을 보낸 우리에게 응답으로 전달해주고, 우리는 그 주소를 통해서 www.google.com의 웹 서비스에 접근할 수 있게 된다.

DNS를 이루는 구조

위의 간소화된 과정에서 몇가지 특징적인 요소들을 볼 수 있다.

  • 도메인 네임에 해당하는 주소를 요청하는 사용자
  • 요청을 받아 도메인 네임을 통해 주소를 검색하는 Local DNS Server : Resolver
  • 도메인 네임의 계층적인 구조: Domain Name Space
  • 도메인 관리 서버: Name Server

도메인 네임 공간(Domain Name Space)

도메인 네임 스페이스는 트리 형태로 재 구성된 도메인 네임이다. 트리의 각 노드(Zone)는 자신에게 해당되는 도메인에 대한 정보를 가지며, 루트 존에서 시작해 여러개의 하위존으로 나뉜다.

Zone, resource record와 같은 생소한 요소에 대해 알아보기전에 도메인 계층이 어떻게 생겼는지 먼저 살펴본다.

도메인 계층

도메인 네임은 여러 label로 구성되어 있으며, 각 label은 특정 도메인 계층에 속해 있다.
도메인 계층은 최상단 도메인부터 최하단 도메인까지 Root domain - Top Level Domain - Second Level Domain - Sub Domain으로 구분 되어진다.

계층 별로 도메인을 나눠 표현한 경우

도메인들의 관계를 표현한 경우

Root Domain

모든 도메인 네임의 가장 오른쪽에 .(생략 가능) 형태로 표시되며, 모든 도메인 네임의 최상단 계층이다.
루트 도메인은 인터넷의 모든 top level domain에 대한 참조를 포함한다.

TLD(Top Level Domain)

우리가 흔하게 접하는 .com등 도메인 네임에서 Root domain을 제외한 가장 우측 부분을 가리킨다. 일반적으로 .com, .net등의 일반 최상위 도메인과 .kr등의 국가 코드 최상위 도메인으로 나뉜다.

  • 일반 최상위 도메인(gTLD)
    com, net, org, biz, info 등의 도메인을 포함한 약 1,200개가 넘는 도메인들이 여기해 해당한다. 일반적으로 국가 코드 최상위 도메인을 제외한 최상위 도메인이 일반 최상위 도메인이라고 생각하면 편하다.{5}
  • 국가 코드 최상위 도메인(ccTLD)
    국제적으로 각나라, 특정 지역 또는 국제단체에 주어진 도메인으로, 일반적으로 각 나라의 영어식 이름을 줄인 것이 사용된다. 국가 도메인을 나타낼때는 언제나 앞에 점을 찍어 사용하는 것을 원칙으로 하고 있다. 대한민국의 경우에는 .kr 또는 .co.kr을 사용한다

SLD(Second Level Domain)

TLD의 하위 도메인을 뜻하며, 도메인 네임에서 TLD 다음에 위치한 부분을 가리킨다. example.com이라는 도메인 네임은 .com이라는 TLD 하위의 SLD이다.
보통 도메인 이름 등록 기관에 도메인 네임을 등록한 조직을 가리킨다

Sub Domain

각 도메인의 하위 도메인(SLD는 TLD의 sub domain)을 의미하나, 일반적으로 SLD 다음 차수의 도메인을 지칭하는 용도로 쓰이고 있다. www.example.com에서 www나 m.example.com(모바일 버전 페이지)에서 m이 이에 해당한다.

네임 서버(Name Server)

네임 서버(혹은 DNS Server라고 부른다)는 DNS에서 쿼리를 통해 도메인 네임을 네트워크 주소로 변환하여 사용자에게 제공하는 서비스를 제공한다.
네임 서버는 역할에 따라 크게 두가지 종류로 나눌 수 있다.

Recursive Name Server

사용자의 재귀 쿼리를 받아 다른 네임 서버와 통신하고, 네트워크 주소를 찾아오는 서버이다. ISP DNS Server(Local DNS Server), Recursive Resolver 라고도 부르며, google 등의 Public recursive server도 포함되는 개념이다.

Authoritative Name Server

authoritative name server는 특정 도메인에 대해 최종적인 DNS 정보를 보유하고 관리하는 서버로, recursive server와 통신하여 자신이 관리하는 도메인 네임에 해당하는 네트워크 주소나, 하위 계층의 네임 서버의 참조를 반환해준다.

위 도메인 계층에서 존재하는 각 도메인에 대한 서버가 이에 해당하지만 Root Name Server와 TLD Name Server는 최종적인 네트워크 주소를 관리하고 있진 않기 때문에 SLD나 SubDomain의 네임 서버 중 최종적으로 네트워크 주소를 반환하는 서버를 지칭하는 용도로 사용하기도 한다.

조금 더 자세하게 알아보기

위의 설명들만 읽어도 DNS의 전체적인 동작 흐름은 파악이 가능하다. 여기서 부터는 name space를 구성하는 요소들 같은 조금 더 작은 부분을 살펴본다.

호스트 이름

네트워크에 연결된 장치들에게 부여되고, 월드 와이드 웹(www), 전자 우편(email) 등의 다양한 형태의 네트워크 시스템에서 장치를 식별하는데 사용되는 label이다. 호스트 이름은 두가지 형태를 지니는 개념이다.

  • 호스트 로컬 이름: 단일 label 형태를 가진다. ex)www, email
  • 인터넷 호스트 이름: .으로 호스트별 label과 구분된 도메인 네임이 추가된 구조화된 형태로 호스트 로컬 이름과 도메인 상위 도메인 네임의 조합이다. 일반적으로 호스트의 네트워크 주소와 함께 DNS 저장되는 경우가 많다.

인터넷에서 호스트 이름은 호스트 컴퓨터에 할당된 인터넷 호스트 이름이다. 이런 경우 호스트 이름을 도메인 네임이라 부르기도 한다. 최상위 도메인을 포함한 완전한 형태인 경우(www.example.com) 이 호스트 이름을 FQDN(정규화된 도메인 네임)이라고도 한다.

DNS와 관련해서 여러 글들을 참고하다 보면, 호스트 이름과 도메인 네임을 비슷한 역할로 사용해 햇갈리는 경우가 있는데, 호스트 이름과 도메인 네임의 관계는 다음과 같이 정리할 수 있다.

  • 호스트 이름: 인터넷 호스트 이름의 형태를 가지며, DNS로 적절하게 구성되었을 경우 도메인 네임이 될 수 있다.
  • 도메인 네임: 인터넷 호스트에 할당되고 호스트의 네트워크 주소와 연결되었을 경우 호스트 이름이 될 수 있다.

존(Zone)

Zone은 특정 조직이나 관리자(관리 권한을 가지는 네임 서버)가 관리하는 도메인 네임 공간(domain name space)의 특정 부분으로, 각 Zone은 0개 이상의 RR(resource record)라는 도메인 리소스를 포함한다.

관리자의 관리 권한은 분할 될 수 있다. 권한이 분리 됨에 따라 새로운 존이 형성되기도 하는데. DNS의 동작 흐름에 따라 시선이 분할된 하위 존으로 이동할 경우 상위 존의 기존 권한은 효력을 잃는다.

각각의 Zone은 완벽하게 분리되어 있지 않다. 한 zone에 여러 하위 도메인이 포함될 수 있고, 동일한 네임 서버에 여러 Zone이 존재할 수도 있다.

사실 Zone은 네임 서버의 관리 권한에 대한 논리적인 구획이다. 즉, Zone은 물리적으로 존재가 아니라 개념적 존재라는 것이다. DNS의 구조인 Name Space의 핵심은 네임 서버이다.

zone file

Zone은 개념적 존재이나, 물리적으로 그 역할이 필요하다 . 그래서 zone file을 통헤 Zone을 물리적으로 표현한다.
zone file은 네임 서버 내부에 위치하며, Zone이 0개 이상의 RR을 포함하는 것처럼 물리적 형태인 zone file은 RR을 물리적으로 보유하고 있다. 일종의 RR의 모음을 zone file이라 봐도 무방하다.

네임 서버는 이러한 zone file을 통해 도메인 네임에 대한 정보를 확인하고 쿼리에 응답할 수 있게 된다.

Resource Record(RR, 리소스 레코드)

RR(Resouce Record)은 도메인 네임과 resource를 매핑하여 하나의 분산 데이터 베이스를 구성하는 요소이다. 이는 RR이 DNS라는 분산 데이터 베이스 시스탬의 엔트리라는 것을 의미한다.

RR은 몇가지 필드를 통해 자신이 속한 권한 있는 네임 서버의 도메인에 대한 ip주소, 메일 서버, 네임 서버 등의 정보를 표현한다.

RR 필드

  • NAME : 도메인 네임
  • TYPE : RR의 유형을 나타내며, 유형에 따라 저장된 데이터의 형식이 결정된다.
  • TTL(time to live) : 캐시 유효 기간을 초 단위로 나타내며, 해당 기간 동안 RR은 캐시에 저장된다.
  • CLASS :
    • ANY : 모든 주소
    • IN : 인터넷
    • CHAOS : Chaos net
  • RDLENGTH : RDATA의 길이를 지정하는 16비트 정수
  • RDATA : type에 따른 다양한 데이터(ip 주소, 메일 서버의 도메인 네임 등)를 포함한다.

RR Type

  • A (Address Record) : IPv4 주소
    • www.example.com IN A 127.0.0.1
  • AAAA (IPv6 Address Record) : IPv6 주소
    • `www.example.com IN AAAA 0:0:0:0:0:0:0:1
  • CNAME (Canonical Name Record) : 별칭 도메인 네임을 정의하며, 도메인 네임을 다른 도메인 네임에 매핑한다.
    • www.example.com IN CNAME example.com
  • MX (Mail Exchange Record) : 메일 서버 정보, 우선 순위 값과 함께 메일 서버의 도메인 네임을 지정한다.
    • example.com IN MX 10 mail.example.com
  • NS (Name Server Record) : 권한 있는 네임 서버의 도메인 네임
    • example.com IN NS ns1.example.com
  • SOA (Start of Authority Record) : DNS Zone의 시작을 나타내며 권한 있는 네임서버와 존 관리자의 이메일 주소, 일련 번호, 갱신 간격 등을 포함한다.
    • example.com IN SOA ns1.example.com. admin.example.com. 0000000000 0000 0000 0000000 00000
  • TXT (Text Record) : 텍스트 데이터를 포함하며 주로 도메인 소유권 확인, 이메일 인증 등 다양한 용도로 사용된다.
    • example.com IN TXT "v=spf1 include:_spf.example.com ~all"
  • PTR (Pointer Record) : ip 주소를 도메인 네임으로 매핑하는 역방향 DNS 조회에 사용된다.
    • 127.0.0.1.in-addr.arpa. IN PTR www.example.com

Resolver(리졸버)

DNS에서 클라이언트를 네임 서버에 연결하는 프로그램이다. resolver는 클라이언트와 동일한 시스템에 있지만 다른 호스트의 네임서버를 참조해야 한다. 여러 네임 서버를 참조하거나 로컬 캐시에 요청된 정보가 있을 수 있으므로 작업을 완료하기까지 밀리초에서 몇 초까지 다양하게 필요할 수 있다.

클라이언트 인터페이스

리졸버에 대한 클라이언트 인터페이스는 로컬 호스트의 규칙에 영향을 받지만 일반적으로 세 가지 기능이 있다.
1. 호스트 이름(www.example.com)을 호스트 주소(네트워크 주소)로 변환

  • 클라이언트가 호스트 이름을 제공하면 리졸버는 이 이름에 해당하는 하나 이상의 32비트 IP주소를 반환한다.
  • 과거 HOSTS.TXT 기반 기능을 모방하여 동작하나, DNS에서는 주로 A 레코드에 대한 요청으로 변환된다.
  • DNS는 여러 개의 IP주소를 반환할 수 있으며, 리졸버는 이 주소들을 정렬하거나 클라이언트에게 하나의 최적의 주소를 선택하여 반환할 수 있다.
  • 여러 주소를 반환하는 것이 권장되지만, 기존 HOSTS.TXT 서비스와의 호환성을 유지하기 위해 단일 주소만 반환할 수도 있다.
  1. 호스트 주소를 호스트 이름으로 변환
    • 클라이언트가 32비트 IP 주소를 제공하면, 리졸버는 이 주소에 해당하는 호스트 이름을 반환한다.
    • RR의 PTR 레코드를 찾아 반환한다.
  2. 일반 조회 기능
    • DNS에서 임의의 정보를 조회하는 기능으로, HOSTS.TXT 서비스에는 대응되는 기능이 없다.
    • 클라이언트는 QNAME(호스트 이름), QTYPE(리소스 타입), QCLASS(리소스 클레스)를 제공하며, 이와 일치하는 모든 RR을 요청한다.

      HOSTS.TXT 시스템
      DNS 이전 주소 변환을 위해 사용된 도메인 네임와 IP 주소를 매핑한 단일 텍스트 파일로 클라이언트는 관리 권한을 가진 중앙 서버(NIC)에서 복사본을 가져와 사용했다.

리졸버가 퀴리를 통한 요청을 처리하고 응답하는 결과는 크게 3가지로 나뉜다.

  • 하나 이상의 RR : 요청된 데이터를 포함하는 하나 이상의 RR
  • Name Error : 전달된 호스트 이름이 존재하지 않는 경우, 호스트 네임(도메인 네임)을 잘못 전달한 경우가 해당한다.
  • Data not found : 전달된 호스트 이름은 존재하지만, 해당하는 QTYPE의 RR이 없는 경우

리졸버가 동작하는 과정에서 호스트 이름으로 별칭이 제공되는 경우가 있다. 이 과정에서 리졸버는 가능하다면 별칭 상태를 클라이언트에게 신호로 알려야 하지만 대부분의 경우 별칭을 발견하면 새로운 호스트 이름(CNAME에서 매칭되어 있는 호스트 이름)에서 쿼리를 재시작 한다. 단 일반 조회 기능에서는 별칭의 새로운 호스트 이름을 추적하지 않고 해당 RR을 반환한다.

리졸버 내부

모든 리졸버의 구현체들은 약간씩 다른 알고리즘을 사용하며, 대부분이 일반적으로 발생하는 오류 처리 로직이다.

Stub Resolver

리졸버의 성능은 네트워크 통신에 필요한 리소스(네트워크 대역폭)에 많은 영향을 받는다.
리졸버를 구현하는 방법 중 하나로, 리졸버의 호스트 이름 처리 시간에 많은 영향을 주는 네트워크 리소스의 부족 문제를 해결 할 수 있는 방식이다. 리졸버의 기능들을 클라이언트에서 재귀 쿼리를 지원하는 네임 서버(recursive name server)로 옮겨 위치시키고, 클라이언트에는 recursive name server로 재귀 쿼리를 요청하는 소프트웨어 모듈을 사용한다.
이렇게 하면 스텁 리졸버는 recursive server의 주소 목록 정보만 가지고 가벼운 쿼리 요청을 보낼 수 있기 때문에 클라이언트의 네트워크 리소스에 대한 부담이 줄어든다.

이 방식이 현재 많이 사용되는 recursive name server를 통한 방식이다.

Resolver query

Resolver는 호스트 이름의 변환을 위해 쿼리를 시작하는 순서를 정하는 역할을 한다. 이러한 쿼리는 크게 3가지 종류가 있다.

비재귀 쿼리

Resolver가 네임 서버에 쿼리를 보내고, 네임 서버는 자신의 권한 내에 있는 레코드를 제공하거나, 다른 서버를 쿼리하지 않고도 부분적인 결과를 제공한다. recursive name server의 경우 자신의 캐시의 비재귀 쿼리는 결과를 제공하고, 네임 서버로부터 초기 응답을 받은 후 일정 기간동안 RR을 캐싱해 authoritative name server에 대한 부하를 줄인다.

재귀 쿼리

Resolver가 단일 DNS 서버에 쿼리를 보내며, 이 DNS 서버는 요청자를 대신해 다른 name server에 쿼리를 보낼 수 있다. 이 경우가 가정용 라우터의 stub resolver와 ISP가 운영하는 DNS 서버(Recursive name server)의 조합이다. 재귀적 쿼리는 Recursive name server가 필요한 다른 name server에 쿼리를 보내 완전한 응답을 제공하는 방식이다.
재귀 쿼리의 사용은 Resolver와 name server 모두 동의하는 경우에만 가능하므로, Resolver 혹은 Recursive name server는 쿼리 헤더의 비트를 사용해 재귀 서비스의 사용을 name server와 협상한다.

반복 쿼리

Resolver가 하나 이상의 DNS 서버의 체인으로 쿼리를 보내는 과정으로 각 서버는 클라이언트를 체인의 다음 서버로 참조하여, 현재 서버가 요청을 완전히 변환할 수있을 때까지 계속한다. www.example.com을 예로 들면, root name server에 쿼리를 보낸 후, com name server로, 마지막으로 example.com name server로 이어진다.

Resolver는 도메인 네임의 변환 과정에서 위의 방식들을 조합해 사용할 수 있다. 일반적인 사용자의 상황(라우터의 stub resolver + ISP의 recursive resolver + www호스트의 example.com)을 예로 들면 다음과 같다.

  • stub resolver : 재귀 쿼리를 recursive name server에 발행
  • recursive name server :
    • 자신의 캐시에 존재하는 경우 - 비재귀 쿼리로 stub resolver에게 결과 전달
    • 캐시에 존재하지 않는 경우 - 다른 name server에게로 반복 쿼리를 발행
  • recursive name server + autoritative name server : 반복 쿼리를 통해 네트워크 주소 탐색 후 찾으면 stub resolver에게 결과 전달

Creative Commons Attribution-ShareAlike License 4.0 - https://creativecommons.org/licenses/by-sa/4.0/

Creative Commons Attribution-ShareAlike License 2.5 - https://creativecommons.org/licenses/by-sa/2.5/

RFC

  • Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, https://www.rfc-editor.org/info/rfc1034. © 1987 IETF Trust and the persons identified as the document authors. All rights reserved. Resolver 섹션(stub resolver 까지) 부분은 RFC 1034의 내용을 바탕으로 작성되었습니다.
  • Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, https://www.rfc-editor.org/info/rfc1035. © 1987 IETF Trust and the persons identified as the document authors. All rights reserved. Resource Record 부분은 RFC 1035의 내용을 바탕으로 작성되었습니다.
profile
Rosevillage
이전 포스트

웹소켓 구경하기

다음 포스트

formData 이미지 전송 웹(react)과 하이브리드 앱(react native) 차이

0개의 댓글

관련 채용 정보