Baca DNS Android dengan betul: ikut rangkaian, bukan resolv.conf

Anda mendapat shell pada peranti, membaca /etc/resolv.conf atau menggali nilai net.dns1 lama, dan mendapat satu alamat. Aplikasi di hadapan anda menyelesaikan melalui sesuatu yang sama sekali lain. Pada keluaran Android semasa resolver adalah mengikut rangkaian: sistem menyimpan dasar bagi setiap Network dan menggunakannya pada socket yang membuat permintaan. Fail dan sifat lama hanyalah sisa, dan kedua-duanya tidak menggambarkan laluan yang benar-benar dilalui pertanyaan anda.

Jurang ini muncul semasa pelaksanaan split-tunnel dan Private DNS, apabila dua aplikasi pada telefon yang sama boleh melihat jawapan berbeza secara sah. Panduan ini bermula daripada penyelesaian yang salah atau tiada dan berundur kepada konfigurasi yang memilikinya.

Resolver milik rangkaian, bukan peranti

Penyelesaian nama pada Android 9 dan kemudian melalui resolver sistem yang berpandukan Network tempat socket terikat. Setiap rangkaian membawa LinkProperties sendiri, dan sifat-sifat itu mengandungi senarai pelayan DNS, domain carian dan keadaan Private DNS bagi rangkaian itu sahaja. Tiada apa dalam model itu yang sepadan dengan satu senarai seluruh peranti yang boleh anda baca daripada fail.

VPN menjadikan pemisahan itu jelas. Apabila terowong naik, aplikasi VPN membekalkan pelayan DNS yang didaftarkan pada rangkaian VPN itu sendiri, jadi aplikasi yang dilalui melaluinya menyelesaikan pada pelayan tersebut manakala aplikasi yang dikecualikan terus menggunakan rangkaian di bawahnya. Satu peranti, dua laluan jawapan, tiada percanggahan.

Baca syot kilat dari dalam aplikasi yang terjejas

Tanya aplikasi itu sendiri. Kaedah yang mempunyai Context dan kebenaran biasa android.permission.ACCESS_NETWORK_STATE boleh membaca syot kilat tanpa menyentuh sifat sistem:

val cm = getSystemService(ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val links = network?.let { cm.getLinkProperties(it) }

val dnsServers = links?.dnsServers
val privateDnsActive = links?.isPrivateDnsActive
val privateDnsName = links?.privateDnsServerName

activeNetwork ialah rangkaian lalai bagi proses anda, bukan satu-satunya rangkaian pada peranti, dan boleh menjadi null apabila pemanggil tiada lalai yang boleh digunakan. VPN lalai yang disekat ialah sebab biasa. isPrivateDnsActive memberitahu anda sama ada pertanyaan pada rangkaian itu pergi melalui TLS ke resolver bernama, yang mengubah apa yang akan ditunjukkan oleh kuar UDP 53 mudah. Permukaan API didokumenkan di bawah LinkProperties, dan setiap nilai di dalamnya ialah syot kilat konfigurasi, bukan bukti bahawa pertanyaan tertentu sampai ke pelayan tertentu.

Apabila rangkaian lalai bukan yang melakukan kerja

Syot kilat hanya menjawab bagi lalai. Aplikasi boleh mengikat prosesnya atau satu socket kepada rangkaian lain, dan penyelesaian kemudian mengikut pilihan itu sementara diagnostik anda masih melaporkan lalai. Pelayar yang membawa resolver DNS-over-HTTPS sendiri tidak pernah merujuk senarai sistem, jadi jawapannya tidak berkata apa-apa tentang seluruh peranti. Aplikasi profil kerja berjalan di bawah pengguna berasingan dengan dasar sendiri. Semak ikatan sebelum menyalahkan pelayan.

Integrasi VPN ialah separuh lagi. Menerima baris dhcp-option DNS dalam profil OpenVPN dan mendaftarkan alamat itu pada rangkaian VPN Android ialah dua langkah berasingan, dan laluan yang hilang ke pelayan gagal sesenyap alamat yang salah. Daripada mesin pembangunan, adb shell dumpsys connectivity mencetak sifat pautan yang sama bagi setiap rangkaian apabila binaan mengizinkan, yang mengesahkan senarai tanpa menulis kod.

Bandingkan konfigurasi dengan satu penyelesaian yang dibenarkan

Pilih satu nama yang mesti diselesaikan dalam ruang nama peribadi dan satu nama awam, dan catat kedua hasil di sebelah syot kilat: rangkaian, pelayan yang dikonfigurasikan, keadaan Private DNS dan teks ralat yang tepat. Pertanyaan terus ke pelayan bernama membuktikan pelayan itu menjawab anda; ia tidak membuktikan penyelesaian aplikasi biasa memilihnya. Jawapan daripada cache bukan ujian baharu, jadi kosongkan cache atau guna nama yang belum ditanya sesiapa hari ini.

Jika resolver hanya melayani klien daripada rangkaian akses tertentu, apa yang dilihatnya selepas keluar VPN boleh menentukan hasil, dan ini soalan dasar bagi yang mengendalikannya, bukan bukti pengendali menyekat UDP 53. Di tempat Private DNS aktif, nama hos tidak layak boleh ditolak mengikut reka bentuk manakala pelayan yang sama menjawab nama awam seperti biasa. Membaca sifatnya memberitahu mod mana yang berkuat kuasa, jadi anda berhenti meneka penapis paket.

Baiki lapisan yang memiliki ketidakpadanan

Bekerja ke atas dan bukan menyunting keadaan global. Jika aplikasi terikat pada rangkaian yang salah, baiki ikatan. Jika profil membekalkan pilihan DNS yang salah, baiki profil. Jika Private DNS ketat pada rangkaian yang resolver-nya tidak dapat melayani zon peribadi anda, itu keputusan pengurusan peranti, bukan alasan mematikan ciri di merata tempat.

Mendesak resolver awam ke dalam cangkuk DHCP atau sifat sistem ialah pembaikan yang berterusan menimbulkan insiden: nama peribadi berhenti diselesaikan, perubahan bertahan melepasi sesi VPN, dan orang seterusnya pada peranti menemui alamat lapuk tanpa pemilik. Simpan perubahan di dalam VPN, aplikasi atau lapisan pengurusan yang memiliki ketidakpadanan itu, kemudian baca semula syot kilat untuk mengesahkan senarai pelayan benar-benar berubah.

Akhirnya yang anda mahu ialah satu permintaan aplikasi terikat pada satu rangkaian, senarai resolver dan keadaan Private DNS. Apabila anda boleh menunjukkan rantaian itu, alamat biasa dalam fail bukan lagi bukti apa-apa.