Apa itu DNS dan cara hubungkan domain ke VPS

Apakah itu DNS, dan mengapa domain anda belum mencapai VPS anda

DNS (domain name system) menukarkan nama seperti example.com kepada alamat IP (internet protocol) seperti 203.0.113.10. Pelayar tidak boleh bersambung kepada nama. Ia bersambung kepada alamat, jadi setiap pemuatan halaman bermula dengan soalan DNS dan jawapannya. Jika anda baru sahaja membeli domain dan sebuah VPS milik anda sendiri, dan tiada apa-apa yang dimuatkan, salah satu daripada dua perkara ini adalah benar: tiada rekod yang menghubungkan nama tersebut kepada alamat pelayan anda, atau rekod sudah wujud tetapi sesuatu di sepanjang laluan tersebut masih memberikan jawapan yang lama.

Kedua-dua situasi ini adalah normal, dan tidak bermakna ada kerosakan. Bahagian di bawah membincangkan perkara tersebut mengikut urutan yang akan anda temui, bermula dengan perkara yang paling banyak membuang masa: panel kawalan mana yang sebenarnya menyimpan rekod anda.

Setiap semakan di sini menggunakan dig, yang tidak dipasang secara lalai pada mesin Ubuntu atau Debian yang baharu.

sudo apt update && sudo apt install -y bind9-dnsutils

Registrar, nameserver, hos DNS: yang mana satu perlu disunting

Tiga nama ini menerangkan tugas yang berbeza. Kekeliruan antara ketiganya adalah punca paling biasa mengapa suntingan tidak memberikan sebarang kesan.

• Registrar ialah syarikat tempat anda membeli domain tersebut. Tugas kritikalnya ialah delegasi: ia memberitahu pendaftar yang mengendalikan TLD (top-level domain, bahagian .com) anda tentang nameserver mana yang berautoriti untuk domain anda.
• Nameserver berautoriti menyimpan rekod sebenar untuk zon anda. Zon ialah domain anda dan nama-nama di bawahnya.
• Hos DNS ialah pihak yang mengendalikan nameserver tersebut. Ia boleh jadi registrar itu sendiri, penyedia berasingan, atau bind9 yang dijalankan pada pelayan milik anda sendiri.

Anda membeli di registrar. Anda menyunting di hos DNS. Jika anda memindahkan domain anda ke nameserver penyedia lain, panel DNS milik registrar tersebut masih akan memaparkan zon, masih menyimpan suntingan anda, namun tiada sesiapa di internet yang akan bertanya kepada zon tersebut. Rekod-rekod itu memang wujud. Ia cuma tidak pernah dirujuk.

Ketahui di mana dunia membuat pertanyaan:

dig example.com NS +short
dig +trace example.com

Perintah pertama mencetak nameserver yang menjawab bagi domain tersebut pada hari ini. Perintah kedua menelusuri rantaian bermula dari pelayan akar dan mencetak rujukan yang diberikan oleh pelayan TLD, iaitu delegasi yang dikawal oleh registrar anda. Jika nama-nama tersebut tergolong dalam penyedia yang tidak anda kenali, penyedia itulah yang memiliki panel yang anda perlukan.

Bagaimana carian tunggal berfungsi

Empat pihak terlibat, dan setiap satu menyimpan salinan maklumat yang diperoleh.

1. Stub resolver pada mesin anda. Ia tidak melakukan carian. Ia bertanya kepada satu pelayan yang dikonfigurasikan dan mempercayai jawapan tersebut. Pada Ubuntu, /etc/resolv.conf biasanya merupakan symlink kepada /run/systemd/resolve/stub-resolv.conf dan menamakan 127.0.0.53, iaitu systemd-resolved yang berjalan secara setempat dengan cache tersendiri.
2. Recursive resolver. Ini ialah resolver yang dijalankan oleh ISP (pembekal perkhidmatan internet) anda, atau resolver awam seperti 1.1.1.1, atau resolver yang anda jalankan sendiri. Ia melakukan kerja sebenar untuk mencari jawapan.
3. Pelayan root dan TLD. Recursive resolver bertanya kepada pelayan root, yang tidak mengetahui alamat anda tetapi membalas dengan rujukan kepada pelayan .com. Pelayan tersebut membalas dengan rujukan kepada nameserver anda.
4. Authoritative nameserver. Ia tidak bertanya kepada sesiapa. Ia menjawab daripada zon anda dan menandakan jawapan tersebut sebagai autoritatif.

