Notes

DNS Resolution Flow

DNS가 domain name을 IP address로 변환하는 구조, recursive resolver와 authoritative DNS의 차이, TTL/cache, DNS record, troubleshooting 관점을 정리한 DevOps 네트워킹 개념 노트

Published: Jun 2, 2026
Updated: Jun 2, 2026
Area: Computer Networks
Type: concept
Series: Cloud Networking
Category: Notes

dnsdomain-name-systemdns-resolutionrecursive-resolverauthoritative-dnsttldns-cachenetworkingkubernetes-dnstroubleshooting

개요

DNS(Domain Name System)는 사람이 읽기 쉬운 domain name을 실제 네트워크 통신에 필요한 IP address로 변환하는 이름 해석 시스템이다.

브라우저에 다음과 같은 주소를 입력한다고 가정한다.

www.example.com

사람은 이 이름을 보고 서비스를 인식할 수 있지만, 네트워크 장비와 서버는 최종적으로 IP address를 기준으로 packet을 전달한다.

www.example.com → 93.184.216.34

즉 DNS의 기본 역할은 다음과 같다.

Human-readable domain name
  ↓
DNS resolution
  ↓
Machine-routable IP address

DNS는 단순한 정적 전화번호부가 아니라, 전 세계에 분산된 계층형 이름 해석 시스템이다. record는 cache될 수 있고, TTL에 따라 만료되며, recursive resolver와 authoritative name server가 서로 다른 역할을 수행한다.

DNS를 전화번호부에 비유하는 이유

DNS는 흔히 인터넷의 전화번호부로 설명된다. 현실에서 사람 이름만으로는 전화를 걸 수 없고 실제 전화번호가 필요하듯, 인터넷에서도 domain name만으로는 목적지에 연결할 수 없고 IP address가 필요하다.

현실 세계	인터넷
사람 이름	Domain name
전화번호	IP address
연락처 앱 또는 전화번호부	DNS
전화를 거는 행위	서버에 접속하는 행위

예를 들어 사용자는 다음과 같은 이름을 기억한다.

www.example.com
api.example.com

하지만 실제 연결에는 다음과 같은 주소가 필요하다.

93.184.216.34
203.0.113.10

이 비유는 입문용으로 유용하지만, DNS를 단순한 정적 목록으로만 이해하면 부족하다. DNS는 다음 특성을 가진다.

계층형 구조를 가진다.
여러 종류의 DNS server가 역할을 나누어 수행한다.
record가 cache된다.
TTL에 따라 변경 반영 시간이 달라진다.
하나의 domain name이 여러 record를 가질 수 있다.
public DNS와 private DNS가 나뉠 수 있다.
CDN, Load Balancer, Kubernetes service discovery와 연결된다.

Domain Name과 IP Address의 차이

DNS를 이해하려면 먼저 domain name과 IP address를 구분해야 한다.

Domain Name

Domain name은 사람이 기억하기 쉬운 이름이다.

www.example.com
api.example.com
www.ibm.com

domain name은 오른쪽에서 왼쪽으로 계층이 세분화된다.

www.example.com.
│   │       │
│   │       └─ Root 아래의 Top-Level Domain: com
│   └───────── Second-Level Domain: example
└───────────── Hostname 또는 Subdomain: www

DNS 이름의 맨 끝에는 root를 의미하는 점 .이 붙을 수 있다.

www.example.com.

일반 사용 환경에서는 마지막 점을 생략해 www.example.com처럼 사용한다.

IP Address

IP address는 네트워크에서 장치나 서버를 식별하고 routing하기 위한 주소다.

IPv4 예시는 다음과 같다.

192.0.2.1
203.0.113.10

IPv6 예시는 다음과 같다.

2001:db8::1

IP address는 사람이 기억하기 어렵지만, 실제 packet routing에는 적합하다.

구분	Domain Name	IP Address
목적	사람이 기억하기 쉬운 이름	네트워크 통신용 주소
예시	`www.example.com`	`203.0.113.10`
사용 위치	브라우저 주소창, 서비스 endpoint	routing, connection, packet 전달
변경 가능성	같은 이름이 다른 IP를 가리킬 수 있음	서버, region, Load Balancer 구성에 따라 변경될 수 있음
운영 의미	주소 추상화 계층	실제 접속 대상

