Saya bertanya-tanya apakah ada cara untuk menanyakan server DNS dan memotong cache (dengan dig). Seringkali saya mengubah zona pada server DNS dan saya ingin memeriksa apakah itu menyelesaikan dengan benar dari workstation saya. Tetapi karena cache server menyelesaikan permintaan, saya sering mendapatkan yang lama. Memulai ulang atau memuat server bukan sesuatu yang baik.
Jawaban:
Anda dapat menggunakan @sintaks untuk mencari domain dari server tertentu. Jika server DNS otoritatif untuk domain itu, responsnya tidak akan berupa hasil di-cache.
dig @ns1.example.com example.com
Anda dapat menemukan server otoritatif dengan meminta NScatatan untuk domain:
dig example.com NS
+norecursedisarankan. +recurseaktif secara default sesekali akan mengubah cara server DNS menginterpretasikan pertanyaan Anda sepenuhnya.
+tracetetapi waspadai caching. Andrew B menulis penjelasan yang bagus tentang bagaimana cache bisa menipu Anda ketika menunggu nameserver berubah.
dig @8.8.8.8 example.com. catatan muncul jauh lebih cepat di sana.
Tidak ada mekanisme dalam protokol DNS untuk memaksa server nama merespons tanpa menggunakan cache-nya. Dig sendiri bukan server nama, itu hanyalah alat yang meneruskan kueri Anda ke server nama mana pun yang telah Anda konfigurasikan, menggunakan permintaan DNS standar. DNS memang menyertakan cara untuk memberi tahu server untuk tidak menggunakan rekursi, tetapi ini bukan yang Anda inginkan. Itu hanya berguna ketika Anda ingin secara langsung meminta server nama yang otoritatif.
Jika Anda ingin menghentikan server nama untuk merespons dari cache, Anda hanya dapat melakukannya dengan mengubah konfigurasi server nama , tetapi jika Anda tidak mengontrol server nama, ini tidak mungkin.
Namun, Anda bisa menggali untuk mem - bypass nameserver yang dikonfigurasi, dan melakukan permintaan rekursifnya sendiri yang kembali ke server root. Untuk melakukan ini, gunakan +traceopsi.
dig example.com +trace
Dalam praktiknya karena ini hanya akan meminta server otoritatif daripada penyelesai caching lokal Anda, hasilnya tidak akan basi meskipun server tersebut menggunakan caching internal. Manfaat tambahan menggunakan +traceadalah Anda bisa melihat semua permintaan terpisah yang dibuat di sepanjang jalan.
+norecursehanya memberi tahu server nama untuk mengembalikan informasi apa pun yang dimilikinya (termasuk info yang di-cache, jika ada), jadi itu tidak benar. +traceakan bekerja karena akan mengikuti rantai rekursi hingga server otoritatif.
+norecurserekomendasi karena membingungkan masalah.
Sesuatu yang penting untuk dicatat di sini, yang saya perhatikan banyak orang tidak pernah memasukkan ketika berbicara tentang +traceadalah menggunakan +tracecara klien penggali akan melakukan pelacakan, bukan server DNS yang ditentukan dalam konfigurasi Anda (/etc/resolv.conf). Jadi, dengan kata lain, klien penggalian Anda akan bekerja seperti server DNS rekursif, jika Anda menanyakannya. Tapi - yang penting, Anda tidak punya cache.
Lebih detail - jadi jika Anda sudah meminta mxcatatan menggunakan dig -t mx example.comdan /etc/resolv.conf Anda adalah 8.8.8.8 maka melakukan apa pun di dalam TTL zona akan mengembalikan hasil yang di-cache. Di satu sisi, jika Anda mencari sesuatu tentang zona Anda sendiri dan bagaimana Google melihatnya, Anda telah semacam meracuni hasil DNS Anda dengan Google untuk TTL Zona Anda. Tidak buruk jika Anda memiliki TTL pendek, agak sampah jika Anda punya 1 jam.
Jadi, sementara +traceakan membantu Anda untuk melihat apa yang AKAN terlihat jika Anda meminta Google untuk pertama kalinya dan tidak ada entri yang di-cache, itu mungkin memberi Anda ide yang salah bahwa Google akan memberi tahu semua orang sama seperti apa +tracehasil Anda , yang tidak akan jika Anda bertanya sebelumnya dan memiliki TTL yang panjang, karena akan melayani dari cache sampai TTL berakhir - MAKA itu akan melayani sama dengan apa yang Anda +traceungkapkan.
Tidak dapat memiliki terlalu banyak detail IMO.
dig mydomain.com +tracehanya mengembalikan saya resolvdhasil rintisan dari 127.0.0.53. Lihat github.com/systemd/systemd/issues/5897
+tracedig, mulailah jejak menggunakan nameserver yang ditentukan (mis., 8.8.8.8 jika itu yang Anda konfigurasikan) untuk pencarian pertama (zona root), tetapi setelah itu ia menggunakan server nama yang dikembalikan untuk pertanyaan lebih lanjut. Jadi jika server nama yang Anda konfigurasikan tidak berfungsi atau tidak merespons dengan benar permintaan untuk server nama root, Anda dapat mengalami masalah (seperti dalam komentar di atas).
Bash ini akan menggali entri DNS example.com dari server nama pertama yang terdaftar:
dig @$(dig @8.8.8.8 example.com ns +short | head -n1) example.com ANY +noall +answer
Berikut ini sama dengan alias untuk .zshrc (dan mungkin .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; }
Inilah output untuk / .:
☀ 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
Solusi ini cukup rumit untuk tidak praktis untuk diingat, tetapi cukup sederhana untuk masalah yang tidak dapat diperbaiki. digbukan spesialisasi saya - penyambutan diterima :-)