Baca DNS Android dengan benar: per jaringan, bukan resolv.conf

Anda mendapat shell di perangkat, membaca /etc/resolv.conf atau menggali nilai net.dns1 lama, dan mendapat satu alamat. Aplikasi di depan Anda menyelesaikan lewat hal yang sama sekali lain. Pada rilis Android terkini resolver bersifat per jaringan: sistem menyimpan kebijakan untuk setiap Network dan menerapkannya pada socket yang mengirim permintaan. File dan properti lama hanyalah sisa, dan keduanya tidak menggambarkan jalur yang benar-benar ditempuh kueri Anda.

Celah ini muncul saat penerapan split-tunnel dan Private DNS, ketika dua aplikasi di ponsel yang sama dapat secara sah melihat jawaban berbeda. Panduan ini dimulai dari penyelesaian yang salah atau hilang dan mundur ke konfigurasi yang memilikinya.

Resolver milik jaringan, bukan perangkat

Penyelesaian nama di Android 9 dan setelahnya melewati resolver sistem yang berpatokan pada Network tempat socket terikat. Setiap jaringan membawa LinkProperties sendiri, dan properti itu memuat daftar server DNS, domain pencarian, dan status Private DNS hanya untuk jaringan tersebut. Tidak ada dalam model itu yang sepadan dengan satu daftar seluruh perangkat yang bisa Anda baca dari file.

VPN membuat pemisahan itu jelas. Saat terowongan naik, aplikasi VPN menyediakan server DNS yang terdaftar di jaringan VPN itu sendiri, sehingga aplikasi yang dirutekan melaluinya menyelesaikan pada server tersebut sementara aplikasi yang dikecualikan tetap memakai jaringan di bawahnya. Satu perangkat, dua jalur jawaban, tanpa pertentangan.

Baca snapshot dari dalam aplikasi yang terdampak

Tanyakan kepada aplikasinya sendiri. Metode yang memiliki Context dan izin android.permission.ACCESS_NETWORK_STATE biasa dapat membaca snapshot tanpa menyentuh properti 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 adalah jaringan default proses Anda, bukan satu-satunya jaringan di perangkat, dan bisa null ketika pemanggil tidak punya default yang bisa dipakai. VPN default yang diblokir adalah alasan umumnya. isPrivateDnsActive memberi tahu apakah kueri di jaringan itu lewat TLS ke resolver bernama, yang mengubah apa yang akan ditunjukkan probe UDP 53 sederhana. Permukaan API didokumentasikan di bawah LinkProperties, dan setiap nilai di dalamnya adalah snapshot konfigurasi, bukan bukti bahwa kueri tertentu mencapai server tertentu.

Ketika jaringan default bukan yang melakukan pekerjaan

Snapshot hanya menjawab untuk default. Aplikasi dapat mengikat prosesnya atau satu socket ke jaringan lain, lalu penyelesaian mengikuti pilihan itu sementara diagnostik Anda tetap melaporkan default. Peramban yang membawa resolver DNS-over-HTTPS sendiri tidak pernah bertanya ke daftar sistem, jadi jawabannya tidak mengatakan apa pun tentang sisa perangkat. Aplikasi profil kerja berjalan di bawah pengguna terpisah dengan kebijakan sendiri. Periksa pengikatan sebelum menyalahkan server.

Integrasi VPN adalah separuh lainnya. Menerima baris dhcp-option DNS di profil OpenVPN dan mendaftarkan alamat itu di jaringan VPN Android adalah dua langkah terpisah, dan rute yang hilang ke server gagal setenang alamat yang salah. Dari mesin pengembangan, adb shell dumpsys connectivity mencetak properti tautan yang sama per jaringan bila build mengizinkan, yang mengonfirmasi daftar tanpa menulis kode.

Bandingkan konfigurasi dengan satu penyelesaian yang boleh Anda lakukan

Pilih satu nama yang harus diselesaikan di ruang nama privat dan satu nama publik, lalu catat kedua hasil di samping snapshot: jaringan, server yang dikonfigurasi, status Private DNS, dan teks galat yang tepat. Kueri langsung ke server bernama membuktikan server itu menjawab Anda; itu tidak membuktikan penyelesaian aplikasi biasa memilihnya. Jawaban dari cache bukan uji baru, jadi kosongkan cache atau gunakan nama yang belum ditanyakan siapa pun hari ini.

Jika resolver hanya melayani klien dari jaringan akses tertentu, apa yang dilihatnya setelah keluar dari VPN bisa menentukan hasil, dan itu pertanyaan kebijakan bagi yang mengelolanya, bukan bukti operator memblokir UDP 53. Di tempat Private DNS aktif, nama host tak berkualifikasi bisa ditolak secara desain sementara server yang sama menjawab nama publik dengan normal. Membaca propertinya memberi tahu mode mana yang berlaku, sehingga Anda berhenti menebak filter paket.

Perbaiki lapisan yang memiliki ketidakcocokan

Bekerjalah ke atas alih-alih menyunting keadaan global. Jika aplikasi terikat ke jaringan yang salah, perbaiki pengikatannya. Jika profil memberi opsi DNS yang salah, perbaiki profilnya. Jika Private DNS ketat pada jaringan yang resolver-nya tidak dapat melayani zona privat Anda, itu keputusan pengelolaan perangkat, bukan alasan mematikan fitur di mana-mana.

Mendorong resolver publik ke kait DHCP atau properti sistem adalah perbaikan yang terus menimbulkan insiden: nama privat berhenti diselesaikan, perubahan bertahan melewati sesi VPN, dan orang berikutnya di perangkat menemukan alamat usang tanpa pemilik. Simpan perubahan di dalam VPN, aplikasi, atau lapisan pengelolaan yang memiliki ketidakcocokan itu, lalu baca snapshot lagi untuk memastikan daftar server benar-benar berubah.

Yang Anda inginkan pada akhirnya adalah satu permintaan aplikasi yang terikat pada satu jaringan, daftar resolver, dan status Private DNS. Begitu Anda bisa menunjukkan rantai itu, alamat yang familier dalam sebuah file tidak lagi menjadi bukti apa pun.