DNS란 무엇입니까? | DNS 작동 방식

DNS는 사용자가 IP 주소 대신 도메인 이름을 사용하여 웹사이트에 연결할 수 있도록 합니다. DNS 작동 방식에 대해 알아보십시오.

Share facebook icon linkedin icon twitter icon email icon

DNS

학습 목표

이 글을 읽은 후에 다음을 할 수 있습니다:

  • DNS 정의
  • DNS 작동 방식 이해
  • 재귀 및 반복 DNS 조회 구분
  • 권한있는 네임서버를 재귀 DNS 확인자로부터 분리
  • DNS 캐싱 작동 방식 살펴보기

DNS란 무엇입니까?

DNS(Domain Name System)는 인터넷 전화번호부입니다. 사람은 nytimes.com 또는 espn.com과 같은 도메인 이름을 통해 온라인으로 정보에 액세스합니다. 웹 브라우저는 인터넷 프로토콜(IP) 주소를 통해 상호작용합니다. DNS는 브라우저가 인터넷 리소스를 로드할 수 있도록 도메인 이름을 IP 주소로 변환합니다.

인터넷에 연결된 각 기기에는 다른 컴퓨터가 기기를 찾는 데 사용하는 고유한 IP 주소가 있습니다. DNS 서버를 사용하면 사람이 192.168.1.1(IPv4의 경우)과 같은 IP 주소 또는 2400:cb00:2048:1::c629:d7a2(IPv6의 경우)와 같은 복잡한 영숫자 IP 주소를 기억할 필요가 없습니다.

DNS

DNS는 어떻게 작동하나요?

DNS 확인 프로세스에는 호스트 이름(예: www.example.com)을 컴퓨터 친화적인 IP 주소(예: 192.168.1.1)로 변환하는 과정이 포함됩니다. IP 주소는 인터넷의 각 기기에 제공되며 거리 주소가 특정 집을 찾는 데 사용되는 것처럼 해당 주소는 적절한 인터넷 기기를 찾기 위해 필요합니다. 사용자가 웹 페이지를 로드하려는 경우 사용자가 웹 브라우저에 입력한 주소(example.com)와 example.com 웹 페이지를 찾는 데 필요한 컴퓨터 친화적인 주소간에 변환이 이루어져야 합니다.

DNS 확인의 배후 프로세스를 이해하려면 DNS 쿼리가 통과해야 하는 다양한 하드웨어 구성 요소에 대해 알아야 합니다. 웹 브라우저의 경우 DNS 조회가 "배후에서” 발생하며 초기 요청을 벗어나 사용자의 컴퓨터와 상호작용할 필요가 없습니다.

웹 페이지 로딩과 관련된 4개의 DNS 서버가 있습니다.

  • DNS 리커서 - 리커서는 도서관의 어딘가에서 특정 책을 찾도록 요구받는 사서로 생각할 수 있습니다. DNS 리커서는 웹 브라우저와 같은 애플리케이션을 통해 클라이언트 컴퓨터로부터 쿼리를 받도록 고안된 서버입니다. 일반적으로 리커서는 클라이언트의 DNS 쿼리를 충족시키기 위해 추가 요청을 수행합니다.
  • 루트 네임서버 - 루트 서버는 사람이 읽을 수 있는 호스트 이름을 IP 주소로 변환(분해)하는 첫 번째 단계입니다. 다른 책장을 가리키는 라이브러리의 색인으로 생각할 수 있으며, 일반적으로 다른 더욱 특정한 위치에 대한 참조로 사용됩니다.
  • TLD 네임서버 - 최상위 도메인 서버(TLD)는 도서관의 특정 책장으로 생각할 수 있습니다. 이 네임서버는 특정 IP 주소 검색의 다음 단계이며, 호스트 이름의 마지막 부분을 호스팅합니다(example.com에서 TLD 서버는 “com”).
  • 권한있는 네임서버 - 이 최종 네임서버는 특정 이름을 해당 정의로 변환할 수 있는 책장의 사전으로 생각할 수 있습니다. 권한있는 네임서버는 네임서버 쿼리의 마지막 중단점입니다. 권한있는 네임서버가 요청한 레코드에 대한 액세스 권한을 가진 경우, 요청한 호스트 이름의 IP 주소를 초기 요청을 한 DNS 리커서(사서)에게 다시 보냅니다.

