1. DNS의 원리

DNS는 사람이 기억하기 쉬운 도메인 이름(hostname)을 컴퓨터가 인식할 수 있는 주소(IPaddress)로 변환해주는 서비스/시스템 이다. google.com, naver.com 의 주소를 브라우저에 입력하면, 각각 google의 서버, naver의 서버로 연결해서 데이터를 받아올 수 있는 것은 DNS가 google의 서버, naver의 서버의 주소를 찾아주기 때문이다.

이번 장에서 DNS의 동작 원리를 더 깊이 배워본다. 출처

1.1 DNS server 4가지

1.1.1 DNS recursor

클라이언트로부터 요청(query)을 받는 서버이다.
이미 처리한 적 있는 DNS 주소에 대해서는 캐시를 통해서 빠르게 응답한다.
→ 국제 택배를 보내기 위해 방문한 고객센터 직원에 해당한다.
고객이 보낸 택배(도메인 요청)를 어디로 보내야 할지 알고, 직접 배송하지 않고 여러 물류센터에 중계 요청을 한다. 이전에 보낸 적 있는 주소라면 바로 경로를 안내해준다.

1.1.2 Root nameserver

도메인 이름(hostname)을 IP 주소로 바꾸는 첫 번째 단계를 root nameserver에서 수행한다.
해당 hostname의 IP 주소를 얻을 수 있는 특정 위치에 물어보도록 연결한다.
→ 국가 간 물류 허브에 해당한다.
"이 택배는 어느 나라로 가야 하니 해당 국가의 물류 시스템으로 넘겨라"라고 결정하는 역할이다. .com, .org, .kr 같은 TLD에 따라 경로를 분기시킨다.

1.1.3 TLD nameserver

TLD(최상위 도메인, Top Level Domain) 서버는 특정 IP 주소 검색의 다음 단계이고, hostname의 마지막 부분(.com 등)을 호스팅한다.
→ 해당 국가의 지역 물류센터에 해당한다.
"미국 내 .com 관련 택배는 이 지역 물류센터에서 담당한다"는 식으로, 더 구체적인 위치로 연결한다.

1.1.4 Authoritative nameserver

hostname에 해당하는 IP 주소를 가지고 있는 담당 서버이자, DNS로부터 IP 주소를 찾는 마지막 단계이다.
authoritative nameserver가 요청한 레코드의 접근을 했었다면, IP 주소를 리턴할 수 있다. 이렇게 얻은 IP 주소는 DNS Recursor에게 전달한다.
→ 최종 배달 주소(수취인 집 주소)를 관리하는 지역 우체국에 해당한다.
"이 택배의 정확한 도착지는 여깁니다"라고 실제 IP 주소를 알려주는 결정적 역할을 한다. 이 정보를 통해 Recursor가 클라이언트에게 최종 목적지를 알려줄 수 있다.

subdomain이 있는 경우, authoritative nameserver가 한 단계 더 추가될 수 있다.

subdomain 이란?
하나의 도메인 안에서 다른 영역을 구분하기 위해 앞에 붙이는 이름으로

• google.com → 기본 도메인 (도메인 이름)
• scala.google.com → "scala"라는 서브도메인을 가진 도메인
• cloud.google.com → "cloud"라는 서브도메인을 가진 도메인

즉, [서브도메인].[기본도메인] 구조이고,
한 회사(도메인) 안에서 여러 서비스를 구분할 때 자주 사용된다.

1.2 DNS lookup을 하는 과정

1.2.1 DNS Lookup process

1. 유저가 브라우저에 example.com 과 같은 hostname을 입력한다. 이 요청은 DNS Recursive resolver에 도착한다.
2. (Recursive) resolver는 DNS root nameserver 에 질의한다.
3. root server 는 resolver 에게 해당 도메인의 IP주소를 찾을 수 있는 TLD 서버를 알려준다. 이 예제에서는 .com 확장자에 대한 정보를 가진 TLD 서버를 알려준다.
4. resolver는 TLD 서버에게 요청한다.
5. TLD 서버는 hostname의 IP주소를 찾을 수 있는 nameserver 를 resolver에게 응답해준다. 이 예제에서는 example.com 을 알고 있는 authoritative nameserver이다.
6. resolver는 해당 도메인의 nameserver에게 질의한다.
7. 해당 도메인의 nameserver는 resolver 에게 IP주소를 리턴한다.
8. DNS resolver가 브라우저에게 IP 주소를 응답한다.
9. 그 다음에 브라우저는 example.com에 해당하는 IP주소를 이용해서, HTTP request 를 만든다.
10. 해당 IP의 서버가 HTTP요청에 대한 응답을 브라우저에게 전달한다.