핵심은 domain name이 사용자와 운영자를 위한 이름이고, IP address는 네트워크가 실제로 사용하는 주소라는 점이다.

DNS가 필요한 이유

DNS가 없다면 사용자는 각 서비스의 IP address를 직접 기억해야 한다.

https://93.184.216.34
https://203.0.113.10
https://198.51.100.25

이 방식은 현실적으로 유지하기 어렵다. 더 큰 문제는 IP address가 항상 고정되지 않는다는 점이다.

서비스 운영 중 IP address는 다음 이유로 변경될 수 있다.

서버 이전
cloud provider 변경
Load Balancer 교체
CDN 도입
region 변경
장애 조치
blue-green deployment
multi-region traffic steering
migration 작업

DNS가 있으면 사용자는 같은 domain name을 계속 사용하고, 운영자는 내부적으로 record를 변경할 수 있다.

사용자: www.example.com 접속
운영자: www.example.com이 가리키는 IP 또는 target 변경

따라서 DNS는 단순한 이름 변환을 넘어 인터넷 서비스 운영에서 주소 추상화 계층 역할을 한다.

DNS의 기본 정신 모델

DNS lookup은 “이 이름의 IP address가 무엇인가?”를 찾아가는 과정이다.

가장 단순한 흐름은 다음과 같다.

Browser
  ↓
DNS Resolver
  ↓
DNS hierarchy
  ↓
IP address
  ↓
Actual connection

사용자가 브라우저에 domain name을 입력하면 브라우저는 먼저 해당 이름의 IP address를 알아야 한다. 이때 사용자의 PC가 전 세계 DNS server를 직접 모두 탐색하는 것이 아니라, 보통 configured DNS resolver에게 질의한다.

Client
  ↓
Recursive Resolver
  ↓
Root / TLD / Authoritative DNS

여기서 중요한 점은 DNS가 웹페이지 자체를 가져오는 프로토콜이 아니라는 것이다. DNS는 실제 HTTP request 이전에 수행되는 접속 대상 확인 단계다.

1. DNS lookup
2. TCP connection
3. TLS handshake
4. HTTP request
5. HTTP response

DNS Resolver

DNS Resolver는 사용자의 요청을 받아 domain name에 해당하는 IP address를 찾아주는 서버다. 일반적으로 recursive resolver, DNS recursor, recursive DNS server라고도 부른다.

사용자가 다음 이름을 조회한다고 가정한다.

www.example.com

client는 resolver에게 다음 질문을 던진다.

www.example.com의 IP address를 찾아줘.

resolver는 다음 순서로 답을 찾는다.

1. 내 cache에 답이 있는지 확인한다.
2. 없으면 root name server에 물어본다.
3. TLD name server를 찾는다.
4. authoritative name server를 찾는다.
5. 최종 DNS record를 받아온다.
6. client에게 IP address를 반환한다.
7. TTL 동안 결과를 cache한다.

보통 resolver는 다음 중 하나일 수 있다.

ISP가 제공하는 resolver
회사나 학교 내부 resolver
public DNS resolver
cloud provider의 resolver
브라우저가 사용하는 DoH resolver
VPC 또는 private network 내부 resolver

DNS Lookup 전체 흐름

DNS lookup은 domain name을 IP address로 변환하는 과정이다. 일반적인 흐름은 다음과 같다.

1. User enters domain name
2. Browser checks browser cache
3. OS checks local DNS cache
4. Client sends query to recursive resolver
5. Resolver checks its own cache
6. Resolver queries root name server
7. Root returns TLD name server referral
8. Resolver queries TLD name server
9. TLD returns authoritative name server referral
10. Resolver queries authoritative name server
11. Authoritative server returns DNS record
12. Resolver returns IP address to client
13. Browser connects to the returned IP address

도식화하면 다음과 같다.

Browser
  ↓
Recursive Resolver
  ↓
Root Name Server
  ↓
