Мне интересно, если есть способ запросить DNS-сервер и обойти кэширование (с dig). Часто я меняю зону на DNS-сервере и хочу проверить, правильно ли она разрешается на моей рабочей станции. Но поскольку сервер кеширует разрешенные запросы, я часто получаю старые. Перезапуск или загрузка сервера на самом деле не является чем-то приятным.
Ответы:
Вы можете использовать @синтаксис для поиска домена с определенного сервера. Если DNS-сервер является полномочным для этого домена, ответ не будет кэшированным результатом.
dig @ns1.example.com example.com
Вы можете найти авторитетные серверы, запросив NSзаписи для домена:
dig example.com NS
+norecurseрекомендуется. +recurseпо умолчанию иногда меняет способ, которым DNS-сервер полностью интерпретирует ваш вопрос.
+traceно остерегайтесь кеширования. Эндрю Б написал хорошее объяснение того, как кеширование может обмануть вас, ожидая изменения серверов имен.
dig @8.8.8.8 example.com. там записи появляются намного быстрее
В протоколе DNS нет механизма, который заставлял бы сервер имен отвечать без использования своего кэша. Dig сам по себе не сервер имен, это просто инструмент, который передает ваш запрос на любой сервер имен, который вы настроили, используя стандартные запросы DNS. DNS действительно позволяет серверу не использовать рекурсию, но это не то, что вам нужно. Это полезно только тогда, когда вы хотите напрямую запросить авторитетный сервер имен.
Если вы хотите, чтобы сервер имен не отвечал из своего кэша, вы могли бы сделать это только путем изменения конфигурации на сервере имен , но если вы не управляете сервером имен, это невозможно.
Однако вы можете получить dig, чтобы обойти сконфигурированные серверы имен и выполнить свой собственный рекурсивный запрос, который возвращается к корневым серверам. Для этого используйте +traceопцию.
dig example.com +trace
На практике, поскольку это будет выполнять запросы только к уполномоченным серверам, а не к вашему локальному решателю кэширования, результат не будет устаревшим, даже если эти серверы будут использовать внутреннее кэширование. Дополнительным преимуществом использования +traceявляется то, что вы можете видеть все отдельные запросы, сделанные по пути.
+norecurseпросто указывает серверу имен возвращать всю имеющуюся информацию (включая кэшированную информацию, если таковая имеется), так что это не правильно. +traceбудет работать, потому что он будет следовать цепочке рекурсии вплоть до авторитетного сервера.
+norecurseрекомендацию, поскольку это запутало проблему.
Здесь следует отметить кое-что важное, о чем, как я заметил, многие люди даже не упоминают, говоря о +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.
dig mydomain.com +traceпросто возвращает мне resolvdрезультаты заглушки 127.0.0.53. См. Github.com/systemd/systemd/issues/5897
+tracedig начинается трассировка с использованием указанного сервера имен (например, 8.8.8.8, если это то, что вы настроили) для первого поиска (корневой зоны), но после этого он использует возвращенные серверы имен для дальнейших запросов. Поэтому, если настроенный вами сервер имен не работает или не отвечает должным образом на запрос корневых серверов имен, у вас могут возникнуть проблемы (как в приведенном выше комментарии).
Этот 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не моя специальность - улучшения приветствуются :-)