dig +trace example.com menunjukkan proses ini berlaku, kerana ia bermula dari root itu sendiri dan mencetak setiap rujukan dan bukannya bertanya kepada cache. Itu adalah cara terpantas untuk melihat sama ada delegasi dan zon tersebut sepadan.

Rekod DNS yang penting apabila anda menjalankan pelayan

• A: memetakan nama kepada alamat IPv4. example.com. A 203.0.113.10. Ini adalah rekod yang menghalakan domain anda ke VPS anda.
• AAAA: memetakan nama kepada alamat IPv6, seperti 2001:db8::10. Terbitkan rekod ini hanya apabila servis anda benar-benar mendengar pada alamat tersebut. Pelanggan pada rangkaian IPv6 akan mencuba jawapan AAAA terlebih dahulu, jadi alamat yang tidak mempunyai respons akan menyebabkan kelewatan pada setiap lawatan.
• CNAME: alias daripada satu nama kepada nama yang lain. www.example.com. CNAME example.com. menghantar pelawat www ke mana sahaja domain asas diselesaikan. CNAME tidak boleh wujud pada apex (example.com asas), kerana apex mesti membawa rekod SOA (start of authority) dan NS sendiri, dan CNAME tidak dibenarkan berkongsi nama dengan mana-mana rekod lain. Penyedia menawarkan penyelesaian di bawah nama seperti ALIAS, ANAME atau CNAME flattening.
• MX: tempat mel untuk domain dihantar. Ia membawa nama hos dan nombor keutamaan, dan nombor yang lebih rendah akan dicuba terlebih dahulu. MX mesti menghala ke nama yang mempunyai rekod alamat. Menghalakan MX ke CNAME adalah tidak sah, dan sesetengah pelayan penghantar akan menolaknya.
• TXT: teks bebas, digunakan untuk bukti dan polisi. Rekod pengesahan mel (SPF, DKIM, DMARC) berada di sini, begitu juga token ACME (automatic certificate management environment) yang mengeluarkan sijil wildcard.
• NS: nama pelayan yang melayani zon tersebut. Salinan yang menentukan ke mana dunia bertanya berada dalam zon induk dan datang daripada delegasi pendaftar anda, bukan salinan di dalam zon anda sendiri.

Dua perincian menyebabkan lebih banyak kekeliruan berbanding jenis rekod itu sendiri. Nama yang berakhir dengan titik adalah mutlak, jadi www.example.com. bermaksud tepat seperti itu dan tiada yang lain. Kebanyakan panel menjangkakan nama relatif dan menambah domain untuk anda, jadi menaip www.example.com ke dalam kotak nama akan memberikan anda www.example.com.example.com, yang tidak dapat diselesaikan oleh sesiapa pun. Perincian lain ialah @, yang dalam hampir setiap panel bermaksud apex: domain itu sendiri, tanpa subdomain.

Halakan rekod A ke VPS anda

Dapatkan alamat IP pelayan anda yang boleh dicapai melalui internet:

curl -4 https://ifconfig.me
ip -brief -4 address show

Seterusnya, cipta satu rekod pada hos DNS anda: jenis A, nama @, nilai alamat tersebut, dan TTL (time to live) 300. Tambah rekod kedua untuk www, sama ada satu lagi A dengan alamat yang sama atau satu CNAME yang menghala ke apex.

Sekarang, sahkan resolusi DNS tersebut, sebaik-baiknya daripada komputer riba anda dan bukannya daripada pelayan itu sendiri:

dig example.com A +short
dig @1.1.1.1 example.com A +short
dig @ns1.your-dns-host.net example.com A +short

Perintah pertama menggunakan laluan biasa mesin anda, termasuk cache. Perintah kedua melangkau cache tempatan anda dan bertanya kepada recursive resolver awam. Perintah ketiga bertanya terus kepada authoritative nameserver anda, jadi jawapannya adalah status terkini tanpa sebarang cache dalam laluan tersebut. Apabila perintah ketiga memulangkan alamat anda manakala perintah pertama tidak, DNS anda telah dikonfigurasikan dengan betul dan anda hanya perlu menunggu salinan cache lama tamat tempoh.

Penyelesaian nama tidak dimuatkan

Penyelesaian nama membuktikan DNS berfungsi. Ia tidak membuktikan apa-apa tentang pelayan web anda. Sebaik sahaja dig mengembalikan alamat yang betul, uji sambungan tersebut:

curl -I http://example.com

