DNS

DNS(Domain Name System)은 인터넷의 전화번호부와 같다.
google.com같은 도메인 이름으로 온라인 정보에 엑세스할 수 있다.
웹 브라우저는 IP 주소로 상호작용하는데, DNS는 도메인 이름을 IP 주소로 변환해 브라우저가 인터넷 리소스를 로드할 수 있도록 해준다.

인터넷에 연결된 각 장치에는 다른 기계가 장치를 찾는데 필요한 고유한 IP 주소가 있다.
DNS 서버는 IPv4, IPv6 체계의 복잡한 영숫자 IP 주소를 기억하지 않아도 된다.

도메인 이름이란?

도메인 이름은 인터넷 인프라의 핵심 부분이다.
도메인 이름은 인터넷에서 사용할 수 있는 모든 웹 서버에 대해 사람이 읽을 수 있는 주소를 제공한다.

도메인 이름 : 클라이언트 소프트웨어에서 웹사이트에 액세스하는 데 사용되는 숫자 IP 주소 에 매핑되는 텍스트 문자열

예를 들어 Google의 도메인 이름은 'google.com'

DNS 덕분에 사용자는 인간 친화적인 도메인 이름을 입력하고 원하는 웹사이트로 라우팅할 수 있다.
이 프로세스를 DNS 요청라고 한다.

DNS 요청

1. 브라우저의 위치 표시줄에 도메인 이름을 입력한다.

2. 브라우저는 (로컬 DNS 캐시를 사용하여) 이 도메인 이름으로 식별되는 IP 주소를 이미 인식하고 있는지 컴퓨터에 묻고, 그렇다면 이름이 IP 주소로 변환되어 브라우저는 웹 서버와 내용을 주고 받는다.

3. 컴퓨터가 도메인 이름 뒤에 어떤 IP가 있는지 모르는 경우 DNS 서버에 계속 요청한다.
   DNS 서버의 작업은 정확히 어떤 IP 주소가 등록된 각 도메인 이름과 일치하는지 컴퓨터에 알려주는 것이다.

4. 컴퓨터가 요청된 IP 주소를 알게 되면 브라우저는 웹 서버와 콘텐츠를 주고 받을 수 있다.

누가 도메인 이름을 관리할까?

도메인 이름은 도메인 레지스트리(최상위 도메인 TLD를 관리하는 조직, ICANN의 IANA)에서 관리된다.
도메인 레지스트리는 도메인 이름의 판매를 레지스트라에게 위임한다.
누구든 도메인 이름을 레지스트라에 등록할 수 있으며, 3억개가 넘는 도메인 이름들이 등록되어 있다.

도메인 레지스트리는 사용자 개인 정보를 어떻게 보호할까?

많은 등록 기관에서 비공개 등록 옵션을 제공한다.

등록 대행자의 정보는 해당 도메인의 WHOIS 목록(도메인 이름 사용 가능 여부)에 제공되며 등록 대행자는 등록자의 대리인 역할을 한다.

이 비공개 등록은 실제 등록자의 정보가 레지스트라의 데이터베이스에 보관되기 때문에 레지스트라만큼 안전하다.

레지스트라는 DNS 보안에서 어떤 역할을 할까?

도메인 등록을 판매하고 등록 정보에 액세스할 수 있는 조직으로서 레지스트라는
악의적인 행위자로부터 데이터와 액세스를 안전하게 유지해야 한다.

• ICANN은 레지스트라가 도메인 하이재킹(특정 도메인을 다른 웹사이트로 연결하는 등)을 방지하기 위해 다음을 포함한 여러 단계를 수행할 것을 권장한다.

  • AuthInfo 코드 관리 개선(도메인 이전 프로세스에서 무작위로 생성된 코드)
  • 도메인 잠금의 더 나은 구현(도메인이 이전되지 않도록 하는 설정)
  • 모든 등록 프로세스에 대한 향상된 신원 확인
  • 도메인 변경에 대한 기록 유지 개선

도메인 이름과 URL의 차이는 무엇일까?

웹 주소라고도 하는 URL(Uniform Resource Locator)에는 사이트의 도메인 이름과 전송 프로토콜 및 경로를 비롯한 기타 정보가 포함된다.

예를 들어, URL 'https://velog.io/recent'에서
https는 프로토콜, velog.io는 도메인 이름, /recent는 특정 페이지의 경로이다.

도메인 이름에 포함된 것은 무엇일까?

도메인 이름은 일반적으로 점으로 구분되어 2~3 부분으로 나뉜다.
오른쪽에서 왼쪽으로 읽을 때 도메인 이름의 식별자는 가장 일반적인 것에서 가장 구체적인 것으로 이동한다.

TLD

• TLD(최상위 도메인) : 도메인 이름의 마지막 점 오른쪽에 있는 섹션.ICANN에서 관리한다.
  • 일반 TLD : .com, .net 및 .org
  • 국가별 TLD : .uk 및 .jp
  • 정부 부서 TLD : .gov
  • 교육 기관 TLD : .edu

레이블

