DNS 깊이 보기 — 무료화가 부른 이름 해석의 세계

• 들어가며 — 왜 지금 다시 DNS인가
• DNS의 기본 구조 — 계층적 위임 시스템
  • 재귀 서버와 권한 서버
• 이름 해석의 전 과정 — 한 번의 질의 따라가기
  • 캐시와 TTL — 빠름과 정확함의 균형
  • 여러 겹의 캐시 — 브라우저부터 재귀 서버까지
  • 스텁 리졸버 — OS 안의 작은 DNS 클라이언트
• 레코드 종류 — 이름에 담는 다양한 정보
  • dig으로 직접 확인하기
  • 역방향 DNS — IP에서 이름으로
• Anycast — 하나의 IP, 전 세계 분산
  • GeoDNS — 위치에 따라 다른 답
• DNSSEC — 답이 위조되지 않았음을 증명하기
• UDP에서 TCP로 — DNS 전송 계층의 진화
• DNS 부하 분산 — 라운드 로빈과 그 한계
• DoH와 DoT — 질의 자체를 암호화하기
• 운영 함정 — 무료화 시대에 더 조심할 것들
  • 1. TTL을 무시한 긴급 변경
  • 2. 네거티브 캐시(NXDOMAIN) 함정
  • 3. 전파(propagation)에 대한 오해
  • 4. CNAME 체인과 응답 지연
  • 5. 무료 DNS의 잠금과 가용성
  • 6. 와일드카드 레코드의 함정
  • 7. 캐시 일관성과 멀티 사업자 운영
• 비판적 시각 — 공짜의 대가
• 실무 적용 — DNS 디버깅 실전
  • 증상별 진단 표
  • 단계별 진단 절차
  • DNS 설계 체크리스트
• 마치며
• 참고 자료

들어가며 — 왜 지금 다시 DNS인가

최근 GeekNews와 Hacker News에서 DNS가 다시 화제의 중심에 올랐습니다. 한 CDN 사업자가 DNS 호스팅을 사실상 무료로 풀면서, "이름 해석이라는 인터넷의 가장 오래된 인프라가 이제 공짜가 되었다"는 논의가 활발해졌습니다. 무료화 자체보다 흥미로운 것은, 이 일을 계기로 많은 개발자들이 "그런데 DNS는 실제로 어떻게 동작하지?"라는 근본적인 질문을 다시 던지기 시작했다는 점입니다.

DNS는 인터넷에서 가장 당연하게 여겨지는 기술입니다. 브라우저에 도메인을 입력하면 알아서 IP 주소로 바뀌고, 우리는 그 과정을 거의 의식하지 않습니다. 하지만 그 "알아서"의 내부에는 재귀 질의, 권한 서버 위임, 캐시 계층, TTL 만료, Anycast 라우팅, 그리고 보안 확장까지 놀라울 만큼 정교한 분산 시스템이 숨어 있습니다.

이 글에서는 도메인 하나가 IP 주소로 해석되기까지의 전 과정을 따라가면서, 레코드 종류와 Anycast, GeoDNS, DNSSEC, DoH/DoT까지 깊이 있게 살펴보겠습니다. 그리고 무료 DNS가 보편화된 2026년에 우리가 실제로 마주치는 운영 함정도 함께 정리합니다.

DNS를 제대로 이해하면 단순히 "도메인이 안 열린다"는 막연한 불안에서 벗어나, 문제의 정확한 위치를 짚어낼 수 있게 됩니다. 캐시 문제인지, 위임 문제인지, 전송 계층 문제인지를 구분하는 능력은 인프라를 다루는 모든 사람에게 든든한 무기가 됩니다.

DNS의 기본 구조 — 계층적 위임 시스템

DNS는 전 세계에 분산된 거대한 트리 구조의 데이터베이스입니다. 가장 위에는 루트(root)가 있고, 그 아래로 최상위 도메인(TLD), 그 아래로 우리가 등록하는 도메인이 위치합니다.

                    . (루트)
                    |
       +------------+------------+
       |            |            |
      com          org           kr
       |            |            |
   example       wikipedia     co.kr
       |
   www.example.com

이 계층 구조의 핵심은 "위임(delegation)"입니다. 루트 서버는 모든 도메인을 알지 못합니다. 단지 "com 도메인은 저쪽 서버들에게 물어보라"고 안내할 뿐입니다. com을 관리하는 서버 역시 example.com의 구체적인 레코드를 직접 알지 못하고, "example.com은 이 권한 서버에게 물어보라"고 위임합니다.

