Мені цікаво, чи є спосіб запиту 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. Там є спосіб сказати «не використовувати рекурсію», але це не те , що ви хочете - це було б просто запобігти будь-Lookups доменних імен в широкому Інтернеті.
Якщо ви хочете не дати серверу імен відповідати з кешу, вам доведеться цього досягти, змінивши конфігурацію на сервері імен , але якщо ви не керуєте сервером імен, ви не можете цього зробити.
Однак ви можете отримати копання для обходу налаштованих серверів імен та виконувати власний рекурсивний запит, який повертається до кореневих серверів. Для цього скористайтеся +traceопцією.
dig example.com +trace
На практиці, оскільки це зажадає лише авторитетних серверів, а не локального вирішувача кешування, результат не буде розмитим, навіть якщо ці сервери використовують внутрішнє кешування. Додатковою перевагою використання +traceє те, що ви можете побачити всі окремі запити, зроблені на цьому шляху.
+norecurseпросто каже серверу імен повертати будь-яку інформацію, яку він має (включаючи інформацію про кешування, якщо така є), так що це не правильно. +traceбуде працювати, оскільки він буде прослідковувати ланцюг рекурсії аж до авторитетного сервера.
+norecurseрекомендацію, оскільки вона плутала проблему.
Щось тут важливо зазначити, що я помічаю, що багато людей ніколи не включають, коли говорити про +traceте, що за допомогою +traceзасобів dig client буде виконувати слід, а не 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/isissue/5897
+tracedig починається трасування за допомогою вказаного сервера імен (наприклад, 8.8.8.8, якщо це те, що ви налаштували) для першого пошуку (кореневої зони), але після цього він використовує повернуті сервери імен для подальших запитів. Тож якщо ваш налаштований сервер імен не працює або не відповідає належним чином на запит кореневих серверів імен, у вас можуть виникнути проблеми (як у коментарі вище).
Цей баш буде викопувати записи 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не моя спеціальність - поліпшення вітаються :-)