TLD Name Server
  ↓
Authoritative Name Server
  ↓
DNS Record
  ↓
Browser connects to IP address

client는 보통 root, TLD, authoritative server를 직접 순회하지 않는다. 이 중간 과정을 recursive resolver가 대신 수행한다.

DNS 서버의 종류

DNS는 하나의 중앙 서버가 모든 domain을 관리하는 구조가 아니다. 역할별로 여러 DNS server가 계층적으로 동작한다.

서버 종류	역할
Recursive DNS Server	사용자를 대신해 DNS record를 찾아오는 서버
Root Name Server	DNS hierarchy의 최상단에서 TLD server를 안내
TLD Name Server	`.com`, `.org`, `.kr` 등 TLD 아래의 authoritative server를 안내
Authoritative Name Server	특정 domain zone의 최종 DNS record를 보유

Recursive DNS Server

Recursive DNS Server는 사용자 쪽에 가까운 서버다. 사용자의 DNS query를 받아 최종 답을 찾을 때까지 DNS hierarchy를 따라 조회한다.

다른 이름은 다음과 같다.

recursive resolver
DNS resolver
DNS recursor
recursive DNS server

역할을 짧게 표현하면 다음과 같다.

사용자를 대신해서 DNS record를 찾아오는 서버

예를 들어 www.example.com을 조회할 때 recursive resolver는 다음 질문을 순서대로 해결한다.

내 cache에 있나?
없으면 root server에 물어보자.
.com TLD server는 어디지?
example.com authoritative server는 어디지?
www.example.com의 A 또는 AAAA record는 뭐지?

Root Name Server

Root name server는 DNS hierarchy의 최상단에 있다. root server는 일반적으로 최종 IP address를 직접 알려주지 않는다. 대신 해당 domain의 TLD를 담당하는 name server를 안내한다.

예를 들어 resolver가 root server에 다음처럼 묻는다고 하자.

www.example.com은 어디에 물어봐야 하나?

root server는 다음과 같은 의미의 응답을 반환한다.

.com TLD name server에 물어봐라.

즉 root name server의 역할은 최종 답변이 아니라 다음 질의 위치 안내다.

TLD Name Server

TLD는 Top-Level Domain을 의미한다.

대표적인 TLD는 다음과 같다.

.com
.org
.net
.kr
.jp
.io
.dev

TLD name server는 특정 TLD 아래 domain에 대한 authoritative name server 정보를 알려준다.

예를 들어 www.example.com 조회 과정에서 .com TLD server는 다음 질문을 받는다.

example.com은 어느 authoritative server가 담당하나?

TLD server는 다음과 같은 의미의 응답을 반환한다.

example.com의 authoritative name server는 ns1.example-dns.com이다.

Authoritative Name Server

Authoritative name server는 특정 domain zone의 최종 DNS record를 가지고 있는 서버다.

예를 들어 example.com zone을 관리하는 authoritative server는 다음과 같은 record를 가질 수 있다.

www.example.com.  300  IN  A      203.0.113.10
api.example.com.  300  IN  CNAME  api-lb.example.net.
example.com.      300  IN  MX     10 mail.example.com.

recursive resolver가 authoritative name server에 묻는 질문은 다음과 같다.

www.example.com의 A record는 무엇인가?

authoritative name server는 최종 record를 반환한다.

www.example.com. 300 IN A 203.0.113.10

운영자가 DNS record를 변경하는 주 대상은 authoritative DNS다.

Recursive DNS와 Authoritative DNS의 구분

DNS를 이해할 때 가장 중요한 구분 중 하나가 recursive DNS와 authoritative DNS다.

구분	Recursive DNS	Authoritative DNS
위치	사용자 쪽에 가까움	domain owner 쪽에 가까움
역할	사용자를 대신해 답을 찾아옴	특정 zone의 최종 record를 보유
주요 동작	cache 확인, root/TLD/authoritative 조회	record 반환
예시	ISP resolver, public resolver, corporate resolver	managed DNS provider의 name server
운영 관점	사용자가 어떤 resolver를 쓰는지 확인 필요	운영자가 record를 설정하는 위치