curl: (6) Could not resolve host: example.com ialah masalah DNS. curl: (7) Failed to connect to example.com port 80 after 21 ms: Connection refused bukan masalah DNS: nama telah diselesaikan dan paket telah sampai, jadi masalahnya ialah tiada apa-apa yang mendengar pada port tersebut. Permintaan yang tergantung dan kemudian tamat masa biasanya bermaksud firewall telah menggugurkan paket secara senyap dan bukannya menolaknya. Di sinilah DNS berhenti menjadi subjek, dan port dan soket pendengar serta peraturan firewall ufw pada VPS anda mengambil alih. Selepas sambungan selesai, baki pemuatan halaman ialah HTTP melakukan tugasnya.

Mengapa pelayar masih menunjukkan hos lama

Tiada proses penyebaran (propagation). Tiada pelayan yang menolak perubahan anda keluar kepada sesiapa pun. Pelayan nama autoritatif anda memegang nilai baharu sebaik sahaja anda menyimpannya, dan setiap salinan cache bagi jawapan sebelumnya kekal sah sehingga pemasa tersendiri tamat tempoh. Pemasa tersebut ialah TTL, dalam saat, yang dibawa oleh rekod itu apabila ia diberikan.

Salinan wujud di lebih banyak tempat daripada yang dijangkakan: cache pendek pelayar itu sendiri, stub resolver pada mesin, recursive resolver yang digunakan oleh rangkaian tersebut, dan mana-mana resolver yang dipasang oleh VPN pada klien. Setiap satunya menyimpan salinan tersebut sehingga tempoh TTL yang diterima. Dua orang pada dua rangkaian berbeza boleh melihat dua jawapan yang berbeza selama berjam-jam, dan kedua-dua mesin berkelakuan dengan betul.

Perhatikan kiraan detik terhadap caching resolver:

dig @1.1.1.1 example.com +noall +answer

Jalankannya dua kali, dengan selang beberapa saat. TTL dalam jawapan tersebut akan berkurangan. Apabila ia mencecah sifar, resolver akan membuang rekod tersebut dan bertanya kepada pelayan nama anda semula.

Terdapat cache kedua yang hampir tidak disedari oleh sesiapa: jawapan negatif. Apabila resolver diberitahu bahawa sesuatu nama tidak wujud, ia juga menyimpan NXDOMAIN tersebut, untuk tempoh masa yang ditetapkan oleh medan terakhir rekod SOA zon anda.

dig example.com SOA +short

Nombor terakhir pada baris tersebut ialah TTL negatif, selalunya 3600. Jadi, melakukan carian staging.example.com sebelum anda menciptanya boleh menyembunyikan rekod tersebut daripada anda selama satu jam penuh selepas anda menciptanya. Cipta rekod tersebut dahulu, kemudian buat pertanyaan mengenainya.

Menukar pelayan nama adalah lebih perlahan berbanding menukar rekod, dan sebabnya adalah mekanikal. Rekod delegasi dalam zon .com dihidangkan dengan TTL selama 172800 saat, iaitu dua hari, jadi resolver yang menyimpan cache pelayan nama lama anda boleh terus bertanya kepadanya selama tempoh tersebut. Inilah asal usul nasihat untuk "memberi masa sehingga 48 jam". Ia terpakai untuk perubahan pelayan nama, bukan untuk suntingan rekod biasa.

Rancang migrasi berdasarkan TTL dan bukannya melawannya:

1. Rendahkan TTL rekod kepada 300 dan simpan.
2. Tunggu lebih lama daripada TTL lama, supaya setiap salinan cache yang membawa nilai lama telah tamat tempoh.
3. Tukar alamat tersebut.
4. Setelah trafik beralih, naikkan semula TTL kepada 3600 atau lebih tinggi, kerana TTL yang rendah bermakna setiap resolver akan bertanya kepada pelayan nama anda dengan lebih kerap.

Untuk mengosongkan apa yang dipegang oleh mesin anda sendiri:

resolvectl flush-caches
resolvectl statistics

resolvectl statistics mencetak bahagian cache dengan pembilang hit dan miss, jadi sejurus selepas pembersihan (flush), carian seterusnya akan dipaparkan sebagai miss. Pelayar menyimpan cache yang berasingan, yang bermaksud Chrome masih boleh menggunakan jawapan lama selepas cache sistem dikosongkan. Kosongkan cache tersebut di chrome://net-internals/#dns. Periksa juga /etc/hosts, kerana baris yang tertinggal di sana akan mengatasi DNS pada mesin tersebut dan hanya pada mesin tersebut. getent hosts example.com menunjukkan jawapan yang akan benar-benar digunakan oleh sistem, termasuk /etc/hosts.

