확대

curl https://api.example.com을 실행하면, 커널이 직접 DNS를 조회하는 게 아닙니다. glibc의 Name Service Switch(NSS)가 /etc/nsswitch.conf에 정의된 순서에 따라 여러 소스를 순차적으로 시도합니다. 이 경로를 모르면 "resolv.conf를 고쳤는데 왜 아직 안 되지"라는 상황이 생깁니다.

확대

Ubuntu 22.04 기준 해석 경로:

애플리케이션 (curl, wget, your-app)
    ↓  getaddrinfo() — glibc
/etc/nsswitch.conf  →  "hosts: files mdns4_minimal [NOTFOUND=return] dns"
    ↓  1순위: files
/etc/hosts          →  127.0.0.1 localhost, ::1 localhost ...
    ↓  없으면 다음
    ↓  2순위: dns
127.0.0.53:53       →  systemd-resolved (stub resolver)
    ↓  캐시 없으면
upstream DNS        →  /run/systemd/resolve/resolv.conf의 nameserver
    ↓  (보통 DHCP에서 받은 라우터 DNS 또는 회사 내부 DNS)
외부 DNS 서버        →  8.8.8.8, 1.1.1.1 등

nsswitch.conf가 중요한 이유: /etc/hosts가 먼저 확인됩니다. 테스트 목적으로 hosts 파일에 임시 항목을 추가했다가 지우지 않으면, DNS 응답과 다른 IP로 연결이 됩니다.

# 현재 hosts 순서 확인
grep "^hosts:" /etc/nsswitch.conf
# hosts: files mdns4_minimal [NOTFOUND=return] dns

# /etc/hosts 내용 확인 (엉뚱한 항목이 있을 수 있음)
cat /etc/hosts

systemd-resolved의 역할: Ubuntu 18.04 이후 기본 활성화된 로컬 DNS 캐시 데몬입니다. 127.0.0.53:53에서 리스닝하며 다음 역할을 합니다.

확대

DNS 문제 진단에서 dig는 가장 신뢰할 수 있는 도구입니다. nslookup보다 출력이 상세하고 옵션도 풍부합니다. 세 가지 패턴만 알면 대부분의 상황을 커버할 수 있습니다.

패턴 1: 공용 DNS로 직접 질의 — systemd-resolved 우회

# 로컬 DNS(systemd-resolved)를 완전히 우회하고 구글 DNS에 직접 질의
dig @8.8.8.8 api.example.com

# 응답 섹션만 간결하게 (스크립트에서 유용)
dig @8.8.8.8 api.example.com +short

이 명령이 성공하고 dig api.example.com이 실패하면 → 로컬 DNS 문제입니다.

패턴 2: 재귀 추적 — Root부터 Authoritative까지 전체 경로

# Root NS부터 Authoritative까지 전체 위임 경로 추적
dig +trace api.example.com

출력 예시 (요약):

.                       518400  IN  NS  a.root-servers.net.
com.                    172800  IN  NS  a.gtld-servers.net.
example.com.            172800  IN  NS  ns1.example.com.
api.example.com.        300     IN  A   93.184.216.34

Root → .com TLD → example.com Authoritative 순서로 위임되는 흐름이 보입니다. 특정 단계에서 응답이 없으면 그 구간이 문제입니다.

패턴 3: 특정 레코드 타입 조회

# A 레코드 (IPv4 주소)
dig api.example.com A

# AAAA 레코드 (IPv6 주소)
dig api.example.com AAAA

# MX 레코드 (메일 서버)
dig example.com MX

# SOA — 도메인 권한 정보 (NXDOMAIN 의심 시 권한 네임서버 확인)
dig example.com SOA

# PTR — 역방향 조회 (IP → 도메인)
dig -x 93.184.216.34

응답 status 값 해석:

확대

DNS 오류 메시지를 보고 바로 원인 카테고리를 좁히면 진단 시간이 크게 줄어듭니다.

NXDOMAIN — 도메인이 없다

$ dig api.internal.corp
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 12345

• Authoritative 서버까지 도달했는데 해당 레코드가 등록되어 있지 않습니다.
• 원인: 오타, 도메인 만료, DNS 레코드 미등록, 검색 도메인(search domain) 문제
• 확인: dig +trace api.internal.corp로 Authoritative 서버까지 도달하는지 봅니다.

