reference: https://www.youtube.com/watch?v=XXzxetbAIfA&t=729s
reference: https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-DNS-%EA%B0%9C%EB%85%90-%EB%8F%99%EC%9E%91-%EC%99%84%EB%B2%BD-%EC%9D%B4%ED%95%B4-%E2%98%85-%EC%95%8C%EA%B8%B0-%EC%89%BD%EA%B2%8C-%EC%A0%95%EB%A6%AC#dns_%EB%8F%99%EC%9E%91_%EC%88%9C%EC%84%9C
인터넷을 이해할 때 핵심적으로 보는 요소는 라우터(Router)와 DNS(Domain Name System)입니다.
프로젝트의 디테일을 잡으며, 서비스 배포를 준비하고 있습니다. 배포란, 내 컴퓨터에서 만든 프로젝트를 인터넷이나 서버에 올려 모두가 사용할 수 있게 만드는 과정을 의미합니다.
그런데 이미 서비스 중인 유튜브나 인스타그램처럼, 사람들이 어떻게 내 서비스에 접속할 수 있는지 이해하려면 DNS의 역할을 아는 것이 중요합니다.
따라서 이번 글에서는, 배포와 연결된 DNS의 개념과 역할을 살펴보겠습니다.
DNS는 Domain Name System입니다.
구글에 접속할 때 우리는 www.google.com을 입력하면 됩니다. 아니면 142.250.207.14를 입력해도 됩니다. 그런데 저는 구글에 접속할 때마다 142.250.207.14 형태를 입력하고 싶지도 않고, 이 숫자들을 외울 자신도 없습니다.
Domain Name System은 사람이 이해하기 쉬운 도메인 이름을 컴퓨터가 이해할 수 있는 IP 주소로 변환하는 인터넷의 전화번호부 역할을 합니다. 마치 우리가 친구의 이름으로 전화번호부에서 번호를 찾아 전화를 거는 것처럼, 컴퓨터도 도메인 이름으로 실제 서버의 위치인 IP 주소를 찾아서 연결합니다.

