Cara Domain dan DNS Berfungsi: Panduan untuk Bukan Pembangun

Domain ialah nama yang orang taip untuk sampai ke laman anda, seperti example.com, dan DNS (Domain Name System) ialah direktori internet yang menterjemahkan nama itu kepada tempat laman anda sebenarnya berada. Anda menyewa domain daripada pendaftar, kemudian menambah rekod DNS yang memberitahu “laman web berada di sana” dan “e-mel pergi ke sini.” Menyambung domain tersuai ke aplikasi kebanyakannya ialah soal menambah rekod yang betul di tempat yang betul dan menunggu ia berkuat kuasa.

Mengapa ia penting apabila membina dengan AI

Pembina aplikasi AI boleh menulis dan menghoskan aplikasi anda, tetapi domain anda berada di luar aplikasi itu — selalunya dengan syarikat berasingan, dalam panel kawalan yang penuh dengan jenis rekod yang tidak biasa. Di sinilah banyak pelancaran terhenti: aplikasi sudah sedia, tetapi domain menunjukkan ralat, atau e-mel tiba-tiba berhenti selepas perubahan DNS.

Sedikit pemahaman membawa jauh. Anda akan tahu rekod mana yang diminta oleh hos anda, mengapa ia belum berfungsi, dan cara mengelak daripada merosakkan perkara (seperti e-mel) yang sudah bergantung pada domain anda.

Analogi harian

Bayangkan senarai kenalan telefon anda.

Anda tidak mengingati nombor rakan anda; anda ketik namanya dan telefon mencarinya. DNS melakukan perkara yang sama untuk internet: anda taip example.com, dan DNS mencari nombor (alamat IP) pelayan untuk disambungkan.

• Domain ialah nama kenalan.
• Pendaftar ialah syarikat yang secara rasmi merekodkan bahawa nama itu milik anda.
• Rekod DNS ialah butiran yang disimpan di bawah nama itu: nombor telefon, alamat e-mel, alamat rumah.
• Pelayan nama ialah buku kenalan mana yang rasmi untuk nama itu.
• Caching ialah telefon anda mengingati nombor untuk seketika. Jika rakan anda menukar nombor, sesetengah telefon akan terus memanggil yang lama sehingga salinan yang disimpan disegarkan — itulah “perambatan” DNS.

Bahagian-bahagian nama domain

Ambil app.example.com:

Anda tidak membeli domain secara terus; anda mendaftarkannya untuk tempoh tertentu (biasanya setahun atau lebih) dan memperbaharuinya. Jika ia tamat tempoh, orang lain boleh mendaftarkannya.

Bagaimana carian DNS berfungsi

Apabila seseorang menaip app.example.com:

1. Pelayar bertanya kepada penyelesai DNS — biasanya dikendalikan oleh pembekal internet mereka atau perkhidmatan awam — untuk alamatnya.
2. Jika penyelesai mempunyai jawapan cache yang segar, ia membalas dengan segera.
3. Jika tidak, ia bergerak ke bawah hierarki: pelayan root menunjuk kepada pelayan .com, yang menunjuk kepada pelayan nama domain anda.
4. Pelayan nama anda memulangkan rekod yang anda tetapkan, seperti CNAME ke hos anda atau rekod A dengan alamat IP.
5. Penyelesai menyimpan jawapan dalam cache untuk TTL (time to live) rekod itu dan menyerahkannya kepada pelayar, yang menyambung ke pelayan.

Ini biasanya berlaku dalam milisaat.

Jenis rekod DNS yang akan anda gunakan

Beberapa peraturan yang patut diketahui:

• CNAME tidak boleh berkongsi nama dengan rekod lain. Itulah sebabnya CNAME standard tidak boleh diletakkan pada domain akar, yang sentiasa mempunyai NS dan rekod lain. Banyak pembekal DNS menawarkan penyelesaian alternatif yang dipanggil ALIAS, ANAME atau CNAME flattening.
• Rekod TXT melakukan banyak kerja e-mel. SPF menyenaraikan siapa yang boleh menghantar e-mel untuk domain anda; DKIM menerbitkan kunci untuk mengesahkan tandatangan; DMARC memberitahu penerima apa yang perlu dilakukan dengan e-mel yang gagal pemeriksaan tersebut.
• Nombor MX yang lebih rendah bermakna keutamaan yang lebih tinggi. E-mel mencuba yang terendah dahulu.

Perambatan dan TTL

“Perambatan” menjadikan kedengaran seperti perubahan tersebar perlahan-lahan di seluruh internet. Apa yang sebenarnya berlaku ialah caching: penyelesai menyimpan salinan setiap jawapan untuk TTL-nya, dan hanya bertanya semula apabila ia tamat. Jadi:

• Rekod baharu yang belum pernah dicari selalunya berfungsi dalam beberapa minit.
• Menukar rekod sedia ada mengambil masa sehingga TTL lamanya untuk dilihat di mana-mana.
• Menukar pelayan nama boleh mengambil masa sehingga sehari atau dua, kerana rekod itu disimpan dalam cache lebih lama di peringkat TLD.

Petua berguna: sebelum perubahan yang dirancang, rendahkan TTL rekod (katakan kepada beberapa minit), tunggu TTL lama tamat, kemudian buat perubahan.

Contoh bekerja: menyambung aplikasi tempahan ke domain anda

Anda memiliki salonanda.com. Laman web semasa anda dan e-mel Google Workspace sudah menggunakannya. Anda telah membina aplikasi tempahan dan mahu ia berada di book.salonanda.com.

1. Cari di mana DNS anda diuruskan. Ia mungkin pendaftar anda atau pembekal DNS berasingan. Rekod NS anda memberitahu anda.
2. Tambah CNAME untuk book yang menunjuk ke sasaran yang diberikan oleh hos aplikasi anda.
3. Tambah sebarang rekod TXT yang diminta oleh hos anda untuk membuktikan pemilikan, jika ia menggunakannya.
4. Biarkan rekod MX dan TXT e-mel tidak disentuh. E-mel terus berfungsi kerana anda tidak mengubahnya.
5. Sahkan dalam hos anda apabila DNS sudah dikemas kini. Hos kemudian mengeluarkan sijil HTTPS untuk book.salonanda.com.
6. Uji pada telefon menggunakan data mudah alih, yang menggunakan penyelesai dan cache yang berbeza daripada Wi-Fi rumah anda.

Jika anda mahukan aplikasi di domain akar salonanda.com sebaliknya, anda memerlukan rekod A atau ciri ALIAS/flattening pembekal DNS anda — dan anda akan menggantikan laman web semasa anda di situ. Untuk langkah lanjut, lihat cara menyambung domain tersuai.

Kesilapan dan salah faham yang biasa

• “Domain dan hosting adalah perkara yang sama.” Domain ialah nama; hosting ialah tempat aplikasi berjalan. DNS menghubungkan kedua-duanya.
• Menggunakan rekod A apabila hos meminta CNAME (atau sebaliknya). Ikut arahan hos dengan tepat.
• Salah taip sasaran. Satu aksara yang salah dalam sasaran CNAME menyebabkan pengesahan gagal.
• Menukar pelayan nama tanpa menyalin rekod. Memindahkan DNS ke pembekal baharu tanpa mencipta semula rekod MX dan TXT ialah cara klasik untuk memutuskan e-mel.
• Proksi apabila tidak sepatutnya. Sesetengah pembekal DNS, seperti Cloudflare, boleh memproksi trafik. Sesetengah hos memerlukan rekod ditetapkan kepada “DNS only” supaya ia boleh mengeluarkan sijil.
• Memadam rekod TXT yang “tidak diketahui”. Ia selalunya rekod pengesahan atau e-mel yang sesuatu bergantung padanya.
• Membiarkan domain tamat tempoh. Hidupkan pembaharuan automatik dan pastikan kad pembayaran sentiasa terkini.

Apa yang perlu diminta daripada pembina AI anda

DNS berada di luar kod anda, jadi ini lebih kepada perkara yang perlu anda tanyakan mengenainya:

• “Apakah rekod DNS tepat yang saya perlukan untuk app.domainsaya.com — jenis, nama dan nilai?”
• “Adakah perubahan ini akan menjejaskan e-mel saya?”
• “Domain saya menunjukkan ralat selepas menambah rekod. Apa yang patut saya semak?”
• “Tambah URL kanonik dan pengalihan yang betul supaya www dan bukan www tidak kedua-duanya memaparkan laman.”
• “Sediakan penghantaran e-mel dari domain saya — apakah rekod SPF, DKIM dan DMARC yang saya perlukan?” Lihat cara menghantar e-mel dari aplikasi anda.

Domain tersuai di Mythex

Setiap aplikasi Mythex yang diterbitkan mendapat alamat namaanda.mythex.app. Pada Pro anda boleh menggunakan domain anda sendiri: beli satu dalam Mythex (pendaftaran dicaj berasingan, dan DNS untuk domain yang dibeli diuruskan untuk anda), atau sambungkan yang sudah anda miliki dengan menambah CNAME daripada subdomain seperti app.example.com ke alamat namaanda.mythex.app aplikasi anda, kemudian klik Verify. HTTPS dikeluarkan secara automatik. Jika DNS anda berada di Cloudflare, tetapkan rekod itu kepada “DNS only.” Subdomain disyorkan; domain akar bergantung pada sokongan ALIAS atau flattening pembekal DNS anda. Dokumentasi domain tersuai menerangkan setiap langkah, dan harga menunjukkan apa yang disertakan dalam Pro.

Soalan lazim