이 둘을 구분하지 못하면 DNS troubleshooting에서 원인을 잘못 판단할 수 있다.

예를 들어 다음 증상이 있다고 하자.

DNS record를 바꿨는데 내 PC에서는 아직 옛 IP로 접속된다.

가능한 원인은 하나가 아니다.

authoritative DNS record가 실제로 변경되지 않았을 수 있다.
recursive resolver cache에 이전 record가 남아 있을 수 있다.
OS cache가 남아 있을 수 있다.
browser cache가 남아 있을 수 있다.
TTL이 아직 만료되지 않았을 수 있다.
내부/외부 DNS 응답이 다른 split-horizon 구조일 수 있다.

따라서 “DNS가 안 된다”가 아니라, “어느 resolver가 어떤 record type에 대해 어떤 응답을 주는지”를 확인해야 한다.

DNS Query: Recursive와 Iterative

DNS query 방식은 크게 recursive query와 iterative query로 나눌 수 있다.

Recursive Query

client가 recursive resolver에게 보내는 query다.

Client → Resolver:
www.example.com의 IP address를 최종적으로 찾아줘.

client는 중간 과정을 신경 쓰지 않는다. resolver가 최종 답을 찾아서 반환해야 한다.

Iterative Query

recursive resolver가 root, TLD, authoritative server를 따라가며 수행하는 query다.

Resolver → Root:
www.example.com은 어디에 물어봐야 하나?

Root → Resolver:
.com TLD server에 물어봐라.

Resolver → TLD:
example.com은 어디에 물어봐야 하나?

TLD → Resolver:
example.com authoritative server에 물어봐라.

Resolver → Authoritative:
www.example.com의 A record는 무엇인가?

전체 구조는 다음처럼 요약할 수 있다.

Client ↔ Resolver: recursive query
Resolver ↔ DNS hierarchy: iterative query

이 구분은 dig +trace 같은 troubleshooting 도구를 사용할 때 중요하다.

DNS Record

DNS는 domain name과 IP address만 저장하지 않는다. 다양한 목적의 record를 통해 web, mail, verification, delegation, reverse lookup 등을 처리한다.

Record Type	목적	예시
`A`	domain name을 IPv4 address에 매핑	`example.com → 203.0.113.10`
`AAAA`	domain name을 IPv6 address에 매핑	`example.com → 2001:db8::1`
`CNAME`	alias를 canonical name으로 연결	`www → example.com`
`MX`	mail server 지정	`example.com → mail.example.com`
`TXT`	text data 저장, 인증 정책 등에 사용	SPF, DKIM, verification
`NS`	zone의 authoritative name server 지정	`example.com → ns1.example-dns.com`
`SOA`	zone의 authority와 serial 정보	primary NS, admin, serial
`PTR`	IP address를 domain name으로 역방향 조회	reverse DNS
`CAA`	인증서 발급 가능한 CA 제한	CA authorization

A Record

A record는 domain name을 IPv4 address에 매핑한다.

www.example.com.  300  IN  A  203.0.113.10

의미는 다음과 같다.

www.example.com은 300초 동안 203.0.113.10으로 해석된다.

여기서 300은 TTL이고, A는 record type이다.

AAAA Record

AAAA record는 domain name을 IPv6 address에 매핑한다.

www.example.com.  300  IN  AAAA  2001:db8::10

IPv6 환경에서는 AAAA record가 중요하다. 일부 접속 문제는 A record는 정상인데 AAAA record가 잘못되어 발생할 수 있다.

CNAME Record

CNAME record는 어떤 이름이 다른 canonical name의 alias임을 나타낸다.

www.example.com.  300  IN  CNAME  example.com.

이 경우 resolver는 www.example.com의 최종 IP를 얻기 위해 example.com의 A 또는 AAAA record를 다시 조회해야 한다.

주의할 점은 CNAME이 최종 IP address가 아니라 다른 이름을 가리키는 record라는 것이다.

www.example.com
  ↓ CNAME
example.com
  ↓ A
203.0.113.10

TTL과 DNS Cache

