DNS

DNS

도메인 이름 시스템(Domain Name System, DNS)은 인터넷의 전화번호부와 같은 역할을 한다.

사람들은 nytimes.com이나 espn.com과 같은 도메인 이름을 통해 온라인에서 정보에 접근한다. 하지만 웹 브라우저는 도메인 이름이 아닌 인터넷 프로토콜(IP) 주소를 통해 상호작용합니다. DNS는 도메인 이름을 IP 주소로 변환하여 브라우저가 인터넷 자원을 로드할 수 있게 해준다.

인터넷에 연결된 각 장치는 고유한 IP 주소를 갖고 있고, 다른 기기들은 이를 사용하여 해당 장치를 찾게 된다. DNS 서버는 인간들이 192.168.1.1과 같은 IPv4 주소나 2400:cb00:2048:1::c629:d7a2와 같은 더 복잡한 알파벳과 숫자의 IPv6 주소와 같은 IP 주소들을 외울 필요 없이 사용할 수 있도록 도와주는 역할이다.

웹 페이지를 로드하는 데 참여하는 DNS 서버

1. DNS recursor(DNS 재귀 서버)

DNS 재귀 서버는 도서관에서 특정 책을 찾아달라는 요청을 받아들이는 사서같은 역할이다.

DNS 재귀 서버는 웹 브라우저와 같은 응용 프로그램을 통해 클라이언트 장치에서 쿼리를 받는 서버이다. 일반적으로 재귀 서버는 클라이언트의 DNS 쿼리를 충족시키기 위해 추가적인 요청을 수행하는 역할을 담당한다.

DNS 조회 과정의 첫 번째 단계로, 초기 요청을 한 클라이언트와 상호작용하는 역할을 한다.

• recursive DNS query와recursive DNS resolver를 구분하는 것이 중요
  • 쿼리는 DNS resolver에게 조회의 해결을 요청하는 요청
  • recursive DNS resolver은 재귀적인 쿼리를 수락하고 필요한 요청을 처리하여 응답을 생성하는 컴퓨터.

2. Root nameserver(루트 네임서버)

루트 서버는 사람이 읽을 수 있는 호스트 이름을 IP 주소로 번역하는 과정에서 첫 번째 단계이다. 도서관의 색인과 같다. 보통 다른 더 구체적인 위치를 가리키는 참조 역할을 한다.

3. TLD nameserver(최상위 도메인 네임서버)

최상위 도메인 서버는 도서관의 특정 책장이다. 이 네임서버는 특정 IP 주소를 찾기 위한 다음 단계이며, 호스트 이름의 마지막 부분을 호스팅합니다 (예: example.com의 경우, TLD 서버는 "com"입니다).

4 . Authoritative nameserver (권한보유 네임서버)

이 최종 네임서버는 사전의 일부다. 특정 이름을 해당 정의로 번역하는 역할을 한다. 권한 있는 네임서버는 네임서버 쿼리의 마지막 단계로, 권한 있는 네임서버가 요청된 레코드에 대한 액세스 권한이 있는 경우, 요청된 호스트 이름에 대한 IP 주소를 DNS 재귀 서버(사서)에게 반환하여 초기 요청을 처리한다.

Authoritative DNS Server

권한 있는 DNS 서버는 실제로 DNS 리소스 레코드를 보유하고 책임지는 서버이다. DNS 조회 체인의 맨 아래에 위치한 서버로 조회된 리소스 레코드에 대한 응답을 제공하고, 웹 브라우저가 요청하는 웹 사이트나 다른 웹 리소스에 접근하기 위해 필요한 IP 주소에 도달하게 해준다. 권한 있는 네임서버는 특정 DNS 레코드에 대해 최종적인 원천 리소스이므로 다른 출처를 조회하지 않고 자체 데이터에서 쿼리를 처리할 수 있다.

서브 도메인의 경우

• foo.example.com 또는 blog.cloudflare.com과 같은 서브도메인에 대한 쿼리의 경우, 권한 있는 네임서버 이후에 서브도메인의 CNAME 레코드를 저장하는 책임 있는 네임서버가 시퀀스에 추가된다.

Authoritative nameserver와 DNS recursor resolver차이점

각각 DNS 쿼리 파이프라인 내의 다른 위치에서 역할을 수행한다. recursor resolver가 DNS 쿼리의 시작에 위치하고 Authoritative nameserver는 끝에 위치한다.

recursor resolver는 클라이언트로부터 재귀적인 요청을 받아 DNS 레코드를 추적하는 컴퓨터이다. 이를 위해 요청된 레코드의 권한 있는 DNS 네임서버에 도달할 때까지 여러 번의 요청을 하면서 추적합니다 (또는 시간 초과 또는 오류가 발생하거나 레코드를 찾을 수 없는 경우).

물론 다행히 recursor resolver는 항상 여러 번의 요청을 하지 않아도 클라이언트에 응답하기 위해 필요한 레코드를 추적할 필요가 없이 캐싱을 사용한다.

DNS 캐싱

캐싱의 목적은 데이터 요청에 대한 성능과 신뢰성을 향상시키는 위치에 데이터를 일시적으로 저장하는 것이다.

