DNS란 무엇이고 어떤 원리로 동작하는가

1. DNS 란?

  인터넷에 연결된 모든 기기는 고유한 IP주소를 가지고 있습니다. 이 IP주소는 다른 기기가 해당 기기를 찾을 때 사용되는 주소가 됩니다. 마치 우리들의 집 주소처럼요. DNS는 사람들이 일일히 이 복잡한 주소인 192.168.1.1(IPv4)나 심지어 더 복잡한 2400:cb00:2048:1::c629:d7a2(IPv6)와 같은 주소를 기억하지 않아도 되도록 만들어주었습니다.  위와 같은 IP주소는 기계가 읽기엔 적합하지만 사람이 읽고 기억하기엔 쉽지 않고, 시간이 흐름에 따라 변할 가능성도 있습니다. 이 DNS는 사람들로 하여금 IP주소를 몰라도 dong-x2.tistory.com  이나 www.weather.go.kr과 같이 도메인 이름을 통해 온라인 상의 정보에 접근할 수 있게 해줍니다. 웹 브라우저는 IP주소를 통해 상호작용하는데, DNS가 웹브라우저가 인터넷 자원에 접근할 수 있도록 도메인 이름을 IP주소로 변환해주는 역할을 합니다.

 

  도메인 이름은 점(dot)(.)로 구분되며 계층적으로 구성되어있습니다. 또한 사실 오른쪽에서 왼쪽으로 읽는 것이 순서입니다. 예를들어 dong-x2.tistory.com 이라는 도메인 이름이 있다고 했을 때 도메인 이름의 구성은 다음과 같습니다.

 

  1-1. TLD(Top-Level Domain) : 도메인 이름의 첫 번째인(오른쪽에서 왼쪽으로 기준) .com에 해당하는 부분입니다. TLD는 사용자들에게 도메인에 해당하는 서비스의 일반적인 목적을 알려줍니다. 흔한 .com, .org, .net은 별다른 조건을 요구하는 웹사이트는 아닙니다만, .us, .fr, .se와 같은 지역기반 TLD(Local TLD)는 특정 나라에서 호스팅되거나 해당 나라의 언어로 웹페이지가 이루어져있어야합니다. 또한 .gov와 같은 경우 정부기관에게만 허용되며 .edu의 경우 교육기관에게만 허용되는 TLD이기도 합니다. TLD는 라틴어를 포함해 총 63자까지 사용이 가능하나 보통은 2자나 3자를 사용합니다.

 

  1-2. label : TLD에 따르는 tistory와 같은 문자열은 보통 label이라고 하는데, TLD의 다음에 위치하기 때문에 SLD(Secondary Level Domain)이라고도 불립니다. 이러한 label은 대소문자를 포함한 모든 알파벳과 0-9의 숫자, - 표시(단 처음이나 마지막에는 사용불가)로 이루어집니다. 

 

  1-3. 또한 위와 같은 label은 dong-x2와 같이 서브도메인을 가질 수 있습니다.

 

2. DNS의 동작 원리

  기본적으로 사용자가 웹 페이지를 로딩할 때, '사용자가 브라우저의 주소창에 입력한 문자들'(도메인 이름)을 그 '문자가 나타내는 주소에 해당하는 기계친화적인 주소'(IP주소)로 변환하는 과정이 일어납니다. 이 과정은 유저와의 별다른 추가적인 상호작용 없이, 처음 요청이 있는 순간(주소창에 도메인 이름 입력)부터는 유저에게 보이지 않는 뒷편에서 이루어집니다. 이 과정을 이해하려면, 이 과정 속에서 DNS 쿼리가 지나게 되는 여러 하드웨어적인 요소들에 대해 알아야 합니다. 웹페이지를 로딩하는데에는 보통 4개의 DNS 서버가 관여합니다.

2-1. DNS 조회 과정(Lookup)에 관여하는 4가지 DNS 서버

2-1-1. DNS recursor(재귀 확인자) : 서점에서 고객이 요청시 특정 위치의 책을 찾아다 주는 서점 직원 같은 역할을 합니다. 사용자로부터 웹브라우저와 같은 어플리케이션을 통해 쿼리를 받도록 설계되어있습니다. 쿼리를 받은 이후에 DNS recursor는 사용자의 DNS쿼리를 만족시켜줄만한 추가적인 요청(request)들을 만드는 역할을 합니다.

 

2-1-2. Root nameserver(루트 네임서버) : 사람이 읽을 수 있는 호스트 이름을 IP주소로 바꾸는 첫번째 단계에 관여합니다. 마찬가지로 서점으로 생각한다면 책이 어느 선반에 있을지 나타내는 선반의 번호와 같은 역할을 합니다.  즉, 추가적인 상세한 위치에 대한 정보를 제공하는거죠.

 