• SLD : TLD 바로 앞에 있는 레이블

  • TLD의 왼쪽에는 두 번째 수준 도메인(2LD)이 있고 2LD 왼쪽에 무언가가 있으면 세 번째 수준 도메인(3LD)이라고 한다.

• Google의 미국 도메인 이름인 google.com:

  • .com : TLD
  • google : 2LD

• Google Korea의 도메인 이름인 google.co.kr의 경우:

  • .com : TLD
  • .co : 2LD
  • google : 3LD

도메인 이름을 안전하게 유지하는 방법

신뢰할 수 있는 레지스트라를 선택해야 한다.

도메인에는 만료 시점이 있고(최대 10년), 갱신할 수 있다.
경우에 따라 등록 대행자는 만료된 도메인을 비싼 값에 다시 판매에 만료된 도메인 이름을 뺏는다.

DNS는 어떻게 작동할까?

DNS 확인 프로세스에는 호스트 이름을 컴퓨터 친화적인 IP 주소로 변환하는 작업이 포함된다.

사용자가 웹 페이지를 로드하려는 경우 사용자가 웹 브라우저에 입력한 내용(google.com)과 해당 웹 페이지를 찾는 데 필요한 기계 친화적인 주소(172.217.161.78) 간에 번역이 이루어져야 한다.

DNS 조회는 초기 요청 외에는 사용자 컴퓨터와 상호 작용이 필요하지 않다.

웹 페이지 로드와 관련된 4개의 DNS 서버

DNS recursor

• 웹 브라우저와 같은 응용 프로그램을 통해 클라이언트 시스템에서 쿼리를 수신하도록 설계된 서버
  • 일반적으로 클라이언트의 DNS 쿼리를 충족하기 위해 추가 요청을 수행한다.

루트 네임 서버

• 루트 서버는 사람이 읽을 수 있는 호스트 이름을 IP 주소로 변환(해석)하는 첫 번째 단계이다.
  index처럼 특정 위치에 대한 참조 역할을 한다.

TLD 네임 서버

• 최상위 도메인 서버는 특정 IP 주소 검색의 다음 단계이며, 호스트 이름의 마지막 부분(ex. .com)을 호스팅한다.

권한 있는 네임 서버

• 요청된 레코드에 엑세스할 수 있는 경우 요청된 호스트 이름의 IP 주소를 초기 요청을 한 DNS Recursor에 반환한다.

권한 있는 DNS 서버 vs 재귀적 DNS 확인자

두 개념 모두 DNS 인프라에 통합된 서버지만, 각각 다른 역할을 수행하여 DNS 쿼리 파이프라인 내부의 다른 위치에 있다.

재귀적 DNS 확인자

• DNS 쿼리의 시작 부분
• 클라이언트의 재귀 요청에 응답하고 DNS 레코드를 추적하는 데 시간을 투자하는 컴퓨터
• 요청한 레코드에 대해 권한있는 DNS 네임 서버에 도달할 때까지 일련의 요청을 하는 방식으로 이를 수행한다.
• 캐싱은 DNS 조회 초기, 요청한 자원 레코드를 제공하여 필요한 요청을 단락시키는 데 도움이 되는 데이터 지속성 프로세스

권한 있는 DNS 서버

• DNS 쿼리의 끝 부분. DNS 조회 체인의 맨 아래에 있는 서버
• 실제로 DNS 리소스 레코드를 보유하고 담당하는 서버
• 웹 브라우저가 웹 사이트 또는 다른 웹 자원에 액세스하는 데 필요한 IP 주소에 도달하도록 요청할 수 있게 한다.
• 특정 DNS 레코드의 최종 원천이므로 다른 원천에 쿼리할 필요 없이 자체 데이터의 쿼리를 충족시킬 수 있다.

DNS 조회 단계

DNS는 도메인 이름을 적절한 IP 주소로 변환한다. 이 프로세스의 작동 방식을 알기 위해 웹 브라우저에서 DNS 조회 프로세스를 거쳐 다시 돌아오는 DNS 조회 경로를 살펴보자.

DNS 조회 정보는 쿼리 컴퓨터 내부에서 로컬로, DNS 인프라에서 원격으로 캐시되는 경우가 많다.
일반적으로 8단계가 있지만, DNS 정보가 캐시되어 있으면 몇 단계를 건너뛰며 더 빨라진다.

DNS 조회의 8단계

1. 사용자가 웹 브라우저에 google.com을 입력하면, 쿼리가 인터넷으로 이동하고 재귀적 DNS 확인자가 이를 수신한다.

2. 이어서 확인자가 DNS 루트 네임 서버(.)를 쿼리한다.

3. 루트 서버가, 도메인에 대한 정보를 저장하는 최상위 도메인(TLD) DNS 서버(.com 또는 .net)의 주소로 Recursor에 응답한다. google.com을 검색할 경우의 요청은 .com TLD를 가리킨다.

4. 확인자가 .com TLD에 요청한다.

5. TLD 서버가 도메인 이름 서버(google.com)의 IP 주소로 응답한다.