# 검색 도메인 문제인지 확인 — 절대 이름으로 조회
dig api.internal.corp.   # 끝에 점(.) = 절대 이름, 검색 도메인 미적용

SERVFAIL — 서버가 처리하지 못했다

$ dig @10.0.1.53 api.internal.corp
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 67890

• DNS 리졸버가 응답을 받아왔지만 처리 중 오류가 발생했습니다.
• 원인: 내부 DNS 서버 장애, Authoritative 서버 비응답, DNSSEC 검증 실패, 방화벽이 DNS 응답 패킷을 차단
• 확인: 다른 DNS 서버로 시도 → dig @8.8.8.8 api.internal.corp

connection timed out — 패킷이 도달하지 못했다

$ dig api.example.com
;; connection timed out; no servers could be reached

• DNS 서버로의 UDP 53 패킷 자체가 차단됐거나 DNS 서버가 완전히 다운됐습니다.
• 원인: 방화벽이 UDP 53을 차단, /etc/resolv.conf의 nameserver IP가 잘못됨, systemd-resolved 다운
• 확인 순서:

# 1. systemd-resolved가 살아있는지 확인
systemctl status systemd-resolved

# 2. 127.0.0.53 포트가 열려있는지 확인
ss -ulnp | grep 53

# 3. resolv.conf의 nameserver로 ping
ping -c 3 $(grep nameserver /etc/resolv.conf | head -1 | awk '{print $2}')

# 4. UDP 53 트래픽 직접 확인
sudo tcpdump -i any -n port 53 &
dig google.com

오류별 요약:

지금까지 DNS를 '질의와 응답'으로만 다뤘지만, 가장 헷갈리는 간헐적 장애 몇 가지는 그 아래 전송 계층에서 벌어집니다. DNS가 어떤 전송을 언제 고르는지 알면, "다른 도메인은 다 되는데 유독 이 도메인만 가끔 안 되는" 상황을 설명할 수 있습니다.

• DNS의 기본은 UDP 53이지만, 응답이 한 패킷에 안 들어가면 TCP로 넘어갑니다. 서버는 응답 헤더에 TC(truncated) 비트를 세워 "잘렸으니 TCP로 다시 물어보라"고 알리고, 리졸버는 같은 질의를 TCP 53으로 재시도합니다. 즉 TCP 53은 예외 상황용이 아니라 정상 프로토콜의 일부입니다.
• 응답이 커지는 경우: A 레코드가 많은 도메인(로드밸런싱), 큰 TXT(SPF/DKIM), 그리고 특히 DNSSEC 서명(RRSIG·DNSKEY)입니다. DNSSEC 응답은 쉽게 UDP 한 패킷을 넘깁니다.
• EDNS0가 UDP 버퍼를 키웁니다. 예전 512바이트 한계를 EDNS0가 4096바이트 등으로 확장해, 큰 응답도 TCP 없이 UDP로 받게 해줍니다(dig 출력의 ; EDNS: version: 0 ... udp: 4096). 하지만 그 큰 UDP 패킷은 IP 단편화(fragmentation)를 유발하고, 중간 장비가 단편을 떨구면 다시 TC→TCP 폴백이 필요해집니다.
• 여기서 고전적 함정이 생깁니다. "DNS는 UDP만 쓴다"는 오해로 방화벽이 UDP 53만 열고 TCP 53을 막아두면, 작은 응답은 통과하는데 큰 응답(DNSSEC·많은 레코드)만 실패합니다. 전면 장애가 아니라 특정 도메인만 간헐적으로 깨지기 때문에 진단이 어렵습니다.

# 응답이 잘렸는지(플래그에 tc), TCP 폴백이 되는지 확인
dig +dnssec example.com          # 큰 응답을 유도 (flags에 tc가 뜨는지)
dig +tcp example.com             # TCP 53으로 강제 질의 — 무응답이면 TCP 차단 의심

정리하면, DNS 장애를 볼 때 "이름이 있느냐/없느냐"(NXDOMAIN·SERVFAIL) 다음으로 "응답이 어느 전송으로 오느냐"를 의심 목록에 넣어야 합니다. 특히 DNSSEC 도입, 레코드 급증, EDNS 큰 패킷은 TCP 53과 경로 MTU를 함께 점검할 신호입니다.