2-1-3. TLD nameserver(TLD 네임서버) - Top Level Domain 서버는 찾는 책이 위치한 특정 선반과 같은 역할입니다. 특정 IP주소를 찾은 다음 단계에 관여를 하며, 호스트 이름의 마지막 부분을 호스트 하는 역할입니다. (이를테면 dong-x2.tistory.com의 .com과 같이)

 

2-1-4. Authoritative nameserver(권한 가진 DNS 서버) : 이 마지막 네임 서버는 서점의 특정 선반 위의 사전(Dictionary)과도 같은 역할입니다. 만약 이 네임 서버가 요청한 record*에 접근을 했다면, 그에 해당하는 IP주소를 DNS recursor(서점 직원)에게 넘겨줍니다.

 

2-2. Authoritative DNS server와 recursive DNS resolver의 차이점

  이 둘은 DNS Lookup 과정중 중요한 역할을 담당하고 있는 것이 공통점이지만, DNS쿼리의 파이프라인상 다른 위치에서 다른 역할을 하고 있습니다. recursor는 파이프라인에 시작부분에 있고 authoritative nameserver는 파이프라인의 마지막에 있죠.

 

  Recursive DNS resolver는 클라이언트의 재귀 요청에 응답하고 DNS record를 추적하는데 시간을 투자하는 컴퓨터입니다. 요청한 record가 적절한 authoritative DNS 서버에 도달할 때 까지 일련의 요청들을 만들어냅니다.(해당하는 요청이 아니라면 시간 초과가 되거나 찾지 못해 에러를 리턴하게 됩니다.) 하지만 이런 요청을 매번 만들어내지는 않습니다. 캐싱 기능을  활용해 DNS lookup 과정 초기에 요청한 record에 해당하는 응답을 빠르게 찾아내기도 합니다.

 

  Authoritative DNS server는 실제 DNS 리소스 record를 보유하고 있는 서버입니다. DNS lookup 과정 중 가장 마지막에서 클라이언트가 요청한 웹 자원에 접근할 수 있는 IP주소에 도달할 수 있도록 해줍니다. 

 

  dong-x2.tistory.com 이나 foo.example.com 과 같은 하위 도메인에 대한 쿼리의 경우, 추가적인 네임서버가 Authoritative DNS server 뒤에 붙어서 서브도메인의 CNAME record를 저장하는 역할을 하고 있기도 합니다.

 

2-3. DNS lookup 과정

  DNS lookup(조회)은 8단계로 이루어져 있습니다. 다만, 보통 이 조회 정보는 쿼리를 하는 컴퓨터나 원격의 DNS 인프라에 캐싱되어 있어, 이렇게 캐싱되어 있을 경우 8단계중 몇가지의 단계를 건너뛰게 되어 더 빠르기도 합니다. 아래는 캐싱되지 않았을 경우 8단계를 모두 나타내보았습니다.

 

 

(1) 사용자가 ‘example.com’을 브라우저의 주소창에 입력하고 해당 쿼리는 인터넷을 통해 DNS recursive resolver에 도달

(2) resolver가 DNS root nameserver(.)에 쿼리

(3) Root server가 resolver에게 해당 쿼리의 정보를 가지고 있는 TLD 서버(.com or .net 등)의 주소를 알려줌

(4) resolver가 .com TLD 서버로 요청

(5) TLD 서버가 해당 도메인의 nameserver의 IP를 응답

(6) resolver가 해당 도메인의 nameserver로 쿼리

(7) nameserver가 example.com에 해당하는 IP주소를 resolver에게 전달

(8) DNS resolver는 웹브라우저에게 처음 요청된 도메인에 해당하는 이 IP주소를 전달

 

  위와 같은 과정이 이루어진 후, 브라우저가 해당 IP로 HTTP요청을 생성하고, 해당 IP의 서버가 웹페이지를 브라우저에게 응답하면 사용자는 원하는 웹페이지를 브라우저에서 볼 수 있게 됩니다.

 