DNS에서 TTL(Time To Live)은 record를 cache해도 되는 시간을 의미한다.

예를 들어 다음 record가 있다고 하자.

www.example.com.  300  IN  A  203.0.113.10

여기서 300은 초 단위 TTL이다.

TTL 300 seconds = 5 minutes

recursive resolver나 local cache는 이 record를 5분 동안 재사용할 수 있다.

TTL이 긴 경우

장점	단점
DNS query 수가 줄어듦	record 변경 반영이 느림
resolver와 authoritative DNS 부하 감소	장애 조치 시 오래된 IP로 접속할 수 있음
cache hit 비율 증가	migration, failover, traffic shift에 불리할 수 있음

TTL이 짧은 경우

장점	단점
변경 반영이 빠름	DNS query 수가 늘어남
failover와 migration에 유리	authoritative DNS 부하가 증가할 수 있음
traffic steering 제어가 쉬움	resolver별 최소 TTL 정책 영향을 받을 수 있음

운영에서는 서비스 성격에 맞게 TTL을 조정해야 한다.

일반 안정 서비스: 비교적 긴 TTL
migration 전 단계: TTL 낮춤
failover 민감 서비스: 짧은 TTL 또는 managed DNS traffic steering

DNS 변경이 즉시 전 세계에 반영된다고 가정하면 안 된다. TTL과 cache 계층을 고려해야 한다.

DNS Lookup과 웹 요청의 관계

DNS는 웹 요청 전 단계다. 따라서 DNS lookup이 느리면 사용자는 아직 HTTP request를 보내기도 전에 지연을 경험한다.

일반적인 웹 접속 흐름은 다음과 같다.

1. DNS lookup
2. TCP connection
3. TLS handshake
4. HTTP request
5. Server processing
6. HTTP response download
7. Browser rendering

DNS resolution이 지연되면 전체 page load time이 증가한다.

특히 다음 환경에서는 DNS latency가 중요해진다.

mobile network
해외 region 접속
많은 third-party domain을 로드하는 웹페이지
CDN 또는 multi-CDN 구성
enterprise proxy 환경
container 내부 service discovery
microservices 간 호출

브라우저 개발자 도구의 Network timing에서 DNS Lookup 구간이 비정상적으로 길다면 resolver, cache, record 구성, network path, DoH/DoT 설정 등을 확인해야 한다.

DNS와 Load Balancer의 관계

DNS와 Load Balancer는 모두 접속 경로에 관여하지만 역할이 다르다.

DNS는 사용자가 접속할 entrypoint의 주소를 알려주고, Load Balancer는 그 주소로 들어온 traffic을 backend server로 분산한다.

User enters domain
  ↓
DNS returns Load Balancer IP or hostname
  ↓
Client connects to Load Balancer
  ↓
Load Balancer forwards request to backend server

예를 들어 다음과 같은 구조가 가능하다.

www.example.com → Load Balancer IP

Load Balancer
  ├─ app-server-1
  ├─ app-server-2
  └─ app-server-3

구분	DNS	Load Balancer
주된 역할	이름을 주소로 변환	들어온 traffic을 backend로 분산
동작 시점	connection 전	connection 또는 request 처리 중
주요 단위	domain name, record, TTL	connection, request, backend pool
예시	`www.example.com → 203.0.113.10`	`request → app-server-2`
운영 이슈	TTL, cache, resolver, propagation	health check, routing policy, session persistence

DNS만으로도 간단한 traffic 분산을 할 수 있다.

www.example.com.  300  IN  A  203.0.113.10
www.example.com.  300  IN  A  203.0.113.11
www.example.com.  300  IN  A  203.0.113.12

하지만 DNS 기반 분산은 Load Balancer처럼 request 단위로 backend health를 정교하게 반영하기 어렵다. production 환경에서는 보통 DNS가 Load Balancer 또는 CDN endpoint를 가리키고, 실제 traffic 분산은 Load Balancer나 CDN 계층에서 수행한다.

Public DNS, Private DNS, Split-Horizon DNS

DevOps 환경에서는 public internet DNS뿐 아니라 private DNS와 split-horizon DNS도 중요하다.

