Cara memeriksa resolver DNS yang dipakai Mac Anda saat VPN

scutil --dns mencetak konfigurasi resolver yang benar-benar dirujuk macOS, bukan satu server DNS yang Anda ketik di panel pengaturan. Keluarannya lebih panjang dari yang dibayangkan kebanyakan orang, karena sistem menyimpan blok resolver terpisah untuk jalur default, untuk antarmuka berlingkup, dan untuk penerusan khusus domain. Blok di puncak keluaran belum tentu yang menjawab kueri. Jika nama privat beresolusi di kantor dan gagal saat VPN menyala, ketidakcocokannya ada pada aturan pencocokan dan rute, bukan pada alamat server. Baca urutannya dulu, lalu buktikan jawabannya dengan pencarian sungguhan.

Baca urutan blok sebelum alamatnya

Setiap entri dibuka dengan resolver #N dan mencantumkan nameserver[0], kadang if_index, baris flags, reach, dan bila blok bukan default biasa, domain serta daftar search domain. Resolver nomor 1 tanpa domain adalah default yang menangani nama publik. Apa pun yang membawa Scoped pada flag-nya terikat ke antarmuka yang disebut if_index, dan apa pun yang ditandai Supplemental hanya berlaku untuk domain yang terdaftar di bawahnya.

Pemilihan adalah pencocokan sufiks. Untuk nama seperti intranet.corp.example, macOS memilih resolver yang entri domain-nya merupakan sufiks cocok terpanjang, sehingga blok dengan domain : corp.example mengalahkan default meski berada jauh di bawah keluaran. order memutuskan seri antar domain dengan panjang sama. Sekilas pandang jarang butuh lebih dari ini: seluruh keluaran saat Anda ingin membaca satu blok dari awal sampai akhir, baris awal untuk mempelajari urutan blok, dan sekali jalan tersaring yang mencetak tajuk blok di samping baris bidang. Blok berlingkup muncul di bawah tajuknya sendiri dan terbaca sebagai lanjutan daftar di atasnya, jadi pertahankan tajuk dalam pandangan setiap kali Anda mengutip keluaran.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

Cocokkan if_index dengan antarmuka terowongan

Indeks hanya berguna jika Anda bisa menyebut antarmuka di baliknya. scutil --nwi mencantumkan informasi jaringan yang dipegang sistem, termasuk antarmuka utama dan keterjangkauan, sedangkan ifconfig -l memberi Anda namanya, di mana utun0 sampai utun9 adalah calon terowongan yang biasanya dibuat klien. Apple memakai scutil --dns sebagai contoh pemeriksaannya sendiri di panduan penyebaran, dan mendokumentasikan bagaimana Network Extension dapat merutekan domain terpilih ke resolver terpilih, yang merupakan mekanisme yang diungkap blok berlingkup itu.

Pemeriksaan yang memutuskan soal ini adalah apakah resolver berada di jalur yang dipasang terowongan:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

Jika route -n get mengembalikan gateway dan antarmuka yang tidak cocok dengan entri resolver, alamatnya bisa sepenuhnya benar namun tetap tak terjangkau. Terowongan terpisah yang hanya membawa subnet korporat membuang kueri yang diarahkan ke server DNS di luarnya, dan kegagalannya muncul sebagai batas waktu, itulah sebabnya keluaran konfigurasi tetap tampak bersih.

Tanyakan resolver sistem, lalu server

Tiga alat menjawab tiga pertanyaan berbeda, dan mencampuradukkannya menghasilkan sebagian besar kesimpulan keliru di bidang ini. dscacheutil -q host -a name melewati resolver sistem yang sama dengan yang dipakai aplikasi biasa, jadi blok berlingkup dan tambahan berlaku. dig tanpa argumen server membaca /etc/resolv.conf, yang bukan sumber kebenaran untuk resolusi berlingkup di macOS, dan sama sekali melewati aturan per domain. dig @address menjangkau tepat satu server dan tidak memberi tahu apa pun tentang pemilihan.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

Saat perintah pertama menjawab dan yang kedua mengembalikan NXDOMAIN, Anda telah menemukan pemisahan yang dicari dan tidak ada yang rusak. Saat yang pertama habis waktu sementara dig @10.20.0.53 menjawab, resolver bekerja tetapi tidak terjangkau di jalur yang dipilih terowongan, jadi langkah berikutnya adalah route -n get bukan mengubah pengaturan DNS. Jauhkan nama privat dari apa pun yang Anda tempelkan ke tiket atau catatan bersama.

Apa yang tidak bisa ditunjukkan keluaran

Beberapa lapisan duduk di atas atau di samping daftar resolver, dan masing-masing dapat mengirim kueri ke tempat yang tidak pernah disebut keluaran. Peramban dengan DNS aman aktif dapat beresolusi lewat saluran terenkripsinya sendiri, jadi halaman yang termuat saat dscacheutil habis waktu bukan kontradiksi. Proksi DNS yang dipasang perangkat lunak keamanan berjalan sebagai penyedia Network Extension dan meneruskan kueri sendiri, dan scutil --dns menunjukkan apa yang dikonfigurasi, bukan alamat hulu yang akhirnya dipakai proksi. Domain pencarian menambah kerutan ketiga: nama tanpa kualifikasi mendapat setiap sufiks terdaftar ditambahkan berurutan, sehingga blok yang menjawab bisa jadi blok yang tidak pernah Anda curigai.

Jawaban basi adalah hal termurah untuk disingkirkan dan paling sering dilewatkan:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

Jika keluaran berubah setelah pembersihan, statusnya tersimpan di cache dan keluaran sebelumnya menggambarkan terowongan yang sudah tidak ada. Jika tidak berubah, konfigurasinya memang begitu, dan pertanyaannya bergeser ke rute dan ke kebijakan aplikasi.

Runbook singkat untuk sebelum dan sesudah

Ambil garis dasar hanya di tempat kebijakan mengizinkan, dan simpan berkasnya di luar folder tersinkron mana pun. Urutan di bawah ini yang saya jalankan di mesin klien: ambil garis dasar, sambungkan, ambil lagi, lalu bandingkan dan cari.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

Baca perbedaannya per blok, bukan per baris. Resolver berlingkup baru yang membawa indeks antarmuka terowongan dan entri domain untuk sufiks privat adalah bentuk yang diharapkan. Resolver default baru yang menunjuk alamat publik adalah temuan yang layak diangkat ke pemilik profil klien. Lalu ulangi pencarian di dalam aplikasi yang benar-benar gagal, bukan hanya di shell, dan catat antarmuka dari route -n get di samping hasilnya.

Untuk membatalkan perubahan, putuskan sambungan dan ulangi pengambilan garis dasar. Jika blok berlingkup hilang, klien sudah membersihkan dirinya. Jika blok masih terdaftar terhadap antarmuka yang sudah tidak ada, statusnya basi, dan pembersihan plus penyambungan ulang adalah perbaikan paling lembut sebelum siapa pun menyentuh profil.

Empat pemeriksaan, dengan urutan ini: apakah ada blok resolver yang cocok dengan sufiks terpanjang nama; apakah blok itu terikat ke antarmuka yang dipasang terowongan; apakah rute ke server namanya memakai terowongan; dan apakah resolver sistem, bukan dig, mengembalikan jawabannya. Pemeriksaan pertama yang gagal memberi tahu Anda apakah harus mengubah kebijakan DNS, rute terowongan, atau aplikasinya. Jika keempatnya lolos dan nama tetap gagal, masalahnya ada di atas DNS, dan hal berikut yang perlu diperiksa adalah apa pun yang menjawab port 53 di depannya.