이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- DNS 조회가 root, TLD, authoritative DNS, recursive resolver를 거쳐 어떻게 IP 후보를 얻는가?
- A, AAAA, CNAME, TXT, CAA, MX 같은 record가 웹 서비스 운영에서 어떤 문제를 만드는가?
NXDOMAIN,SERVFAIL, CNAME chain, split-horizon DNS, IPv6 장애를 어떻게 구분하는가?
개요
DNS는 사람이 읽는 이름을 네트워크가 사용할 주소와 정책 정보로 바꾸는 분산 데이터베이스다. 백엔드 개발자는 DNS를 “인프라가 알아서 하는 것”으로만 보면 도메인 이전, 인증서 발급, 특정 통신사 장애, IPv6 사용자 장애, 내부망 전용 장애를 제대로 좁히기 어렵다.
- DNS 조회는 root, TLD, authoritative server를 거쳐 record를 찾는 분산 시스템이다.
- 웹 서비스에서는 A/AAAA, CNAME, TXT, CAA record를 특히 자주 만난다.
- AAAA가 잘못 열려 있으면 IPv6 경로 사용자만 실패하는 드문 장애가 난다.
왜 백엔드 개발자가 알아야 하는가
DNS가 틀리면 앱 코드는 실행되지도 않는다. 하지만 DNS가 정상이어도 TCP, TLS, HTTP는 따로 실패할 수 있다. 그래서 DNS 장애를 의심할 때는 “이름이 어떤 record로 해석되었는가”와 “그 주소로 실제 연결이 되는가”를 분리해야 한다.
- 새 도메인 연결 후 일부 사용자만 실패하면 resolver cache, split-horizon, AAAA, CNAME chain을 확인해야 한다.
- 인증서 자동 발급이 실패하면 DNS-01 TXT record, CAA record, authoritative DNS 반영 상태를 봐야 한다.
- 외부 API 호출이 간헐적으로 실패하면 JVM/OS DNS cache, service discovery, 내부 DNS 장애가 원인일 수 있다.
- Kubernetes나 사내망에서는 search domain과 내부 DNS가 public DNS와 다른 답을 줄 수 있다.
요청 흐름에서의 위치
DNS는 HTTP 요청 전에 이름을 주소 후보로 바꾸는 단계다.
URL host
→ local cache / hosts
→ recursive resolver
→ root
→ TLD
→ authoritative DNS
→ A/AAAA/CNAME 등 record
→ TCP 연결 시도백엔드 장애에서는 두 방향을 모두 본다. 사용자가 우리 서비스 도메인을 찾는 inbound DNS와, 우리 서버가 외부 API/DB/cache/service discovery 이름을 찾는 outbound DNS다.
원리
자주 만나는 record의 의미는 다음과 같다.
| Record | 의미 | 실무 포인트 |
|---|---|---|
| A | IPv4 주소 | LB, CDN, 서버 IP로 연결 |
| AAAA | IPv6 주소 | 일부 IPv6 사용자만 실패하는 원인이 될 수 있음 |
| CNAME | 다른 이름으로 alias | chain이 길면 추적이 어려워지고 apex 도메인에서는 제약이 있음 |
| TXT | 텍스트 검증/정책 | 도메인 소유 검증, SPF, DKIM, DMARC, DNS-01 인증서 |
| CAA | 인증서 발급 CA 제한 | 잘못 설정하면 인증서 발급 실패 |
| MX | 메일 서버 | 웹 요청은 아니지만 도메인 운영에서 자주 함께 관리 |
응답 code도 중요하다.
| DNS 응답 | 의미 | 판단 |
|---|---|---|
| NOERROR + answer | 정상 응답 | record 값과 TTL 확인 |
| NOERROR + no answer | 이름은 있으나 요청한 type 없음 | A는 있는데 AAAA는 없을 수 있음 |
| NXDOMAIN | 이름 자체가 없음 | 오타, zone 누락, 아직 생성 안 됨 |
| SERVFAIL | resolver나 authoritative 처리 실패 | DNSSEC, 권한 DNS 장애, 위임 문제 가능 |
| REFUSED | 서버가 질의를 거부 | 잘못된 resolver, 접근 제한 가능 |
DNS는 “정답 하나”가 아니다. resolver별 cache 상태, 내부/외부 view, IPv4/IPv6, record type에 따라 답이 다를 수 있다.
핵심 판단 기준
- “도메인이 안 된다”는 제보는 resolver, record type, 응답 code, TTL, 반환 IP를 함께 받아야 한다.
- A만 확인하지 말고 AAAA도 확인한다. IPv6 경로만 깨진 장애는 개인 프로젝트에서도 생긴다.
- CNAME은 최종 대상까지 따라가며 인증서 SAN, LB listener, origin host 설정과 맞는지 본다.
- 내부망과 외부망의 결과가 달라야 하는 도메인은 split-horizon 의도가 문서화되어 있어야 한다.
- outbound DNS 문제는 HTTP client timeout이 아니라 DNS resolution timeout처럼 보일 수 있다.
실무에서 자주 만나는 문제
- A record만 보고 CNAME chain을 놓친다.
- 내부 DNS와 외부 DNS가 다른 split-horizon 문제를 놓친다.
- TXT/CAA 설정이 인증서 발급 실패로 이어지는 것을 늦게 발견한다.
www.example.com은 되는데 apexexample.com은 안 된다. CNAME apex 제약이나 ALIAS/ANAME 지원 차이 때문일 수 있다.- public DNS는 새 IP인데 회사 VPN 내부 DNS는 옛 IP를 반환한다.
- AAAA record가 있는데 IPv6 listener, security group, firewall, 인증서가 준비되지 않았다.
- Kubernetes service name이 search domain 때문에 의도하지 않은 내부 이름으로 해석된다.
SERVFAIL을 앱 장애로 보고 재시작만 반복한다.
DNS 문제는 보통 “모두 안 됨”보다 “일부 위치, 일부 네트워크, 일부 record type만 안 됨”으로 나타난다. 그래서 재현 위치와 resolver를 기록하지 않으면 원인 후보가 넓어진다.
디버깅 방법
dig +trace로 authoritative 경로를 본다.dig A와dig AAAA를 모두 확인한다.- 내부망과 외부망에서 같은 도메인의 결과를 비교한다.
@1.1.1.1,@8.8.8.8, 사내 resolver, VPC resolver를 나눠 질의한다.+noall +answer +authority로 answer와 authority를 분리한다.- DNS가 정상이라면 반환된 IP로 TCP/TLS/HTTP를 별도 확인한다.
dig +trace api.example.com
dig @1.1.1.1 api.example.com A +noall +answer
dig @8.8.8.8 api.example.com AAAA +noall +answer
dig api.example.com CNAME +noall +answer
dig example.com CAA +noall +answer
dig _acme-challenge.example.com TXT +noall +answerdig 결과가 정상이어도 아직 끝이 아니다. 다음처럼 DNS 이후 연결을 확인한다.
IP="$(dig +short api.example.com A | head -n1)"
curl -v --resolve "api.example.com:443:${IP}" https://api.example.com/health--resolve는 특정 IP로 접속하면서 Host/SNI는 원래 도메인으로 유지한다. DNS와 TLS/HTTP를 분리해서 볼 때 유용하다.
코드로 확인하기
JVM 애플리케이션에서는 DNS 결과가 런타임 안에서 cache될 수 있다. 장애 재현 때는 애플리케이션 내부에서 어떤 주소를 보고 있는지 확인할 수 있어야 한다.
import java.net.InetAddress;
import java.util.Arrays;
public class DnsProbe {
public static void main(String[] args) throws Exception {
String host = args.length > 0 ? args[0] : "api.example.com";
InetAddress[] addresses = InetAddress.getAllByName(host);
Arrays.stream(addresses)
.forEach(address -> System.out.println(host + " -> " + address.getHostAddress()));
}
}Java의 DNS cache 정책은 JVM 버전, security property, security manager 설정, OS resolver에 따라 달라질 수 있다. “dig는 새 IP인데 앱은 옛 IP를 본다”면 프로세스 내부 cache와 connection pool을 같이 의심한다.
주니어가 자주 하는 오해
dig example.com한 번으로 전 세계 DNS 상태를 알 수 있다고 생각한다.- 실제 사용자는 여러 recursive resolver와 cache를 거친다.
- A record만 맞으면 DNS는 끝났다고 생각한다.
- AAAA, CNAME, CAA, TXT, 내부 DNS가 별도 문제를 만들 수 있다.
NXDOMAIN과SERVFAIL을 같은 장애로 본다.- 하나는 이름 부재에 가깝고, 하나는 DNS 처리 실패에 가깝다.
- DNS가 정상이라면 네트워크는 정상이라고 생각한다.
- DNS는 연결 전 단계일 뿐이고 TCP/TLS/HTTP는 따로 실패할 수 있다.
시니어의 설계 판단 기준
- 핵심 도메인은 authoritative DNS, registrar, DNSSEC, CAA, 인증서 자동화까지 한 묶음으로 관리한다.
- IPv6를 열었다면 LB, WAF, firewall, observability, rate limit도 IPv6 기준으로 준비한다.
- 내부 service discovery와 public DNS 이름이 충돌하지 않게 naming convention을 둔다.
- 외부 API 의존성이 DNS 장애를 일으킬 때 fallback, circuit breaker, DNS cache 정책을 정한다.
- DNS 변경은 record diff, 예상 TTL, rollback record, 검증 resolver를 포함한 변경 요청으로 다룬다.
인프라 협업 포인트
- DNS 장애를 전달할 때는 도메인, record type, 질의 resolver, 응답 code, answer, TTL, 재현 위치를 포함한다.
- 내부 DNS라면 VPC/VNet, namespace, search domain, pod/node 위치, resolver IP를 같이 준다.
- 인증서 발급 문제라면 TXT/CAA record와 authoritative DNS 결과를 함께 확인한다.
- 인프라 팀은 DNS 변경이 작아 보여도 registrar, authoritative DNS, CDN, LB, certificate automation까지 영향 범위를 봐야 한다.
실전 팁
- 장애 제보를 받을 때 “어느 DNS 서버에 물어봤는가”를 꼭 묻는다.
- 새 도메인을 연결하면 A/AAAA, TLS 인증서, HTTP Host routing, redirect, cookie domain을 한 번에 smoke test한다.
- CNAME chain은 짧을수록 좋다. 길면 책임 경계와 장애 분석이 어려워진다.
- 개인 프로젝트에서도 DNS provider 계정 MFA, registrar lock, 인증서 자동 갱신을 챙긴다.
위험 신호!
- public DNS와 internal DNS가 다른 값을 주는데 문서가 없다.
- AAAA record가 있지만 IPv6 모니터링과 alert가 없다.
- 인증서 자동 발급 실패를 애플리케이션 배포 실패로만 본다.
- 장애 보고에 resolver, record type, TTL이 없다.
- DNS provider, registrar, CDN 권한이 개인 계정에만 묶여 있다.
확인 질문
확인 질문
NXDOMAIN과SERVFAIL은 어떻게 다른가?
NXDOMAIN은 이름이 없다는 응답이고,SERVFAIL은 DNS 서버가 질의를 처리하지 못했다는 신호다.- A record가 정상인데 일부 사용자가 접속하지 못하면 무엇을 더 봐야 하는가?
- AAAA, CNAME chain, resolver별 cache, 내부/외부 DNS 차이, TCP/TLS/HTTP 연결 여부를 봐야 한다.
- 인증서 발급 실패와 DNS record는 어떤 관계가 있는가?
- DNS-01 검증은 TXT record가 필요하고, CAA record는 어떤 CA가 인증서를 발급할 수 있는지 제한할 수 있다.