LETO

DNS 조회 도구 사용법 (dig, nslookup)

dig로 특정 네임서버에 직접 질의해 설정 오류와 캐시 문제를 구분하는 방법입니다. 기본 문법, +short 와 +trace, ANSWER와 AUTHORITY 섹션 읽기, TTL 해석, nslookup과 Windows 환경, 캐시 비우기까지 실제 명령으로 정리했습니다.

작성

DNS 문제를 혼자 좁히는 가장 빠른 방법은 dig 로 권한 네임서버에 직접 질의해 보는 것입니다. 일반 조회는 중간 리졸버의 캐시를 거친 답이지만, 권한 네임서버에 직접 물으면 지금 존에 저장된 값을 그대로 확인할 수 있습니다. 이 두 결과를 비교하면 설정이 잘못된 것인지 캐시가 남은 것인지 바로 구분됩니다.

dig 는 macOS 와 대부분의 리눅스에 포함되어 있고, 리눅스 배포판에서는 bind-utils 나 dnsutils 패키지로 설치합니다. Windows 는 기본으로 nslookup 이 있고, PowerShell 에서는 Resolve-DnsName 을 쓸 수 있습니다.

dig 기본 문법과 자주 쓰는 옵션

기본 형태는 조회할 이름과 레코드 종류를 나란히 적는 방식입니다.

dig example.co.kr A                  # 이름과 종류
dig A example.co.kr                  # 순서는 바뀌어도 됩니다
dig MX example.co.kr
dig TXT _dmarc.example.co.kr
dig NS example.co.kr
dig CAA example.co.kr
dig -x 203.0.113.10                  # IP 로 이름을 되찾는 역방향 조회

출력이 길어 필요한 부분만 보고 싶을 때 쓰는 옵션이 몇 가지 있습니다.

옵션하는 일쓰는 상황
+short값만 한 줄씩 출력값이 맞는지만 빠르게 확인
+noall +answer응답 섹션만 출력 (TTL 포함)값과 TTL 을 함께 확인
+trace루트부터 단계별로 직접 따라 내려감위임이 어디서 끊겼는지 확인
+norecurse재귀 조회를 요청하지 않음캐시에 들어 있는지만 확인
+dnssec서명 레코드까지 요청DNSSEC 설정 점검
+comments헤더와 플래그, status 표시응답 상태를 봐야 할 때

+trace 는 특히 유용합니다. 리졸버의 캐시를 쓰지 않고 루트 네임서버부터 직접 질의해 내려가므로, 상위 존이 알려 주는 실제 위임을 볼 수 있습니다.

dig NS example.co.kr +trace | tail -20

네임서버를 바꾼 직후라면 이 결과가 새 네임서버를 가리키는지부터 확인합니다. 변경 절차는 네임서버 변경하기에 있습니다.

특정 네임서버에 직접 묻기

이름 앞에 @ 와 서버 주소를 붙이면 그 서버에만 질의합니다. 진단의 핵심 도구입니다.

# 공개 리졸버에 물어보기 (캐시를 거친 답)
dig @8.8.8.8 A www.example.co.kr +short
dig @1.1.1.1 A www.example.co.kr +short

# 권한 네임서버에 직접 물어보기 (존에 저장된 원본)
dig @ns1.example-dns.com A www.example.co.kr +noall +answer
dig @ns2.example-dns.com A www.example.co.kr +noall +answer

# 권한 네임서버 이름을 먼저 알아내기
dig NS example.co.kr +short

네임서버가 두 개 이상이면 모두에 물어봐야 합니다. 한쪽에만 레코드가 반영되어 있으면 사용자 절반은 정상이고 절반은 실패하는, 가장 진단하기 어려운 증상이 됩니다.

응답 읽는 법

옵션 없이 실행하면 전체 응답이 보입니다. 아래는 www 가 CNAME 을 거쳐 A 로 풀리는 전형적인 모습입니다.

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41203
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;www.example.co.kr.             IN      A