이런 위임 구조 덕분에 DNS는 중앙 집중 없이도 전 세계 규모로 확장됩니다. 누구도 전체를 알 필요가 없고, 각자 자기 영역만 책임지면 됩니다.

이 설계는 1980년대 초에 등장했습니다. 그 전에는 모든 컴퓨터의 이름과 주소를 hosts.txt라는 단일 파일에 모아 두고 각 기관이 내려받았습니다. 인터넷이 커지면서 이 방식은 곧 한계에 부딪혔습니다. 파일은 비대해졌고, 갱신은 느렸으며, 단일 파일을 관리하는 곳에 부하가 집중됐습니다. DNS는 바로 이 "중앙 집중 파일"의 문제를 "분산된 위임 트리"로 대체하기 위해 태어났습니다. 40년이 지난 지금도 이 기본 설계가 거의 그대로 작동하고 있다는 사실은, 좋은 분산 시스템 설계의 위력을 잘 보여줍니다.

재귀 서버와 권한 서버

DNS에는 역할이 다른 두 종류의 서버가 있습니다.

• 권한 서버(Authoritative Server): 특정 도메인의 실제 레코드를 보유한 서버입니다. example.com의 A 레코드가 무엇인지에 대한 "최종 답"을 가진 주체입니다.
• 재귀 서버(Recursive Resolver): 클라이언트를 대신해 루트부터 권한 서버까지 차례로 물어보며 답을 찾아주는 서버입니다. 통신사 DNS나 8.8.8.8, 1.1.1.1 같은 공개 리졸버가 여기에 해당합니다.

우리가 도메인을 입력하면 실제로는 재귀 서버에게 "이 이름의 답을 찾아줘"라고 부탁하는 것이고, 재귀 서버가 모든 수고를 대신합니다.

이 둘의 구분은 실무에서 매우 중요합니다. 문제를 진단할 때 "재귀 서버가 잘못 캐시한 것인지", 아니면 "권한 서버의 레코드 자체가 잘못된 것인지"를 가려내는 것이 첫걸음이기 때문입니다. 권한 서버에 직접 질의하면 캐시를 건너뛰고 진짜 답을 볼 수 있고, 평소처럼 재귀 서버에 질의하면 캐시된 답을 봅니다. 이 둘을 비교하는 것만으로도 많은 DNS 문제의 원인이 드러납니다.

이름 해석의 전 과정 — 한 번의 질의 따라가기

www.example.com을 처음 방문할 때, 재귀 서버 입장에서 어떤 일이 벌어지는지 단계별로 따라가 보겠습니다.

클라이언트  →  재귀 서버:  www.example.com 의 A 레코드 줘
재귀 서버  →  루트 서버:  www.example.com 알아?
루트 서버  →  재귀 서버:  com 은 저 TLD 서버들에게 물어봐 (위임)
재귀 서버  →  TLD 서버:   www.example.com 알아?
TLD 서버   →  재귀 서버:  example.com 은 이 권한 서버에게 물어봐 (위임)
재귀 서버  →  권한 서버:  www.example.com 알아?
권한 서버  →  재귀 서버:  A 레코드 = 93.184.216.34
재귀 서버  →  클라이언트:  93.184.216.34 (그리고 캐시에 저장)

처음에는 이렇게 여러 번 왕복하지만, 재귀 서버는 한 번 받은 답을 캐시에 저장합니다. 그래서 같은 도메인에 대한 이후 질의는 거의 즉시 응답됩니다. 이 캐시 계층이 DNS 전체의 부하를 극적으로 낮추는 핵심입니다.

흥미로운 점은 재귀 서버가 최종 답만 캐시하는 게 아니라는 것입니다. 위임 정보(어느 TLD 서버, 어느 권한 서버가 담당하는지)도 함께 캐시합니다. 그래서 example.com을 한 번 조회한 뒤에는, 같은 도메인의 다른 서브도메인(api.example.com 등)을 조회할 때 루트와 TLD를 다시 거치지 않고 곧장 권한 서버로 갈 수 있습니다. 이 중간 캐시 덕분에 두 번째 질의부터는 첫 질의보다 훨씬 빠릅니다.

캐시와 TTL — 빠름과 정확함의 균형

각 레코드에는 TTL(Time To Live)이라는 값이 붙습니다. 이는 "이 답을 몇 초 동안 캐시해도 좋다"는 유효 기간입니다.

example.com.   300   IN   A   93.184.216.34
               ^^^
               TTL = 300초(5분) 동안 캐시 가능

