DNS(Domain Name System)

먼저, 네트워크 프로토콜은 크게 두 가지로 나눌 수 있습니다.

• 데이터 프로토콜 : 실제로 데이터를 실어나르는 프로토콜

• 컨트롤 프로토콜 : 이 데이터 프로토콜이 잘 동작하도록 도와주는 컨트롤 프로토콜

컨트롤 프로토콜은 통신에 직접 관여하지 않지만 처음 통신 관계를 맺거나 유지하는 데 큰 역할을 합니다.

TCP/IP 프로토콜 체계를 유지하기 위한 주요 컨트롤 프로토콜에는 ARP, ICMP, DNS가 있습니다.

이 중에서 DNS(Domain Name System)는 도메인 주소를 IP 주소로 변환하는 역할을 합니다.

IP 주소보다 도메인 주소를 이용하는 것이 일반 사용자에게 더 익숙하고 서버 IP 변경에 쉽게 대처할 수 있습니다.

📌 DNS

우리는 흔히 사이트에 접속할 때, www.google.com 같은 도메인 주소를 입력하게 됩니다. 하지만 실제 네트워크 통신에서는 숫자로 구성된 IP 주소를 이용합니다.

사용자는 이 숫자로 구성된 IP 주소를 모두 외우기는 어렵고, IP 주소보다 의미 있는 문자열로 구성된 도메인 주소가 우리가 인식하고 기억하기 더 쉽습니다.

도메인 주소를 이용하면 하나의 IP 주소를 이용해 여러 개의 웹 서비스를 운영할 수 있고, 서비스 중인 IP 주소가 변경되더라도 도메인 주소 그대로 유지해 접속 방법 변경 없이 서비스를 그대로 유지할 수 있습니다. 또한, 도메인을 이용하면 지리적으로 여러 위치에서 서비스할 수도 있습니다.

물론 서비스를 도메인 주소를 사용하더라도 실제로 패킷을 만들어 통신하려면 네트워크 계층의 IP 주소를 알아야 하고 이를 위해 문자열로 된 도메인 주소를 실제 통신에 필요한 IP 주소로 변환하는 DNS(Domain Name Server) 정보를 네트워크 설정 정보에 입력해야 합니다.

아래의 이미지는 www.naver.com에 접속하기 위한 절차입니다.
사용자가 웹 브라우저에 naver.com을 입력하면 DNS 서버에 naver.com의 주소가 무엇인지 질의하고 DNS 서버는 naver.com의 IP 주소가 202.179.177.21이라고 사용자에게 알려줍니다. 사용자는 DNS로 응답받은 202.179.177.21이라는 IP 주소를 이용해 실제 naver.com에 접속하게 됩니다.

📌 DNS 구조와 명명 규칙

도메인은 계층 구조입니다.

역트리 구조로 최상위 루트부터 Top-Level 도메인, Second-Level 도메인, Third-Level 도메인과 같이 하위 레벨로

원하는 주소를 단계적으로 찾아갑니다. 우리가 도메인 주소를 사용할 때는 각 계층의 경계를 "."으로 표시하고 뒤에서 앞으로 해석합니다.

www.naver.com 의 경우, 맨 뒤에 생략된 루트(.)를 시작으로 Top-Level인 com, Second-Level인 naver, Third-Level인 www와 같이 뒤에서 앞으로 해석합니다.
도메인 계층은 최대 128계층까지 구성할 수 있습니다.

계층별 길이는 최대 63바이트까지 사용할 수 있고 도메인 계층을 구분하는 구분자 "."을 포함한 전체 도메인 네임의 길이는 최대 255바이트까지 사용할 수 있습니다. 문자는 알파벳, 숫자, "ㅡ"만 사용할 수 있고 대소문자 구분이 없습니다.

📌 DNS 동작 방식

도메인을 IP 주소로 변환하려면 DNS 서버에 도메인 쿼리하는 과정을 거쳐야 합니다.

하지만 DNS 서버없이 로컬에 도메인과 IP 주소를 직접 설정해 사용할 수도 있습니다. 로컬에서 도메인과 IP 주소를 관리하는 파일을 hosts 파일이라고 합니다. hosts 파일에 도메인과 IP 주소를 설정해두면 해당 도메인 리스트는 항상 DNS 캐시에 저장됩니다.

• 도메인을 쿼리하면 DNS 서버에 쿼리를 하기 전 로컬에 있는 DNS 캐시 정보를 먼저 확인합니다.
  -> 동일한 도메인을 매번 질의하지 않고 캐시를 통해 성능을 향상시키기 위해서입니다.

