캐시를 사용하지 않고 강제로 파기 해결되는지 확인하고

DNS 서버를 쿼리하고 캐싱을 무시하는 방법이 있는지 궁금합니다 dig. 종종 DNS 서버에서 영역을 변경하고 내 워크 스테이션에서 올바르게 해결되는지 확인하고 싶습니다. 그러나 서버는 해결 된 요청을 캐시하기 때문에 종종 이전 요청을받습니다. 서버를 다시 시작하거나로드하는 것이 실제로 좋은 것은 아닙니다.



답변

@구문을 사용하여 특정 서버에서 도메인을 조회 할 수 있습니다 . DNS 서버가 해당 도메인에 대해 권한이 있으면 응답이 캐시 된 결과가 아닙니다.

dig @ns1.example.com example.com

NS도메인 에 대한 레코드를 요청하여 신뢰할 수있는 서버를 찾을 수 있습니다 .

dig example.com NS


답변

DNS 프로토콜에는 이름 서버가 캐시를 사용하지 않고 응답하도록하는 메커니즘이 없습니다. 발굴 자체는 네임 서버가 아니며 표준 DNS 요청을 사용하여 구성한 네임 서버로 쿼리를 전달하는 도구입니다. DNS 에는 서버에 재귀를 사용하지 않도록 지시하는 방법 포함되어 있지만 원하는 것은 아닙니다. 신뢰할 수있는 네임 서버를 직접 쿼리하려는 경우에만 유용합니다.

네임 서버가 캐시에서 응답 하지 못하게 하려면 네임 서버 의 구성 변경해야만 할 수 있지만 네임 서버를 제어하지 않으면 불가능합니다.

그러나 구성된 네임 서버 를 무시 하고 루트 서버로 돌아가는 자체 재귀 요청을 수행 할 수 있습니다. 이렇게하려면 +trace옵션을 사용하십시오 .

dig example.com +trace

실제로 이것은 로컬 캐싱 확인자가 아닌 권한있는 서버 만 쿼리하므로 해당 서버가 내부 캐싱을 사용하더라도 결과가 오래되지 않습니다. 사용의 추가 이점은 +trace경로를 따라 작성된 모든 개별 요청을 볼 수 있다는 것입니다.


답변

내가 얘기 할 때 많은 사람들이 이제까지 포함되지 않습니다주의 여기서 주목해야 할 중요한 무언가가, +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를 가질 수 없습니다.


답변

이 bash는 example.com의 DNS 항목을 첫 번째로 나열된 이름 서버에서 발굴합니다.

dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
  • 내부 발굴은 Google의 DNS (8.8.8.8)를 쿼리하여 example.com의 네임 서버를 얻습니다.
  • 외부 발굴은 example.com의 이름 서버를 쿼리합니다.

다음은 .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내 전문이 아닙니다-개선을 환영합니다 🙂


답변