Назад | Перейти на главную страницу

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

Мне интересно, есть ли способ запросить 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
  • Внутренний dig запрашивает 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 не моя специальность - улучшения приветствуются :-)