권한있는 DNS 서버와 재귀 DNS 확인자의 차이점은 무엇입니까?

두 개념은 모두 DNS 인프라에 통합된 서버(서버 그룹)를 나타내지만 각각 다른 역할을 수행하고 DNS 쿼리 파이프라인 내부의 다른 위치에 있습니다. 차이점에 대해 생각하는 한 가지 방법은 재귀 확인자는 DNS 쿼리의 시작 부분에 있고 권한있는 네임서버는 끝부분에 있다는 것입니다.

재귀 DNS 확인자

재귀 확인자는 클라이언트의 재귀 요청에 응답하고 DNS 레코드를 추적하는 데 시간을 투자하는 컴퓨터입니다. 요청한 레코드에 대해 권한있는 DNS 네임서버에 도달할 때까지 일련의 요청을 하는 방식으로 이를 수행합니다(또는 레코드가 없으면 시간 초과되거나 오류를 반환). 다행히 재귀 DNS 확인자는 클라이언트에 응답하는 데 필요한 레코드를 추적하기 위해 항상 여러 요청을 할 필요는 없습니다. 캐싱은 DNS 조회 초기에 요청한 리소스 레코드를 제공하여 필요한 요청을 단락시키는 데 도움이 되는 데이터 지속성 프로세스입니다.

DNS query diagram

권한있는 DNS 서버

간단히 말해서 권한있는 DNS 서버는 실제로 DNS 리소스 레코드를 보유하고 담당하는 서버입니다. 이 서버는 쿼리한 리소스 레코드로 응답하는 DNS 조회 체인의 맨 아래에 있는 서버로, 궁극적으로 웹 브라우저가 웹사이트 또는 다른 웹 리소스에 액세스하는 데 필요한 IP 주소에 도달하도록 요청할 수 있게 합니다. 권한있는 네임서버는 특정 DNS 레코드의 최종 소스이므로 다른 소스를 쿼리할 필요없이 자체 데이터의 쿼리를 충족시킬 수 있습니다.

DNS query diagram

foo.example.com 또는 blog.cloudflare.com과 같은 하위 도메인에 대한 쿼리인 경우 추가 네임서버가 권한있는 네임서버 다음의 시퀀스에 추가되어 하위 도메인의 CNAME 레코드 저장을 담당합니다.

DNS query diagram

많은 DNS 서비스와 Cloudflare가 제공하는 서비스 간에는 중요한 차이점이 있습니다. Google DNS, OpenDNS와 같은 다른 DNS 재귀 확인자와 Comcast와 같은 공급자는 모두 DNS 재귀 확인자의 데이터 센터 설치를 유지 관리합니다. 이러한 확인자는 최적화된 DNS 최적화 컴퓨터 시스템 클러스터를 통해 빠르고 쉬운 쿼리를 허용하지만 Cloudflare에서 호스팅하는 네임서버와 근본적으로 다릅니다.

Cloudflare는 인터넷 기능에 필수적인 인프라 수준의 네임서버를 유지 관리합니다. Cloudflare가 부분적으로 호스팅을 담당하는 f-루트 서버 네트워크가 대표적인 예입니다. F- 루트는 하루에 수십억 건의 인터넷 요청을 담당하는 루트 수준의 DNS 네임서버 인프라 구성 요소 중 하나입니다. 당사의 Anycast 네트워크는 서비스 중단없이 대량의 DNS 트래픽을 처리할 수 있는 고유한 위치에 있습니다.

DNS 조회의 단계는 무엇입니까?

대부분의 경우에 DNS는 도메인 이름이 적절한 IP 주소로 변환되는 것과 관련이 있습니다. 이 프로세스의 작동 방식을 배우려면 웹 브라우저에서 DNS 조회 프로세스를 거쳐 다시 돌아오는 DNS 조회 경로를 따르는 것이 도움이 됩니다. 단계를 살펴보겠습니다.