1.2.2 Domain name syntax

위의 설명에서 이런 질문을 할 수 있다. "왜 .com 이 Top Level 인가?"

Domain Name의 문법은 dot(.)을 기준으로 다음과 같은 tree hierarchy를 구성하고 있다.

이미지 출처 : https://ko.wikipedia.org/wiki/%ED%8C%8C%EC%9D%BC:DNS_schema.svg

즉 우리가 쓰는 도메인 주소는 subdomain.domain.topleveldomain 형식이라고 보면 된다.
모두 조합된 이름을 hostname 이라고 한다.

1.3 DNS Caching

하루에 검색을 위해서 google, naver 에 수도 없이 들어간다.
이렇게 들어갈 때마다 위에 쓰여진 DNS 주소 찾는 과정을 거친다면, 그만큼 비용이 많이들 것이다.
그런데 신뢰성있게 서비스를 운영하는 회사라면 DNS가 연결되는 IP 주소가 자주 바뀌지 않을 것이다.
그러면 바뀌지 않는 동안은 한번 얻은 IP주소를 계속 사용하면 어떨까? 이런 생각에서 DNS Caching을 사용한다. Caching은 기본적으로 TTL을 가지고 있다.

1.3.1 Browser DNS Caching

최신 브라우저는 모두 DNS caching을 사용한다.

Chrome에서는 chrome://net-internals/#dns 에서 DNS 캐시의 상태를 볼 수 있고, 캐시를
삭제할수도 있다.

1.3.2 OS level DNS Caching

운영체제에서도 DNS caching을 사용한다. App에서 cache를 찾지 못하면, OS에서 hit 되는 경우가 많다. OS에서도 찾지 못하면, 그때 DNS resolver 에게 네트워크로 도메인의 IP주소를 찾기위한 요청을 전달한다.

1.3.3 Recursive Resolver 에서의 Caching

Recursive resolver가 client로부터 요청을 받으면 다음과 같은 순서로 캐시를 확인한다.

1. resolver 가 해당 도메인의 A Record(IP address)를 가지고 있는 경우, 바로 응답한다.

2. resolver 가 A Record(IP address)는 가지고 있지 않지만, authoritative nameserver의 NS record(domain)을 가지고 있는 경우. 이 경우에는 앞의 과정을 생략하고 바로 authoritative nameserver로 요청을 전송한다. 위 1.2 DNS lookup을 하는 과정 에서 6단계로 바로간다.

3. resolver 가 도메인의 TLD 정보를 가지고 있지만 NS record를 가지고 있지 않은 경우, resolver 는 TLD 서버에게 요청한다. 위 1.2 DNS lookup을 하는 과정 에서 4단계로 바로 간다.

4. 위 1,2,3이 아닌 경우, root server에게 질의하는 것부터 모두 수행한다.

1.4 Linux 에서의 DNS 관련 설정

리눅스에서 DNS resolver 설정은 /etc/resolv.conf 에 있다. 특정 DNS를 못찾는 경우 이 설정이 잘못되었거나, 내가 찾고자하는 DNS를 찾아줄 수 있는 nameserver 가 등록이 안되어있는지 확인해보아야 한다.

• ubuntu의 경우 DNS를 설정하기 위해서는 systemd-resolved.service 를 사용해서 수정해야한다.

별도의 전용망 또는 kubernetes cluster 에 속한 노드 등, 외부 인터넷에 연결되지 않은 환경에서는 DNS 문제가 생겼을 때 이 파일을 확인하는 것이 1번이다.