Public DNS

외부 인터넷에서 접근 가능한 domain record를 해석한다.

www.example.com → public IP

public website, API endpoint, CDN, public Load Balancer 등이 여기에 해당한다.

Private DNS

내부 network에서만 사용하는 이름을 해석한다.

db.internal.example.com → 10.0.12.34
api.service.local → 10.0.4.20

VPC, Kubernetes, VPN, corporate network에서 자주 사용된다.

Split-Horizon DNS

같은 domain name이라도 내부와 외부에서 서로 다른 응답을 반환하는 구조다.

External user:
app.example.com → public load balancer IP

Internal user:
app.example.com → private load balancer IP

이 구조는 편리하지만 troubleshooting이 어려워질 수 있다.

예를 들어 다음 증상이 발생할 수 있다.

회사 내부에서는 접속된다.
외부에서는 접속되지 않는다.

또는

외부에서는 정상인데 VPN 연결 시 다른 IP로 resolve된다.

이 경우 어떤 resolver에 질의했는지 확인하는 것이 중요하다.

DNS 보안 이슈

DNS는 인터넷 접속의 출발점이기 때문에 보안상 중요한 공격 표면이 된다.

대표적인 DNS 관련 보안 이슈는 다음과 같다.

이슈	설명
DNS Spoofing / Cache Poisoning	잘못된 DNS 응답을 통해 사용자를 공격자 IP로 유도
DNS Amplification	DNS 응답 크기를 악용해 DDoS traffic을 증폭
DNS Tunneling	DNS query/response 안에 비정상 데이터를 숨겨 통신
Subdomain Takeover	삭제된 외부 resource를 가리키는 DNS record가 남아 공격에 악용

DNS Spoofing / Cache Poisoning

공격자가 resolver cache에 잘못된 record를 넣으면 사용자는 정상 domain을 입력했는데도 공격자 서버로 연결될 수 있다.

www.example.com → 정상 IP
www.example.com → 공격자 IP

DNS Amplification

공격자가 victim IP를 source address로 spoofing한 뒤 DNS server에 query를 보내면, DNS server가 큰 response를 victim에게 보낼 수 있다.

Attacker spoofs victim IP
  ↓
DNS server receives query
  ↓
DNS server sends large response to victim

DNS Tunneling

DNS query/response 안에 원래 DNS가 아닌 데이터를 숨겨 보안 정책을 우회하는 방식이다.

encoded-data-1234.attacker-domain.com

Subdomain Takeover

더 이상 사용하지 않는 cloud resource를 가리키는 DNS record가 남아 있을 때 발생할 수 있다.

old-app.example.com CNAME old-app.cloudprovider.com

만약 old-app.cloudprovider.com에 해당하는 resource가 삭제되었고, 공격자가 같은 이름의 resource를 등록할 수 있다면 old-app.example.com이 공격자 서비스로 연결될 수 있다.

DNSSEC, DoH, DoT

DNS의 보안과 privacy를 강화하기 위해 DNSSEC, DoH, DoT 같은 개념이 사용된다.

구분	목적	특징
DNSSEC	DNS 응답의 출처와 무결성 검증	암호화가 아니라 서명 검증
DoH	DNS query를 HTTPS로 전송	HTTPS traffic과 섞이며 browser 친화적
DoT	DNS query를 TLS로 전송	전용 DNS-over-TLS 방식
일반 DNS	기본 DNS query	단순하지만 query가 평문으로 노출될 수 있음

DNSSEC

DNSSEC는 DNS response가 실제 authoritative source에서 왔는지, 중간에서 변조되지 않았는지 검증하기 위한 보안 확장이다.

중요한 점은 DNSSEC가 DNS traffic 자체를 암호화하는 것은 아니라는 점이다.

DNSSEC의 목적:
이 DNS 응답이 진짜인가?
이 DNS 응답이 중간에서 변조되지 않았는가?

DoH

DoH(DNS over HTTPS)는 DNS query를 HTTPS 위에서 수행하는 방식이다.

Traditional DNS: UDP/TCP 53
DoH: HTTPS 443