참고: 종종 DNS 조회 정보는 쿼리 컴퓨터 내부에서 로컬로 또는 DNS 인프라에서 원격으로 캐시됩니다. DNS 조회에는 일반적으로 8단계가 있습니다. DNS 정보가 캐시되면 DNS 조회 프로세스에서 단계를 건너 뛰어 더 빨라집니다. 아래 예시는 캐시되지 않은 8단계를 모두 보여줍니다.

DNS 조회의 8단계:

  1. 사용자가 웹 브라우저에 'example.com'을 입력하면 쿼리가 인터넷으로 이동하고 DNS 재귀 확인자가 수신합니다.
  2. 그런 다음 확인자가 DNS 루트 이름 서버(.)를 쿼리합니다.
  3. 그런 다음 루트 서버가 도메인에 대한 정보를 저장하는 최상위 도메인(TLD) DNS 서버(예: .com 또는 .net)의 주소로 확인자에 응답합니다. example.com을 검색할 때 요청은 .com TLD를 가리 킵니다.
  4. 그런 다음 확인자가 .com TLD에 요청합니다.
  5. 이어서 TLD 서버가 도메인 이름 서버(example.com)의 IP 주소로 응답합니다.
  6. 마지막으로 재귀 확인자가 도메인의 네임서버로 쿼리를 보냅니다.
  7. 그러면 example.com의 IP 주소가 네임서버에서 확인자에게 반환됩니다.
  8. 이어서 DNS 확인자가 처음 요청한 도메인의 IP 주소로 웹 브라우저에 응답합니다.

  9. DNS 조회의 8단계가 example.com의 IP 주소를 반환하면 브라우저가 웹 페이지를 요청할 수 있습니다.

  10. 브라우저가 IP 주소로 HTTP 요청을 합니다.
  11. 해당 IP의 서버가 브라우저에서 렌더링할 웹 페이지를 반환합니다(10단계).
DNS query diagram

DNS 확인자란 무엇입니까?

DNS 확인자는 DNS 조회의 첫 번째 중단점이며 초기 요청을 한 클라이언트를 처리합니다. 확인자는 URL이 궁극적으로 필요한 IP 주소로 변환되도록 하는 일련의 쿼리를 시작합니다.

참고: 캐시되지 않은 일반적인 DNS 조회에는 재귀 쿼리와 반복 쿼리가 모두 포함됩니다.

재귀 DNS 쿼리와 재귀 DNS 확인자를 구분하는 것이 중요합니다. 쿼리는 쿼리 확인을 요구하는 DNS 확인자에게 수행하는 요청을 의미합니다. DNS 재귀 확인자는 재귀 쿼리를 수락하고 필요한 요청을 수행하는 방식으로 응답을 처리하는 컴퓨터입니다.

DNS query diagram

DNS 쿼리 유형은 무엇입니까?

일반적인 DNS 조회에서는 세 가지 유형의 쿼리가 발생합니다. 이러한 쿼리 조합을 사용하면 DNS 확인을 위한 최적화된 프로세스로 이동 거리를 줄일 수 있습니다. 이상적인 상황에서 캐시된 레코드 데이터를 사용할 수 있으므로 DNS 네임서버가 비재귀 쿼리를 반환할 수 있습니다.

세 가지 유형의 DNS 쿼리:

  1. 재귀 쿼리 - 재귀 쿼리에서 DNS 클라이언트는 확인자가 레코드를 찾을 수 없는 경우 DNS 서버(일반적으로 DNS 재귀 확인자)가 요청한 리소스 레코드 또는 오류 메시지를 사용하여 클라이언트에 응답하도록 요구합니다.

  2. 반복 쿼리 - 이 경우 DNS 클라이언트는 DNS 서버가 가능한 최상의 응답을 반환하도록 합니다. 쿼리한 DNS 서버가 쿼리 이름과 일치하지 않으면 하위 수준의 도메인 네임스페이스에 대해 권한있는 DNS 서버에 대한 참조를 반환합니다. 그러면 DNS 클라이언트가 참조 주소를 조회합니다. 이 프로세스는 오류 또는 제한 시간 초과가 발생할 때까지 추가 DNS 서버가 쿼리 체인을 중단한 상태로 계속됩니다.

  3. 비재귀 쿼리 - 일반적으로 DNS 확인자 클라이언트가 레코드에 대한 권한이 있거나 캐시 내부에 레코드가 있기 때문에 액세스 권한이 있는 레코드를 DNS 서버에 쿼리할 때 발생합니다. 일반적으로 DNS 서버는 추가 대역폭 소비 및 업스트림 서버의 로드를 방지하기 위해 DNS 레코드를 캐시합니다.

