Сила роет для разрешения, не используя кэш
Этот вопрос Serverfault мог быть связан. С другой стороны, Вы могли использовать что-то как mod_auth_tkt.
Вы можете использовать синтаксис @ для поиска домена с определенного сервера. Если 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 .
Не могу быть слишком подробным 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 серверы имен.
- Внешний поиск запрашивает первый сервер имен 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
Это решение Достаточно сложный, чтобы его было непрактично запомнить, но достаточно простой, чтобы проблему не решить. копать не моя специальность -
улучшения приветствуются: -)