답변:
@구문을 사용하여 특정 서버에서 도메인을 조회 할 수 있습니다 . DNS 서버가 해당 도메인에 대해 권한이 있으면 응답이 캐시 된 결과가 아닙니다.
dig @ns1.example.com example.com
NS도메인 에 대한 레코드를 요청하여 신뢰할 수있는 서버를 찾을 수 있습니다 .
dig example.com NS
+norecurse권장됩니다. +recurse기본적으로 설정되어 있으면 DNS 서버가 질문을 완전히 해석하는 방식이 때때로 변경됩니다.
+trace캐싱 이 있지만 부모를 찾을 수 있습니다 . Andrew B는 네임 서버가 변경되기를 기다릴 때 캐싱이 어떻게 속일 수 있는지에 대한 좋은 설명을 작성했습니다.
dig @8.8.8.8 example.com. 레코드가 훨씬 빠르게 나타납니다.
DNS 프로토콜에는 이름 서버가 캐시를 사용하지 않고 응답하도록하는 메커니즘이 없습니다. 발굴 자체는 네임 서버가 아니며 표준 DNS 요청을 사용하여 구성한 네임 서버로 쿼리를 전달하는 도구입니다. DNS 에는 서버에 재귀를 사용하지 않도록 지시하는 방법 이 포함되어 있지만 원하는 것은 아닙니다. 신뢰할 수있는 네임 서버를 직접 쿼리하려는 경우에만 유용합니다.
네임 서버가 캐시에서 응답 하지 못하게 하려면 네임 서버 의 구성 을 변경해야만 할 수 있지만 네임 서버를 제어하지 않으면 불가능합니다.
그러나 구성된 네임 서버 를 무시 하고 루트 서버로 돌아가는 자체 재귀 요청을 수행 할 수 있습니다. 이렇게하려면 +trace옵션을 사용하십시오 .
dig example.com +trace
실제로 이것은 로컬 캐싱 확인자가 아닌 권한있는 서버 만 쿼리하므로 해당 서버가 내부 캐싱을 사용하더라도 결과가 오래되지 않습니다. 사용의 추가 이점은 +trace경로를 따라 작성된 모든 개별 요청을 볼 수 있다는 것입니다.
+norecurse하면 네임 서버가 캐시 된 정보를 포함하여 보유하고있는 모든 정보를 반환하도록 지시하므로 올바르지 않습니다. +trace재귀 체인을 따라 권위있는 서버까지 계속 작동하기 때문에 작동합니다.
+norecurse하여 문제를 혼동하는 권장 사항 을 제거했습니다 .
내가 얘기 할 때 많은 사람들이 이제까지 포함되지 않습니다주의 여기서 주목해야 할 중요한 무언가가, +trace사용하는 것입니다 +trace수단을 발굴 클라이언트하면 추적 아닌, 설정 (/etc/resolv.conf 파일)에 지정된 DNS 서버를 할 것입니다. 다시 말해, dig 클라이언트는 요청하면 재귀 DNS 서버처럼 작동합니다. 그러나 중요한 것은 캐시가 없다는 것입니다.
자세한 내용-이미 mx사용 dig -t mx example.com하고 있는 레코드를 요청했고 /etc/resolv.conf가 8.8.8.8 인 경우 영역의 TTL 내부에서 작업을 수행하면 캐시 된 결과가 반환됩니다. 어떤 방식 으로든 자신의 영역과 Google에서 어떻게 보이는지 찾고 있다면 영역의 TTL을 위해 Google로 DNS 결과를 중독시킨 것입니다. 짧은 TTL이 있으면 나쁘지 않으며 1 시간이면 버릴 수 있습니다.
따라서 +trace처음으로 Google에 요청하고 캐시 된 항목이없는 경우 WOULD가 표시되는 내용을 확인하는 데 도움이되지만 Google은 모든 사람에게 +trace결과 와 동일한 내용을 알려줄 것이라는 잘못된 아이디어를 제공 할 수 있습니다. TTL이 만료 될 때까지 캐시에서 서비스를 제공하기 때문에 이전에 요청했고 긴 TTL을 보유한 경우에는 그렇지 않습니다 +trace. 그러면 공개 된 것과 동일하게 제공됩니다 .
너무 자세한 IMO를 가질 수 없습니다.
+trace발굴하기 시작 지정된 네임 서버를 사용하여 추적을 (예를 들어, 8.8.8.8 즉, 사용자가 설정 한 거라면) 첫 번째 조회 (루트 영역)에 대한,하지만 그 이후로는 더 쿼리에 대한 반환 된 네임 서버를 사용합니다. 따라서 구성된 네임 서버가 작동하지 않거나 루트 네임 서버에 대한 쿼리에 제대로 응답하지 않으면 위의 설명과 같이 문제가 발생할 수 있습니다.
이 bash는 example.com의 DNS 항목을 첫 번째로 나열된 이름 서버에서 발굴합니다.
dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
다음은 .zshrc (및 .bashrc)의 별칭과 동일합니다.
# e.g. `checkdns google.com`
checkdns () { dig @$(dig @8.8.8.8 $1 ns +short | head -n1) $1 ANY +noall +answer; ping -c1 $1; }
/. 출력 결과는 다음과 같습니다.
☀ checkdns slashdot.org dev
-->Server DNS Query
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.dnsmadeeasy.com. slashdot.org ANY +noall +answer
; (2 servers found)
;; global options: +cmd
slashdot.org. 21600 IN SOA ns0.dnsmadeeasy.com. hostmaster.slashdotmedia.com. 2016045603 14400 600 604800 300
slashdot.org. 86400 IN NS ns3.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns4.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns0.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns2.dnsmadeeasy.com.
slashdot.org. 86400 IN NS ns1.dnsmadeeasy.com.
slashdot.org. 3600 IN MX 10 mx.sourceforge.net.
slashdot.org. 3600 IN TXT "google-site-verification=mwj5KfwLNG8eetH4m5w1VEUAzUlHotrNwnprxNQN5Io"
slashdot.org. 3600 IN TXT "v=spf1 include:servers.mcsv.net ip4:216.34.181.51 ?all"
slashdot.org. 300 IN A 216.34.181.45
-->Local DNS Query
PING slashdot.org (216.34.181.45) 56(84) bytes of data.
64 bytes from slashdot.org (216.34.181.45): icmp_seq=1 ttl=242 time=33.0 ms
--- slashdot.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.026/33.026/33.026/0.000 ms
이 솔루션은 기억하기에는 비현실적이지만 문제가 해결되지 않을만큼 간단합니다. dig내 전문이 아닙니다-개선을 환영합니다 :-)