DNS 캐싱은 요청하는 클라이언트에 가까운 위치에 데이터를 저장하여 DNS 쿼리를 빨리 해결하고 DNS 조회 체인의 하위에서 더 많은 쿼리를 피하며 로드 시간을 개선하고 대역폭/CPU 소비를 감소시키는 역할을 해준다. DNS 데이터는 TTL (Time-to-Live)에 의해 결정된 일정한 시간 동안 다양한 위치에 캐싱될 수 있다.

브라우저 DNS 캐싱

현대 웹 브라우저는 기본적으로 DNS 레코드를 일정한 시간 동안 캐시한다.

• DNS 캐싱이 웹 브라우저에 가까운 위치에서 발생할수록 캐시를 확인하고 올바른 IP 주소로 요청을 수행하는 데 필요한 처리 단계가 적어지기 때문
• DNS 레코드를 요청할 때, 브라우저 캐시는 요청된 레코드를 확인하는 첫 번째 위치입니다.

운영 체제 (OS) 수준의 DNS 캐싱

운영 체제 수준의 DNS resolver은 DNS 쿼리가 사용자의 기기를 떠날 때의 두 번째 및 마지막 로컬 처리 지점이다. 이 쿼리를 처리하기 위해 설계된 운영 체제 내의 프로세스는 일반적으로 stop resolver 또는 DNS 클라이언트라고 한다.

• 응용 프로그램으로부터 요청이 들어오면 stop resolver은 먼저 자체 캐시를 확인하여 레코드가 있는지 확인한다.
• 레코드가 없다면 로컬 네트워크 외부인 인터넷 서비스 제공자 (ISP) 내의 recursive DNS resolver로 DNS 쿼리를 보내게 된다.

ISP 내부의 recursive resolver가 DNS 쿼리를 받으면, 이전의 단계들과 마찬가지로, 요청된 호스트와 IP 주소 간의 변환 결과가 이미 로컬 지속성 레이어에 저장되어 있는지 확인한다.

recursive resolver는 캐시에 저장된 레코드의 유형에 따라 추가적인 기능을 가지고 있다:

1. 만약 resolver가 A 레코드를 가지고 있지 않고 권한 있는 네임서버의 NS 레코드를 가지고 있다면, DNS 쿼리를 빠르게 해결하기 위해 해당 네임서버에 직접 쿼리를 보내게 된다. 이러한 단축은 루트와 .com 네임서버(예: example.com을 찾는 경우)에서의 조회를 우회하며 DNS 쿼리의 해결을 더 빠르게 도와줄 수 있다.
2. 만약 resolver가 NS 레코드를 가지고 있지 않다면, TLD 서버에 쿼리를 보내게 되며 루트 서버를 건너뛴다.
   • (.com의 경우).
3. resolver가 TLD 서버를 가리키는 레코드가 없는 경우, 루트 서버에 쿼리를 보내게 됩니다. 이러한 경우는 일반적으로 DNS 캐시가 삭제된 후에 발생하는 일이 드물지만 발생할 수는 있다.

DNS 작동원리

호스트 이름(예: www.example.com) 을 컴퓨터 친화적인 IP 주소(예: 192.168.1.1)로 변환하는 과정을 포함한다.

인터넷의 각 장치에는 IP 주소가 할당되어 있고, 해당 주소를 사용하여 적절한 인터넷 장치를 찾을 수 있다

사용자가 웹 페이지를 로드하려면 사용자가 웹 브라우저에 입력한 내용(example.com)과 example.com 웹 페이지를 찾기 위해 필요한 기계 친화적인 주소 간에 번역이 되어야 한다.

DNS 작동 원리를 이해하기 위해서는 DNS 쿼리가 통과해야 하는 다양한 하드웨어 구성 요소에 대해 알아야 한다. 웹 브라우저에서는 DNS 조회가 백엔드에서 발생하며, 사용자의 컴퓨터에서 초기 요청 외에는 사용자의 상호작용이 필요하지 않다.

조회 과정

DNS 조회 정보는 일반적으로 조회하는 컴퓨터 내부에 로컬 캐시되거나 원격으로 DNS 인프라에 캐시된다. DNS 정보가 캐시되면 DNS 조회 과정에서 단계가 건너뛰어져 빨라집니다. 아래의 예시는 캐시가 없는 경우의 8개의 DNS 조회 단계를 설명한다.

1. 사용자가 웹 브라우저에 'example.com'을 입력하고 해당 쿼리가 인터넷을 통해 DNS recusor에 도달.
2. resolver는 DNS 루트 네임서버 (.)에 쿼리를 전송.
3. Root nameserver는 TLD nameserver(예: .com 또는 .net)의 주소를 resolver에 응답합니다. 예를 들어 example.com을 찾을 때, 우리의 요청은 .com TLD로 이동됩니다.
4. resolver은 .com TLD에 요청.
5. TLD nameserver는 도메인의 네임서버인 example.com의 IP 주소를 응답.
6. 마지막으로, recursor resolver은 domain nameserver에 쿼리를 전송.
7. example.com의 IP 주소가 네임서버로부터 resolver에 반환.
8. DNS resolver은 최초에 요청한 도메인의 IP 주소를 웹 브라우저에 응답.

DNS 조회의 8개의 단계가 example.com의 IP 주소를 반환하면, 브라우저는 웹 페이지를 요청한다. (별도 2단계)

1. 브라우저가 IP 주소로 HTTP 요청
2. 해당 IP 주소의 서버가 웹 페이지를 브라우저에 반환