DNS 동작 원리 - 도메인과 URL을 IP 주소로 해석하는 과정

네트워크 통신에서 목적지에 도달하기 위해서는 목적지의 IP 주소가 필요합니다. 하지만 IP는 8bit와 4개의 옥텟으로 구성된 2진수를 10진수 형태로 보여주는 고유값이기 때문에 이러한 모든 사이트의 IP 주소를 일일이 기억하고 입력하기는 굉장히 불편하죠. 그래서 좀 더 알아보기 쉬운 고유의 영문 이름 형태의 주소를 IP 주소와 mapping하고 해당 영문 이름 주소를 입력하여 목적지에 연결될 수 있도록 하면 어떨까 하는 발상에서, 도메인과 URL, DNS 라는 개념이 등장했습니다.

본 포스팅에서는 우리가 흔히 사용하는 도메인의 구조와 이를 IP 주소로 해석하여 목적지 서버에 접속하는 과정에 대해서 다뤄보려고 합니다.

도메인(Domain)과 URL의 구조

도메인은 특정 영역이나 범위를 지칭하는 고유 명사를 뜻하는 말로, IT에서는 사용자의 네트워크 요청을 받고 응답하는 서버 혹은 인프라 집단에 공통적으로 부여하는 고유의 영문 이름을 의미합니다. 반면 URL은 인터넷상에서 얻고자 하는 리소스의 위치를 지칭하는 말로, 해당 리소스를 저장하고 응답하는 서버의 도메인에 어떤 형태의 응답을 받을 것인가를 나열한 Query String과 프로토콜을 붙인 형태로 나타납니다.

웹 브라우저는 자동으로 https 프로토콜이 적용되므로 우리가 특정 웹 사이트의 홈페이지에 접속하기 위해 입력하는 것이 그 사이트의 도메인이 됩니다. 그리고 홈페이지 내에서 사이트맵이나 게시글 등 버튼을 누르면 출력되는 화면이나 콘텐츠 자체를 지칭할 땐 URL을 사용해요. 따라서 별도의 웹 서핑 없이 사이트에 저장된 콘텐츠를 바로 불러오기 위해서는 도메인이 아닌 그 콘텐츠의 URL을 입력해서 불러오는 것이 훨씬 편리할 수 있습니다.

Root

위의 이미지는 최근 화제가 되었던 ‘흑백요리사’를 구글 사이트에 검색했을 때의 URL입니다. 이 때 사용한 구글 사이트의 도메인은 www.google.com인데 이러한 도메인은 끝에 온점(.) 하나를 생략한 형태입니다. 즉 사실은 www.google.com. 이 되는 것입니다. 이 온점(.)은 Root 네임 서버부터 도메인 이름 해석을 시작한다는 의미를 갖고 있는데, 모든 도메인은 이러한 이름 해석 방식으로 mapping된 IP 주소를 해석하므로 대체로 생략됩니다.

TLD

Top-Level Domain의 약자로, 모든 도메인이 흔히 갖고 있는 도메인의 가장 오른쪽 부분, 즉 최상위 도메인을 의미합니다. TLD는 일반 TLD(gTLD) 및 국가 코드 TLD(ccTLD) 로 구분되는데, 일반 TLD는 .net, .com, .org 등 특정 국가에 종속되지 않은 사이트의 도메인에 사용되고 국가 코드 TLD는 국내 기업이나 관공서 등 특정 국가에 종속된 기관의 사이트의 도메인에 사용되는 최상위 도메인입니다. 예시로 우리나라의 경우는 .kr, 미국은 .us, 중국은 .cn가 있습니다.

SLD

Second-Level Domain의 약자로, 도메인의 가장 오른쪽에서 두번째 부분입니다.

SLD에는 naver, google과 같이 사이트가 가진 고유 이름이나 사이트를 운영하는 회사의 이름이 되는 경우가 있고 co, or과 같이 기업이나 비영리 기관 등 사이트 운영 단체의 유형을 뜻하는 SLD가 있습니다.

후자의 경우는 co.kr, or.kr과 같이 앞서 설명한 국가 코드 TLD 앞에 붙이는 경우가 많아서 이러한 조합 자체가 하나의 TLD(ccSLD)로 간주되어 처리되기도 합니다.

Root Domain

SLD와 TLD를 합친 형태로, 사이트의 고유한 이름과 운영 목적, 기관 등의 정보가 포함된 고유 도메인 입니다. 특정 사이트를 개설할 경우 이러한 루트 도메인을 도메인 등록 기관(Domain Registrar)으로부터 구매 및 등록, 소유할 수 있습니다. 도메인 등록 기관으로는 가비아, GoDaddy, 아마존 Route 53이 있으며 이들 기관에서 도메인을 구입한 후에는 주기적으로 기간을 연장해야 계속 사용할 수 있습니다.

Sub Domain