TTL은 트레이드오프의 산물입니다.

• 긴 TTL: 캐시 적중률이 높아 빠르고 권한 서버 부하가 적습니다. 하지만 레코드를 바꿨을 때 변경이 전파되는 데 오래 걸립니다.
• 짧은 TTL: 변경이 빠르게 반영되지만, 캐시 효과가 줄어 질의가 잦아지고 응답이 느려질 수 있습니다.

서비스 이전을 앞두고 TTL을 미리 낮춰두는 것은 DNS 운영의 기본 상식입니다. 변경 직전에 TTL을 60초로 줄여두면, 실제 전환 시 빠르게 새 주소로 옮겨갈 수 있습니다.

여러 겹의 캐시 — 브라우저부터 재귀 서버까지

흔히 "DNS 캐시"라고 하면 재귀 서버의 캐시만 떠올리지만, 실제로는 여러 계층에 캐시가 존재합니다. 하나의 도메인 해석 요청은 다음과 같은 캐시 계단을 거칩니다.

브라우저 캐시   ->  OS(스텁 리졸버) 캐시  ->  재귀 서버 캐시  ->  권한 서버
   (수십 초)         (운영체제 설정)          (TTL 기반)        (최종 답)

각 계층은 자체적으로 답을 캐시합니다. 그래서 권한 서버의 레코드를 바꿔도, 브라우저나 OS 수준에서 옛 값을 들고 있으면 변경이 즉시 보이지 않습니다. 개발 중에 "분명히 바꿨는데 왜 안 바뀌지?"라고 당황하는 일의 상당수가 이 다층 캐시 때문입니다.

이럴 때는 각 계층을 차례로 비워야 합니다.

# OS 수준 DNS 캐시 비우기 (운영체제마다 다름)
# macOS 예시
sudo dscacheutil -flushcache

# 브라우저는 자체 캐시를 따로 가지므로 별도로 비워야 함
# (브라우저 설정의 네트워크/보안 항목에서 처리)

이 다층 구조를 이해하면, "전파가 안 된다"는 막연한 불평 대신 "어느 계층의 캐시가 문제인지"를 정확히 짚어낼 수 있습니다. 그리고 그것이 곧 빠른 문제 해결로 이어집니다.

스텁 리졸버 — OS 안의 작은 DNS 클라이언트

운영체제에는 스텁 리졸버(stub resolver)라는 작은 DNS 클라이언트가 들어 있습니다. 애플리케이션이 어떤 이름을 해석해 달라고 하면, 스텁 리졸버가 그 요청을 받아 설정된 재귀 서버로 보냅니다. 즉 우리가 직접 재귀 서버와 통신하는 것이 아니라, OS의 스텁 리졸버가 중개자 역할을 합니다.

스텁 리졸버는 보통 캐시도 갖고 있고, hosts 파일 같은 로컬 설정도 먼저 확인합니다. 그래서 hosts 파일에 항목을 추가하면 DNS 질의 없이도 이름을 해석할 수 있습니다. 로컬 개발 환경에서 도메인을 가짜로 매핑할 때 흔히 쓰는 기법입니다.

레코드 종류 — 이름에 담는 다양한 정보

DNS는 단순히 이름을 IP로 바꾸는 것 이상을 합니다. 레코드 타입에 따라 다양한 정보를 담습니다.

CNAME에는 한 가지 함정이 있습니다. 루트 도메인(example.com 자체)에는 CNAME을 둘 수 없습니다. 루트에는 반드시 SOA와 NS 레코드가 있어야 하는데, CNAME은 같은 이름에 다른 레코드가 공존하는 것을 허용하지 않기 때문입니다. 많은 DNS 사업자가 이 문제를 ALIAS 또는 ANAME이라는 비표준 레코드로 우회합니다.

dig으로 직접 확인하기

레코드를 직접 조회할 때는 dig 명령이 가장 유용합니다.

# A 레코드 조회
dig example.com A

# 특정 권한 서버에 직접 질의 (캐시 우회)
dig @ns1.example.com example.com A

# 위임 경로를 단계별로 추적
dig +trace example.com

# 응답 시간만 빠르게 확인
dig example.com +stats | grep "Query time"

dig +trace는 재귀 서버를 거치지 않고 루트부터 직접 따라가므로, 위임이 어디서 끊어졌는지 진단할 때 특히 유용합니다.

역방향 DNS — IP에서 이름으로