;; ANSWER SECTION:
www.example.co.kr.      3600    IN      CNAME   web.example.co.kr.
web.example.co.kr.      300     IN      A       203.0.113.10

;; Query time: 24 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

읽는 순서는 status, 플래그, 섹션입니다.

항목의미
status: NOERROR질의가 정상 처리됨. ANSWER 가 0 이면 이름은 있지만 그 종류의 레코드가 없다는 뜻
status: NXDOMAIN그 이름이 존에 존재하지 않음
status: SERVFAIL네임서버가 답을 만들지 못함. DNSSEC 검증 실패나 상위 위임 오류에서 자주 나옴
status: REFUSED그 서버가 이 도메인에 대한 질의를 받지 않음. 잘못된 서버에 물은 경우
flags 의 aa권한 있는 응답. 권한 네임서버에 직접 물었을 때 붙습니다
flags 의 ra그 서버가 재귀 조회를 해 준다는 뜻. 공개 리졸버에 붙습니다

ANSWER 섹션은 실제 답이고, AUTHORITY 섹션은 "이 질문에 답할 권한은 이쪽에 있다"는 안내입니다. ANSWER 가 비어 있고 AUTHORITY 에 NS 목록만 있다면, 물어본 서버가 답을 가지고 있지 않고 다른 서버를 가리키는 상태입니다. ANSWER 가 비어 있고 AUTHORITY 에 SOA 한 줄만 있다면, 그 존은 찾았지만 해당 종류의 레코드가 없다는 뜻입니다. 레코드를 넣었는데 이 응답이 나오면 이름이나 종류를 잘못 입력했을 가능성이 큽니다.

두 번째 열의 숫자가 TTL입니다. 권한 네임서버에 직접 물으면 존에 설정된 값이 그대로 나오고, 리졸버에 물으면 캐시에 남은 시간이 나오므로 반복 질의할 때마다 숫자가 줄어듭니다. 숫자가 줄어들고 있다면 캐시된 답을 보고 있다는 확실한 신호이고, 그 숫자만큼 기다리면 새 값으로 바뀝니다.

nslookup 과 Windows 환경

Windows 에서 추가 설치 없이 쓸 수 있는 도구는 nslookup 입니다. 문법만 다르고 할 수 있는 일은 비슷합니다.

nslookup example.co.kr
nslookup -type=mx example.co.kr
nslookup -type=txt _dmarc.example.co.kr
nslookup -type=a www.example.co.kr 8.8.8.8
nslookup -type=ns example.co.kr ns1.example-dns.com

마지막 인자가 질의할 서버입니다. dig 의 @서버 와 같은 역할입니다. 출력에 "Non-authoritative answer" 가 보이면 캐시를 거친 답이라는 뜻이고, 권한 네임서버에 직접 물었을 때는 이 문구가 없습니다.

PowerShell 에서는 더 자세한 정보를 주는 명령을 쓸 수 있습니다.

Resolve-DnsName example.co.kr -Type A
Resolve-DnsName www.example.co.kr -Type A -Server 8.8.8.8
Resolve-DnsName example.co.kr -Type MX -Server ns1.example-dns.com
Resolve-DnsName example.co.kr -Type A -DnsOnly -NoHostsFile

nslookup 과 Resolve-DnsName 은 OS 의 hosts 파일을 보지 않는 경우가 있어, ping 은 되는데 조회 결과는 다르게 나올 수 있습니다. 반대로 브라우저에서만 안 열린다면 DNS 가 아니라 브라우저 쪽 캐시나 서버 설정일 수 있습니다.

캐시 비우기

조회는 여러 단계에서 캐시됩니다. 비울 수 있는 것은 내 환경뿐입니다.

