우분투 실전 명령어 | dig/nslookup으로 DNS 조회 장애 진단

Last updated on 

서버는 살아 있는데 도메인만 안 열릴 때가 많습니다. 이럴 때는 앱 로그부터 보기보다 DNS 경로를 먼저 쪼개서 확인하는 편이 빠릅니다. dig, nslookup, resolvectl 조합만 익혀도 문제 구간을 거의 바로 좁힐 수 있습니다.

언제 쓰는가

  • 특정 도메인만 접속 실패할 때
  • 서버에서만 DNS 조회가 느리거나 실패할 때
  • 사내 DNS와 공용 DNS 결과가 다를 때
  • A 레코드는 보이는데 서비스 연결이 안 될 때

바로 쓰는 명령어

# 기본 A 레코드 조회
dig example.com +short

# NS/MX/TXT 등 레코드 타입 지정 조회
dig example.com NS +short
dig example.com MX +short
dig example.com TXT +short

# 특정 DNS 서버로 강제 질의
# 사내 DNS와 공용 DNS 결과 비교할 때 유용
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short

# +trace로 위임 경로 확인
# 루트 -> TLD -> 권한 DNS 순서로 확인
dig example.com +trace

# nslookup으로 빠른 점검
nslookup example.com
nslookup -type=mx example.com

# 시스템이 실제로 쓰는 resolver 상태 확인
resolvectl status
resolvectl query example.com

# getent는 glibc name service 경로를 타므로 실제 앱 동작에 가깝다
getent hosts example.com

핵심 옵션/패턴

  • +short: 결과를 짧게 출력해 스크립트 처리에 좋다.
  • @DNS서버IP: 어떤 DNS 서버에 질의할지 강제로 지정한다.
  • +trace: 위임 체인 전체를 따라가서 어느 구간에서 깨지는지 찾는다.
  • +time=2 +tries=1: 느린 환경에서 타임아웃 기준을 줄여 빠르게 재시도한다.
  • dig +nocmd +noall +answer: 답변 섹션만 출력해 로그 노이즈를 줄인다.

명령 출력 예시

$ dig example.com A +short
93.184.216.34

$ dig @8.8.8.8 example.com A +short
93.184.216.34

$ dig @10.0.0.53 example.com A +short
# 

$ resolvectl query example.com
example.com: 93.184.216.34                 -- link: eth0
             (example.com)

-- Information acquired via protocol DNS in 12.3ms.
-- Data is authenticated: no

자주 하는 실수

  • 브라우저 캐시 문제를 DNS 장애로 오인한다.
    • 서버에서 dig/getent로 먼저 재현해야 판단이 정확하다.
  • A 레코드만 보고 정상이라고 결론낸다.
    • 실제 서비스는 CNAME, AAAA, TXT(SPF), MX 등 다른 레코드 영향도 크다.
  • 로컬 PC 결과만 보고 서버도 같을 거라고 가정한다.
    • 서버 resolver 설정, VPC DNS, 사내 DNS 포워더가 다르면 결과가 달라진다.
  • +trace 결과를 끝까지 읽지 않고 중간에서 멈춘다.
    • delegation 끊김은 마지막 권한 구간에서 드러나는 경우가 많다.

검증 방법

# 1) 서버가 쓰는 DNS 서버 확인
resolvectl status | sed -n '/DNS Servers/,+2p'

# 2) 공용 DNS와 사내 DNS 결과 비교
dig @8.8.8.8 myservice.example.com A +short
dig @1.1.1.1 myservice.example.com A +short
dig @10.0.0.53 myservice.example.com A +short

# 3) 애플리케이션 관점 확인
getent hosts myservice.example.com

# 4) IPv6 영향 확인
dig myservice.example.com AAAA +short

운영 팁

장애 대응 때는 조회 결과를 타임스탬프와 함께 남기는 습관이 좋습니다. 같은 도메인이라도 전파 구간에 따라 분 단위로 값이 바뀔 수 있어서, 나중에 원인 분석할 때 증거가 됩니다. 팀 내에서 공용 DNS 2개와 사내 DNS 1개를 고정해 비교하는 플레이북을 만들어두면 대응 속도가 눈에 띄게 빨라집니다.

출처

  • ISC BIND 9 Administrator Reference Manual
  • Ubuntu Server Guide
  • Cloudflare Learning Center
  • Google Public DNS Documentation