6. 재귀 확인자가 DNS로 쿼리를 보낸다.

7. google.com의 IP 주소가 네임 서버에서 확인자에게 반환된다.

8. DNS 확인자가, 처음 요청한 도메인의 IP 주소로 웹 브라우저에 응답한다.

DNS 조회의 8단계를 거쳐 google.com의 IP 주소가 반환되면, 이제 브라우저가 웹 페이지를 요청할 수 있다.

9. 브라우저가 IP 주소로 HTTP 요청을 보낸다.
10. 해당 IP의 서버가 브라우저에서 렌더링할 웹 페이지를 반환한다.

DNS Resolver

DNS 확인자는 DNS 조회의 첫 번째 단계이며, 초기 요청을 한 클라이언트를 처리한다.
확인자는 URL이 필요한 IP 주소로 변환되는 일련의 쿼리를 시작한다.

일반적인 캐시되지 않은 DNS 조회에는 재귀 쿼리, 반복 쿼리가 모두 포함된다.

• DNS Recursive Query : 쿼리 해결이 필요한 DNS 확인자에 대한 요청
• DNS Recursive Resolver : Recursive Query를 수락하고 필요한 요청을 만들어 응답을 처리하는 컴퓨터

DNS Query의 유형

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

3가지 유형의 DNS Query

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

2. 반복 쿼리 - 이 상황에서 DNS 클라이언트는 DNS 서버가 가능한 최선의 답변을 반환하도록 한다. 쿼리된 DNS 서버에 쿼리 이름과 일치하는 항목이 없으면 하위 수준의 도메인 네임스페이스에 대해 권한이 있는 DNS 서버에 대한 참조를 반환한다. 그런 다음 DNS 클라이언트는 참조 주소를 쿼리한다.
   이 프로세스는 오류 또는 시간 초과가 발생할 때까지 쿼리 체인 아래에 있는 추가 DNS 서버에서 반복된다.

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

DNS 캐싱

캐싱 : 데이터 요청에 대한 성능과 안정성을 향상시키는 위치에 데이터를 임시로 저장하는 것

DNS 캐싱은 요청하는 클라이언트에 더 가깝게 데이터를 저장해 DNS 쿼리를 더 일찍 해결할 수 있고 DNS 조회 체인 아래에 있는 추가 쿼리를 피할 수 있어서 로드 시간이 향상되고 대역폭/CPU 소비가 줄어든다.

DNS 데이터는 다양한 위치에 캐시될 수 있으며, 각 위치는 TTL(Time-to-Live)에 의해 결정된 정해진 시간 동안 DNS 레코드를 저장한다.

브라우저 DNS 캐싱

최신 웹 브라우저는 기본적으로 설정된 시간 동안 DNS 레코드를 캐시하도록 설계되었다.

DNS 캐싱이 웹 브라우저에 가까울수록 캐시를 확인하고 IP 주소에 올바른 요청을 하기 위해 더 적은 수의 처리 단계를 수행해야 한다.

DNS 레코드에 대한 요청이 있을 때 브라우저 캐시는 요청된 레코드를 확인하는 첫 번째 위치이다.

chrome://net-internals/#dns

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

운영 체제 수준 DNS 확인자는 DNS 쿼리의 두 번째이자 마지막 단계다.

이 쿼리를 처리하도록 설계된 운영 체제 내부의 프로세스를 일반적으로 "스텁 확인자" 또는 DNS 클라이언트라고 한다.

스텁 리졸버는 애플리케이션에서 요청을 받으면 먼저 자체 캐시를 확인하여 레코드가 있는지 확인한다. 그렇지 않은 경우 로컬 네트워크 외부의 DNS 쿼리(재귀 플래그 설정 포함)를 ISP(인터넷 서비스 공급자) 내부의 DNS 재귀 해석기로 보낸다.

ISP 내부의 재귀 해석기가 이전의 단계와 마찬가지로 DNS 쿼리를 수신하면 요청된 호스트에서 IP 주소로의 변환이 이미 로컬 지속성 계층 내부에 저장되어 있는지도 확인한다.

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

1. 확인자에 A 레코드(IP주소)가 없지만 권한 있는 네임서버에 대한 NS 레코드가 있는 경우 DNS 쿼리의 여러 단계를 건너뛰고 해당 네임서버에 직접 쿼리한다.
   이 바로 가기는 루트 및 .com 이름 서버(예: example.com 검색)에서 조회를 방지하고 DNS 쿼리 확인이 더 빨리 발생하도록 도와준다.

2. 리졸버에 NS 레코드가 없으면 루트 서버를 건너뛰고 TLD 서버(이 경우 .com)에 쿼리를 보낸다.

3. 확인자에 TLD 서버를 가리키는 레코드가 없는 경우에는 루트 서버에 쿼리한다. 이 이벤트는 일반적으로 DNS 캐시가 제거된 후에 발생한다.

참조 링크

What is DNS?
What is a domain name? | Domain name vs. URL
What is a domain name registrar?
What is a Domain Name?