3. DNS record 란?

  DNS record는 authoritative DNS 서버에 존재하는 명령어들입니다. Zone file이라고 불리기도 하죠. 이 record는 도메인과 연관된 IP주소와, 그 도메인에 대한 요청을 어떻게 다룰지에 대한 정보를 제공합니다. 이러한 record들은 DNS Syntax로 알려진 문법으로 작성된 일련의 텍스트파일들로 구성되어 있습니다. DNS Syntax란 DNS 서버에게 무엇을 해야할지 알려주는 단순한 문자들의 나열입니다. 모든 DNS record들은 TTL을 가지고 있으며 DNS 서버가 얼마나 그 record를 최신화할지를 나타냅니다. 모든 도메인은 사용자가 그들의 웹사이트에 도메인 이름을 통해 접근할 수 있도록 최소한의 필수적인 DNS record들을 가지고 있어야하고 몇몇 optional record들은 추가적인 목적을 위해 사용됩니다. ( DNS record에 대해 잘 나타낸 영상 : https://www.youtube.com/watch?v=7lxgpKh_fRY )

 

3-1. 일반적인 유형의 DNS record

A record - Address record, 도메인에 해당하는 IP주소(IPv4)를 가지고 있는 record.
AAAA record - 도메인에 해당하는 IPv6 주소를 가지고 있는 record.
CNAME record - Canonical NAME record, IP주소를 제공하지는 않고 한 도메인이나 서브도메인을 또 다른 도메인으로 포워딩하는 record.
MX record - Main eXchanger record, Email 서버로 메일을 전송하는 record
TXT record - TeXT record, admin이 record에 텍스트 메모를 저장할 수 있게 하는 record,  도메인 이름의 소유권을 확인하고자하는 서드파티에 의해 사용되며 보통 이메일 보안에 사용됩니다.
NS record - Name Server record, DNS entry에 대한 nameserver를 저장하는 record.
SOA record - 도메인에 관한 admin 정보를 저장하는 record.
SRV record - 특정 서비스들을 위한 port를 특정하는 record.
PTR record - 역조회(reverse-lookup)에서 도메인 이름을 제공하는 record.

 

3-2. 그 외의 DNS record

  AFSDB record, APL record, CAA record, DNSKEY record, CDNSKEY record, ...

 

4. DNS 쿼리의 유형

  보통의 DNS 조회 과정에선 세 가지 유형의 쿼리가 생성됩니다. 이 쿼리들의 조합으로 이동(travel) 거리를 줄여 최적화된 DNS resolution 과정을 만들 수 있습니다. 가장 이상적인 상황에선, 캐싱된 record를 사용해, DNS nameserver가 비재귀 쿼리를 생성하게 됩니다.

 

4-1. Recursive query(재귀적 쿼리)

  일반적인 경우로, DNS 클라이언트는 DNS 서버가 요청된 자원의 record를 반환하거나, record를 못 찾았을 경우에는 에러 메시지로 응답하기를 요구합니다.

 

4-2. Iterative query(반복적 쿼리)

  이 경우엔 DNS 클라이언트는 DNS 서버가 가능한 최상의(best) 답을 할 수 있도록 허용합니다. 쿼리를 받은 DNS 서버가 쿼리에 해당하는 것을 갖고 있지 않다면, 하위 계층의 도메인 namespace에 대해 권한이 있는(authoritative) DNS 서버에 대한 참조를 반환합니다. 그러면 DNS 클라이언트는 이것을 받아 참조 주소를 쿼리하게 됩니다. 이 과정은 에러나 시간초과가 있기 전까지 쿼리 체인 상에 위치한 추가적인 DNS 서버들을 타고 내려가며 진행됩니다.

 

4-3. Non-recursive query(비재귀적 쿼리)

  이 경우는 일반적으로 해당 레코드에 대한 권한이 있거나 캐시 내부에 해당 레코드를 갖고 있는 DNS 서버에게 DNS resolver 클라이언트가 쿼리할 때 발생됩니다. (통상적으로, DNS 서버는 추가 대역폭 소비 및 서버의 부하를 방지하기 위해 DNS 레코드를 캐싱합니다.)

 

5. DNS 캐싱

  캐싱을 하면 DNS 쿼리는 더 일찍 응답받을 수 있고, DNS lookup chain을 따라 내려가는 추가적인 쿼리들을 방지할 수 있어 로드 시간을 줄이고 대역폭과 CPU 사용량을 개선할 수 있습니다. DNS 데이터는 여러 곳에서 캐싱될 수 있는데, 각각의 저장소에서는 time-to-live(TTL)에 의해 지정된 시간만큼만 DNS record를 저장합니다.

 

5-1. 브라우저 DNS 캐싱

  최신의 웹 브라우저들은 기본적으로 일정 시간동안 DNS record들을 캐싱하도록 디자인 되었습니다. 웹 브라우저에서 가까운 쪽에서 캐싱이 될수록, 캐시를 찾고 정확한 IP주소를 위한 요청을 만드는데 걸리는 단계와 시간을 줄일 수 있기 때문에 브라우저에서 캐싱 기능을 지원합니다. 크롬에서는 chrome://net-internals/#dns 에서 DNS 캐시의 상태를 볼 수 있습니다.

 

5-2. OS 레벨 DNS 캐싱

  사용자 컴퓨터의 OS에 내장된 캐시 저장소로서, stub resolver 혹은 DNS client라고 불립니다. Stub resolver가 어플리케이션으로부터 요청을 받으면, 가장 먼저 스스로가 그에 대한 record를 가지고 있는지 확인합니다. 확인 결과 record를 가지고 있지 않다면 그 때 비로소 DNS 쿼리를 보내는데 이 때, 쿼리는 로컬 네트워크 외부, ISP 내부의 DNS recursive resolver로 향합니다.