지금까지는 이름에서 IP를 찾는 정방향 해석만 다뤘지만, 그 반대도 가능합니다. IP 주소로 이름을 찾는 것을 역방향 DNS(reverse DNS)라 하고, PTR 레코드를 사용합니다. 역방향 조회는 특별한 영역인 in-addr.arpa(IPv4)와 ip6.arpa(IPv6) 아래에서 이루어집니다.

# IP 주소로 이름 찾기 (PTR 조회)
dig -x 93.184.216.34

역방향 DNS는 일상적인 웹 브라우징에는 거의 쓰이지 않지만, 특정 영역에서는 매우 중요합니다. 대표적인 것이 메일 서버입니다. 많은 메일 서버가 보내는 쪽 IP의 PTR 레코드가 제대로 설정되어 있는지를 스팸 판별의 한 기준으로 삼습니다. 정방향과 역방향이 일치하는지(forward-confirmed reverse DNS) 검사하는 것입니다. 그래서 자체 메일 서버를 운영한다면 PTR 설정은 선택이 아니라 필수입니다.

역방향 DNS는 또한 네트워크 진단과 로그 분석에서도 유용합니다. 접속 로그에 남은 IP를 사람이 읽을 수 있는 이름으로 바꿔 어떤 조직에서 온 트래픽인지 가늠하는 데 도움이 됩니다.

Anycast — 하나의 IP, 전 세계 분산

DNS의 안정성과 속도를 떠받치는 핵심 기술이 Anycast입니다. 보통 하나의 IP 주소는 하나의 서버를 가리키지만(Unicast), Anycast에서는 같은 IP를 전 세계 수십, 수백 곳의 서버가 동시에 광고합니다.

           1.1.1.1 (같은 IP를 전 세계가 광고)

  서울 사용자 ----+
                 |  BGP가 가장 가까운 곳으로 라우팅
  서울 노드 <-----+

  런던 사용자 ----+
                 |
  런던 노드 <-----+

  (사용자는 자신과 네트워크적으로 가장 가까운 노드에 도달)

이것이 가능한 이유는 라우팅 프로토콜인 BGP 때문입니다. 같은 IP가 여러 위치에서 광고되면, 각 네트워크는 자신에게 가장 가까운 경로를 선택합니다. 결과적으로 서울 사용자는 서울 노드에, 런던 사용자는 런던 노드에 도달합니다.

Anycast가 주는 이점은 분명합니다.

• 지연 감소: 사용자가 항상 가까운 노드에 연결됩니다.
• 부하 분산: 트래픽이 자연스럽게 여러 노드로 흩어집니다.
• 장애 격리: 한 노드가 죽으면 BGP가 자동으로 다른 노드로 경로를 재계산합니다.
• DDoS 흡수: 공격 트래픽이 한곳에 집중되지 않고 전 세계로 분산됩니다.

8.8.8.8이나 1.1.1.1 같은 공개 DNS가 어디서든 빠르게 응답하는 비결이 바로 이 Anycast입니다.

물론 Anycast에도 미묘한 함정이 있습니다. UDP처럼 상태가 없는 프로토콜에는 이상적이지만, TCP처럼 연결 상태를 유지해야 하는 프로토콜에서는 경로가 도중에 바뀌면 연결이 다른 노드로 향해 끊길 수 있습니다. DNS가 주로 짧은 UDP 질의를 쓰기 때문에 이 문제가 크게 부각되지 않을 뿐입니다. 또한 어떤 사용자가 "가장 가까운" 노드에 도달하는지는 순전히 BGP 라우팅 정책에 달려 있어, 지리적으로 가까운 노드가 항상 네트워크적으로 가까운 것은 아니라는 점도 기억해 둘 만합니다.

GeoDNS — 위치에 따라 다른 답

Anycast가 "같은 답을 가장 가까운 곳에서 준다"면, GeoDNS는 "위치에 따라 다른 답을 준다"는 점에서 다릅니다. 권한 서버가 질의를 보낸 재귀 서버의 위치(또는 EDNS Client Subnet 정보)를 보고, 지역마다 다른 IP를 응답하는 방식입니다.

아시아 사용자 질의  ->  권한 서버  ->  A = 아시아 리전 IP
유럽 사용자 질의    ->  권한 서버  ->  A = 유럽 리전 IP

이 기법은 CDN과 글로벌 서비스가 사용자를 가까운 데이터센터로 보내는 데 널리 쓰입니다. 다만 재귀 서버의 위치와 실제 사용자의 위치가 다를 수 있다는 한계가 있어, EDNS Client Subnet이라는 확장으로 사용자의 대략적인 위치를 권한 서버에 전달하기도 합니다.