DNS 캐싱이란 무엇입니까? DNS 캐싱은 어디서 발생합니까?

캐싱의 목적은 데이터 요청에 대해 성능과 신뢰성을 개선할 수 있는 장소에 데이터를 임시 저장하는 것입니다. DNS 캐싱은 요청하는 클라이언트에 더 가까운 곳에 데이터를 저장하여 DNS 쿼리를 더 일찍 확인할 수 있고 DNS 조회 체인의 추가 쿼리를 피할 수 있으므로, 로드 시간이 향상되고 대역폭/CPU 소비가 줄어듭니다. DNS 데이터는 다양한 위치에 캐시될 수 있으며, 각 위치는 TTL(Time-To-Live)에 의해 결정된 설정 시간 동안 DNS 레코드를 저장합니다.

브라우저 DNS 캐싱

최신 웹 브라우저는 기본적으로 정해진 시간 동안 DNS 레코드를 캐시하도록 설계되었습니다. 여기서의 목적은 분명합니다. DNS 캐싱이 웹 브라우저에 더 가까울수록 캐시를 확인하고 IP 주소에 대한 올바른 요청을 하기 위해 처리 단계를 더 적게 수행해야 합니다. DNS 레코드를 요청할 때 브라우저 캐시는 요청한 레코드를 확인하는 첫 번째 위치입니다.

Chrome에서는 chrome://net-internals/#dns로 이동하여 DNS 캐시의 상태를 볼 수 있습니다.

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

운영 체제 수준 DNS 확인자는 DNS 쿼리가 컴퓨터를 떠나기 전 두 번째이자 마지막 로컬 중단점입니다. 이 쿼리를 처리하도록 설계된 운영 체제 내부의 프로세스를 일반적으로 "스텁 확인자" 또는 DNS 클라이언트라고 합니다. 스텁 확인자는 애플리케이션에서 요청을 받으면 먼저 자체 캐시를 검사하여 레코드가 있는지 확인합니다. 레코드가 없으면 로컬 네트워크 외부의 (재귀 플래그가 설정된) DNS 쿼리를 인터넷 서비스 공급자(ISP) 내부의 DNS 재귀 확인자로 보냅니다.

ISP 내부의 재귀 확인자가 모든 이전 단계와 같이 DNS 쿼리를 수신하면 요청한 호스트-IP-주소 변환이 로컬 지속성 계층 내에 이미 저장되어 있는지도 확인합니다.

재귀 확인자는 캐시에 있는 레코드 유형에 따라 추가 기능도 있습니다.

  1. 확인자가 A 레코드는 없지만 권한있는 네임서버에 대한 NS 레코드를 갖고 있는 경우, DNS 쿼리의 여러 단계를 거치지 않고 해당 네임서버를 직접 쿼리합니다. 이 바로가기는 루트 및 .com 네임서버(예: example.com 검색)에서 조회를 방지하고 DNS 쿼리의 확인이 더 빨리 이루어 지도록 도와줍니다.
  2. 확인자에 NS 레코드가 없는 경우 루트 서버를 건너뛰고 TLD 서버(이 경우 .com)로 쿼리를 보냅니다.
  3. 확인자에 TLD 서버를 가리키는 레코드가 없는 경우 루트 서버를 쿼리합니다. 이 이벤트는 일반적으로 DNS 캐시가 제거된 후에 발생합니다.

Cloudflare DNS와 다른 DNS 공급자의 차이점에 대해 알아보십시오.