루트 도메인으로부터 용도별로 파생되는 도메인을 말합니다. 앞서 예시를 든 구글 도메인의 경우 구글 드라이브는 drive.google.com, Gmail은 mail.google.com, 일반 홈페이지는 www.google.com의 도메인을 갖는데요. 이 때 각 용도별 접두사인 drive., mail., www. 가 서브 도메인이 됩니다. 이 외에도 사용자가 접근할 수 있는 다양한 서브 도메인이 존재할 수 있고 api., user. 등 시스템 내부적으로 사용할 수 있는 서브 도메인을 둘 수도 있습니다.

Query String

쿼리 스트링은 사용자가 웹 사이트에서 로그인을 하거나 정보를 검색하는 등의 다양한 기능을 사용할 때 시스템 내부에 저장된 적절한 데이터와 양식을 응답받을 수 있는 질의문입니다. 사진에 첨부된 URL은 구글 사이트에서 ‘흑백요리사’를 검색했을 때 검색 결과를 응답받는 쿼리 스트링이 구글 도메인 뒤에 붙어 있는 것을 확인할 수 있습니다.

도메인 이름 해석 과정

Pre) hosts 파일에 질의

사용자가 웹 브라우저에 “www.google.com”라는 도메인을 입력한다고 가정해 보겠습니다.

위의 이미지에서 확인할 수 있는 단계는 아니지만, 사용자의 PC는 정식으로 DNS 서버에 도메인 이름 해석을 질의하기 전에 hosts 라는 설정 파일을 확인합니다. 정확히는 Unix 계열의 OS에서는 /etc/hosts, Windows 계열에서는 C:\Windows\System32\drivers\etc\hosts 파일을 확인하죠. 이 파일에 요청하는 도메인에 mapping하는 IP 주소가 있으면 해당 IP 주소를 응답받아 접속하게 됩니다. 파일에 기재된 IP 주소가 해당 도메인의 실제 IP 주소가 아니더라도 hosts 파일에 적혀 있다면 무조건 해당 IP 주소를 응답해요. 꽤 중요한 역할을 하는 파일이기 때문에 hosts 파일은 관리자 권한을 가져야만 접근할 수 있도록 설정되어 있습니다. 이 파일은 주로 개발자나 엔지니어 분들이 PROD 환경의 실제 도메인을 갖고 DEV 혹은 TEST 환경에 테스트 목적으로 접속할 때 사용되곤 합니다.

각각 윈도우와 우분투 리눅스 OS에서 hosts 파일을 위와 같이 편집하면 통상적인 구글 사이트의 IP 주소가 아닌 기재된 주소 1.2.3.4로 접속하게 됩니다.

1) Local DNS에 질의

hosts 파일에 정보가 없으면 사용자 PC에 설정된 Local DNS 서버에 UDP 기반 dns 프로토콜을 통해 질의합니다. 캐시된 데이터가 있을 경우 이를 응답하고, 없을 경우 Root/TLD/SLD 네임 서버에 차례로 질의하며 도메인을 해석하는 과정을 수행하게 됩니다. 바로 이 과정을 Recursive Query라고 합니다.

Local DNS는 ISP 업체가 설정한 DNS 서버 혹은 사내에서 운영하는 DNS 서버를 지정하거나 구글 DNS 서버(8.8.8.8)와 같이 개인이 원하는 DNS 서버를 지정할 수 있습니다.

유닉스 계열의 OS에서는 /etc/resolv.conf 라는 파일이나 resolvectl 명령어에서, 윈도우에서는 제어판이나 설정 탭에서 Local DNS 서버를 설정할 수 있습니다.

2) Root NS에 질의

Local DNS는 요청받은 도메인을 가장 먼저 Root 네임 서버에 질의합니다. Root 네임 서버는 다양한 TLD에 대한 DNS Zone을 보유하고 이를 바탕으로 .com TLD에 대한 네임 서버 주소를 응답합니다.

Root 네임 서버는 전 세계에 13개가 분포해 있으며, ICANN(국제인터넷주소관리기구)에 의해 관리됩니다.

3) TLD NS에 질의

Local DNS는 응답받은 .com TLD 네임 서버에 질의합니다. .com TLD 네임 서버는 .com 이라는 TLD를 가진 수많은 SLD에 대한 DNS Zone을 보유하고 이를 바탕으로 google.com SLD에 대한 네임 서버 주소를 응답합니다.

TLD 네임 서버는 ICANN 산하의 IANA(인터넷 할당 번호 관리 기관이라는 뜻으로 직역되는 최상위 도메인 관리 기관)에서 관리되며, TLD에 대한 DNS zone을 관리하는 역할을 합니다.

4) SLD NS에 질의

Local DNS는 응답받은 google.com SLD 네임 서버에 질의합니다. 이 때 google.com 도메인 자체가 고유한 루트 도메인이 되고 www. 라는 서브 도메인이 포함된 최종 FQDN(Fully Qualified Domain Name)의 주소를 응답받는 순서만 남게 됩니다. SLD 네임 서버는 Local DNS가 요청하는 도메인에 대한 최종 IP를 응답합니다.

