Вопрос: Принудительно разойтись без использования кеша


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


69
2018-03-21 17:15


Источник




Ответы:


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

dig @ns1.example.com example.com

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

dig example.com NS

95
2018-03-21 17:21



Ох, ну ладно. Да, я был знаком с синтаксисом @, но у меня не было идеи запрашивать авторитетный сервер. Благодаря! - Daniel
Сторона примечания: в тех случаях, когда вы пытаетесь понять, какие ответы получит сервер кеширования, +norecurse Рекомендовано. +recurse по умолчанию будет иногда изменять способ, которым DNS-сервер полностью интерпретирует ваш вопрос. - Andrew B
Что делать, если вы ожидаете изменения авторитетных серверов? - guaka
@KasperSouren Вы говорите о NS-записях на авторитетных серверах или клей-записи у родителя? Вы можете найти родителя с +trace но остерегайтесь кеширования. Эндрю Б написал хорошее объяснение того, как кеширование может обмануть вас, ожидая изменения имен серверов. - Ladadadada
вы также можете проверить на google dns dig @8.8.8.8 example.com, записи там намного быстрее. - machineaddict


Нет стандартного надежного способа заставить сервер имен отвечать, не используя его кеш. Сам Dig не является сервером имен, это просто инструмент, который передает ваш запрос на любой сервер имен, который вы настроили, используя стандартные DNS-запросы. Там является способ сказать «не использовать рекурсию», но это не то, что вы хотите - это просто предотвратило бы поиск доменных имен в более широком Интернете.

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

Тем не менее, вы можете байпас настроенных серверов имен и выполнить собственный рекурсивный запрос, который возвращается к корневым серверам. Для этого используйте +trace вариант.

dig example.com +trace

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


18
2018-05-31 15:00



С помощью +norecurse просто сообщает серверу имен возвращать всю имеющуюся у него информацию (включая кешированную информацию, если таковая имеется), поэтому это неверно. +trace будет работать, потому что он будет следовать цепочке рекурсии вплоть до авторитетного сервера. - Raman
Обратите внимание, что я изменил этот ответ, чтобы удалить +norecurse поскольку это путало проблему. - thomasrutter


Здесь важно что-то важное, что я замечаю, что многие люди никогда не включают, когда говорят о +trace заключается в том, что использование +trace означает, что ковер-клиент выполнит трассировку, а не DNS-сервер, указанный в вашей конфигурации (/etc/resolv.conf). Итак, другими словами, ваш копающийся клиент будет работать, как рекурсивный 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.


10
2018-05-24 23:10



Копает ли собственный кеш или использует кэш ОС? - CMCDragonkai
У Dig нет кеша. Однако, если он использует сервер восходящего потока, это приносит пользу. - thomasrutter
dig mydomain.com +trace просто возвращает мне resolvd результат 127.0.0.53, Видеть github.com/systemd/systemd/issues/5897 - James Bowery
Когда используешь +trace копать начинается трассировку с использованием указанного сервера имен (например, 8.8.8.8, если это то, что вы настроили) для первого поиска (корневая зона), но после этого он использует возвращенные серверы имен для дальнейших запросов. Поэтому, если ваш настроенный сервер имен не работает или не отвечает на запрос для корневых серверов имен, у вас могут быть проблемы (как в приведенном выше комментарии). - thomasrutter


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

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


1
2018-01-11 17:49