발굴 매뉴얼 페이지를 보면 다음과 같은 결과가 나타납니다.
+[no]trace
Toggle tracing of the delegation path from the root name servers for the name
being looked up. Tracing is disabled by default. When tracing is enabled, dig
makes iterative queries to resolve the name being looked up. It will follow
referrals from the root servers, showing the answer from each server that was
used to resolve the lookup.
실제로 어떻게 작동합니까? dig기능적으로 동등한 일련의 명령 (+ 추적없이)은 무엇입니까?
답변:
dig +trace 이름 서버 인 척하여 작동하며 트리의 루트에서 시작하여 반복 조회를 따라 반복 쿼리를 사용하여 네임 스페이스 트리를 처리합니다.
가장 먼저하는 일은 일반 시스템 DNS 서버에 "."에 대한 NS 레코드를 요청하는 것입니다.
루트 이름 서버의 현재 목록이 될 응답을 얻은 후 하나를 선택한 다음 추가 레코드 섹션에서 처음 얻지 못한 경우 해당 이름에 대한 A 레코드를 요청합니다. 다음 쿼리를 보낼 IP 주소 IP 주소가 192.5.5.241 인 f.root-servers.net을 선택한다고 가정 해 봅시다.
이제 dig +trace www.google.co.uk.해결 경로를 추적 할 도메인 이름을 가진 명령으로 사용하겠습니다 .
다음 비하인드 쿼리는 다음과 같습니다.
$ dig +norecurse @192.5.5.241 www.google.co.uk
; <<>> DiG 9.9.4 <<>> +norecurse @192.5.5.241 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8962
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 15
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.co.uk. IN A
;; AUTHORITY SECTION:
uk. 172800 IN NS ns5.nic.uk.
uk. 172800 IN NS ns6.nic.uk.
uk. 172800 IN NS ns4.nic.uk.
uk. 172800 IN NS nsc.nic.uk.
uk. 172800 IN NS ns2.nic.uk.
uk. 172800 IN NS ns3.nic.uk.
uk. 172800 IN NS nsd.nic.uk.
uk. 172800 IN NS nsa.nic.uk.
uk. 172800 IN NS ns7.nic.uk.
uk. 172800 IN NS nsb.nic.uk.
uk. 172800 IN NS ns1.nic.uk.
;; ADDITIONAL SECTION:
ns1.nic.uk. 172800 IN A 195.66.240.130
ns2.nic.uk. 172800 IN A 217.79.164.131
ns3.nic.uk. 172800 IN A 213.219.13.131
ns4.nic.uk. 172800 IN A 194.83.244.131
ns5.nic.uk. 172800 IN A 213.246.167.131
ns6.nic.uk. 172800 IN A 213.248.254.130
ns7.nic.uk. 172800 IN A 212.121.40.130
nsa.nic.uk. 172800 IN A 156.154.100.3
nsb.nic.uk. 172800 IN A 156.154.101.3
nsc.nic.uk. 172800 IN A 156.154.102.3
nsd.nic.uk. 172800 IN A 156.154.103.3
ns1.nic.uk. 172800 IN AAAA 2a01:40:1001:35::2
ns4.nic.uk. 172800 IN AAAA 2001:630:181:35::83
nsa.nic.uk. 172800 IN AAAA 2001:502:ad09::3
;; Query time: 45 msec
;; SERVER: 192.5.5.241#53(192.5.5.241)
;; WHEN: Tue Feb 11 19:19:14 MST 2014
;; MSG SIZE rcvd: 507
와우, 이제 우리는 네임 서버가 uk있고 그것이 루트 서버가 아는 유일한 것임을 알고 있습니다. 우리는 재귀를 요청하지 않았기 때문에 추천입니다 ( +norecurse끄기).
헹구고 반복합니다. 이번에는 uk네임 서버 중 하나를 골라 같은 질문을한다 .
$ dig +norecurse @195.66.240.130 www.google.co.uk
; <<>> DiG 9.9.4 <<>> +norecurse @195.66.240.130 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 618
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.google.co.uk. IN A
;; AUTHORITY SECTION:
google.co.uk. 172800 IN NS ns1.google.com.
google.co.uk. 172800 IN NS ns3.google.com.
google.co.uk. 172800 IN NS ns2.google.com.
google.co.uk. 172800 IN NS ns4.google.com.
;; Query time: 354 msec
;; SERVER: 195.66.240.130#53(195.66.240.130)
;; WHEN: Tue Feb 11 19:22:47 MST 2014
;; MSG SIZE rcvd: 127
굉장히, 우리는 uk최상위 네임 서버가 호출 된 존이 있다는 것을 알고 google.co.uk네임 서버에게 질문을하라고 알려줍니다. 이것은 또 다른 추천입니다.
헹구고 반복하십시오.
그러나 이번에는 응답의 추가 레코드 섹션에 A 레코드가 없으므로 ns2.google.com과 같이 하나를 선택하고 주소를 찾아야합니다. 우리는 다시 시작 ns2.google.com의 IP 주소를 찾기 위해 나무 아래로 (다시 루트) 쿼리 및 추적을. 간결하게하기 위해이 부분을 건너 뛰지 만 IP의 길이는 216.239.34.10이라는 것을 알게됩니다.
따라서 다음 쿼리는 다음과 같습니다.
$ dig +norecurse @216.239.34.10 www.google.co.uk
; <<>> DiG 9.9.4 <<>> +norecurse @216.239.34.10 www.google.co.uk
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33404
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.google.co.uk. IN A
;; ANSWER SECTION:
www.google.co.uk. 300 IN A 74.125.225.216
www.google.co.uk. 300 IN A 74.125.225.223
www.google.co.uk. 300 IN A 74.125.225.215
;; Query time: 207 msec
;; SERVER: 216.239.34.10#53(216.239.34.10)
;; WHEN: Tue Feb 11 19:26:43 MST 2014
;; MSG SIZE rcvd: 82
그리고 우리는 끝났습니다! (마침내) 우리가 끝났다는 것을 어떻게 알 수 있습니까? www.google.co.uk의 A 레코드 인 검색어에 대한 답변을 받았습니다. 더 이상 추천이 아니기 때문에 aa비트가 마지막 응답에 설정되어 있음을 의미하며 이는 쿼리에 대한 정식 답변 입니다.
그래서 당신이 사용할 때 각 단계에서 일어나는 일 dig +trace입니다.
DNSSEC 인식 버전의 dig +dnssec가 있고 명령에 추가 하면 더 많은 레코드가 표시 될 수 있습니다. 그 여분의 기록은 독자를위한 연습으로 남지만 ... dig +sigchase작동 방식에 들어갑니다.
당신이 찾고 있다고 말할 수 있습니다
www.domain.co.uk
DNS는 TLD (도메인 이름의 마지막 부분)에 대해 권한이있는 서버를 알고있는 루트 서버로 시작하는 계층입니다. 따라서
dig subdomain.domain.co.uk
단계별는 다음과 같습니다.
dig SOA @g.root-servers.net uk
(즉, 루트 서버 중 하나에 쿼리하여 .uk의 권한을 가진 사람을 찾습니다)
이것은 일련의 권위있는 영국 서버로 응답하므로 co.uk를 가진 사람에게 문의하십시오.
dig SOA @ns6.nic.uk co.uk
그리고 우리는 SOA (권한)가 같은 서버에 있다고 들었습니다.
따라서 ns1.nic.uk를 쿼리하여 domain.co.uk를 가진 사람을 볼 수 있습니다.
dig SOA @ns1.nic.uk domain.co.uk
다시 돌아와서 도메인 권한은 dns.dns1.de (백업 포함)에 있습니다.
이제 A 레코드를 요청할 수 있습니다.
dig A @dns.dns2.de www.domain.co.uk
;; QUESTION SECTION:
;www.domain.co.uk. IN A
;; ANSWER SECTION:
www.domain.co.uk. 86400 IN CNAME domain.co.uk.
domain.co.uk. 86400 IN A 95.130.17.36
A모든 레코드를 요구합니다 . SOA쿼리로의 마술 전환은 없습니다 . (해결 프록시가 언제 전환해야하는지 알 수 없기 때문에 존재할 수 없었습니다.) 질문에 도메인 이름을 마술로 수정 한 것도 없습니다. 그것은의 www.domain.co.uk.를 통해 방법을 모두. 이는 쿼리 한 모든 컨텐츠 서버가 완전한 답변을 제공 할 수 있기 때문에 기억 해야합니다 .