브라우저에서 요청한 도메인을 DNS 를 통해 해석되는 절차에 대해서 알아보자
개요
얼마 전, 저희 팀 내부에서 자유로운 주제로 발표하는 ‘MORNING CTC’ 세션을 통해, ‘HTTP’에 이어, ‘DNS’를 주제로 하여 발표를 진행하게 되었는데요, 발표 내용을 정리할 겸 블로그에 해당 내용을 업로드 해 보고자 합니다.
인터넷이 상용화 된 오늘 날, 대부분의 웹 서비스는 사용자들과 커뮤니케이션을 하기 위해 사용자들이 쉽게 알아볼 수 있는 형태인 문자열 기반의 도메인을 통해 서비스를 제공하고 있습니다. 또한 최근 기업 비즈니스 환경에서 클라우드를 도입하는 기업이 증가하면서 클라우드에 대한 중요성은 더욱이 커지고 있는데, 이러한 클라우드 환경에서도 도메인 베이스의 서비스를 제공하고 있습니다.
이처럼 우리에게 편의성을 제공하는 HTTP 만큼 익숙한 DNS는 도메인을 해석하는 역할을 하고 있는데요, IP 주소보다 도메인을 이용하는 게 일반 사용자들에게 익숙하기도 하고, 유동 아이피 환경에도 쉽게 대응할 수 있다보니 최근 네트워크 통신에서 DNS는 매우 중요한 역할을 담당합니다.
본 게시글에서는 초기 TCP/IP 시절, 도메인 이름을 전제로 개발된 시스템인 DNS가 등장하게 된 배경과 도메인 계층 구조, 그리고 DNS에서 도메인을 해석하는 절차와 여러 리소스 레코드마다 RFC에 제시된 요건과 그에 따른 스펙에 대해서 살펴보고, 도메인을 발급하는 과정부터 네임서버에 리소스 레코드 정보를 등록하는 과정에 대해 정리 해 보겠습니다.
각 주제에 대한 세부적인 상세 내용은 다루지 않으니, 이 점 참고하여 읽어주시면 감사드리겠습니다.
목차
- 안녕 DNS!
- 단일 관리 책임자를 통한 HOSTS 파일 집중 관리
- 집중 관리 방식에서 계층화와 위임을 통한 관리 범위 분산화
- 도메인 이름을 해독하는 DNS는 어떻게 동작할까?
- Zone Transfer, DNS영역을 전달하여 네임서버 가용성 향상
- 도메인 발급부터 AWS Route 53 네임서버 설정을 위한 절차
안녕, DNS!
DNS는 Domain Name System의 약자로 C/S 모델을 따르며, Application 계층에서 동작하는 프로토콜로, 우리가 웹 브라우저에 도메인을 입력하게 되면 해당 도메인을 해석하는 역할을 담당합니다.
대부분의 웹 서비스는 도메인 기반으로 서비스를 제공하고 있는데요. 사실 실제 네트워크 통신에서는 C/S 간 통신 상대를 식별할 때, 인터넷 계층의 IP 헤더 내 목적지 대상 주소를 기반으로 데이터를 전달하게 됩니다. 때문에 상대의 아이피 주소 정보를 알고 있지 않다면, 데이터를 전달할 수 없습니다. 그래서 이러한 통신 상대를 식별하기 위해서 목적지 주소 정보를 제공하는 역할을 DNS가 담당하고 있습니다.
만약 사용자들에게 도메인을 통해 서비스를 제공 받을 수 있도록 하는 DNS가 없었다면, IP 주소 정보를 모두 기억하고 있어야 하는데요, 사실 사람이 수많은 IP 정보를 외우고 있는 건 어려운 일 입니다.
이처럼 우리에게 편의성을 제공하는 도메인 해석 프로세스가 도입되기 이전에는 사용자들에게 어떻게 서비스를 제공했을지 궁금하지 않으신가요?
단일 관리 책임자를 통한 HOSTS 파일 집중 관리
DNS 기능이 개발되기 이전인 인터넷 초기 시절, 스마트폰에 각자의 전화번호를 저장하여 관리하듯, 과거에는 ‘HOSTS.TXT’ 파일을 통해 각 단말 장치를 식별하는 별칭과 호스트 아이피 정보를 매핑하여 호스트 테이블을 관리하였습니다.
현재는 주로 내부 테스트 용도로 활용되고 있는 ‘HOSTS.TXT’ 파일이 과거에는 DNS 처럼 활용되었습니다.
해당 파일은 하기 그림과 같이 한 라인 당 하나의 엔트리를 가지고 있으며, 호스트 아이피 정보와 호스트 네임, 별칭 필드로 구성 되었습니다. 이러한 호스트 테이블 정보를 가진 호스트 파일은 과거 ‘SRI-NIC(Stanford Research Institution Network Information Center)’에서 인터넷에 연결된 모든 호스트 정보를 매핑하여 관리 하였습니다.
과거에는 해당 파일을 통해 각 조직의 신청 내용을 확인하여 심사를 거치고, 아이피 주소를 할당하여 그 결과를 등록해서 업데이트 된 파일은 2주에 한 번씩 인터넷에 배포 하였습니다. 그리고 배포된 파일을 사용자들이 다운로드하여 사용하는 방식이었습니다.
그러나 서비스 제공자가 증가하면서 SRI-NIC에 신청하는 호스트의 수도 증가하게 되었고, 이에 따라 신청부터 아이피 할당, 업데이트 된 사항에 대해 반영하고 배포하기까지 상당한 시간이 소요되었습니다. 또한 이 파일은 단일 관리 책임자 한정으로 관리가 되었기에 관리자의 부담과 복잡성으로 인한 한계도 있었습니다.
따라서 새로운 방식의 도메인 해석 프로세스를 고안하여 이 문제를 해소하고자 하였고, 이 방식이 오늘날 우리에게 친근한 프로토콜인 DNS 입니다.
집중 관리 방식에서 계층화와 위임을 통한 관리 범위 분산화
새롭게 도입된 도메인 해석 프로세스는 단일 파일을 활용한 집중 관리 방식이 아닌, 도메인을 계층화하여 여러 레지스트리에서 분산 관리하도록 개선 되었습니다. 개선된 이 방식은 계층화와 위임 구조라는 체계를 도입하는 형태인데요, 루트 노드로부터 위임 받은 담당 영역에 대해서만 관리 책임자가 되어 관리는 형태로 운영 합니다.
해당 내용을 설명하기 이전에 도메인이 어떻게 계층화 되는지, 도메인 형식과 도메인 명명 규칙에 대해서 살펴 보도록 하겠습니다.
상기 그림과 같이 도메인은 역트리 구조로 구성되어, 루트부터 왼쪽 방향으로 Top-Level Domain, Second-Level Domain, Third-Level Domain와 같은 형태로 상위 레벨부터 하위 레벨로 계층적으로 나누어 지도록 설계 되었습니다. 그리고 이러한 FQDN(Fully Qualified Domain Name)은 오른쪽부터 해석되는 게 아닌, 왼쪽 방향부터 해석하게 됩니다.
RFC1034에서 정리한 내용에 따르면, 도메인은 루트 노드를 기준으로 하여 각 계층을 온점(.)으로 연결한 형태로 표기하며, 각 온점 사이의 문자열은 레이블(Label)로 명명하도록 정의 되어 있습니다. 각 레이블은 영숫자와 하이픈(-) 기호를 포함하고 있으며, 대소문자를 구분하지 않습니다. 전체 도메인에 대한 최대 크기는 255byte이며, 하나의 레이블 당 최대 63byte 크기를 가지고 있습니다.
이러한 도메인 체계로 구분된 최상위 도메인은 대표적으로 일반 최상위 도메인인 gTLD(Generic Top Level Domain)와 New gTLD(New Generic Top Level Domain)으로 구분되며, 국가 코드 도메인은 ccTLD(Country Code Top Level Domain)와 같이 두 가지 유형으로 분류됩니다.
국가 코드 최상위 도메인에 해당되는 ccTLD는 국가 최상위 도메인을 원칙으로 하여 ISO 3166 표준으로 규정된 두 글자의 국가 코드가 사용되고 있습니다. 이는 ISO 3166에서는 알파벳 두 글자를 사용한 alpha-2와 알파벳 세 글자를 사용한 alpha-3, 그리고 숫자 세 글자를 사용한 numeric-3이 규정되어 있는데요, ccTLD를 정할 때, 세 글자인 TLD ‘.com’등은 이미 사용이 되고 있었고, 숫자로 하기에는 IP 주소와 혼동 될 가능성이 있기에 알파벳 두 글자를 사용한 alpha-2를 채택하게 되었다고 합니다.
다음으로 일반 최상위 도메인에 해당되는 gTLD는 특별한 제한 없이 사용되는 ‘.com’ 혹은 ‘.edu’, ‘.gov’ 와 같이 세 글자 이상으로 구성 되었습니다. 참고로 교육 기관(.edu), 정부 기관(.gov)은 일부 일정 요건이 필요하며, 커뮤니티, 지리명, 브랜드에 따른 다양한 gTLD도 존재합니다.
이와 같이 다양한 유형의 TLD는 하기의 링크에서 참고 가능한데요, 정말 많은 최상위 도메인들이 관리되고 있네요! 놀랍지 않나요?
이처럼 현재 인터넷 상에서 사용되는 도메인은 매우 다양합니다. 때문에 동일한 도메인 정보들은 하나의 서버에서 모두 관리하기엔 어려우므로 새로운 도메인 프로세스에서는 분산된 데이터베이스로 서로 도와주도록 설계가 되었으며, 도메인 이름을 계층별로 서로 분리하여 도메인마다 별개의 네임서버들이 나누어져서 관리되는 체계로 운영됩니다.
상기 그림과 같이 원본 루트 DNS 서버는 현재 전 세계 13개의 기관에서 관리되고 있으며, 대표적으로 국제인터넷주소관리기구(ICANN)를 비롯하여 NASA, 메릴랜드 대학교, Verisign, ISC 등에서 운영하고 있습니다.
전 세계 루트 DNS 운영 현황 정보는 하기의 링크를 참고 바랍니다.
이러한 루트 DNS는 도메인의 최상위 계층인 루트 노드가 되어, 하위 계층인 TLD(최상위 도메인) ‘.com’ 같은 최상위 도메인의 네임서버 정보를 가지며, 해당 정보를 토대로 TLD 네임서버로 안내합니다. 그리고 TLD 네임서버도 루트 DNS와 마찬가지로 하위 계층인 Authoritative DNS 서버의 정보를 가지고 있습니다. 이 권한 있는 서버는 우리가 일반적으로 알고 있는 AWS에서 제공하는 Route 53 혹은 가비아, 후이즈와 같은 도메인 등록 대행자 업체에 해당되는데요, 이처럼 등록 대행자 업체에서 관리되는 네임서버가 권한 있는 네임서버에 해당됩니다. 이 네임서버에서는 실제 개별 호스트에 대한 도메인과 아이피 주소에 대한 리소스 레코드셋 정보를 관리합니다.
물론 이러한 업체에서 제공하는 네임서버 외에도 자체적으로 구축한 네임서버도 권한 있는 서버에 해당됩니다.
정리하자면, 새로운 도메인 해석 프로세스인 DNS는 트리 구조와 유사한 형태로 계층화되어, 상위 도메인은 하위 도메인에 대한 정보를 유지하고 제공하도록 설계가 되어 이를 통해 집중 관리 방식의 한계를 극복하고 폭증한 단말을 수용할 수 있게 되었습니다.
도메인 이름을 해독하는 DNS는 어떻게 동작할까?
사용자가 브라우저에 서비스를 제공 받기 위해 특정 웹 서버에 대한 도메인을 입력 했다고 가정한다면, 먼저 브라우저에서는 요청 도메인에 대한 URL 정보를 해석하여 액세스 경로를 파악하고, 사용자 요청에 따른 HTTP 요청 메시지를 생성하여 이 메시지를 대상 웹 서버로 전달합니다.
다만, 메시지를 전달하는 과정에서 한 가지 문제점이 있는데요. 브라우저에서는 URL을 해독하여 액세스 경로를 파악하거나 HTTP 메시지를 생성할 수 있지만, 생성된 메시지를 네트워크로 송출하지 못합니다. 그렇기 때문에 사용자의 요청을 목적지 대상에게 전달하기 위해서 OS의 도움을 받아야 하는데, OS를 통해 송신하기 위해서는 도메인명이 아닌, 목적지 대상 아이피 주소로 메시지를 받을 상대를 지정해야 합니다.
이유는 어플리케이션 계층에서 어플리케이션 프로세스를 정의하고 서비스를 수행하게 되면, 인터넷 계층에서는 IP 주소와 같이 논리적인 주소로 목적지 네트워크 대역을 식별하고, 해당 경로로 패킷을 라우팅하게 됩니다. 따라서 하기 그림과 같이 IP 전송 단위인 데이터그램이라는 패킷 내에 목적지 호스트 정보를 포함하게 되고, 이 정보를 기반으로 패킷 네트워크 상에서 목적지 대상에게 패킷을 전송하게 됩니다.
이러한 이유로 상대측에게 데이터를 보내기 위해서는 목적지 호스트 아이피 주소 정보로 데이터를 전달하기 때문에 사용자가 요청한 도메인을 해석하여야 하며, 이러한 역할을 DNS 가 수행하게 됩니다. 참고로 DNS 에게 정보를 요청하는 역할을 소켓 라이브러리의 리졸버가 담당합니다.
정리하자면, 클라이언트 어플리케이션 브라우저에서는 도메인에 대응하는 호스트 IP 주소 정보를 조사하기 위해서 OS 내부에 포함되어 있는 소켓 라이브러리의 리졸버 함수를 호출하게 되고, 리졸버를 통해 DNS 서버에게 정보를 요청합니다. 다만, 리졸버도 브라우저와 마찬가지로 데이터 송/수신을 하기 위한 기능은 없기 때문에 OS 내부에 포함된 네트워크 제어용 소프트웨어를 이용해 DNS 서버로 정보를 요청합니다. 이후 DNS 서버를 통해 응답을 받게 되면 리졸버는 응답 메시지를 해석하여 메모리에 주소 정보를 적재합니다.
참고로 도메인에 대응하는 호스트 IP 주소를 조사하는 역할을 하는 대표적인 getaddrinfo() 함수의 원형은 하기의 코드 블록과 같습니다.
#include <sys/socket.h>
#include <netdb.h>
int getaddrinfo(const char *nodename,
const char *service,
const struct addrinfo *hints,
struct addrinfo **res);
※ 과거에 사용한 gethostbyname() 함수는 deprecated 되었습니다.이처럼 어플리케이션에서 호출되어 도메인명을 아이피 주소로 변환하는 리졸버의 이름을 스터브 리졸버라고 하며, 이 리졸버는 실제 응용상에서 이용하는 도메인에 대해 정보를 물어보는 역할을 하게 됩니다.
도메인 해석 요청을 받은 스터브 리졸버는 도메인에 대한 정보를 알아내기 위해서 일차적으로 HOSTS 파일을 참조하게 됩니다. 그리고 해당 파일에 정보가 없다면, 시스템 내부에 등록한 Local DNS 정보를 확인하여 해당하는 로컬 DNS 에게 도메인 해석을 요청합니다. 이 로컬 DNS에서 도메인 해석을 담당하는 리졸버는 풀 리졸버라고 하며, 이러한 클라이언트 어플리케이션에서 호출한 스터브 리졸버가 로컬 DNS로 요청하는 과정을 재귀 질의(Recursive Query)라고 합니다.
로컬 DNS는 보통 KT, SK 브로드밴드와 같은 ISP 업체에서 관리하며, 이 외에도 Google Public DNS, Quad9, Cloudflare 등 다양한 퍼블릭 DNS가 있습니다.
그리고 풀 리졸버는 루트 DNS부터 하위 계층의 네임서버까지 질의하여 도메인 이름을 클라이언트에게 반환해주는 역할을 담당합니다. 이 리졸버는 루트 DNS에게 요청하기 이전에 본인이 가지고 있는 리소스 레코드셋 정보를 참조하여 응답하게 되고, 정보가 없다면 하기 그림과 같이 루트 DNS 정보를 담은 Root Hint 파일을 참조하여 루트 DNS 서버부터 계층적인 순서로 반복 질의(Iterative Query)를 합니다.
따라서 해당 파일을 통해 알아낸 루트 DNS 서버에게 하위 계층에 해당되는 TLD 부터, 레지스트라에서 관리하는 네임서버까지 도메인에 대한 정보를 요청하게 되고, 이 과정을 토대로 요청 도메인에 대한 주소 정보를 전달 받습니다. 그리고 로컬 DNS에서는 이 정보를 다음번 요청에 대한 응답으로 재 사용하기 위해 응답에 대한 결과를 캐싱합니다.
클라이언트에서 도메인 네임서버로 질의하는 과정을 정리하면, 다음의 두 가지로 나누어 볼 수 있습니다.
- 클라이언트 스터브 리졸버의 재귀 질의(Recursive Query) 과정
→ DNS Cache → Hosts 파일 참조 → 로컬 DNS 서버 질의
- 로컬 DNS 풀 리졸버의 반복 질의(Iterative Query) 과정
→ DNS Cache → Local DNS Zone 파일 참조 → 루트 서버 리스트를 담은 Root Hint 파일 참조 → 반복 질의
이와 같이 각각의 도메인에 대해서 네임서버가 정보를 가지고 있고, 네임서버에서는 특정 도메인에 대한 해석을 할 수 있도록 리소스 레코드로 등록되는 Zone 파일이라는 형태로 도메인에 대한 리소스 레코드(Resource Record) 정보를 관리합니다. 실제로 우리가 도메인 등록 업체에서 관리되는 네임서버에 등록하는 정보들이 이러한 리소스 레코드 정보가 되며, 이 정보를 토대로 도메인에 대응하는 정보를 반환합니다.
이러한 리소스 레코드 정보를 담은 파일은 영역 데이터 파일(Zone Database) 이라고 하며, 특정 영역에 대한 정방향 해석을 위한 정방향 영역(Forward Zone)이 설정된 파일과 특정 영역에 대한 역방향 해석을 위한 역방향 영역(Reverse Zone)이 설정된 파일로 구분됩니다.
하기 그림은 영역 데이터 파일의 리소스 레코드 세트(RRset)를 담은 기본 파일인데요, 이처럼 도메인마다 리소스 레코드 데이터를 존 파일 형식으로 관리하고 있으며, 이 파일은 RFC 1033–1035에서 정의한 규칙을 따라 작성됩니다.
네임서버에서 관리되는 이러한 리소스 레코드 정보는 하기의 링크를 통해 참고 가능합니다.
리소스 레코드 형식은 하기 그림과 같이 응답된 리소스 레코드가 캐시 테이블에 존재할 수 있는 시간인 TTL 정보와 동작할 네트워크 환경을 의미하는 클래스, 리소스 레코드의 종류를 구분하는 타입, 그리고 리소스 레코드의 실제 데이터 등으로 구성되며, 이 정보를 토대로 실제 주소 해석이 이루어집니다.
지원하고 있는 리소스 레코드 종류가 많지만, 주요 DNS 리소스 레코드 종류는 다음과 같습니다.
- A (IPv4 호스트) - 요청 도메인을 IPv4 주소로 변환
- AAAA (IPv6 호스트) - 요청 도메인을 IPv6 주소로 변환
- CNAME (별칭) - 도메인 이름을 다른 도메인 별칭(Alias) 지정
- SOA (권한 시작) - DNS 영역에 대한 기본 정보(시간 정보 등)을 제공, 영역을 관리하는 담당자 정보와 유효 기간 등을 포함
- NS (도메인에 대한 네임서버) - 요청 도메인이 설정된 네임 서버 도메인 주소
- MX (메일 교환기) - 이메일을 전송하기 위한 메일 서버 호스트 이름 지정
- PTR (포인터) - 요청 IP 주소의 역방향 도메인
- TXT (텍스트) - 도메인 이름과 연결된 임의의 텍스트 텍스트 정보를 지정, 예로 들어 이메일 보안을 위한 SPF(Sender Policy Framework) 레코드 유형 등에 사용
이러한 리소스 레코드셋 정보는 클라이언트에서 dig 혹은 nslookup과 같은 명령줄 도구로도 조회가 가능하며, DNS 서버를 지정하지 않으면 Local DNS로 질의하여 사용자에게 정보를 제공합니다.
Zone Transfer, DNS 영역을 전달하여 네임서버 가용성 향상
만일 영역을 관리하는 네임서버가 한 대 뿐이고, 그 서버에 장애가 발생하게 된다면 해당 네임서버에서 관리하는 존의 정보는 제공할 수가 없게 되고, 서비스에 영향을 미치게 됩니다. 때문에 DNS에서는 동일한 존의 데이터를 가진 네임서버를 여러 대 마련하고, 풀 리졸버의 요청을 분산하여 관리할 수 있도록 합니다. 이 방식을 통해 DNS 서버 가용성 향상과 동시에 풀 리졸버는 RTT(Round Trip Time, 왕복 시간)를 체크하여 RTT가 짧은 네임서버에 우선적으로 질의하여 레이턴시를 최소화하기도 합니다.
이 방식은 기본적으로 주 네임서버(Primary)와 다수의 보조 네임서버(Secondary)로 구성되어, 보조 네임서버가 영역 데이터의 최신화를 위해 주 네임서버에게 주기적으로 Zone Transfer를 요구하고, 그 요구를 받은 주 네임서버가 영역 데이터를 보조 네임서버에게 보내는 순서로 동기화가 이루어지게 됩니다. 이러한 과정을 통해 보조 네임서버에서는 주 네임서버로부터 받은 존 데이터를 사용하여 풀 리졸버 질의에 응답할 수 있게 됩니다. 참고로 주 네임서버와 보조 네임서버 간 신뢰성을 보장한 동기화를 위해 TCP Connection을 맺기도 합니다.
이러한 존 전송 방식은 크게 두 가지로, 모든 정보를 보내는 AXFR(Authoritative Transfer)방식과 수정본에 대해서만 전송하는 IXFR(Incremental Transfer)방식으로 구분됩니다. AXFR 방식은 SOA 레코드의 필드 중, 도메인 존을 갱신하는 주기 시간인 Refresh에 설정된 초 단위 시간마다 주 네임서버에서 존 영역을 한 번에 전송하기 때문에 갱신할 데이터가 큰 경우, 동기화 지연시간 및 상당한 네트워크 트래픽을 유발할 수 있는데요. 이 방식과 비교하여 IXFR 방식은 변경된 사항에 대해서만 업데이트를 하기 때문에 AXFR 방식에 비해 효율적입니다. 다만, IXFR 방식은 이전 상태의 변경 내용을 추적하고 있어야 하므로, 주 네임서버에서 이 방식을 지원하는 기능을 제공해야 합니다.
도메인 발급부터 AWS Route 53 네임서버 설정 절차
도메인을 발급하기 위해서는 다음과 같은 절차를 따를 수 있습니다. 먼저, 도메인을 구매하고자 하는 등록자는 레지스트리에서 제공하는 hosting.kr, whois와 같은 서비스를 통해서 도메인 이름 등록 가능 여부를 확인합니다. 그리고 등록자는 가격이나 서비스 내용 등을 비교하여 등록 대행자를 선택해 도메인 구매 신청을 하고, 이후에 구매한 도메인으로 서비스를 제공하기 위해서 도메인 구매처에서 운영하는 네임서버 혹은 타사 네임서버를 통해 리소스 레코드 정보를 설정하게 됩니다.
저는 ‘doasdoa.site’ 라는 도메인을 구매하여 이용하고 있는데요, 하기 그림과 같이 해당 도메인에 대한 정보를 AWS 에서 제공하는 Amazon Route 53 을 통해 관리하기 위해 Route 53 네임서버 정보를 도메인 구매처에 등록했습니다.
참고로 네임서버 정보는 NS 레코드로 등록이 가능한데요, 이 레코드 유형은 어떠한 DNS 서버가 해당 도메인의 권한 있는 서버에 해당되는지, 즉, 실제 DNS 리소스 레코드셋 정보를 가지고 있는 서버인지를 지시합니다.
참고로 Amazon Route 53 네임서버의 영역 데이터 파일은 하기 그림과 같이 웹 콘솔을 통해 간편하게 설정이 가능하도록 제공하고 있으며, 웹 콘솔을 통해 A 레코드 유형, 메일 서버를 운용하기 위한 MX 레코드와 IP 주소를 기반으로 도메인 주소를 찾기 위한 PTR 레코드, 화이트 도메인 등록과 스팸 메일 인증에서도 활용되는 TXT 등의 다양한 리소스 레코드 유형 정보를 등록할 수 있습니다.
마치며
이처럼 인터넷상에서 도메인을 해석하기 위해서 중요한 역할을 담당하고 있는 DNS 프로토콜은 그 절차가 매우 간단해 보여도, 사실은 매우 복잡한 형태로 구성이 되어 있습니다. 상당히 흥미롭지 않나요? 이번 글에서는 DNS를 통해 확장된 기술에 대해서는 다루지 못했지만, 추후에 기회가 된다면 해당 내용도 정리 하고자 합니다!
지금까지 긴 글 읽어주셔서 감사합니다.
[1]: Doa’s Engineering Blog. [Network] 브라우저에서 요청한 도메인을 DNS를 통해 해석되는 절차를 살펴보자
https://blog.naver.com/pearl097/223027842086