여기서 Anycast와 GeoDNS의 관계를 짚어둘 만합니다. 둘은 경쟁 기술이 아니라 보완 기술입니다. Anycast는 DNS 질의 자체를 가까운 권한 서버로 보내 응답을 빠르게 하고, GeoDNS는 그 응답의 내용(어느 데이터센터로 갈지)을 위치에 맞게 고릅니다. 즉 "어디서 답하느냐"는 Anycast가, "무엇을 답하느냐"는 GeoDNS가 책임지는 셈입니다. 현대의 대형 CDN은 이 둘을 결합해, 사용자가 가까운 DNS 노드에서 가까운 콘텐츠 서버의 주소를 빠르게 받도록 설계합니다.

GeoDNS에도 함정은 있습니다. 사용자가 자신의 위치와 멀리 떨어진 공개 리졸버를 쓰면(예: 해외 VPN을 거치거나 특정 공개 DNS를 지정한 경우), 권한 서버는 그 리졸버의 위치를 기준으로 엉뚱한 리전의 답을 줄 수 있습니다. EDNS Client Subnet이 이 문제를 일부 완화하지만, 프라이버시 우려로 이 확장을 보내지 않는 리졸버도 있어 완전한 해결책은 아닙니다.

DNSSEC — 답이 위조되지 않았음을 증명하기

기본 DNS에는 치명적인 약점이 있습니다. 응답에 서명이 없어, 중간에서 답을 위조해도 클라이언트가 알아챌 방법이 없다는 것입니다. 이를 노린 것이 캐시 포이즈닝 같은 공격입니다.

DNSSEC는 각 레코드에 디지털 서명을 붙여 이 문제를 해결합니다. 권한 서버는 레코드에 RRSIG(서명)를 함께 제공하고, 상위 영역은 하위 영역의 공개키 해시를 DS 레코드로 보증합니다. 이렇게 루트부터 권한 서버까지 신뢰의 사슬(chain of trust)이 형성됩니다.

루트 (신뢰의 출발점)
  | DS 레코드로 com 의 키를 보증
com
  | DS 레코드로 example.com 의 키를 보증
example.com
  | RRSIG 로 각 레코드에 서명
실제 레코드 (위조 불가능)

DNSSEC는 응답의 무결성과 출처를 보장하지만, 내용을 암호화하지는 않습니다. 즉 누군가 위조한 답을 주는 것은 막지만, 내가 어떤 도메인을 조회하는지는 여전히 노출됩니다. 이 프라이버시 문제를 해결하는 것이 다음에 볼 DoH/DoT입니다.

DNSSEC의 도입은 생각보다 까다롭습니다. 키를 주기적으로 교체(rollover)해야 하고, 상위 영역에 DS 레코드를 정확히 등록해야 하며, 서명이 만료되기 전에 갱신해야 합니다. 이 운영 부담 때문에 DNSSEC 도입률은 기대만큼 높지 않습니다. 서명 만료를 깜빡해 도메인 전체가 해석 불가능해지는 사고도 드물지 않게 보고됩니다. 보안과 운영 복잡성 사이의 트레이드오프를 잘 보여주는 사례입니다.

UDP에서 TCP로 — DNS 전송 계층의 진화

전통적으로 DNS는 UDP 53번 포트를 씁니다. 질의와 응답이 보통 한 패킷에 들어갈 만큼 작기 때문에, 연결 설정 비용이 없는 UDP가 효율적이었습니다. 하지만 응답이 커지면 이야기가 달라집니다.

작은 응답 (A 레코드 하나):   UDP 한 패킷으로 충분
큰 응답 (DNSSEC 서명 포함):  UDP 한 패킷을 넘김 -> 잘림(TC 비트) -> TCP 재시도

응답이 UDP 패킷 크기 한계를 넘으면, 서버는 "잘렸다(truncated)"는 표시(TC 비트)를 보냅니다. 그러면 클라이언트는 같은 질의를 TCP로 다시 보냅니다. DNSSEC 서명이나 큰 TXT 레코드처럼 응답이 커지는 경우 이 TCP 폴백이 자주 일어납니다.

이 한계를 완화하기 위해 EDNS(Extension Mechanisms for DNS)가 도입되었습니다. EDNS는 클라이언트가 "나는 더 큰 UDP 응답을 받을 수 있다"고 알려, 불필요한 TCP 폴백을 줄입니다. 또한 앞서 본 EDNS Client Subnet 같은 확장 옵션을 실어 나르는 통로 역할도 합니다.