이러한 루트 도메인의 DNS Zone을 보유한 SLD 네임 서버는 해당 도메인을 발급하고 등록한 기관에서 관리는 경우가 있고, 도메인 등록 기관에서 발급받은 도메인을 다른 네임 서버의 DNS Zone에 등록하여 Local DNS에 응답하도록 할 수 있습니다.

5) 최종적으로 해석된 IP 전달 및 캐시

Local DNS는 응답받은 www.google.com도메인의 IP를 사용자에 응답하고 사용자는 해당 IP를 통해 구글 웹 서버에 HTTP 프로토콜로 접근할 수 있게 됩니다. 비로소 구글 웹 사이트에 접속하게 되는 것이죠. 구글 웹 사이트에서 여러 가지 기능들을 사용하게 될 텐데 그럴 때마다 일일히 동일한 Recursive Query를 수행하게 되면 Local DNS에 부하가 가중될 뿐만 아니라 응답을 받는 데에도 상당한 시간을 소모하게 됩니다. 이러한 문제를 고려하여 네임 서버는 Local DNS에 사용자가 요청한 도메인의 IP 주소를 일정 시간 동안 캐시합니다. 이렇게 캐싱되는 시간을 TTL(Time To Live)이라고 부르고, 이 TTL 값은 네임 서버에서 지정합니다.

도메인 이름 해석 과정의 유동성

그렇다면 특정 도메인 이름 해석을 통해 응답받을 수 있는 IP는 고정적일까요? 그렇지 않습니다. 특히 전 세계에서 접근하는 대규모 사이트의 경우 많은 수의 서버를 보유하기 때문에 사용자는 지역별 데이터 거버넌스와 물리적 거리, 요청 리소스 등을 고려하여 최적의 주소를 응답받을 수 있어야 합니다. 그래서 Local DNS는 적절한 네임 서버에 질의하고, 네임 서버는 여러 개의 IP 주소 레코드를 저장하였다가 자체적으로 적용된 정책에 따라 적합한 레코드를 응답으로 제공하기도 합니다. 따라서 설정된 Local DNS와 네임 서버 존 및 레코드, 도메인의 규모에 따라 응답받는 주소가 다를 수 있습니다.

DNS Zone과 레코드

이미지는 example.com라는 도메인에 대한 DNS Zone 및 내부 레코드를 예시로 표현한 것입니다. 이처럼 특정 도메인과 용도별 서브도메인에 대한 mapping 정보를 테이블 형태로 저장한 것을 DNS Zone 이라고 합니다. 그리고 DNS Zone 내 각각의 mapping 데이터 row를 레코드 라고 부릅니다.

• A : 도메인에 대한 IPv4 주소

• AAAA : 도메인에 대한 IPv6 주소

• MX : 도메인이 메일을 수신할 수 있는 서버를 식별하기 위한 주소 혹은 도메인

• NS : 도메인의 네임 서버 주소 혹은 도메인

• CNAME : 도메인의 별칭, 해당 도메인이 가질 수 있는 또 다른 도메인이라고 볼 수 있다.

• 이 외 외부에서 참조하기 위한 텍스트를 작성하는 TXT, IP 주소를 역으로 조회할 때 도메인 이름을 제공하기 위한 PTR, 도메인에서 이메일을 보낼 수 있는 주소를 작성하는 SPF 레코드가 있다.

DNS Zone은 IETF 표준을 준수하기 위해 위의 레코드 외 SOA라는 정보를 필수로 갖고 있습니다. SOA는 Start Of Authority의 약자로 권한의 시작을 의미하며 도메인 관리자 주소, 기본 네임 서버, 요청 재시도 시간, DNS 캐싱 시간(TTL) 등 중요한 정보를 저장하고 있습니다. 아래와 같이 nslookup 명령어 조합을 통해 쉽게 확인해볼 수 있습니다.

DNS 운영 시 주의 사항

SOA에 포함되는 정보인 TTL을 길게 설정하면 변경된 레코드를 클라이언트가 DNS에서 전달받기까지 그만큼 오랜 시간이 걸릴 수 있습니다. 반면 TTL을 짧게 설정할 경우 DNS를 통해 Recursive Query를 수행하는 빈도가 잦아 트래픽이 과도하게 증가할 수 있습니다.

그리고 다수의 좀비 PC를 동원하여 DNS 서버에 동일한 혹은 몇 가지 도메인 이름 해석을 대량으로 시도하는 DNS Query Flooding 공격 사례 또한 나타나고 있습니다. 이러한 공격을 효과적으로 방어하기 위해서는 기준 시간 내 임계치 이상의 도메인 질의 요청을 일정 시간 동안 차단하도록 설정할 수 있고, 존재하지 않는 도메인이나 서브 도메인만 랜덤하게 변경하여 대량으로 질의하는 IP를 차단하는 방법이 있습니다.