환경명령 또는 방법
macOSsudo dscacheutil -flushcache 와 sudo killall -HUP mDNSResponder
Windows명령 프롬프트에서 ipconfig /flushdns, PowerShell 에서 Clear-DnsClientCache
리눅스 (systemd)sudo resolvectl flush-caches
브라우저주소창에 chrome://net-internals/#dns 를 열어 호스트 캐시를 지우거나 브라우저를 완전히 종료 후 재시작

통신사나 회사 네트워크의 리졸버 캐시는 비울 수 없습니다. 그 캐시는 해당 레코드의 TTL 이 지나야 만료됩니다. 그래서 변경 예정일 하루나 이틀 전에 TTL 을 낮춰 두는 준비가 캐시를 비우는 것보다 훨씬 효과적입니다. TTL 기준값은 DNS 레코드 설정에 정리되어 있습니다.

결과로 무엇을 판단할 수 있나

조회 결과해석다음 행동
권한 네임서버는 새 값, 공개 리졸버는 옛 값설정 완료, 캐시 잔존TTL 만큼 기다림
권한 네임서버의 답이 비어 있음레코드가 실제로 없음이름과 종류를 다시 확인해 입력
두 네임서버의 답이 서로 다름한쪽에만 반영됨콘솔에서 존 전체를 다시 확인
+trace 결과가 옛 네임서버를 가리킴위임이 아직 바뀌지 않음등록기관 설정과 반영 시간 확인
도메인 전체가 NXDOMAIN이름 오류, 위임 누락, 또는 만료WHOIS 로 상태 확인
SERVFAIL 이 지속됨DNSSEC 검증 실패나 위임 불일치DS 레코드와 네임서버 응답 점검
DNS 는 정상인데 사이트만 안 열림DNS 문제가 아님서버, 인증서, 방화벽 순서로 확인

도메인의 등록 상태와 네임서버 목록은 WHOIS 조회에서도 확인할 수 있습니다. 변경이 반영되지 않는 경우의 점검 순서는 DNS 변경이 반영되지 않을 때, 사이트 접속 자체가 안 되는 경우는 웹사이트가 열리지 않을 때를 참고하세요.

자주 묻는 질문

진단 목적이라면 dig 가 낫습니다. 응답의 각 섹션과 플래그, TTL을 가공 없이 보여 주므로 설정 문제와 캐시 문제를 구분할 수 있습니다. nslookup 은 Windows 에 기본 포함되어 있어 접근성이 좋지만 출력이 단순하고, Windows 에서는 PowerShell 의 Resolve-DnsName 이 더 자세한 정보를 줍니다.

일반 조회는 중간 리졸버의 캐시를 거친 답이고, 권한 네임서버에 직접 물으면 현재 존에 저장된 값을 그대로 봅니다. 두 결과가 다르면 설정은 맞고 캐시가 아직 남은 상태이므로 기다리면 됩니다. 두 결과가 같게 틀렸다면 설정 자체가 잘못된 것이므로 기다려도 해결되지 않습니다.

정상입니다. 리졸버는 캐시에 남은 시간을 TTL로 돌려주기 때문에 같은 리졸버에 반복 질의하면 숫자가 줄어듭니다. 숫자가 줄어드는 중이라면 캐시된 답을 보고 있다는 뜻이고, 권한 네임서버에 직접 물으면 항상 설정된 원래 값이 나옵니다.

그 이름이 존에 아예 없다는 뜻입니다. 레코드를 분명히 추가했다면 이름을 잘못 입력했는지, 콘솔이 이름 뒤에 도메인을 한 번 더 붙였는지 확인하세요. 도메인 전체가 NXDOMAIN 이면 이름 문제가 아니라 위임이나 만료 문제일 가능성이 큽니다.

내 컴퓨터와 브라우저의 캐시만 비워집니다. 통신사나 회사의 리졸버, 그리고 다른 사용자의 캐시는 그대로이므로 전체 반영 속도는 바뀌지 않습니다. 내 환경에서만 새 값을 먼저 확인하고 싶을 때 쓰는 방법입니다.

관련 가이드