Принудительно копать, чтобы разрешить без использования кеша

Мне интересно, если есть способ запросить DNS-сервер и обойти кэширование (с dig). Часто я меняю зону на DNS-сервере и хочу проверить, правильно ли она разрешается на моей рабочей станции. Но поскольку сервер кеширует разрешенные запросы, я часто получаю старые. Перезапуск или загрузка сервера на самом деле не является чем-то приятным.

Вы можете использовать @синтаксис для поиска домена с определенного сервера. Если DNS-сервер является полномочным для этого домена, ответ не будет кэшированным результатом.

dig @ns1.example.com example.com

Вы можете найти авторитетные серверы, запросив NSзаписи для домена:

dig example.com NS

В протоколе DNS нет механизма, который заставлял бы сервер имен отвечать без использования своего кэша. Dig сам по себе не сервер имен, это просто инструмент, который передает ваш запрос на любой сервер имен, который вы настроили, используя стандартные запросы DNS. DNS действительно позволяет серверу не использовать рекурсию, но это не то, что вам нужно. Это полезно только тогда, когда вы хотите напрямую запросить авторитетный сервер имен.

Если вы хотите, чтобы сервер имен не отвечал из своего кэша, вы могли бы сделать это только путем изменения конфигурации на сервере имен , но если вы не управляете сервером имен, это невозможно.

Однако вы можете получить dig, чтобы обойти сконфигурированные серверы имен и выполнить свой собственный рекурсивный запрос, который возвращается к корневым серверам. Для этого используйте +traceопцию.

dig example.com +trace

На практике, поскольку это будет выполнять запросы только к уполномоченным серверам, а не к вашему локальному решателю кэширования, результат не будет устаревшим, даже если эти серверы будут использовать внутреннее кэширование. Дополнительным преимуществом использования +traceявляется то, что вы можете видеть все отдельные запросы, сделанные по пути.

Здесь следует отметить кое-что важное, о чем, как я заметил, многие люди даже не упоминают, говоря о +traceтом, что использование +traceозначает, что клиент dig будет выполнять трассировку, а не DNS-сервер, указанный в вашей конфигурации (/etc/resolv.conf). Итак, другими словами, ваш dig-клиент будет работать как рекурсивный DNS-сервер, если вы спросите его. Но - главное, у вас нет кэша.

Более подробно - так что если вы уже запросили mxзапись с использованием dig -t mx example.comи ваш /etc/resolv.conf равен 8.8.8.8, то выполнение каких-либо действий внутри TTL зоны вернет кэшированный результат. В некотором смысле, если вы ищете что-то о своей собственной зоне и о том, как ее видит Google, вы как бы отравили свои результаты DNS с помощью Google для TTL вашей зоны. Неплохо, если у вас короткий TTL, немного мусора, если у вас 1 час.

Таким образом, хотя +traceвы сможете увидеть, что будет видно, если вы впервые запросите Google, а у него нет кэшированной записи, это может дать вам ложное представление о том, что Google будет рассказывать всем то же самое, что и ваш +traceрезультат, что это не произойдет, если вы спросили ранее, и у вас будет длинный TTL, так как он будет обслуживать его из кэша до истечения срока действия TTL - ТОГДА он будет служить так же, как и ваш +traceпоказанный.

Не могу иметь слишком много деталей IMO.

Этот bash будет копать записи DNS сайта example.com со своего первого сервера имен:

dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer

• Внутреннее копирование запрашивает DNS Google (8.8.8.8), чтобы получить сервер имен example.com.
• Внешний dig запрашивает сервер имен 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не моя специальность - улучшения приветствуются :-)