Apakah menggali + jejak selalu akurat?

Ketika keakuratan cache DNS dipertanyakan, dig +tracecenderung menjadi cara yang disarankan untuk menentukan jawaban otoritatif untuk internet yang menghadapi catatan DNS. Ini tampaknya sangat berguna ketika juga dipasangkan dengan +additional, yang juga menunjukkan catatan lem.

Kadang-kadang tampaknya ada beberapa ketidaksepakatan pada titik ini - beberapa orang mengatakan bahwa itu bergantung pada resolver lokal untuk mencari alamat IP dari nameserver menengah, tetapi output perintah tidak memberikan indikasi bahwa ini terjadi di luar daftar awal root server nama. Tampaknya logis untuk berasumsi bahwa ini tidak akan terjadi jika tujuannya +traceadalah untuk memulai di root server dan melacak jalan Anda. (setidaknya jika Anda memiliki daftar nameserver root yang tepat)

Apakah dig +tracebenar-benar menggunakan resolver lokal untuk sesuatu yang melewati nameserver root?

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.

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:

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:

1. respons referensi terpotong karena ukuran respons yang melebihi 512 byte untuk kueri berulang berikutnya

2. 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.10

Namun 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 ms

496 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.