DoH는 DNS query의 노출을 줄일 수 있지만, enterprise network에서는 중앙 DNS 정책 적용과 visibility 측면에서 별도 고려가 필요할 수 있다.

DoT

DoT(DNS over TLS)는 DNS query를 TLS로 보호하는 방식이다. DoH와 목적은 유사하지만 transport와 운영 방식이 다르다.

DNS Troubleshooting 관점

DNS 문제는 “DNS가 안 된다”로 뭉뚱그리면 원인을 찾기 어렵다. 어느 계층에서 어떤 응답이 나오는지 분리해 봐야 한다.

대표적인 증상은 다음과 같다.

사이트가 안 열린다.
특정 네트워크에서만 접속이 안 된다.
내 PC에서는 옛 IP로 붙는다.
도메인 변경 후 일부 사용자만 정상 접속된다.
메일이 수신되지 않는다.
Kubernetes 내부에서는 되는데 외부에서는 안 된다.

확인해야 할 대상은 다음과 같다.

확인 대상	검증 질문
Browser cache	browser가 이전 DNS 결과를 들고 있나?
OS DNS cache	local OS cache가 남아 있나?
Recursive resolver	현재 사용하는 resolver가 어떤 응답을 주나?
Authoritative DNS	authoritative server에는 올바른 record가 있나?
TTL	이전 record의 TTL이 아직 남아 있나?
Record type	`A`, `AAAA`, `CNAME`, `MX`, `TXT` 등이 올바른가?
Split-horizon	내부/외부 resolver 응답이 다른가?
CDN/LB	DNS는 맞지만 downstream target이 잘못되었나?
DNSSEC	서명 또는 DS record 문제가 있나?

`dig`를 이용한 기본 확인

DNS 확인에는 dig를 사용할 수 있다.

dig example.com
dig example.com A
dig example.com AAAA
dig example.com NS
dig example.com MX
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com
dig +trace example.com

명령별 의미는 다음과 같다.

명령	확인 목적
`dig example.com`	기본 resolver가 반환하는 응답 확인
`dig example.com A`	IPv4 address record 확인
`dig example.com AAAA`	IPv6 address record 확인
`dig example.com NS`	authoritative name server delegation 확인
`dig example.com MX`	mail server record 확인
`dig @8.8.8.8 example.com`	특정 resolver 기준 응답 확인
`dig @1.1.1.1 example.com`	다른 resolver와 응답 비교
`dig +trace example.com`	root부터 authoritative까지 resolution 경로 추적

dig +trace는 recursive resolver가 내부적으로 수행하는 iterative lookup 과정을 사람이 직접 따라가는 데 유용하다.

DNS 장애 분석 절차

DNS 문제가 의심될 때는 다음 순서로 분리해서 확인할 수 있다.

local 환경에서 응답을 확인한다.

dig example.com

record type을 명시해 확인한다.

dig example.com A
dig example.com AAAA

여러 public resolver의 응답을 비교한다.

dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

authoritative delegation 경로를 확인한다.

dig +trace example.com

authoritative name server에 직접 질의한다.

dig @ns1.example-dns.com example.com A

TTL과 cache 가능성을 확인한다.

응답에 포함된 TTL이 아직 남아 있는가?
변경 전 record의 TTL이 길지 않았는가?

DNS 이후 계층을 확인한다.

DNS는 올바른 IP를 반환하지만 Load Balancer, CDN, firewall, TLS, application이 문제일 수 있다.

Kubernetes와 DNS

Kubernetes 내부 service discovery도 DNS 기반으로 동작하는 경우가 많다.

예를 들어 다음 Service가 있다고 가정한다.

Service name: api
Namespace: prod
Cluster domain: cluster.local

Pod 내부에서는 다음 이름으로 service를 조회할 수 있다.

api.prod.svc.cluster.local

흐름은 다음과 같다.

Pod
  ↓
CoreDNS
  ↓
Kubernetes Service record
  ↓
ClusterIP
  ↓
Pod endpoints

Kubernetes에서 DNS 문제가 발생하면 다음 증상이 나타날 수 있다.

