Мне интересно, есть ли способ запросить DNS-сервер и обойти кеширование (с dig
). Часто я меняю зону на DNS-сервере и хочу проверить, правильно ли она разрешается с моей рабочей станции. Но поскольку сервер кеширует разрешенные запросы, я часто получаю старые. Перезагрузка или перезагрузка сервера - не самое приятное.
Вы можете использовать @
синтаксис для поиска домена с определенного сервера. Если DNS-сервер является официальным для этого домена, ответ не будет кэшированным.
dig @ns1.example.com example.com
Вы можете найти официальные серверы, запросив NS
записи для домена:
dig example.com NS
В протоколе DNS нет механизма, заставляющего сервер имен отвечать без использования его кеша. Сам по себе Dig не является сервером имен, это просто инструмент, который передает ваш запрос любым настроенным вами серверам имен, используя стандартные запросы DNS. DNS делает включить способ запретить серверу использовать рекурсию, но это не то, что вам нужно. Это полезно только тогда, когда вы хотите напрямую запросить авторитетный сервер имен.
Если вы хотите, чтобы сервер имен не отвечал из своего кеша, вы могли бы сделать это, только изменив конфигурацию на сервере имен, но если вы не контролируете сервер имен, это невозможно.
Однако вы можете копать обход настроенных серверов имен и выполняет свой собственный рекурсивный запрос, который возвращается к корневым серверам. Для этого используйте +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
раскрыто.
ИМО, подробностей не может быть.
Этот bash будет копать записи DNS example.com с его первого указанного сервера имен:
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
не моя специальность - улучшения приветствуются :-)