Sijil wildcard dibuktikan dengan rekod TXT

Pihak CA (certificate authority) menyemak kawalan ke atas sesuatu nama sebelum ia mengeluarkan sijil. Cabaran HTTP-01 menghidangkan fail melalui port 80 pada hostname yang tepat, yang berfungsi dengan baik untuk satu nama sahaja. Sijil wildcard meliputi *.example.com, iaitu set hostname terbuka yang tidak membolehkan CA mengambil fail daripadanya, jadi Let's Encrypt hanya mengeluarkan sijil wildcard melalui cabaran DNS-01. Anda menerbitkan rekod TXT pada _acme-challenge.example.com yang mengandungi token yang diberikan oleh CA, dan kawalan ke atas zon tersebut menjadi buktinya.

Ini menjadikan hos DNS anda sebahagian daripada pembaharuan sijil. Certbot perlu mencipta dan memadam rekod TXT tersebut pada setiap pembaharuan tanpa campur tangan anda, jadi ia memerlukan API dan pemalam yang sepadan untuk penyedia anda. Apabila pengesahan gagal, mesej biasa yang muncul ialah DNS problem: NXDOMAIN looking up TXT for _acme-challenge.example.com, yang bermaksud CA membuat permintaan sebelum rekod tersebut kelihatan: sama ada ia tidak pernah disimpan, atau jawapan negatif masih dalam cache. Prosedur penuh terdapat dalam panduan sijil wildcard dengan cabaran DNS-01.

Apabila VPN mengambil alih resolver anda

Klien VPN (virtual private network) biasanya menggantikan resolver sistem semasa ia disambungkan. Ini kerana menghantar carian ke rangkaian tempatan akan mendedahkan nama setiap laman yang anda lawati kepada rangkaian tersebut. Ini adalah kelakuan yang betul, namun ia boleh gagal dalam dua keadaan.

Jika terowong diaktifkan dan nama berhenti diselesaikan (resolve) sementara alamat IP masih berfungsi, resolver yang dipasang oleh klien tidak boleh dicapai dari dalam terowong. ping 1.1.1.1 berjaya dan curl https://example.com mengembalikan curl: (6) Could not resolve host: example.com. Jika sebaliknya terowong diaktifkan dan carian masih pergi ke rangkaian tempatan anda, trafik anda disalurkan melalui terowong manakala resolver tempatan terus melihat setiap nama yang anda minta.

resolvectl status

Perintah tersebut mencetak resolver yang digunakan bagi setiap pautan, supaya anda boleh melihat yang mana satu dipasang oleh terowong dan sama ada ia adalah resolver yang anda inginkan. Terowong WireGuard menetapkan perkara ini daripada baris DNS = dalam konfigurasi klien, dan membaiki DNS apabila WireGuard mengambil alih resolver merangkumi kes systemd-resolved dan resolvconf secara terperinci.

Kod balasan dan maksud setiap satunya

• NXDOMAIN: pelayan autoritatif menyatakan bahawa nama tersebut tidak wujud. Semak ejaan, semak sama ada terdapat akhiran domain berganda, dan pastikan anda telah menyunting zon yang ditunjuk oleh delegasi anda.
• NOERROR dengan ANSWER SECTION kosong: nama tersebut wujud, tetapi ia tidak mempunyai rekod bagi jenis yang anda minta. Meminta AAAA sedangkan hanya A yang wujud akan menghasilkan keputusan ini.
• SERVFAIL: resolver telah mencuba tetapi tidak dapat memberikan jawapan. Dua punca lazim ialah pelayan autoritatif yang tidak pernah membalas, dan kegagalan pengesahan DNSSEC (domain name system security extensions). Uji dengan dig @1.1.1.1 example.com A +cd, yang melumpuhkan pengesahan. Jawapan dengan +cd dan SERVFAIL tanpa pengesahan bermakna tandatangan adalah puncanya, yang sering berlaku selepas pemindahan pelayan nama di mana pihak induk masih menerbitkan rekod DS (delegation signer) yang lama.
• REFUSED: pelayan yang anda tanya tidak akan menjawab soalan tersebut, biasanya kerana anda menghalakan dig kepada pelayan autoritatif bagi domain yang tidak diselenggaranya.
• ;; connection timed out; no servers could be reached: dig tidak pernah sampai ke resolver. Ini adalah masalah rangkaian atau resolver di pihak anda, jadi domain tersebut bukanlah puncanya.

