카테고리
게시일
Dec 28, 2025
기초 개념
도메인 네임이란?
IP주소에 매핑되는 텍스트 문자열을 말한다.
google.com 같은게 Domain Name 이다.유저가 google.com을 치면, 유저의 os는 dns 서버에서 domain name 에 해당하는 ip를 받아온다. 실제 유저의 브라우저가 google과 통신하는 것은 이 받아온 ip주소로 한다.
최상위 도메인
- gTLD →
.com.net등
- ccTLD →
.kr등
맨 끝에 가장 큰 단위의 도메인(영역)을 최상위 도메인이라고 하는데, 일반 도메인과 각 국가에서 관리하는 것이 나뉘어있다.
등록기관
일반적으로 국가 도메인은 각 국가의 정부기관에서 관리하며, .net과 같은 도메인은 사기업에서 관리한다.
DNS
이 도메인을 다루는 하나의 거대한 시스템을 DNS라고 한다. 도메인 네임 → IP로 변환시켜주는 서비스를 실질적으로 수행하는 것을 바로 DNS 서버라고 한다.
도메인 네임 구매
도메인 네임을 구매한다는 것은 등록기관에서 특정 도메인 네임을 자신의 서비스에 연동하는 권한을 사는 것으로, 도메인마다 가격이 다르며, 인기 도메인이거나, 특이한 이름일수록 비싸다.
등록기관마다 가격이 다른데, 개인적으로는 CloudFlare를 추천한다. CloudFlare는 대여 시 중간 수수료가 없기 때문에 비용이 저렴한 편이다. (물론 프로모션을 받는다면 다른 업체가 더 저렴한 경우도 있지만, 프로모션을 미끼로 나중에 도메인 등록 비용을 확 올려버리는 곳도 있기 때문에 주의해야 한다.)
DNS record 등록
도메인을 구매했다면 DNS record를 등록해야 서비스에 연결이 가능하다.
- A 레코드 : 도메인 네임을 ip 주소로 바꿔주는 레코드이다.
- AAAA 레코드 : 도메인 네임을 ipv6 주소로 바꿔주는 레코드이다.
- CNAME 레코드 : 다른 도메인 네임으로 중계하는 레코드
- TXT 레코드 : 범용 레코드로, 종종 토큰 인증하고 할 때 사용할 수 있다.
- MX 레코드 : 메일 수신 서버를 등록할 때 사용한다.
아래 내용부터 심화 내용입니다.
등록기관 (Registrar)
우리가 알고 있는 많은 제너릭 도메인은 버지니아 주 소재 사기업인
VeriSign 에서 독점하고 있다.( .com 등)Verisign이 하는 일은 이것 보다도 막강한데, 예를 들면 “
.kr 도메인은 kisa 쪽 서버로 가서 찾아보세요” 라는 정보를 주기도 한다. 이를 루트존이라고 한다.다만 verisign이 모든걸 맘대로 할 수 있는 것은 아니며, 루트존의 관리는 비영리 기관인 ICANN의 규제 하에 이루어지고 있다. ICANN에 대해서는 아래 글 참고
ICANN과 IANA우리가 아는 도메인을 사는곳(GoDaddy, 가비아 등)는 일단 등록기관 (Registrar) 라고 하는데, 이곳들이 개인 도메인을 최상위 등록기관(Verisign이나 kisa)에 등록을 대행하는 역할을 한다.
DNS resolver (Public DNS server)
일반적으로 그냥 “DNS 서버” 라고 하면 바로 이 Public DNS resolver를 의미하는 것이다.
예를 들어 유저가 minseok.page을 브라우저 주소창에 검색하면, 브라우저는 public DNS resolver에 DNS 프로토콜 형식으로 minseok.page의 ip주소를 요청한다. 그러면 DNS resolver는 ip주소를 브라우저에 반환한다.
대표적인 public dns 서버는 아래와 같다.
- 1.1.1.1 (cloud flare)
- 8.8.8.8 (google)
- 통신사 DNS 등
public DNS 서버는 minseok.page의 ip주소를 어디서 가져올까? 바로 하술할 Authoritative DNS server 로 부터 가져온다. Authoritative DNS server도 종류가 여러개가 있는데, 보통 다음과 같은 순서로 순차적으로 쿼리해서 최종 ip주소를 알아낸다.
- Root DNS server ( .page 도메인을 어느 서버에서 관리하는지 알려준다.)
- TLD DNS server (minseok.page 도메인 네임을 어느 서버에서 관리하는지 알려준다.)
- Authoritative DNS server (minseok.page 도메인의 실제 ip 주소는 뭔지 알려준다.)
여기서 중요한 사실은, 매번 User가 minseok.page를 할 때마다 저 단계를 거치면 지연시간이 장난아니라는 것이다. 따라서 한번 이렇게 알아낸 주소는 public DNS 서버에서 캐싱해둔다. 그래서 resolver를 Caching DNS resolver 라고도 한다. 또한 Root부터 재귀적으로 ip 주소를 찾아내기 때문에 Recursive DNS resolver 라고도 한다.
Public DNS resolver마다 캐싱 주기가 다르기 때문에 도메인 네임을 등록했을 때 전 세계 모든 public DNS resolver에 적용되기 까지는 시간이 좀 걸린다. 다만 대부분은 수십초에서 5분 안쪽으로 캐싱을 갱신한다.
Authorative DNS Server
Root DNS resolver
각 TLD를 관리하는 것은 KISA등의 최상위 Registrary이다. 그렇다면 어느 TLD가 어느 Registrary에 매칭되는지는 누가 관리할까? Tld - registrary가 매치된 명단을 root.zone파일이라고 한다. 이는 iana에서 디지털 서명하여, Root DNS resolver에 배포중이다.
이 Root DNS resolver들의 주소는 13개로 고정되어있다. 상술한 verisign을 비롯해 몇 개의 기업과 기관이 root dns resolver를 운영하고 있다.
Root DNS resolver는 하술할 NS레코드를 뒤져보고 TLD registrary를 알려준다.
에를 들어 minseok.page의 경우, 우선 도메인인
.page를 관리하는 서버가 어디있는지 알아야 할 것이다. 이때 root 서버에 물어보면, 서버는 “ .page도메인은 charlestonroadregistry 쪽 DNS resolver에서 관리해” 하고 알려주는 것이다.TLD DNS resolver
TLD에서는 도메인네임을 보고 Authrative Resolver의 주소를 알려준다. 대표적으로
.kr을 관장하는 Kisa가 있다.TLD resolver는 “minseok.page는 가비아 resolver에서 관리해” 라고 알려준다.
Authoritative DNS resolver
Public resolver가 최종적으로 찾아보는 DNS resolver이다. 기업과 개인이 도메인 네임을 실제로 구매하는 곳이기도 하다. Cloudflare, GoDaddy, 가비아 등등… 의 registrar의 resolver 들이 해당된다. 이들이 하는 일은 첫번째로 TLD resolver에 등록을 대행하며, 두번째로 각 도메인 네임에 대한 레코드를 저장 및 제공하는 일을 한다.
Public dns서버는 여기를 거쳐서야 드디어 최종적으로 ip주소를 알아내 캐싱할 수 있다.
DNS 프로토콜
Tcp, udp 53번은 DNS 프로토콜에 할당되어있다. 즉 DNS 요청을 보내는 쪽에서는 DNS Resolver의 53번 포트로 보내면 된다.
Http와 마찬가지로 TCP/UDP 단 위에서 동작하기에 애플리케이션 계층 프로토콜에 속한다.
DNS Header
- Query ID
DNS Header는 여러가지 정보로 구성되어있는데, 가장 중요하다고 볼 수 있는것은 쿼리 id이다. DNS는 보통 UDP로 통신하기 때문에 순서가 보장되지 않는다. 랜덤한 쿼리 id를 질의자가 넣어 보내면 응답자(dns server)에서 해당 id를 담아 보내 매칭한다.
쿼리 ID는 DNS를 외부 공격자가 마치 악성 서버가 공식 서버인 것 처럼 위장하는 dns 응답 패킷을 무차별적으로 살포하는 DNS Poisning 공격 방어에도 유용하다. 운영체제가 쿼리 id가 맞지 않는 응답은 제거하기 때문이다.
DNS record
각 DNS 서버는 저장중인(캐시중인) record에 따라 사용자에게 응답을 해준다. 즉 Public DNS서버가 캐싱하는 정보란, 바로 이 레코드인 것이다.
A, AAAA 레코드 : 도메인네임에 대응되는 IP주소, AAAA는 ipv6
CNAME 레코드 : 다른 도메인네임으로 중계하는 레코드
TXT 레코드 : 범용 레코드로, 문자열을 반환한다. 반환된 문자열에대한 해석은 요청하는 쪽에서 알아서. 보통 토큰 인증 같은데 많이 쓴다.
MX 레코드 : 메일서버
NS 레코드 : 해당 도메인네임을 어느 Authoritative 서버에서 관리하는지 알려준다. 보통 resolver 끼리의 통신에서 사용된다.
Glue
Glue는 dns응답에 도메인네임과 그 도메인네임의 ip를 붙여서 보내주는 것을 말한다.
예를들어 Dns resolver가 minseok.page을 캐싱하려
.page tld dns server에 minseok.page NS 쿼리를 보냈다고 가정하자. 레코드 응답은 이런식으로 온다.minseok.page NS mario.cloudflare.com
이는 minseok.page 에 대한 정보는 mario.cloudflare.com에 들어가서 찾으라는 얘기다.
근데 dns resolver가 mario.cloudflare.com의 ip 주소를 모른다고 가정하자. 그러면 이번에는
.com을 관장하는 TLD dns server쪽에 쿼리를 해야한다. cloudflare.com NS mario.cloudflare.com
그럼 이런 쿼리를 날릴텐데 뭔가 모순이다. 애초에 mario.cloudflare.com을 몰라서 쿼리를 날린건데, 다시 cloudflare는 mario.cloudflare.com에서 찾으라고 응답하는 것이다. 무한루프에 빠지는 것이다.
이걸 막기위해, TLD DNS server 에서는 질의자가 요청하는 도메인 네임과 NS dns 서버의 도메인이 같다면, glue record라는 것을 붙여서 응답한다.
를 응답할 때 아래 내용을 덧붙인다. 즉 무한루프를 막기 위해서이다.
;; Additional Section ns1.example.com. A 192.0.2.1 ns2.example.com. A 192.0.2.2
DNSSEC
이 부분은 추후 작성
일반 사이트도 DNSSEC를 사용할 수 있지만, 아직까지는 사용하는 사례가 많지 않음. 근본적으로는 HTTPS 로도 대부분의 공격을 사전차단할 수 있기 때문으로 보인다.
DNSSEC을 사용하지 않는 상황에서 DNS resolver가 오염되는 시나리오
- DNS resolver가 오염당함 (sample.com)
- 가짜 ip 주소가 DNS resolver에 배포
- 유저가 sample.com으로 DNS resolver에 접근
- DNS resolver에서 sample.com에 대한 가짜 ip 주소 제공
- HTTPS TLS 인증 실시
- CA에서 서명한 sample.com에 대한 인증서가 응답이 안옴
- 브라우저 NET::ERR_CERT_AUTHORITY_INVALID 에러
어차피 브라우저에서 https 인증이 되지 않으면 오류를 내기 때문에 큰 의미는 없다.
다만 DNSSEC을 이용하면 DNS resolver의 오염 자체를 막을 수 있다. 문제는 DNS resolver에게는 오버헤드가 있다는 것. 그래서 일반 홈페이지 도메인 네임에는 적용을 잘 하지 않고, Authrotative DNS 서버들이 보통 사용한다.
DNS 프로토콜 실습
DNS가 어떻게 쿼리되는지 실험해보고 싶다면, dig 명령어로 가능하다.
dig설치
Debian /Ubuntu
sudo apt install bind9-dnsutils Windows powershell
winget install ISC.BIND- google.com DNS 쿼리하기
dig google.com @8.8.8.8
- 결과
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38340 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 300 IN A 142.250.207.110 ;; Query time: 40 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP) ;; WHEN: Sun Dec 28 14:28:26 KST 2025 ;; MSG SIZE rcvd: 55
- 결과 분석
;; QUESTION SECTION:
;google.com. IN A google.com에 대한 A 레코드를 질문함.
;; ANSWER SECTION:
google.com. 300 IN A 142.250.207.110그 결과는 142.250.207.110
;; Query time: 40 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP) 40ms가 결렸고, 쿼리한 DNS resolver는 8.8.8.8
- minseok.page DNS tracing하며 쿼리하기 (DNS resolver를 흉내면서 동작한다.)
dig +trace +nodnssec minseok.page
+trace : 직접 DNS resolver 처럼 DNS의 IP를 재귀적으로 DNS 서버들에 쿼리하며 알아내는 옵션
+nodnssec : dnssec 사용 안함 (실제로는 대부분의 DNS resolver에서 DNSSEC을 사용하지만, 공부하는 입장에서 DNSSEC 에서 검증하는 과정이 지저분하기에 없이 보는게 좋음)
- 결과
PS C:\Users\user> dig +trace +nodnssec minseok.page ; <<>> DiG 9.17.12 <<>> +trace +nodnssec minseok.page ;; global options: +cmd . 518317 IN NS a.root-servers.net. . 518317 IN NS b.root-servers.net. . 518317 IN NS c.root-servers.net. . 518317 IN NS d.root-servers.net. . 518317 IN NS e.root-servers.net. . 518317 IN NS f.root-servers.net. . 518317 IN NS g.root-servers.net. . 518317 IN NS h.root-servers.net. . 518317 IN NS i.root-servers.net. . 518317 IN NS j.root-servers.net. . 518317 IN NS k.root-servers.net. . 518317 IN NS l.root-servers.net. . 518317 IN NS m.root-servers.net. ;; Received 239 bytes from 1.1.1.1#53(1.1.1.1) in 3 ms page. 172800 IN NS ns-tld3.charlestonroadregistry.com. page. 172800 IN NS ns-tld5.charlestonroadregistry.com. page. 172800 IN NS ns-tld2.charlestonroadregistry.com. page. 172800 IN NS ns-tld1.charlestonroadregistry.com. page. 172800 IN NS ns-tld4.charlestonroadregistry.com. ;; Received 425 bytes from 192.5.5.241#53(f.root-servers.net) in 2 ms minseok.page. 10800 IN NS wren.ns.cloudflare.com. minseok.page. 10800 IN NS mario.ns.cloudflare.com. ;; Received 130 bytes from 216.239.38.105#53(ns-tld4.charlestonroadregistry.com) in 38 ms minseok.page. 600 IN A 216.198.79.1 ;; Received 57 bytes from 108.162.193.203#53(mario.ns.cloudflare.com) in 3 ms
- 결과 분석
. 518317 IN NS a.root-servers.net. . 518317 IN NS b.root-servers.net. . 518317 IN NS c.root-servers.net. . 518317 IN NS d.root-servers.net. . 518317 IN NS e.root-servers.net. . 518317 IN NS f.root-servers.net. . 518317 IN NS g.root-servers.net. . 518317 IN NS h.root-servers.net. . 518317 IN NS i.root-servers.net. . 518317 IN NS j.root-servers.net. . 518317 IN NS k.root-servers.net. . 518317 IN NS l.root-servers.net. . 518317 IN NS m.root-servers.net. ;; Received 239 bytes from 1.1.1.1#53(1.1.1.1) in 3 ms
dig는 먼저
1.1.1.1 resolver에게 root zone DNS 서버들의 주소가 뭔지 쿼리한다.. IN NS 쿼리를 보냈을 것으로 추정page. 172800 IN NS ns-tld3.charlestonroadregistry.com. page. 172800 IN NS ns-tld5.charlestonroadregistry.com. page. 172800 IN NS ns-tld2.charlestonroadregistry.com. page. 172800 IN NS ns-tld1.charlestonroadregistry.com. page. 172800 IN NS ns-tld4.charlestonroadregistry.com. ;; Received 425 bytes from 192.5.5.241#53(f.root-servers.net) in 2 ms
그 다음에는 13개 root zone DNS server들 중,
f.root-servers.net 에게 .page 를 관장하는 TLD DNS server가 누구냐고 쿼리하는 모습이 보인다.page. IN NS 쿼리를 보냈을 것으로 추정총 5개의 TLD DNS server 도메인 네임을 응답함
minseok.page. 10800 IN NS wren.ns.cloudflare.com. minseok.page. 10800 IN NS mario.ns.cloudflare.com. ;; Received 130 bytes from 216.239.38.105#53(ns-tld4.charlestonroadregistry.com) in 38 ms
5개의 서버 중
ns-tld4.charlestonroadregistry.com 에게 minseok.page 를 관장하는 Authoritative DNS server가 누구냐고 쿼리하는 모습이 보인다.minseok.page. IN NS 쿼리를 보냈을 것으로 추정총 2개의 Cloudflare 소속 Authoritative DNS Server가 보임. (wren하고 mario인데 Cloudflare에서는 자기네 dns 서버 이름을 참 독특하게 짓는다)
이건 minseok.page의 도메인네임이 CloudFlare에 등록되었다는 뜻이다.
minseok.page. 600 IN A 216.198.79.1 ;; Received 57 bytes from 108.162.193.203#53(mario.ns.cloudflare.com) in 3 ms
최종적으로
mario.ns.cloudflare.com 에 질의한 후, minsoek.page 의 IP주소가 나타납니다. (저 주소는 이 블로그를 배포하는 Vercel 쪽 IP이다. Vercel에서는 http 헤더의 minseok.page 를 보고 실제 응답을 바꿔준다. )한 도메인을 여러 서버로 나누는 법
도메인 하나의 A레코드는 단 한개의 IP주소로 매칭된다. 그렇다면, youtube.com 같이 어마어마하게 큰 서비스는 단 한개의 IP 주소로 때우기는 힘들것이다. 이 문제를 어떻게 해결 하는가?
- AnyCast 기법
사실 한 IP 주소라도, Anycast 형식으로 ip를 공유하는 서버를 여러개 구축하면 서버를 분산시킬 수 있다. Anycast 기법에 따라 네트워크에서 가장 빠른 엣지 서버가 응답한다. 자세한 것은 Anycast 글 확인.
- DNS resolver 마다 다른 IP 주소 매칭
실제로
dig youtube.com @1.1.1.1 과 dig youtube.com @kns.kornet.net 를 쳐보면, 서버에 따라 같은 youtube.com이라도 다른 IP 주소를 응답한다. 왜 이런 현상이 가능한지 추측해봤는데, 아마 다음단계때문이 아닐까 싶다. - 각 DNS resolver는 레코드를 캐싱할 때 Authoritative dns 서버의 ip로 쿼리한다.
- Authoritative dns 서버의 ip조차도 Anycast로 구성되어있어, 각 dns마다 서로 다른 ip를 반환한다.
그니까, dns resolver가 캐싱하는 google의 Authoritative DNS 서버가 Anycast 라우팅 되어있고, 심지어 그렇게 받아온 ip 조차도 Anycast 라우팅 되어있는 게 아닐까 추측
여러 도메인이 한 ip 주소를 공유하는 법
한 Ip 주소를 여러 도메인이 공유하기도 한다. 그니까 예를 들면 a.com이랑 b.com이 같은 ip주소를 가리킬 수도 있다. 근데 a.com이랑 b.com이 같은 ip주소인데 어떻게 다른 응답을 해줄 수 있을까? 이건 사실 DNS쪽에서 뭘 따로 해주는 건 아니고, 서버가 요청자의 https 쿼리 헤더에 달린 도메인을 보고 다른 응답을 생성 해주는 것이다.
예를들면 github에서 운영하는 github pages로 호스팅하는 고객들의 웹페이지들은 모두 같은 ip주소를 가지고 있다. 이를 github쪽 서버가 사용자 https 쿼리의 헤더를 보고 도메인에 따라 서로 다른 웹사이트를 응답하는 것이다.
여담인데, 이는 isp에서 dns가 응답하는 ip주소만 보고 qos를 적용하기 힘든 이유기도 하다. 왜냐면 a.com에 대한 qos를 걸기 위해 a.com과 매칭되는 ip주소를 다 qos걸어버린다면, 해당 ip주소를 공유하는 여러 다른 도메인들이 함께 qos가 걸려버린다. 그래서 qos를 걸 때는 보통 dpi 기법, 즉 http 헤더를 뜯어보는것이다.