# EDNS 버퍼 크기를 명시해 질의 (큰 응답 처리)
dig example.com A +bufsize=4096

# DNSSEC 관련 레코드까지 함께 요청
dig example.com A +dnssec

실무에서 중요한 점은, 방화벽이 DNS의 TCP 53번이나 큰 UDP 패킷을 막아 두면 DNSSEC가 동작하지 않을 수 있다는 것입니다. "A 레코드는 되는데 DNSSEC 검증만 실패한다"면 전송 계층의 패킷 크기 문제를 의심해 볼 만합니다.

DNS 부하 분산 — 라운드 로빈과 그 한계

DNS는 단순한 부하 분산 도구로도 오래 쓰여 왔습니다. 한 이름에 여러 A 레코드를 등록해 두면, 권한 서버는 질의마다 순서를 바꿔 응답하는 라운드 로빈(round-robin)을 수행합니다.

example.com.  60  IN  A  192.0.2.10
example.com.  60  IN  A  192.0.2.11
example.com.  60  IN  A  192.0.2.12

질의 1 -> 10, 11, 12 순서로 응답
질의 2 -> 11, 12, 10 순서로 응답 (순환)

이 방식은 설정이 간단하다는 장점이 있지만, 한계도 분명합니다. DNS는 각 서버의 실제 건강 상태를 모릅니다. 한 서버가 죽어도 그 IP를 계속 응답에 포함시킬 수 있고, 클라이언트와 재귀 서버가 응답을 캐시하므로 분산이 고르지 않습니다. 그래서 진지한 부하 분산은 보통 DNS가 아니라 별도의 로드 밸런서 계층에서 처리하고, DNS는 가까운 리전이나 진입점으로 보내는 역할까지만 맡깁니다.

여기서 GeoDNS와 헬스 체크를 결합한 현대적 DNS 서비스가 등장합니다. 이들은 각 엔드포인트의 건강 상태를 주기적으로 점검하고, 죽은 엔드포인트를 응답에서 자동으로 빼며, 사용자의 위치에 따라 가장 가까운 건강한 엔드포인트를 돌려줍니다. 단순한 라운드 로빈을 넘어선, 지능적인 트래픽 유도의 영역입니다.

DoH와 DoT — 질의 자체를 암호화하기

전통적인 DNS는 평문 UDP로 오갑니다. 같은 네트워크에 있는 누군가는 내가 어떤 사이트를 방문하는지 그대로 엿볼 수 있습니다. 이를 막기 위해 등장한 것이 암호화된 DNS입니다.

• DoT (DNS over TLS): 전용 포트(853)에서 TLS로 DNS 트래픽을 암호화합니다. DNS 트래픽임이 포트로 드러나므로 관리자가 식별하고 정책을 적용하기 쉽습니다.
• DoH (DNS over HTTPS): 일반 HTTPS(443) 위에 DNS 질의를 실어 보냅니다. 일반 웹 트래픽과 구분이 어려워 검열 우회에 유리하지만, 같은 이유로 기업 망 관리자에게는 통제가 어려운 골칫거리이기도 합니다.

# DoH로 질의 보내기 (Cloudflare 예시)
curl -H "accept: application/dns-json" \
  "https://cloudflare-dns.com/dns-query?name=example.com&type=A"

DoH의 등장은 단순한 기술 변화가 아니라 통제권의 이동이기도 합니다. 과거 DNS는 네트워크 관리자가 손쉽게 관찰하고 차단할 수 있는 지점이었지만, DoH는 그 통제권을 애플리케이션(특히 브라우저)으로 옮겨 놓았습니다. 이 때문에 보안과 프라이버시, 그리고 망 관리 사이의 긴장이 여전히 진행 중입니다.

실무에서 DoH/DoT를 도입할 때는 한 가지 균형을 고민해야 합니다. 프라이버시는 분명한 이득이지만, 사내 DNS 기반 정책(특정 도메인 차단, 내부 전용 이름 해석 등)이 우회될 수 있습니다. 그래서 많은 조직이 신뢰하는 사내 리졸버로만 암호화된 DNS를 보내도록 설정해, 프라이버시와 통제를 함께 확보하려 합니다. 암호화 자체가 목적이 아니라, "누구를 신뢰하느냐"를 명확히 하는 것이 핵심입니다.

운영 함정 — 무료화 시대에 더 조심할 것들

