dig 명령어: 리눅스 DNS 조회와 +short, +trace 출력 읽기
도메인에 연결된 DNS 레코드를 DNS 서버의 응답 헤더까지 그대로 확인할 때는 dig 명령어를 사용합니다. AlmaLinux 9와 Debian 12 서버에서 example.com의 레코드를 종류별로 조회하고 묻는 DNS 서버를 바꿔 본 결과, 응답 헤더의 status와 flags만으로 이름이 없는 경우와 DNS 서버가 답을 내지 못한 경우, 레코드를 관리하는 서버가 직접 답한 경우를 구분할 수 있었습니다.
아래 출력은 AlmaLinux 9.8 서버(root 계정)와 Debian 12 서버(일반 계정)에서 실행한 결과입니다. 서버에 설정된 DNS 서버 주소는 예시 값 192.0.2.53으로, dig 버전 번호도 예시 값으로 바꿨습니다.
1️⃣ dig 명령어 사용법
기본 형식은 [dig @서버 이름 종류]이고, 서버와 종류는 생략할 수 있습니다. 공식 매뉴얼 기준으로 서버를 적지 않으면 /etc/resolv.conf에 설정된 DNS 서버에 묻고, 종류를 적지 않으면 A 레코드를 조회합니다.
dig example.com; <<>> DiG 9.16.20-RH <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62441
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 62 IN A 104.20.23.154
example.com. 62 IN A 172.66.147.243
;; Query time: 1 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:18 UTC 2026
;; MSG SIZE rcvd: 72세미콜론으로 시작하는 줄은 설명 줄이고, 세미콜론 없는 줄이 실제로 받은 레코드입니다. 구역마다 확인하는 내용은 아래와 같습니다.
| 출력 | 확인하는 것 |
|---|---|
| ; <<>> DiG 9.16.20-RH <<>> example.com | 실행한 dig 버전과 입력한 인자 |
| ->>HEADER<<- … status: NOERROR, id: 62441 | 응답 코드(status)와 질의 번호(id) |
| flags: qr rd ra | 응답 헤더의 플래그 — 응답한 서버가 재귀 조회를 했는지, 레코드를 관리하는 서버인지 |
| QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 | 구역마다 담긴 레코드 수 |
| OPT PSEUDOSECTION · EDNS … udp: 4096 | EDNS 확장 정보와 UDP로 받을 수 있는 응답 크기(바이트) |
| QUESTION SECTION | 보낸 질문 — 이름, 클래스(IN), 레코드 종류 |
| ANSWER SECTION | 받은 레코드 — 이름, TTL(초), 클래스, 종류, 값 순서 |
| Query time: 1 msec | 응답이 오기까지의 시간 |
| SERVER: 192.0.2.53#53(192.0.2.53) | 응답한 DNS 서버 주소와 포트 번호 |
| WHEN · MSG SIZE rcvd: 72 | 조회 시각과 받은 응답 크기(바이트) |
flags 줄의 qr는 응답, rd는 재귀 조회 요청, ra는 재귀 조회 지원을 의미합니다(RFC 1035). aa 없이 ra만 있어, 이 응답은 레코드를 관리하는 서버가 아니라 재귀 조회를 수행하는 DNS 서버가 보낸 것입니다.
ANSWER 구역의 62는 TTL로, 이 레코드를 캐시에 둘 수 있는 남은 시간(초)입니다. 바로 뒤 같은 이름을 8.8.8.8에 묻자 300이 나와, DNS 서버마다 캐시에 담아 둔 시점에 따라 숫자가 달랐습니다.
같은 조회를 nslookup 명령어로 하면 응답 코드와 TTL이 기본 출력에 나오지 않습니다. 두 명령의 출력에서 달랐던 점은 아래와 같습니다.
| 비교 | dig | nslookup |
|---|---|---|
| 응답 코드 | HEADER 줄의 status에 늘 나옴 | 오류일 때만 server can't find 줄로 나옴 |
| TTL | ANSWER 레코드 줄마다 나옴 | -debug를 붙여야 나옴 |
| 응답한 DNS 서버 | 맨 아래 SERVER 줄 | 맨 위 Server · Address 줄 |
| NXDOMAIN 종료 코드 | 0 | 1 |
설치된 dig 버전은 -v로 확인합니다. AlmaLinux 9 서버는 9.16, Debian 12 서버는 9.18이었습니다.
dig -vDiG 9.16.20-RH2️⃣ dig 레코드 조회
이름 뒤에 레코드 종류를 적으면 그 레코드만 조회합니다. 종류마다 담는 값과 이 글에서 조회한 결과는 아래와 같습니다.
| 종류 | 담는 값 | 조회 결과 |
|---|---|---|
| A | IPv4 주소 | example.com → 104.20.23.154 외 1개 |
| AAAA | IPv6 주소 | example.com → 2606:4700:10::6814:179a 외 1개 |
| MX | 메일 서버와 우선순위 | example.com → 0 . (메일을 받지 않음) |
| NS | 레코드를 관리하는 네임 서버 | example.com → hera · elliott.ns.cloudflare.com. |
| TXT | 정해진 형식 없는 글자 값(SPF 등) | example.com → v=spf1 -all 외 1개 |
| CNAME | 다른 이름의 별칭 | www.github.com → github.com. |
| SOA | 영역의 주 네임 서버와 시간 값 | example.com → elliott.ns.cloudflare.com. … |
| PTR | IP 주소에 연결된 이름(역방향) | -x 8.8.8.8 → dns.google. |
메일 서버는 MX 레코드로 확인합니다. example.com의 MX를 조회하자 ANSWER 구역에 [0 .] 한 줄이 나왔습니다.
dig example.com MX; <<>> DiG 9.16.20-RH <<>> example.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34433
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN MX
;; ANSWER SECTION:
example.com. 300 IN MX 0 .
;; Query time: 5 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:23 UTC 2026
;; MSG SIZE rcvd: 550은 우선순위이고, 메일 서버 이름 자리에 점 하나만 있는 MX는 이 도메인이 메일을 받지 않는다는 Null MX입니다(RFC 7505). 종류를 소문자 mx로 적어도 같은 결과가 나왔습니다.
레코드 줄만 볼 때는 [+noall +answer]를 붙입니다. 공식 매뉴얼 기준으로 +noall은 출력 구역을 모두 끄고, +answer는 ANSWER 구역만 다시 켭니다.
dig example.com NS +noall +answerexample.com. 12192 IN NS hera.ns.cloudflare.com.
example.com. 12192 IN NS elliott.ns.cloudflare.com.example.com의 네임 서버는 둘이었습니다. 이 두 서버가 example.com의 레코드를 직접 관리하는 권한 있는 네임 서버입니다.
dig example.com TXT +noall +answerexample.com. 300 IN TXT "v=spf1 -all"
example.com. 300 IN TXT "_k2n1y4vw3qtb4skdx9e7dxt97qrmmq9"TXT 레코드에는 정해진 형식 없이 글자 값을 넣을 수 있습니다. v=spf1 -all은 이 도메인 이름으로 메일을 보낼 수 있는 서버가 없다는 SPF 값입니다.
dig www.github.com CNAME +noall +answerwww.github.com. 291 IN CNAME github.com.www.github.com은 github.com의 별칭(CNAME)이었습니다. 종류를 적지 않고 같은 이름을 조회하자 CNAME 줄 뒤에 github.com의 A 레코드가 이어서 나왔습니다.
SOA 레코드는 +multiline을 붙이면 숫자마다 이름과 시간이 주석으로 붙어 읽기 쉽습니다.
dig example.com SOA +multiline +noall +answerexample.com. 1765 IN SOA elliott.ns.cloudflare.com. dns.cloudflare.com. (
2418004112 ; serial
10000 ; refresh (2 hours 46 minutes 40 seconds)
2400 ; retry (40 minutes)
604800 ; expire (1 week)
1800 ; minimum (30 minutes)
)serial은 레코드를 고칠 때마다 올라가는 일련번호이고, refresh와 retry, expire는 보조 네임 서버가 주 서버와 레코드를 맞출 때 쓰는 시간 값입니다. minimum은 없는 이름이나 레코드에 대한 응답을 캐시에 두는 시간입니다.
값만 필요할 때는 +short를 붙입니다. A 레코드는 IP 주소만, MX는 우선순위와 메일 서버 이름만 남았습니다.
dig +short example.com172.66.147.243
104.20.23.154dig google.com MX +short10 smtp.google.com.[+noall +answer] 뒤에 +stats를 더하면 조회 시간과 응답한 서버 줄이 함께 나옵니다. Debian 12 서버의 dig 9.18에서는 SERVER 줄 끝에 질의를 보낸 방식 (UDP)가 붙었고, AlmaLinux 9 서버의 dig 9.16에는 이 표기가 없었습니다.
dig example.com +noall +answer +statsexample.com. 235 IN A 172.66.147.243
example.com. 235 IN A 104.20.23.154
;; Query time: 0 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Thu Oct 29 00:10:26 UTC 2026
;; MSG SIZE rcvd: 723️⃣ dig DNS 서버 지정과 역방향 조회
이름 앞에 @와 DNS 서버를 적으면 서버에 설정된 DNS 서버 대신 그 서버에 묻습니다. 8.8.8.8에 묻자 SERVER 줄이 8.8.8.8로 바뀌고, flags에 ad가 더해졌습니다.
dig @8.8.8.8 example.com; <<>> DiG 9.16.20-RH <<>> @8.8.8.8 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61431
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 300 IN A 104.20.23.154
example.com. 300 IN A 172.66.147.243
;; Query time: 30 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 29 00:09:29 UTC 2026
;; MSG SIZE rcvd: 72ad는 응답한 서버가 DNSSEC 서명을 검증해 응답의 레코드를 믿을 수 있다고 판단했다는 플래그입니다(RFC 4035). 서버에 설정된 DNS 서버의 응답에는 ad가 없었습니다.
NS 조회에서 나온 네임 서버를 @ 뒤에 적으면 example.com의 레코드를 관리하는 서버에 직접 묻게 됩니다.
dig @elliott.ns.cloudflare.com example.com; <<>> DiG 9.16.20-RH <<>> @elliott.ns.cloudflare.com example.com
; (6 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61828
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 300 IN A 172.66.147.243
example.com. 300 IN A 104.20.23.154
;; Query time: 4 msec
;; SERVER: 2606:4700:58::a29f:2ce4#53(2606:4700:58::a29f:2ce4)
;; WHEN: Thu Oct 29 00:09:29 UTC 2026
;; MSG SIZE rcvd: 72이번에는 flags에 aa가 나와, 권한 있는 네임 서버가 직접 답했다는 것을 확인할 수 있었습니다. 이 서버는 다른 서버를 거쳐 이름을 찾는 재귀 조회를 지원하지 않아 ra가 빠졌고, [WARNING: recursion requested but not available] 줄이 붙었습니다.
(6 servers found)는 네임 서버 이름이 IPv4 주소 셋과 IPv6 주소 셋으로 풀렸다는 뜻입니다. SERVER 줄에는 그중 답을 보낸 IPv6 주소가 나왔습니다.
-x 뒤에 IP 주소를 적으면 PTR 레코드를 조회해 그 주소에 연결된 이름을 찾습니다.
dig -x 8.8.8.8 +noall +answer8.8.8.8.in-addr.arpa. 300 IN PTR dns.google.dig는 8.8.8.8을 거꾸로 적고 in-addr.arpa를 붙인 이름을 조회했고, 그 PTR 값 dns.google.이 8.8.8.8의 이름이었습니다.
4️⃣ dig +trace 위임 경로
+trace를 붙이면 dig가 루트 네임 서버부터 차례로 물어, 이름이 어느 서버로 넘겨졌는지 단계마다 출력합니다. 공식 매뉴얼 기준으로 +trace는 DNSSEC 서명 줄도 함께 요청하므로, 위임 경로만 보려고 +nodnssec를 같이 붙였습니다.
dig +trace +nodnssec example.com; <<>> DiG 9.16.20-RH <<>> +trace +nodnssec example.com
;; global options: +cmd
. 86333 IN NS j.root-servers.net.
. 86333 IN NS g.root-servers.net.
. 86333 IN NS b.root-servers.net.
. 86333 IN NS e.root-servers.net.
. 86333 IN NS k.root-servers.net.
. 86333 IN NS f.root-servers.net.
. 86333 IN NS l.root-servers.net.
. 86333 IN NS m.root-servers.net.
. 86333 IN NS h.root-servers.net.
. 86333 IN NS c.root-servers.net.
. 86333 IN NS d.root-servers.net.
. 86333 IN NS a.root-servers.net.
. 86333 IN NS i.root-servers.net.
;; Received 239 bytes from 192.0.2.53#53(192.0.2.53) in 1 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 836 bytes from 2001:7fd::1#53(k.root-servers.net) in 30 ms
example.com. 172800 IN NS hera.ns.cloudflare.com.
example.com. 172800 IN NS elliott.ns.cloudflare.com.
;; Received 359 bytes from 2001:503:d414::30#53(f.gtld-servers.net) in 66 ms
example.com. 300 IN A 104.20.23.154
example.com. 300 IN A 172.66.147.243
;; Received 72 bytes from 108.162.195.228#53(elliott.ns.cloudflare.com) in 3 ms단계마다 마지막 [Received … from] 줄에 그 응답을 보낸 서버가 나옵니다. 네 단계에서 물은 서버와 받은 것은 아래와 같습니다.
| 단계 | 물은 서버 | 받은 것 |
|---|---|---|
| 1 | 서버에 설정된 DNS 서버(192.0.2.53) | 루트(.) 네임 서버 13개 |
| 2 | k.root-servers.net | .com 네임 서버 13개(gtld-servers.net) |
| 3 | f.gtld-servers.net | example.com 네임 서버 2개 |
| 4 | elliott.ns.cloudflare.com | example.com의 A 레코드 2개 |
+trace 출력은 등기 우편의 배송 조회 기록과 같습니다.
마지막 단계의 A 레코드는 example.com의 네임 서버가 직접 보낸 값이라 캐시를 거치지 않은 지금 값입니다. 네임 서버를 바꾼 직후에는 3단계에서 .com 서버가 새 네임 서버를 응답하는지부터 확인합니다.
5️⃣ dig 응답 오류와 옵션
🔲 응답 오류
없는 이름을 조회하면 status가 NXDOMAIN으로 나옵니다. .invalid는 실제로 쓰지 않도록 예약된 최상위 도메인이라 이 응답을 확인하는 데 사용했습니다.
dig example.invalid; <<>> DiG 9.16.20-RH <<>> example.invalid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23779
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.invalid. IN A
;; AUTHORITY SECTION:
invalid. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800
;; Query time: 1 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:33 UTC 2026
;; MSG SIZE rcvd: 96ANSWER는 0이었고, AUTHORITY 구역에는 그 영역의 SOA 레코드가 들어 있었습니다. SOA의 마지막 숫자 10800은 이 응답을 캐시에 둘 수 있는 시간(초)입니다.
no-such-host.example.com은 NXDOMAIN 대신 status가 NOERROR, ANSWER가 0으로 끝났습니다. 오류 코드 없이 레코드만 비어 있는 응답이라, status와 ANSWER 수를 함께 확인합니다.
dig no-such-host.example.com; <<>> DiG 9.16.20-RH <<>> no-such-host.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31671
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;no-such-host.example.com. IN A
;; AUTHORITY SECTION:
example.com. 1800 IN SOA elliott.ns.cloudflare.com. dns.cloudflare.com. 2418004112 10000 2400 604800 1800
;; Query time: 7 msec
;; SERVER: 192.0.2.53#53(192.0.2.53)
;; WHEN: Thu Oct 29 00:09:33 UTC 2026
;; MSG SIZE rcvd: 115SERVFAIL은 DNS 서버가 답을 만들지 못했다는 응답 코드입니다(RFC 1035). DNSSEC 검증 실패를 시험하는 공개 도메인 dnssec-failed.org를 8.8.8.8에 묻자, SERVFAIL과 함께 EDE 줄이 나왔습니다.
dig @8.8.8.8 dnssec-failed.org; <<>> DiG 9.16.20-RH <<>> @8.8.8.8 dnssec-failed.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57521
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of dnssec-failed.org)
;; QUESTION SECTION:
;dnssec-failed.org. IN A
;; Query time: 333 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct 29 00:09:41 UTC 2026
;; MSG SIZE rcvd: 97EDE는 오류 까닭을 덧붙이는 확장 오류 코드(RFC 8914)입니다. 9 (DNSKEY Missing)은 상위 영역의 DS 레코드와 맞는 DNSKEY를 찾지 못했다는 뜻으로, 8.8.8.8은 서명을 확인할 수 없는 이름에 주소 대신 SERVFAIL을 돌려보냈습니다.
DNS 서버가 응답하지 않으면 status 줄 없이 [connection timed out; no servers could be reached]로 끝납니다. 문서 예시용 주소 192.0.2.1에 [+timeout=2 +tries=1]로 묻자 2초 뒤에 이 줄이 나왔습니다.
dig @192.0.2.1 example.com +timeout=2 +tries=1; <<>> DiG 9.16.20-RH <<>> @192.0.2.1 example.com +timeout=2 +tries=1
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached옵션 없이 같은 주소에 묻자 15초 뒤에 같은 줄이 나왔습니다. 공식 매뉴얼의 기본값이 응답 하나에 5초, 시도 3번이기 때문입니다. Debian 12 서버의 dig 9.18에서는 [communications error to 192.0.2.1#53: timed out] 줄이 먼저 나오고, 마지막 줄은 [no servers could be reached]였습니다.
스크립트에서 종료 코드로 결과를 나눌 때는 NXDOMAIN도 0이라는 점을 고려합니다. example.invalid를 +short로 조회한 뒤 종료 코드를 출력하자 빈 결과와 함께 0이 나왔고, 응답이 없던 192.0.2.1 조회는 9였습니다.
dig +short example.invalid; echo $?0응답 오류마다 출력에서 확인할 줄과 다음에 확인할 것은 아래와 같습니다.
| 출력 | 뜻 | 다음에 확인할 것 |
|---|---|---|
| status: NXDOMAIN | 그 이름이 없음 | 도메인 철자와 등록 상태, +trace로 위임 경로 |
| status: NOERROR · ANSWER: 0 | 그 종류의 레코드가 응답에 없음 | 레코드 종류와 네임 서버의 레코드 설정 |
| status: SERVFAIL | DNS 서버가 답을 만들지 못함 | EDE 줄, 다른 DNS 서버(@8.8.8.8 · @1.1.1.1)의 응답 |
| connection timed out | DNS 서버가 응답하지 않음 | DNS 서버 주소와 53번 포트를 막는 방화벽 |
🔲 dig 명령어 옵션
📌 주요 옵션: 이 글에서 실행한 결과
| 옵션 | 하는 일 | 이 글에서 본 결과 | |
|---|---|---|---|
| @서버 | 서버에 설정된 DNS 서버 대신 지정한 서버에 물음 | @8.8.8.8에 SERVER 줄이 8.8.8.8로 바뀌고 flags에 ad가 더해짐, 권한 있는 네임 서버에 묻자 aa | |
| 종류 | 이름 뒤에 적은 레코드 종류만 조회 | example.com MX에 [0 .] 한 줄, 소문자 mx도 같은 결과 | |
| -x 주소 | IP 주소의 PTR 레코드를 조회 | -x 8.8.8.8에 dns.google. | |
| -v | 버전을 출력 | AlmaLinux 9 서버는 9.16, Debian 12 서버는 9.18 | |
| -r | 홈 폴더의 .digrc를 읽지 않음 | .digrc에 +short를 넣어도 -r을 붙이자 레코드 줄이 그대로 나옴 | |
| +short | 레코드 값만 출력 | A는 IP 주소 둘, google.com MX는 10 smtp.google.com. | |
| +noall +answer | 출력 구역을 모두 끄고 ANSWER 구역만 다시 켬 | example.com NS에 네임 서버 줄 둘만 남음 | |
| +multiline | SOA 같은 긴 레코드를 여러 줄로 나눠 주석을 붙임 | serial, refresh 같은 이름과 시간이 숫자마다 주석으로 붙음 | |
| +stats | 조회 시간과 응답한 서버 줄을 함께 출력 | Debian 12 서버의 dig 9.18에서 SERVER 줄 끝에 (UDP) | |
| +trace | 루트 네임 서버부터 차례로 물어 위임 경로를 출력 | 네 단계마다 마지막 [Received … from] 줄에 응답한 서버가 나옴 | |
| +nodnssec | DNSSEC 서명 레코드를 요청하지 않음 | +trace와 함께 붙여 위임 경로만 남김 | |
| +timeout=초 | 응답 하나를 기다리는 시간, 기본 5초 | 192.0.2.1에 +timeout=2 +tries=1로 묻자 2초 뒤 [connection timed out], 옵션 없이는 15초 | |
| +tries=횟수 | 질의를 보내는 횟수, 기본 3번 | +timeout=2와 함께 1로 두자 한 번만 묻고 2초 뒤 끝남 | |
| +tcp | 질의를 UDP 대신 TCP로 보냄 | Debian 12 서버의 dig 9.18에서 SERVER 줄 끝이 (UDP)에서 (TCP)로 바뀌고 레코드는 같음 |
📎 그 밖의 옵션: 공식 매뉴얼 기준
| 옵션 | 하는 일 | |
|---|---|---|
| -4 | IPv4로만 질의 | |
| -6 | IPv6로만 질의 | |
| -t 종류 | 조회할 레코드 종류를 지정 | |
| -q 이름 | 조회할 이름을 지정, 다른 인자와 헷갈리지 않게 할 때 | |
| -p 포트 | 53번 대신 지정한 포트로 질의 | |
| -b 주소 | 질의를 보내는 출발 IP 주소를 지정 | |
| -f 파일 | 파일에 줄마다 적은 조회를 차례로 실행 | |
| +norecurse | 재귀 조회 요청(RD)을 끄고 질의 | |
| +dnssec | DNSSEC 레코드를 함께 요청 | |
| +nssearch | 권한 있는 네임 서버를 찾아 서버마다 가진 SOA 레코드를 출력 | |
| +nocmd | 맨 앞의 버전과 옵션 설명 줄을 빼고 출력 | |
| +nocomments | 응답 헤더와 구역 이름 같은 설명 줄을 빼고 출력 | |
| +ttlunits | TTL을 s, m, h, d, w 단위로 출력 | |
| +retry=횟수 | 첫 질의를 빼고 다시 보낼 횟수, 기본 2 |
🔲 dig 명령어 시뮬레이터
아래 시뮬레이터에서 레코드 종류와 DNS 서버, 출력 옵션을 바꿔 가며 dig를 직접 입력해 볼 수 있습니다.
🔢 FAQ & 추천 콘텐츠
ℹ️ 제휴 안내
본 사이트의 콘텐츠에는 제휴 링크가 포함되어 있습니다. 방문자가 이 링크를 통해 상품 또는 서비스를 구매하면 본 사이트는 판매처로부터 수수료를 지급받습니다. 이 과정에서 구매자가 지불하는 금액(이벤트 할인 시 금액이 내려갑니다↓)은 오르지 않습니다. 게시된 가격·할인·재고 정보는 작성 시점 기준이며 실제와 다를 수 있으므로, 구매 전 판매처에서 최종 확인하시기 바랍니다. 상품 선정과 평가는 자체 기준에 따라 작성되며, 수수료 지급 여부가 소개 순서나 평가 내용에 영향을 주지 않습니다.