• 이런 DNS 캐시 정보에는 기존 DNS 조회를 통해 확인한 동적 DNS 캐시와 함께 hosts 파일에 저장되어 있는 정적 DNS 캐시가 함께 저장되어 있습니다.

• DNS 캐시 정보에 필요한 도메인 정보가 없으면 DNS 서버로 쿼리를 수행하고 DNS 서버로부터 응답을 받으면 그 결과를 캐시에 먼저 저장합니다. 전에 쿼리를 한 번 수행한 DNS 정보는 캐시부터 조회하므로 DNS 서버에 별도로 쿼리하지 않고 캐시 정보를 사용합니다.

• 간단하게 naver.com이라는 도메인을 쿼리하기 위해 먼저 로컬 캐시를 조회하고 로컬 캐시에 없으면 DNS 서버로 다시 쿼리해 도메인 쿼리를 수행하는 과정을 거친다는 의미입니다.

지금까지 클라이언트 관점에서 DNS 질의 과정을 설명했다면 반대로 DNS 시스템 관점에서 도메인에 대한 결과값을 클라이언트에 보내주는 과정을 살펴보겠습니다.

전 세계 도메인 정보를 DNS 서버 하나에 저장할 수 없습니다. 왜냐하면 데이터의 양이 너무 방대하기 때문에 실시간으로 도메인 리스트를 업데이트할 수 없기 때문입니다.

그래서 DNS 서버는 분산된 데이터베이스로 서로 도와주도록 설계되었는데 자신이 가진 도메인 정보가 아니면 다른 DNS에 질의해 결과를 받을 수 있습니다.

• DNS 기능을 서버에 올리면 DNS 서버는 기본적으로 루트 DNS 관련 정보를 가지고 있습니다. 클라이언트의 쿼리가 자신에게 없는 정보라면 루트 DNS에 쿼리하고 루트 DNS에서는 쿼리한 도메인의 TLD 값을 확인해 해당 TLD값을 관리하는 DNS가 어디인지 응답합니다.

• 예를 들어, 'naver.com' 이라는 도메인을 클라이언트가 DNS 서버에 쿼리했다면 DNS 서버는 루트 DNS에 다시 쿼리하고 루트 DNS는 .com에 대한 정보를 관리하는 DNS 주소 정보를 DNS 서버에 응답합니다.

• 이 응답을 받은 DNS 서버는 .com을 관리하는 DNS 서버에 naver.com에 대해 쿼리합니다.

• DNS 서버는 마지막으로 naver.com을 관리하는 DNS에 쿼리하고 naver.com에 대한 최종 결괏값을 받게 됩니다.

처음 쿼리를 받은(클라이언트에 DNS 서버로 설정된) DNS 서버는 이 정보를 클라이언트에 응답합니다.

이 과정을 보면 클라이언트에서 처음 질의를 받은 DNS가 중심이 되어 책임지고 루트 DNS부터 상위 DNS에 차근차근 쿼리를 보내 결괏값을 알아낸 후 최종 결괏값만 클라이언트에 응답합니다.

클라이언트는 한 번의 쿼리를 보내지만 이 요청을 받은 DNS 서버는 여러 단계로 쿼리를 상위 DNS 서버에 보내 정보를 획득합니다.

호스트가 DNS 서버에 질의했던 방식을 재귀적 쿼리(Recursive Query)라고 하고 DNS 서버가 루트 NS와 TLS NS에 질의한 방식을 반복적 쿼리(Iterative Query)라고 합니다.

💡 재귀적 쿼리(Recursive Query)와 반복적 쿼리(Iterative Query)

• 재귀적 쿼리는 쿼리를 보낸 클라이언트에 서버가 최종 결괏값을 반환하는 서버 중심 쿼리입니다.

• 반복적 쿼리는 최종값을 받을 때까지 클라이언트에서 쿼리를 계속 진행하는 방식입니다.

일반적으로 재귀적 쿼리는 클라이언트와 로컬 DNS 간에서 사용하고 반복적 쿼리는 로컬 DNS 서버와 상위 DNS 구간에서 사용합니다. 이때 로컬 DNS는 클라이언트로 동작해 상위 DNS에 반복적으로 쿼리합니다.

이상으로 DNS에 대해서 간단히 알아봤습니다.

참고

• IT 엔지니어를 위한 네트워크 입문 (고재성, 이상훈 지음)