DNS 호스팅이 무료가 되면서 진입 장벽은 낮아졌지만, 운영의 함정은 오히려 더 자주 마주치게 됩니다. 실무에서 반복되는 대표적인 사례를 정리합니다.

1. TTL을 무시한 긴급 변경

장애 대응으로 레코드를 급히 바꿨는데, 기존 TTL이 24시간이라 전 세계 캐시가 좀처럼 갱신되지 않는 상황은 흔합니다. 평소에 핵심 레코드의 TTL을 적정 수준(예: 300초)으로 유지하면 긴급 상황에서 운신의 폭이 넓어집니다.

2. 네거티브 캐시(NXDOMAIN) 함정

존재하지 않는 도메인을 조회하면 "없음(NXDOMAIN)"이라는 답도 캐시됩니다. 이 음성 캐시의 기간은 SOA 레코드의 마지막 필드가 결정합니다. 새 서브도메인을 만들었는데 한참 동안 안 보이는 경우, 음성 캐시가 원인일 때가 많습니다.

3. 전파(propagation)에 대한 오해

"DNS가 전 세계로 전파된다"는 표현은 사실 부정확합니다. 권한 서버의 레코드는 바꾸는 즉시 갱신되지만, 각 재귀 서버는 자신이 캐시한 답의 TTL이 끝나야 새 값을 가져옵니다. 따라서 "전파 지연"의 정체는 대부분 캐시 만료를 기다리는 시간입니다.

4. CNAME 체인과 응답 지연

CNAME이 또 다른 CNAME을 가리키는 긴 체인은 재귀 서버가 여러 번 질의하게 만들어 첫 응답을 느리게 합니다. 가능하면 체인을 짧게 유지하는 것이 좋습니다.

5. 무료 DNS의 잠금과 가용성

무료 서비스라도 그것에 전적으로 의존하면, 그 사업자의 장애가 곧 우리 서비스의 장애가 됩니다. 중요한 서비스라면 권한 서버를 둘 이상의 사업자에 분산(secondary DNS)하는 것을 고려할 만합니다. 무료화로 비용 부담이 줄어든 만큼, 오히려 이중화를 적용하기 더 쉬워졌다고 볼 수도 있습니다.

6. 와일드카드 레코드의 함정

와일드카드 레코드(별표로 시작하는 레코드)는 정의되지 않은 모든 서브도메인에 같은 답을 줍니다. 편리하지만 위험합니다. 의도하지 않은 서브도메인까지 모두 응답하게 되어, 오타나 존재하지 않는 이름이 엉뚱한 서버로 향할 수 있습니다. 또한 와일드카드는 더 구체적인 레코드가 있으면 그것에 가려지는 등 우선순위 규칙이 직관과 다르게 작동하는 경우가 있어, 설정 시 동작을 정확히 확인해야 합니다.

7. 캐시 일관성과 멀티 사업자 운영

권한 서버를 여러 사업자에 분산하면 가용성은 높아지지만, 두 사업자의 레코드가 항상 일치하도록 동기화하는 일이 새로운 과제가 됩니다. 한쪽만 갱신하고 다른 쪽을 깜빡하면, 사용자마다 다른 답을 받는 혼란이 생깁니다. 이런 경우 한 곳을 단일 진실 공급원(source of truth)으로 두고 나머지를 자동으로 동기화하는 구조가 안전합니다.

비판적 시각 — 공짜의 대가

DNS 무료화는 분명 환영할 일이지만, 한 발 물러서 보면 생각할 지점도 있습니다. 무료 서비스가 늘수록 트래픽은 소수의 대형 사업자에게 집중됩니다. 인터넷의 가장 기초적인 인프라가 소수의 손에 모이는 것은, 그 자체로 중앙화의 위험을 키웁니다. 한 대형 DNS 사업자의 장애가 전 세계 수많은 서비스를 동시에 멈춰 세운 과거 사례들이 이를 잘 보여줍니다.

또한 "무료"는 종종 데이터로 지불됩니다. 누가 어떤 도메인을 얼마나 자주 조회하는지는 그 자체로 귀중한 정보입니다. 무료 DNS를 선택할 때 사업자의 데이터 정책을 확인하는 것은 그래서 중요합니다.

실무 적용 — DNS 디버깅 실전

이론을 알았으니, 실제로 문제가 생겼을 때 어떻게 진단하는지 정리해 보겠습니다. DNS 문제는 증상이 모호해서 엉뚱한 곳을 헤매기 쉽습니다. 체계적인 접근이 시간을 아껴 줍니다.

증상별 진단 표