브라우저에 www.naver.com을 입력했을 때 실제로 일어나는 과정을 자세히 살펴보겠습니다.
먼저 브라우저는 자신의 캐시에서 해당 도메인의 IP 주소를 찾아봅니다. 최근에 같은 사이트를 방문했다면 브라우저가 그 정보를 기억하고 있어서 즉시 연결할 수 있습니다. 브라우저에 정보가 없으면 운영체제의 DNS 캐시를 확인합니다. Windows나 macOS 같은 운영체제도 자주 방문하는 사이트의 정보를 저장해두고 있기 때문입니다.
그래도 정보를 찾지 못하면 이제 본격적인 DNS 조회가 시작됩니다. 컴퓨터는 ISP(인터넷 서비스 제공업체)의 DNS 서버에 질의를 보냅니다. 우리가 인터넷을 사용하기 위해서는 IP를 할당해주는 KT, LG 등의 통신사에 우리 컴퓨터를 연결하게 되는데, 인터넷이 연결되는 순간 각 통신사의 DNS 서버가 기본 DNS 서버로 등록됩니다. 일반적으로 ISP의 DNS 서버를 로컬 DNS 서버로 이해할 수 있습니다만, 사용자가 구글 퍼블릭 DNS(8.8.8.8)와 같은 회사 내부 DNS 서버를 지정해두면, 그게 곧 나의 로컬 DNS 서버가 된다고 볼 수 있습니다. 한마디로, 내 컴퓨터가 설정해둔 가장 가까운 DNS 서버가 로컬 DNS 서버인 셈이죠.
이러한 로컬 DNS 서버에는 www.naver.com의 IP 주소가 있을 수도 없을 수도 있습니다. 네이버의 IP 주소가 로컬 DNS 서버에 캐싱되어 있다면 바로 위 이미지의 1단계에서 8단계로 넘어가게 됩니다. 빠르게 네이버 웹 페이지에 접속할 수 있다는 뜻이죠. 그런데 나머지 과정을 설명하기 위해 로컬 DNS 서버에 네이버의 IP 주소가 캐싱되어 있지 않았다고 가정하겠습니다.
이제 로컬 DNS 서버는 www.naver.com의 IP 주소를 찾아내기 위해 Root DNS 서버에게 네이버의 IP 주소를 요청하게 됩니다.
Root DNS 서버는 www.naver.com 전체의 IP 주소는 찾을 수 없으니 com DNS 서버에게 물어보라는 응답을 로컬 DNS 서버에 내려줍니다. 후술하겠지만 com DNS 서버는 TLD DNS 서버(최상위 도메인 서버)에 해당합니다.
응답을 받은 로컬 DNS 서버는 com 도메인을 관리하는 TLD DNS 서버에 다시 www.naver.com에 대한 IP 주소를 요청합니다.
com DNS 서버는 www.naver.com의 IP 주소는 찾을 수 없으니 naver.com DNS 서버에게 물어보라는 응답을 로컬 DNS 서버에 내려줍니다. 여기서 naver.com DNS 서버는 Second-level DNS 서버에 해당합니다.
로컬 DNS 서버는 naver.com DNS 서버에게 다시 www.naver.com의 IP 주소를 요청합니다.
naver.com DNS 서버에는 www.naver.com의 IP 주소가 있습니다. 따라서 로컬 DNS 서버에게 네이버의 IP 주소인 222.122.195.6를 내려주게 됩니다.
로컬 DNS 서버는 www.naver.com의 IP 주소를 캐싱합니다. 최종적으로 사용자는 네이버의 웹 페이지를 볼 수 있게 됩니다.
⚠️ 로컬 DNS 서버가 여러 DNS 서버에 차례대로 요청을 진행하여 원하는 IP 주소를 찾는 과정을 재귀적 쿼리(Recursive Query)라고 합니다.
DNS는 단일 서버가 아니라 전 세계에 분산된 여러 단계의 서버들이 계층적으로 구성된 시스템입니다. 이러한 분산 구조 덕분에 전 세계의 수억 개 도메인 정보를 효율적으로 관리할 수 있으며, 한 곳에 장애가 발생해도 시스템 전체가 멈추지 않습니다. 이번에는 위 흐름에서 언급되었던 개별 DNS 서버에 대해 깊게 살펴보겠습니다.
기지국 DNS 서버는 우리가 인터넷에 연결할 때 가장 먼저 접촉하는 DNS 서버입니다. KT, LG, SK 같은 인터넷 서비스 제공업체(ISP)에서 운영하는 이 서버는 사용자와 전 세계 DNS 시스템 사이의 중개자 역할을 합니다.

로컬 DNS 서버의 가장 중요한 기능은 캐싱입니다. 많은 사용자들이 네이버, 구글, 유튜브 같은 인기 사이트를 자주 방문하기 때문에, 기지국 DNS 서버는 이런 사이트들의 IP 주소 정보를 미리 저장해둡니다. 그래서 다른 사용자가 같은 사이트에 접속하려고 할 때는 멀리 있는 다른 서버까지 가지 않고도 즉시 답을 줄 수 있습니다.
만약 캐시에 정보가 없다면 기지국 DNS 서버는 재귀적 쿼리를 수행합니다. 이는 사용자를 대신해서 다른 DNS 서버들에게 차례차례 질문을 하고, 최종 답을 찾아서 사용자에게 돌려주는 과정입니다. 마치 도서관 사서가 책을 찾기 위해 여러 서가를 뒤지고, 다른 도서관에도 문의해서 결국 원하는 책을 찾아주는 것과 같습니다.
루트 DNS 서버는 DNS 계층 구조의 최상위에 위치한 서버로, 인터넷의 모든 도메인 질의가 궁극적으로 거쳐가는 출발점입니다. 전 세계에 13개의 루트 서버가 운영되고 있으며, A부터 M까지의 이름으로 구분됩니다.
(base) wonminkwan@wonmingwan-ui-MacBookAir ~ % dig . NS
; <<>> DiG 9.10.6 <<>> . NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10605
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;. IN NS
;; ANSWER SECTION:
. 294286 IN NS k.root-servers.net.
. 294286 IN NS d.root-servers.net.
. 294286 IN NS b.root-servers.net.
. 294286 IN NS l.root-servers.net.
. 294286 IN NS a.root-servers.net.
. 294286 IN NS m.root-servers.net.
. 294286 IN NS c.root-servers.net.
. 294286 IN NS e.root-servers.net.
. 294286 IN NS f.root-servers.net.
. 294286 IN NS j.root-servers.net.
. 294286 IN NS g.root-servers.net.
. 294286 IN NS h.root-servers.net.
. 294286 IN NS i.root-servers.net.
루트 DNS 서버의 주된 역할은 최상위 도메인(TLD) 서버의 위치를 알려주는 것입니다. 예를 들어 누군가 www.example.com을 찾고 있다면, 루트 서버는 ".com 도메인은 이 주소에 있는 TLD 서버에서 관리하고 있어요"라고 알려줍니다. 실제로 IP 주소를 직접 제공하지는 않고, 다음 단계로 갈 수 있는 길잡이 역할만 합니다.
이 13개의 루트 서버는 각각 전 세계 곳곳에 수백 개의 미러 서버를 두고 있습니다. 그래서 실제로는 수천 개의 루트 서버가 운영되고 있으며, 사용자는 가장 가까운 서버와 통신할 수 있습니다. 이러한 분산 구조 덕분에 99.9% 이상의 가용성을 보장할 수 있으며, 인터넷의 핵심 인프라로서 안정적으로 동작합니다.
루트 DNS 서버의 주된 역할이, 최상위 도메인(TLD) 서버의 위치를 알려주는 것이었죠. TLD(Top-Level Domain) 서버는 루트 DNS 서버 바로 아래 단계에 있는 1단계 도메인에 해당합니다.
TLD 서버는 최상위 도메인을 관리하는 서버입니다. 최상위 도메인에는 두 가지 주요 유형이 있습니다.

