Ini jelas merupakan Q&A yang dipentaskan, tetapi ini cenderung membingungkan orang sering dan saya tidak dapat menemukan pertanyaan kanonik yang mencakup topik tersebut.
dig +traceadalah alat diagnostik yang hebat, tetapi satu aspek dari desainnya banyak disalahpahami: IP setiap server yang akan ditanyakan diperoleh dari pustaka resolver Anda . Ini sangat mudah diabaikan dan seringkali hanya berakhir menjadi masalah ketika cache lokal Anda memiliki jawaban yang salah untuk server nama di-cache.
Analisis terperinci
Ini lebih mudah dipecah dengan sampel output; Saya akan menghilangkan semuanya setelah delegasi NS pertama.
; <<>> DiG 9.7.3 <<>> +trace +additional serverfault.com
;; global options: +cmd
. 121459 IN NS d.root-servers.net.
. 121459 IN NS e.root-servers.net.
. 121459 IN NS f.root-servers.net.
. 121459 IN NS g.root-servers.net.
. 121459 IN NS h.root-servers.net.
. 121459 IN NS i.root-servers.net.
. 121459 IN NS j.root-servers.net.
. 121459 IN NS k.root-servers.net.
. 121459 IN NS l.root-servers.net.
. 121459 IN NS m.root-servers.net.
. 121459 IN NS a.root-servers.net.
. 121459 IN NS b.root-servers.net.
. 121459 IN NS c.root-servers.net.
e.root-servers.net. 354907 IN A 192.203.230.10
f.root-servers.net. 100300 IN A 192.5.5.241
f.root-servers.net. 123073 IN AAAA 2001:500:2f::f
g.root-servers.net. 354527 IN A 192.112.36.4
h.root-servers.net. 354295 IN A 128.63.2.53
h.root-servers.net. 108245 IN AAAA 2001:500:1::803f:235
i.root-servers.net. 355208 IN A 192.36.148.17
i.root-servers.net. 542090 IN AAAA 2001:7fe::53
j.root-servers.net. 354526 IN A 192.58.128.30
j.root-servers.net. 488036 IN AAAA 2001:503:c27::2:30
k.root-servers.net. 354968 IN A 193.0.14.129
k.root-servers.net. 431621 IN AAAA 2001:7fd::1
l.root-servers.net. 354295 IN A 199.7.83.42
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms
com. 172800 IN NS m.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS a.gtld-servers.net.
a.gtld-servers.net. 172800 IN A 192.5.6.30
a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30
b.gtld-servers.net. 172800 IN A 192.33.14.30
b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30
c.gtld-servers.net. 172800 IN A 192.26.92.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
e.gtld-servers.net. 172800 IN A 192.12.94.30
f.gtld-servers.net. 172800 IN A 192.35.51.30
g.gtld-servers.net. 172800 IN A 192.42.93.30
h.gtld-servers.net. 172800 IN A 192.54.112.30
i.gtld-servers.net. 172800 IN A 192.43.172.30
j.gtld-servers.net. 172800 IN A 192.48.79.30
k.gtld-servers.net. 172800 IN A 192.52.178.30
l.gtld-servers.net. 172800 IN A 192.41.162.30
;; Received 505 bytes from 192.203.230.10#53(e.root-servers.net) in 13 ms
- Permintaan awal untuk
. IN NS(nameserver root) mengenai resolver lokal, yang dalam hal ini adalah Comcast. ( 75.75.75.75) Ini mudah dikenali.
- Kueri berikutnya adalah untuk
serverfault.com. IN Adan berjalan melawan e.root-servers.net., dipilih secara acak dari daftar server nama root yang baru saja kita dapatkan. Ia memiliki alamat IP 192.203.230.10, dan karena kami telah +additionalmengaktifkannya sepertinya berasal dari lem.
- Karena tidak resmi untuk serverfault.com, ini akan didelegasikan ke
com.server nama TLD.
- Apa yang tidak jelas dari output di sini adalah bahwa
digtidak mendapatkan alamat IP e.root-servers.net.dari lem.
Di latar belakang, inilah yang sebenarnya terjadi:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:03:43.301022 IP 192.0.2.1.59900 > 75.75.75.75.53: 63418 NS? . (17)
02:03:43.327327 IP 75.75.75.75.53 > 192.0.2.1.59900: 63418 13/0/14 NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net. (512)
02:03:43.333047 IP 192.0.2.1.33120 > 75.75.75.75.53: 41110+ A? e.root-servers.net. (36)
02:03:43.333096 IP 192.0.2.1.33120 > 75.75.75.75.53: 5696+ AAAA? e.root-servers.net. (36)
02:03:43.344301 IP 75.75.75.75.53 > 192.0.2.1.33120: 41110 1/0/0 A 192.203.230.10 (52)
02:03:43.344348 IP 75.75.75.75.53 > 192.0.2.1.33120: 5696 0/1/0 (96)
02:03:43.344723 IP 192.0.2.1.37085 > 192.203.230.10.53: 28583 A? serverfault.com. (33)
02:03:43.423299 IP 192.203.230.10.53 > 192.0.2.1.37085: 28583- 0/13/14 (493)
+tracemenipu dan berkonsultasi dengan resolver lokal untuk mendapatkan alamat IP dari server nama hop berikutnya daripada berkonsultasi dengan lem. Sneaky!
Ini biasanya "cukup baik" dan tidak akan menimbulkan masalah bagi kebanyakan orang. Sayangnya, ada kasus tepi. Jika karena alasan apa pun cache DNS hulu Anda memberikan jawaban yang salah untuk server nama, model ini sepenuhnya rusak.
Contoh dunia nyata:
- domain kedaluwarsa
- lem diulang di nameserver redirection registrar
- IP palsu disimpan dalam cache untuk ns1 dan ns2.yourdomain.com
- domain diperbarui dengan lem yang dipulihkan
- setiap cache dengan IP nameserver palsu terus mengirim orang ke situs web yang mengatakan bahwa domain tersebut untuk dijual
Dalam kasus di atas, +traceakan menyarankan bahwa nameserver pemilik domain itu sendiri adalah sumber masalahnya, dan Anda sekali lagi salah memberitahu pelanggan bahwa server mereka salah konfigurasi. Apakah itu sesuatu yang Anda dapat (atau mau) lakukan sesuatu adalah cerita lain, tetapi penting untuk memiliki informasi yang benar.
dig +trace adalah alat yang hebat, tetapi seperti alat apa pun, Anda perlu tahu apa yang dilakukannya dan tidak dilakukan, dan cara memecahkan masalah secara manual ketika terbukti tidak mencukupi.
Edit:
Perlu juga dicatat bahwa dig +tracetidak akan memperingatkan Anda tentang NScatatan yang menunjuk CNAMEalias. Ini adalah pelanggaran RFC yang ISC BIND (dan mungkin orang lain) tidak akan berusaha untuk memperbaikinya. +traceakan sangat senang menerima Acatatan yang didapatnya dari server nama yang Anda konfigurasi secara lokal, sedangkan jika BIND akan melakukan rekursi penuh, itu akan menolak seluruh zona dengan SERVFAIL.
Ini bisa sulit untuk memecahkan masalah jika ada lem; ini akan berfungsi dengan baik sampai catatan NS di-refresh , lalu tiba-tiba rusak. Delegasi Glueless akan selalu mematahkan rekursi BIND ketika sebuah NSrecord menunjuk pada alias.
+nssearch?+nssearchmelakukanNSpencarian catatan terhadap resolver lokal Anda untuk catatan yang diminta, diikuti oleh serangkaianA/AAAApencarian terhadap resolver lokal untuk masing-masing server nama yang dikembalikan. Ini juga rentan terhadap catatan nameserver palsu dalam cache.Cara lain untuk melacak resolusi DNS tanpa menggunakan resolver lokal untuk apa pun kecuali menemukan nameserver root, menggunakan dnsgraph (Pengungkapan penuh: Saya menulis ini). Ini memiliki alat baris perintah dan versi web, yang dapat Anda temukan contohnya di http://ip.seveas.net/dnsgraph/
Contoh untuk serverfault.com, yang sebenarnya memiliki masalah DNS sekarang:
sumber
Sangat terlambat untuk utas ini, tapi saya pikir bagian dari pertanyaan mengapa penggalian + jejak menggunakan kueri rekursif untuk resolver lokal belum dijelaskan secara langsung, dan penjelasan ini relevan dengan keakuratan hasil penggalian + jejak.
Setelah kueri rekursif awal untuk catatan NS dari zona root, maka penggalian dapat mengeluarkan kueri berikutnya untuk resolver lokal di bawah kondisi berikut:
respons referensi terpotong karena ukuran respons yang melebihi 512 byte untuk kueri berulang berikutnya
dig memilih NS record dari bagian AUTHORITY dari respon referral dimana record A yang sesuai (lem) hilang di bagian ADDITIONAL
Karena dig hanya memiliki nama domain dari catatan NS, dig harus menyelesaikan nama ke alamat IP dengan menanyakan server DNS lokal. Ini adalah penyebab root (pun intended, maaf).
AndrewB memiliki contoh yang tidak sepenuhnya sesuai dengan apa yang baru saja saya jelaskan, di mana catatan NS zona root dipilih:
. 121459 IN NS e.root-servers.net.memiliki catatan A yang sesuai:
e.root-servers.net. 354907 IN A 192.203.230.10Namun perlu dicatat bahwa tidak ada catatan AAAA yang sesuai untuk e-root, serta tidak ada catatan AAAA untuk beberapa server root lainnya.
Perhatikan juga ukuran respons:
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms496 byte adalah ukuran umum untuk respons yang telah terpotong (yaitu catatan lem berikutnya seharusnya> 16 byte, menempatkan respons lebih dari 512 byte). Dengan kata lain, dalam kueri untuk catatan NS root, OTORITAS lengkap dan TAMBAHAN lengkap (baik catatan A dan AAAA) akan melebihi 512 byte, jadi setiap kueri berbasis UDP yang tidak menentukan ukuran kueri yang lebih besar melalui opsi EDNS0 akan dapatkan respons yang terpotong di suatu tempat di bagian TAMBAHAN, seperti yang ditunjukkan oleh jejak di atas (hanya f, h, i, j, dan k yang memiliki catatan lem A dan AAAA).
Kurangnya catatan AAAA untuk e.root-servers.net dan ukuran respons terhadap "NS." permintaan sangat menyarankan bahwa permintaan rekursif berikutnya dilakukan karena alasan saya mengklaim. Mungkin klien O / S mampu IPv6, dan lebih suka catatan AAAA - atau alasan lainnya.
Tetapi bagaimanapun juga, setelah membaca utas ini, saya melihat fenomena menggali + melakukan kueri rekursif setelah yang pertama untuk root. Korespondensi antara memilih catatan NS tanpa catatan A / AAAA lem yang sesuai dan menggali kemudian mengirimkan permintaan rekursif untuk catatan tersebut ke DNS lokal adalah 100%, menurut pengalaman saya. Dan kebalikannya adalah benar - saya belum melihat permintaan rekursif ketika catatan NS yang dipilih dari referensi memiliki catatan lem yang sesuai.
sumber