Ikuti kueri DNS langkah demi langkah untuk menemukan sumber sebenarnya
Alamat resolver yang didorong tidak menentukan sumber mana yang dilihat resolver. Telusuri klien, penerus, dan server penerima, lalu catat jalurnya.
Memberi klien alamat resolver menetapkan ke mana kueri dikirim, bukan sumber mana yang akan dilihat resolver. Perutean, penerusan, dan penerjemahan masing-masing mendapat giliran di antara kedua ujung. Buku kerja untuk pertanyaan sumber mengikuti kueri langkah demi langkah dan mencatat apa yang benar-benar dilihat setiap pengamat. Urutannya penting, karena klaim yang dibuat sebelum pengamatan hanyalah dugaan dengan format yang lebih baik.
Catat susunannya sebelum mengumpulkan bukti
Empat tempat dapat memberi tahu sesuatu tentang sumber DNS, dan tidak semuanya mengatakan hal yang sama. Kernel klien tahu sumber mana yang akan dipakainya, penerus tahu apa yang dikirimnya ke hulu, perangkat penerjemah tahu apa yang ditulis ulangnya, dan resolver penerima tahu apa yang tiba. Catat mana di antaranya yang benar-benar dapat Anda jangkau sebelum mengumpulkan apa pun.
| Observation point | What it can prove | What it cannot prove | How to read it |
|---|---|---|---|
| client kernel | which source address it would use for that resolver | anything a device in between rewrote | ip route get against the resolver address |
| forwarder | that it sent an upstream query, and from which source | what the client originally asked for | its own log and its cache state |
| translating device | that a source was rewritten, and to what | whether the query was legitimate | NAT policy and its counters |
| receiving resolver | the address that actually arrived | which client behind that address asked | a scoped capture on port 53 |
Catat juga harapan Anda, termasuk resolver yang Anda yakini sedang dipakai. Rute terbelah dapat mengirim kueri ke tempat yang sama sekali lain, dan cache dapat menjawab tanpa pertukaran ke hulu sama sekali, sehingga asumsi yang hanya disimpan di ingatan tidak akan bertahan menghadapi kejutan pertama. Simpan rancangan yang dinyatakan dan jalur yang diamati di kolom terpisah pada catatan yang sama; ketika keduanya tidak sepakat, Anda telah menemukan pertanyaan yang layak dikejar.
Periksa proses mana yang benar-benar mengirim kueri
Mulailah dari klien: catat alamat resolver, nama kueri, dan waktu, lalu pastikan proses mana yang mengirimnya. Baris pertama di bawah menyebut proses yang memegang soket UDP, dan itulah pemeriksaan yang dijanjikan judul ini. Jika proses itu adalah pembantu peramban atau runtime kontainer alih-alih resolver sistem, sisa jejaknya menggambarkan jalur yang tidak diminta siapa pun.
ss -tunp 'dport = :53'
dig @10.20.30.53 host.corp.example +noall +answer
ip route get 10.20.30.53Pada host dengan beberapa antarmuka, cari tahu alamat sumber mana yang dipilih kernel untuk tujuan itu sebelum Anda melihat ke tempat lain. Itu titik terakhir ketika jalur sepenuhnya dalam kendali Anda, dan itulah nilai yang akan Anda bandingkan dengan apa yang dilaporkan resolver. Ketidakcocokan adalah tanda bahwa sesuatu di antaranya menulis ulang paket, atau bahwa dua kueri berbeda telah dikirim.
Simpan nama uji sebagai internal, karena nama internal yang dikirim ke resolver publik tidak membuktikan apa pun tentang jalur internal dan menerbitkan nama yang tidak perlu Anda terbitkan. Peramban dengan DNS aman aktif tidak akan muncul sama sekali dalam daftar soket itu, dan ketidakhadiran itu sendiri adalah jawabannya.
Penerus membuat kueri kedua yang terpisah
Penerus mengubah satu pertukaran menjadi dua. Permintaan hilir tiba, lalu penerus mengirim kuerinya sendiri ke hulu dari alamat yang dipilihnya. Konfigurasinya, bukan klien, yang menentukan apa yang dilihat resolver hulu.
manual dnsmasq layak dibaca karena alasan itu: dokumen itu menjelaskan bagaimana penerus memilih server hulu dan mengikat sisi pendengarannya, dan tidak ada apa pun dalam susunan itu yang membawa sumber klien ke hulu. Karena itu log resolver yang menampilkan alamat gateway adalah hal normal, bukan bukti kerusakan. Ketidakhadiran sama mudahnya dibaca keliru, karena tembakan cache tidak menghasilkan kueri hulu apa pun dan tampak identik dengan kueri yang tidak pernah tiba. Baca konfigurasi penerus dan keadaan cache-nya sebelum menarik salah satu dari dua kesimpulan itu. Dua pertanyaan, dua tempat untuk melihat.
Baca sumbernya di resolver penerima
Satu-satunya pengamatan yang menyelesaikan hal ini diambil di sisi server. Segala yang disimpulkan dari daftar antarmuka klien tetap merupakan hipotesis sampai resolver melaporkan apa yang benar-benar tiba.
tcpdump -ni any port 53 and host 10.20.30.53Tangkap di host resolver, jaga tangkapan tetap singkat dan terbatas, dan simpan di tempat yang diizinkan kebijakan. Jika sumber yang diamati adalah alamat yang diterjemahkan, pertanyaan berikutnya adalah perangkat mana yang melakukan penerjemahan dan apakah kebijakannya adalah yang dimaksud. Tangkapan menjawab apa yang tiba; ia tidak menjelaskan mengapa kebijakan mengizinkannya. Sebutkan pengamat dan langkahnya dalam catatan, karena klaim privasi tentang gateway adalah klaim tentang langkah itu dan bukan tentang seluruh jalur.
Tulis temuan sebagai jalur, bukan sebagai alamat
Catat klien, resolver, penerus mana pun, sumber yang diamati pada setiap langkah, dan kebijakan yang mengaturnya. Catatan semacam itu menjawab sebagian besar pertanyaan di masa depan tanpa tangkapan lain. Gambarlah sebagai rantai, karena daftar alamat menyembunyikan langkah mana yang menghasilkan yang mana.
Lampirkan tanggal, versi klien, dan revisi konfigurasi pada gambar, agar pembaca nanti dapat mengatakan apakah gambar itu masih berlaku. Pisahkan sumber transportasi dari segala hal lain yang diproses layanan, karena melihat alamat gateway tidak mengatakan apa pun tentang apa lagi yang disimpan. Lokasi resolver juga tidak mengatakan apa pun tentang klien mana yang bertanya. Justru menjaga klaim-klaim itu tetap terpisah yang membuat kesimpulannya dapat dipertahankan saat ditinjau.