먼저 일반 최상위 도메인(gTLD)이 있습니다. .com은 상업적 목적으로 사용되는 가장 인기 있는 도메인이고, .org는 비영리 조직에서, .net은 네트워크 관련 조직에서, .edu는 교육기관에서 주로 사용됩니다. 최근에는 .app, .blog, .shop 같은 새로운 일반 최상위 도메인들도 많이 생겨났습니다.
다음으로 국가 코드 최상위 도메인(ccTLD)이 있습니다. .kr은 대한민국, .jp는 일본, .cn은 중국, .us는 미국을 나타냅니다. 각 국가의 정부나 지정된 기관에서 관리하며, 해당 국가와 관련된 조직이나 개인만 등록할 수 있는 경우가 많습니다.
TLD 서버는 해당 최상위 도메인 하위의 Second-level DNS 서버 정보를 관리합니다. 예를 들어 .com TLD 서버는 google.com, naver.com, facebook.com 같은 도메인들이 어느 DNS 서버에서 관리되는지 알고 있습니다. 또한 도메인 등록 관리 기관과 연동되어 새로운 도메인의 등록과 갱신, 삭제 등의 작업을 처리합니다.
Second-level DNS 서버는 특정 도메인에 대한 권한을 가진 DNS 서버로, 실제 도메인과 IP 주소의 매핑 정보를 보관하는 곳입니다. 이 서버야말로 "naver.com의 IP 주소는 223.130.195.200입니다"라고 확답을 주는 최종 권한자입니다.
이 서버는 해당 도메인의 모든 서브도메인 정보도 함께 관리합니다. 네이버의 경우 mail.naver.com, blog.naver.com, cafe.naver.com 등 수많은 서브도메인이 있는데, 이들의 IP 주소 정보를 모두 Second-level DNS 서버에서 관리합니다. 도메인 소유자가 직접 이 서버를 운영하기도 하지만, 대부분은 전문 DNS 호스팅 업체에 관리를 맡깁니다.
DNS 레코드에는 여러 종류가 있습니다. A 레코드는 도메인을 IPv4 주소에 매핑하는 가장 기본적인 레코드이고, AAAA 레코드는 IPv6 주소에 매핑합니다. CNAME 레코드는 도메인을 다른 도메인의 별칭으로 설정할 때 사용하며, www.example.com을 example.com의 별칭으로 만드는 식으로 활용됩니다. MX 레코드는 메일 서버 정보를, NS 레코드는 네임서버 정보를, TXT 레코드는 SPF나 DKIM 같은 메일 보안 설정 등 다양한 텍스트 정보를 저장합니다.
Sub DNS 서버는 서브도메인을 관리하는 DNS 서버로, 대규모 조직에서 내부 도메인 관리를 세분화하기 위해 사용됩니다. 네이버를 예로 들면, mail.naver.com은 네이버 메일 서비스를, blog.naver.com은 네이버 블로그 서비스를, cafe.naver.com은 네이버 카페 서비스를 담당합니다.
이런 서브도메인들은 상위 도메인인 Second-level DNS 서버에서 위임받아 별도로 관리됩니다. 이렇게 하면 각 서비스팀이 독립적으로 자신들의 도메인을 관리할 수 있고, 서비스별로 다른 서버나 CDN을 사용하는 것도 가능해집니다. 또한 내부 네트워크에서 개발, 테스트, 운영 환경을 구분하는 데도 활용되며, 로드밸런싱과 서비스 분산에도 중요한 역할을 합니다.
서비스를 실제로 배포할 때 DNS 설정은 필수적인 과정입니다. 아무리 훌륭한 웹사이트를 만들어도, 사용자들이 접속할 수 있는 도메인이 없다면 소용이 없기 때문입니다.
도메인을 구입하고 서비스를 배포하는 전체 과정을 살펴보겠습니다. 먼저 도메인 등록 대행사(가비아, 후이즈, GoDaddy 등)에서 원하는 도메인을 구입합니다. 이때 도메인은 단순히 이름만 예약하는 것이고, 실제로 어떤 서버와 연결할지는 별도로 설정해야 합니다.
다음 단계는 DNS 서버 설정입니다. 도메인을 구입하면 기본적으로 등록업체의 네임서버가 설정되는데, 이를 실제 DNS 호스팅을 제공하는 업체(Cloudflare, Route 53, CloudDNS 등)로 변경합니다. 그리고 해당 DNS 호스팅 업체에서 A 레코드를 설정해서 도메인을 실제 서버의 IP 주소와 연결합니다. 보통 www 서브도메인도 함께 설정하는데, 이는 CNAME 레코드로 메인 도메인을 가리키도록 만듭니다.
마지막으로 보안을 위해 SSL 인증서를 적용해야 합니다. 요즘은 모든 웹사이트가 HTTPS를 사용하기 때문에, Let's Encrypt 같은 무료 인증서나 유료 SSL 인증서를 설치해서 암호화된 연결을 제공해야 합니다.
DNS 설정에서 중요한 고려사항들도 있습니다. TTL(Time To Live)은 DNS 레코드가 캐시에 얼마나 오래 저장될지를 결정하는 값입니다. 너무 길게 설정하면 변경사항이 반영되는 데 시간이 오래 걸리고, 너무 짧게 설정하면 DNS 조회가 자주 발생해서 응답 속도가 느려질 수 있습니다. CDN을 사용하는 경우에는 전 세계 사용자들이 빠르게 접속할 수 있도록 DNS 설정을 최적화해야 하고, 로드밸런서를 사용한다면 여러 서버의 IP 주소를 설정해서 트래픽을 분산시켜야 합니다.
DNS는 인터넷의 핵심 인프라로, 우리가 웹사이트에 쉽게 접속할 수 있게 해주는 중요한 시스템입니다. 복잡한 IP 주소 대신 기억하기 쉬운 도메인 이름을 사용할 수 있는 것도, 전 세계 어디서든 같은 웹사이트에 빠르게 접속할 수 있는 것도 모두 DNS의 분산 구조와 캐싱 시스템 덕분입니다.
서비스를 배포할 때 DNS를 제대로 이해하고 설정하는 것은 사용자 경험과 서비스 안정성에 직접적인 영향을 미칩니다. DNS 설정이 잘못되면 사용자들이 사이트에 접속할 수 없거나, 접속 속도가 느려질 수 있기 때문입니다. 반대로 DNS를 최적화하면 전 세계 사용자들에게 빠르고 안정적인 서비스를 제공할 수 있습니다.
DNS의 계층적 구조는 단순해 보이지만 실제로는 매우 정교하게 설계된 시스템입니다. 루트 DNS 서버부터 서브 DNS 서버까지, 각 단계의 서버들이 서로 협력해서 전 세계 수억 개의 도메인을 효율적으로 관리하고 있습니다.