단계별 진단 절차

가장 먼저 할 일은 "권한 서버의 진짜 답"과 "재귀 서버가 주는 답"을 분리하는 것입니다. 둘이 다르다면 캐시 문제이고, 같다면 설정 문제입니다.

# 1단계: 재귀 서버(기본 리졸버)가 주는 답
dig example.com A

# 2단계: 권한 서버에 직접 물어본 진짜 답
dig @ns1.example.com example.com A

# 3단계: 여러 공개 리졸버 비교 (전파 상태 확인)
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A

# 4단계: 위임 경로 전체 추적
dig +trace example.com

1단계와 2단계의 답이 다르다면, 재귀 서버가 옛 값을 캐시하고 있다는 뜻입니다. TTL이 끝나기를 기다리거나, 캐시를 비울 수 있다면 비웁니다. 답이 같다면 권한 서버의 레코드 자체를 점검해야 합니다.

DNS 설계 체크리스트

새 서비스의 DNS를 설계할 때 점검할 항목을 정리하면 다음과 같습니다.

1. 핵심 레코드의 TTL을 적정 수준으로: 변경 가능성이 있는 레코드는 300초 안팎으로 유지합니다.
2. 권한 서버 이중화: 가능하면 둘 이상의 사업자에 권한 서버를 분산합니다.
3. CNAME 체인 최소화: 루트 도메인에는 CNAME 대신 ALIAS/ANAME 또는 A 레코드를 씁니다.
4. 메일 보안 레코드 점검: SPF, DKIM, DMARC를 TXT 레코드로 올바로 설정합니다.
5. CAA 레코드로 인증서 발급 제한: 허용된 인증 기관만 인증서를 발급하도록 막습니다.
6. 모니터링: 외부에서 주기적으로 핵심 레코드를 조회해 가용성과 정확성을 감시합니다.

이 중에서도 권한 서버 이중화는 무료화 시대에 특히 실천하기 쉬워졌습니다. 비용 부담이 줄어든 만큼, 서로 다른 사업자에 권한 서버를 두어 단일 장애점을 없애는 설계가 현실적인 선택지가 되었습니다.

마치며

DNS는 인터넷에서 가장 오래되고 가장 당연하게 여겨지는 기술이지만, 그 내부는 재귀와 위임, 캐시와 TTL, Anycast와 GeoDNS, 그리고 DNSSEC와 암호화된 전송까지 놀라울 만큼 정교한 분산 시스템입니다. 무료화라는 표면적 사건을 계기로 그 깊은 곳을 다시 들여다보는 일은, LLM 시대에 "깊이 이해하는 것"의 가치가 재조명되는 흐름과도 맞닿아 있습니다.

도구가 공짜가 되고 추상화가 두꺼워질수록, 그 아래에서 실제로 무슨 일이 벌어지는지 아는 사람의 가치는 오히려 커집니다. 다음에 브라우저에 도메인을 입력할 때, 그 짧은 순간에 펼쳐지는 전 세계적 협력의 풍경을 한 번쯤 떠올려 보시기 바랍니다.

DNS를 깊이 이해하는 일의 보상은 분명합니다. 장애가 터졌을 때 남들이 막연히 "DNS 문제인 것 같다"고 말할 때, 여러분은 "재귀 서버의 캐시가 옛 값을 들고 있고, TTL이 두 시간 남았다"고 정확히 짚어낼 수 있습니다. 새 서비스를 설계할 때, 권한 서버 이중화와 적정 TTL, PTR과 CAA까지 빠짐없이 챙길 수 있습니다. 이런 구체적인 이해는 추상화 위에 또 추상화를 쌓는 시대에 오히려 더 희소하고 더 값진 자산이 됩니다.

무료화는 끝이 아니라 시작입니다. 진입 장벽이 낮아진 만큼, 이제 차이를 만드는 것은 도구를 쓸 수 있느냐가 아니라 도구가 하는 일을 이해하느냐입니다. 이 글이 그 이해로 가는 작은 디딤돌이 되었기를 바랍니다.

참고 자료

• RFC 1034 — Domain Names: Concepts and Facilities
• RFC 1035 — Domain Names: Implementation and Specification
• RFC 4033 — DNS Security Introduction and Requirements (DNSSEC)
• RFC 8484 — DNS Queries over HTTPS (DoH)
• RFC 7858 — DNS over Transport Layer Security (DoT)
• Cloudflare Learning — What is DNS?
• Cloudflare Learning — What is Anycast?
• Hacker News
• GeekNews