Mengapa MagicDNS me-resolve perangkat tetapi bukan nama host kantor

MagicDNS memberi setiap perangkat di sebuah tailnet nama yang diturunkan dari nama mesinnya dan domain DNS tailnet itu. Nama itu dibuat oleh Tailscale dan dijawab melalui jalur resolver Tailscale. Nama host kantor seperti files.office.example milik zona yang tidak pernah ditulis Tailscale, jadi mengganti nama perangkat tidak dapat membuatnya. Kedua ruang nama hidup berdampingan; mereka hanya punya pemilik berbeda.

Mekanisme itu berada di balik laporan yang sangat umum: host Tailscale menjawab, dan server file tetap mengembalikan galat resolusi.

Dua ruang nama, dua pemilik

Nama perangkat dihasilkan dari nama host mesin itu sendiri, tabrakan diselesaikan oleh Tailscale, dan hasilnya hidup di bawah domain tailnet. Zona kantor dipelihara oleh siapa pun yang menjalankan resolver kantor, dengan catatan dibuat oleh administrator atau melalui pendaftaran dinamis. Nama pendek menyembunyikan perbedaannya: files mungkin perluasan sufiks pencarian yang dijawab DNS kantor, perangkat tailnet, atau tidak sama sekali. Kueri nama lengkap menunjukkan sistem mana yang benar-benar menjawab.

Mengubah nama mesin router subnet tidak melakukan apa pun untuk zona kantor. Itu mengganti nama satu perangkat Tailscale dan membiarkan catatan di server kantor tak tersentuh, itulah sebabnya ganti nama dan coba lagi tidak pernah bertemu.

Arahkan zona kantor ke resolver-nya

DNS terpisah Tailscale mengirim kueri untuk domain terpilih ke server nama yang Anda tentukan, dan semua yang lain mengikuti kebijakan sisanya. Tambahkan domain yang benar-benar dilayani resolver kantor, bukan sufiks pencarian yang kebetulan Anda ketik. Sufiks pencarian memberi tahu klien apa yang harus ditambahkan; itu tidak memberi tahu resolver ke mana harus melihat. Kedua pengaturan itu tampak serupa di konsol dan berperilaku sangat berbeda.

Server nama terbatas harus otoritatif untuk domain yang terkait dengannya, atau jawabannya akan berupa rujukan, bukan alamat.

Keterjangkauan datang sebelum resolusi

Klien juga harus menjangkau server nama itu. Untuk resolver di LAN privat, rute subnet harus diiklankan dan diterima, kebijakan akses harus mengizinkan kueri, dan jalur balik harus ada. Alamat DNS yang benar di konsol admin hanya membuktikan bahwa konfigurasi disimpan. Jika paket tidak dapat menjangkau resolver, gejalanya adalah batas waktu, yang terlihat berbeda dari jawaban otoritatif bahwa catatan semacam itu tidak ada.

Perbedaan itu bersifat diagnostik. Batas waktu menunjuk ke perutean atau kebijakan, sementara jawaban negatif seketika menunjuk ke catatan atau zona. Baca mana yang Anda dapatkan sebelum mengubah pengaturan DNS apa pun.

Pisahkan kegagalan nama dari kegagalan layanan

Jika sumber daya menjawab di alamat privatnya tetapi tidak dengan nama host, penyelidikan tetap di DNS. Jika keduanya tidak berhasil, perbaiki perutean atau layanan lebih dulu, karena nama yang ter-resolve ke alamat tak terjangkau bukanlah kemajuan. Kueri nama lengkap dan catat server mana yang menjawab. Di macOS sebagian alat baris perintah menempuh jalur berbeda dari aplikasi biasa, sehingga terminal dig dan peramban dapat berbeda pendapat tentang nama yang sama.

Ulangi pengujian dengan node keluar dipilih jika itu mode normal bagi perangkat. Penanganan DNS node keluar berbeda dari konfigurasi tanpa node keluar, dan menguji hanya dalam satu mode dapat melewatkan kegagalan yang benar-benar dilihat pengguna.

Catat zona, alamat resolver, dan rute yang membawa kueri. Ketiganya menjelaskan sebagian besar kejutan MagicDNS tanpa putaran penggantian nama lagi.