service name으로 접속이 안 된다.
Pod에서 외부 domain resolve에 실패한다.
특정 namespace의 service만 조회되지 않는다.
CoreDNS pod CPU 사용률이 증가한다.
ndots 설정 때문에 불필요한 DNS query가 많아진다.

특히 container의 /etc/resolv.conf에 설정된 search domain과 ndots는 DNS query 수에 영향을 준다.

예를 들어 ndots:5 환경에서 api.example.com을 조회하면 다음과 같이 여러 후보를 시도할 수 있다.

api.example.com.default.svc.cluster.local
api.example.com.svc.cluster.local
api.example.com.cluster.local
api.example.com

microservices 환경에서는 이러한 DNS query 증가가 latency 또는 CoreDNS 부하로 이어질 수 있다.

DNS와 CDN, Global Traffic Steering

DNS는 단순히 하나의 IP만 반환하는 데 그치지 않고 global traffic steering에도 사용될 수 있다.

예를 들어 전 세계 사용자가 하나의 domain에 접속한다고 하자.

www.example.com

DNS provider 또는 CDN은 사용자 위치, resolver 위치, latency, region 상태, health check 결과 등을 고려해 다른 응답을 줄 수 있다.

Korea user  → Seoul edge
Japan user  → Tokyo edge
US user     → Virginia edge
Europe user → Frankfurt edge

다만 DNS 기반 traffic steering에는 한계가 있다.

사용자의 실제 위치가 아니라 resolver 위치를 기준으로 판단할 수 있다.
TTL 동안 응답이 cache되어 즉각적인 전환이 어렵다.
client 또는 resolver가 예상보다 오래 cache할 수 있다.
일부 resolver는 privacy 정책 때문에 위치 정보를 제한할 수 있다.

따라서 DNS traffic steering은 request-level Load Balancing과 다르게 동작한다는 점을 이해해야 한다.

자칫 실수하기 쉬운 부분

DNS를 운영할 때 자주 발생하는 실수는 다음과 같다.

실수	문제
DNS 변경이 즉시 반영된다고 가정	TTL과 cache 때문에 일부 사용자는 이전 응답을 받을 수 있음
recursive DNS와 authoritative DNS 혼동	record 설정 위치와 사용자 응답 위치를 잘못 판단
`A` record만 확인	IPv6 환경에서는 `AAAA` record 문제일 수 있음
CNAME을 최종 IP로 오해	CNAME은 다른 이름을 가리키는 alias
내부/외부 resolver 차이 미확인	split-horizon DNS 환경에서 서로 다른 결과 발생
DNS만 확인하고 downstream 미확인	DNS 이후 Load Balancer, firewall, TLS, application 문제가 남을 수 있음
오래된 cloud CNAME 방치	subdomain takeover 위험 발생 가능

정리

DNS는 사람이 기억하기 쉬운 domain name을 실제 네트워크 통신에 필요한 IP address로 변환하는 계층형·분산형 이름 해석 시스템이다.

핵심 정리는 다음과 같다.

항목	정리
기본 역할	domain name을 IP address로 변환
주요 컴포넌트	recursive resolver, root name server, TLD name server, authoritative name server
핵심 흐름	client → resolver → root → TLD → authoritative → record 반환
주요 record	`A`, `AAAA`, `CNAME`, `MX`, `TXT`, `NS`, `SOA`, `PTR`, `CAA`
cache 제어	TTL을 통해 record cache 시간을 제어
운영 이슈	propagation, resolver cache, split-horizon, DNSSEC, Load Balancer/CDN 연동
troubleshooting 관점	어느 resolver가 어떤 record type에 대해 어떤 응답을 주는지 분리해서 확인

DNS를 제대로 이해하려면 “domain name을 IP address로 바꾼다”에서 멈추면 안 된다. 실제 운영에서는 resolver cache, TTL, authoritative DNS, record type, private DNS, Kubernetes service discovery, CDN, Load Balancer, DNS 보안까지 함께 고려해야 한다. DNS는 웹 접속의 사전 단계이지만, 이 단계가 흔들리면 application이 정상이어도 사용자는 서비스에 도달할 수 없다.

개요