ping: example.com: Temporary failure in name resolution adalah kelas kegagalan yang sama yang dilaporkan oleh glibc dan bukannya oleh dig.

Patutkah anda menjalankan nameserver pada VPS sendiri?

Anda boleh melakukannya. bind9, knot atau nsd akan menghoskan zon anda daripada pelayan tersebut, dan ia memberikan anda lebih banyak pengetahuan tentang DNS berbanding mana-mana panel kawalan. Bantahan terhadap perkara ini adalah bersifat praktikal. Sesuatu domain sepatutnya mempunyai sekurang-kurangnya dua nameserver pada rangkaian yang berasingan, jadi satu VPS sahaja akan menjadi titik kegagalan tunggal bagi setiap servis pada domain tersebut, termasuk e-mel. Nameserver yang dinamakan di dalam domain yang dihoskannya memerlukan glue records di pendaftar domain, iaitu alamat ns1.example.com yang disimpan dalam zon induk, kerana jika tidak, carian tidak mempunyai cara untuk bermula. Apabila resolver tidak dapat mencapai nameserver anda, ia tidak akan beralih ke laman web anda: seluruh domain akan hilang bagi pengguna tersebut. DNS terhos dengan API adalah pilihan yang lebih rendah risikonya bagi kebanyakan orang. Menjalankan caching resolver pada VPS anda untuk mesin sendiri adalah tugas yang berbeza, dan komitmen yang jauh lebih kecil.

FAQ

Mengapakah perubahan DNS saya belum tersebar?

Tiada istilah penyebaran (propagation). Pelayan nama autoritatif anda menyimpan nilai baharu sebaik sahaja anda menyimpannya, dan setiap penyelesai (resolver) yang telah membuat pertanyaan akan menyimpan salinan cache sehingga tempoh TTL yang diterima tamat. Tanya pelayan autoritatif secara terus menggunakan dig @ns1.your-dns-host.net example.com A +short. Jika ia memulangkan alamat baharu, perubahan tersebut telah aktif dan selebihnya hanyalah isu cache. Jika anda menukar pelayan nama dan bukannya rekod, jangkakan masa yang lebih lama kerana delegasi TLD diberikan dengan TTL selama dua hari.

Bagaimanakah cara untuk mengetahui pelayan nama yang sebenarnya digunakan oleh domain saya?

dig example.com NS +short memaparkan pelayan nama yang menjawab bagi domain tersebut sekarang, dan dig +trace example.com menunjukkan rantaian rujukan daripada root, termasuk delegasi yang diberikan oleh pelayan TLD. Jika nama-nama tersebut bukan penyedia yang panelnya sedang anda sunting, itulah ralat anda. Sama ada sunting rekod pada penyedia yang dinamakan dalam delegasi, atau tukar delegasi pada pendaftar domain anda supaya ia menghala ke tempat yang anda mahukan.

Domain saya selesai diselesaikan (resolve) tetapi laman web masih tidak dimuatkan. Apa seterusnya?

Tugas DNS selesai sebaik sahaja dig example.com A +short memulangkan alamat pelayan anda. Selepas itu, masalahnya ialah sambungan. curl -I http://example.com yang memulangkan Connection refused bermakna tiada apa-apa yang mendengar pada port tersebut. Permintaan yang tergantung sehingga tamat tempoh (timeout) bermakna firewall telah menggugurkan paket tersebut. Pastikan pelayan web anda sedang berjalan dan terikat pada alamat awam, kemudian periksa firewall pada pelayan dan firewall rangkaian berasingan dalam panel kawalan penyedia anda.

Mengapakah saya tidak boleh meletakkan CNAME pada domain root saya?

CNAME menyatakan bahawa sesuatu nama adalah alias bagi nama lain, dan nama yang mempunyai CNAME tidak dibenarkan membawa sebarang rekod lain. Domain root anda mesti membawa rekod SOA dan NS supaya ia wujud sebagai zon, jadi ia tidak boleh menjadi CNAME. Gunakan rekod A yang menyimpan alamat pada root, atau gunakan ciri penyedia yang dijual sebagai ALIAS, ANAME atau CNAME flattening, yang menyimpan sesuatu nama dan menjawab pertanyaan dengan alamat yang diselesaikan oleh nama tersebut pada masa ini.