리눅스 dig 명령어 사용법 - DNS 조회와 전파 확인 실전 예제

이 명령어를 언제 쓰는가

"사이트가 안 열린다"는 신고를 받으면 가장 먼저 확인할 것은 DNS다. 도메인이 어떤 IP로 풀리는지, 그 답이 어느 네임서버에서 온 것인지, TTL이 얼마나 남았는지를 봐야 서버 문제인지 DNS 문제인지 갈린다. dig는 그 답을 DNS 응답 원본 그대로 보여준다.

A 레코드를 바꿨는데 아직 옛 IP로 간다거나, 메일이 안 들어온다거나, 인증서 발급용 TXT 레코드가 반영됐는지 확인할 때도 dig다. ping이나 브라우저는 OS 캐시와 hosts 파일을 거치기 때문에 진짜 DNS 상태를 못 보여준다. dig는 지정한 리졸버에 직접 물어본다.

Ubuntu/Debian은 dnsutils, RHEL/Rocky는 bind-utils 패키지에 들어 있다. 최소 설치 서버에는 없는 경우가 많으니 설치부터 해야 할 수도 있다.

기본 형식

dig [@네임서버] 도메인 [레코드타입] [+옵션]

@네임서버 — 물어볼 리졸버. 생략하면 /etc/resolv.conf의 첫 번째 서버에 묻는다. @8.8.8.8, @1.1.1.1 처럼 지정하면 로컬 캐시를 우회한다.
레코드타입 — A, AAAA, MX, TXT, NS, CNAME, SOA, PTR. 생략하면 A다.
+옵션 — 출력 형식과 조회 방식을 바꾼다. 하이픈이 아니라 플러스로 시작하는 것이 dig의 특징이다.

자주 쓰는 옵션

옵션	의미	예시
`+short`	결과값만 한 줄씩. 스크립트에 쓰기 좋다	`dig +short devin.kr`
`+noall +answer`	ANSWER 섹션만. TTL까지 같이 본다	`dig +noall +answer devin.kr`
`+trace`	루트부터 위임을 따라가며 실제 권한 서버를 찾는다	`dig +trace devin.kr`
`-x`	역방향 조회(IP에서 이름)	`dig -x 8.8.8.8`
`+norecurse`	재귀 조회 금지. 캐시에 있는지만 확인	`dig +norecurse @8.8.8.8 devin.kr`
`ANY`	모든 레코드 요청(요즘 대부분 거부되거나 축약됨)	`dig devin.kr ANY`
`+tcp`	UDP 대신 TCP로 질의	`dig +tcp devin.kr`
`+time=2 +tries=1`	타임아웃 2초, 재시도 1회. 죽은 DNS를 빨리 포기	`dig +time=2 +tries=1 devin.kr`

실전 예제

1. 도메인이 어떤 IP로 풀리는지만 빠르게 본다. 배포 스크립트나 헬스체크에 넣기 좋은 형태다.

dig +short devin.kr A

182.222.121.235

2. TTL을 확인한다. IP를 바꾼 뒤 "언제쯤 전파되나"의 답은 TTL에 있다. 남은 초가 줄어드는 값이므로, 이 값만큼 기다리면 캐시가 만료된다.

dig +noall +answer devin.kr

devin.kr.		21	IN	A	182.222.121.235

세 번째 칸의 21이 남은 TTL(초)이다. 레코드 변경 전날에 TTL을 300초 정도로 낮춰두면 전환이 훨씬 매끄럽다.

3. 권한 네임서버에 직접 물어 "내 변경이 반영됐는지" 확인한다. 캐시 리졸버는 옛 값을 들고 있을 수 있으므로, 원본을 봐야 한다.

dig +short devin.kr NS
dig @ns1.hosting.co.kr devin.kr A +noall +answer

권한 서버에 새 IP가 있는데 @8.8.8.8에는 옛 IP가 나오면 설정은 끝났고 캐시 만료만 남은 상태다. 권한 서버조차 옛 IP면 설정이 안 된 것이다.

4. 메일이 안 들어올 때 MX와 SPF를 본다.

dig +short google.com MX

10 smtp.google.com.

dig +short devin.kr TXT | grep spf

5. 위임 경로가 어디서 끊겼는지 추적한다. 도메인을 새로 등록했거나 네임서버를 옮긴 직후에 쓴다.

dig +trace devin.kr A

루트(.) → kr. → 도메인의 네임서버 순으로 응답이 찍힌다. 중간에서 멈추거나 예상과 다른 네임서버가 나오면 등록기관(레지스트라)에 설정한 NS가 잘못된 것이다.

6. 리버스 DNS(PTR)를 확인한다. 메일 서버를 직접 운영하면 PTR이 없으면 대부분 스팸 처리된다.

dig -x 8.8.8.8 +short

dns.google.

함정과 주의점

dig는 /etc/hosts를 보지 않는다. 이것이 장점이자 함정이다. 애플리케이션은 hosts에 적힌 IP로 붙는데 dig는 전혀 다른 IP를 보여줄 수 있다. "dig는 맞는데 접속은 다른 데로 간다"면 /etc/hosts와 /etc/nsswitch.conf를 확인한다. 반대로 애플리케이션이 실제로 무엇으로 푸는지 보려면 getent hosts 도메인을 쓴다.

systemd-resolved 환경에서는 캐시를 두 번 본다. Ubuntu 18.04 이후 /etc/resolv.conf가 127.0.0.53을 가리키면 dig는 로컬 스텁 리졸버에 묻는 것이고, 그 앞단 캐시가 낀 상태다. 진짜 상태를 보려면 dig @1.1.1.1처럼 외부 리졸버를 직접 지정하고, 캐시를 비우려면 sudo resolvectl flush-caches를 쓴다.

+short는 실패도 조용히 넘긴다. 도메인이 없어도 아무것도 출력하지 않고 종료 코드는 0이다. 스크립트에서 결과가 비었는지 반드시 확인해야 한다. 실패 원인을 알려면 +short를 빼고 헤더의 status:를 본다. NXDOMAIN은 도메인 없음, SERVFAIL은 네임서버 장애나 DNSSEC 검증 실패, REFUSED는 질의 거부다.

ANY는 이제 믿을 수 없다. DNS 증폭 공격 때문에 대부분의 권한 서버가 ANY 질의에 축약 응답만 주거나 거부한다. 레코드를 훑고 싶으면 타입별로 각각 조회한다.