DNS Dijelaskan: Apa Sebenarnya Ia Kawal

Kebanyakan pemilik perniagaan hanya berdepan DNS dua kali: sekali semasa laman web atau e-mel mula-mula disediakan, dan sekali lagi — biasanya dengan sedikit panik — apabila sesuatu berhenti berfungsi selepas perubahan yang tiada siapa ingat dibuat. Ia salah satu bahagian paling tidak kelihatan dalam menjalankan laman web, sehinggalah ia merosakkan sesuatu. Panduan ini menerangkan apa sebenarnya DNS kawal, apa berlaku di sebalik tabir antara menaip domain dan laman dimuatkan, rekod yang penting untuk perniagaan kecil, di mana sebenarnya untuk menukarnya, dan beberapa kesilapan yang bertanggungjawab atas hampir semua gangguan berkaitan DNS.

Apa sebenarnya DNS lakukan

Setiap peranti di internet sebenarnya dicari melalui alamat berangka, bukan nama. DNS ialah sistem yang memetakan nama domain yang orang sebenarnya taip — atau klik daripada hasil carian — kepada alamat tersembunyi itu, sama seperti buku telefon memetakan nama seseorang kepada nombor mereka. Apabila seseorang melawat yourdomain.com, pelayar mereka bertanya DNS "ke mana domain ini mengarah?", mendapat jawapan dalam sepersekian saat, dan memuatkan laman daripada situ. Tiada apa-apa kandungan laman web anda berada dalam DNS itu sendiri — ia semata-mata buku alamat yang membawa pelawat ke tempat yang betul, dan carian yang sama berlaku lagi, secara berasingan, setiap kali pelayan mel perlu menghantar e-mel ke domain anda.

Bagaimana carian DNS berfungsi, langkah demi langkah

Satu lawatan ke laman web mencetuskan rantaian carian pendek yang kebanyakan orang tidak pernah lihat, setiap satu disemak sebelum yang seterusnya ditanya:

• Cache pelayar dan peranti. Pelayar dan sistem operasi mula-mula menyemak sama ada mereka sudah tahu jawapan daripada lawatan baru-baru ini, dan jika ya, terus memuatkan laman.
• Resolver rekursif. Jika tiada dalam cache, permintaan pergi ke resolver — biasanya dikendalikan oleh penyedia internet pelawat atau perkhidmatan awam — yang melakukan kerja sebenar mencari jawapan bagi pihak pelawat.
• Pelayan root dan TLD. Resolver bertanya pelayan root internet pelayan mana yang bertanggungjawab untuk sambungan domain itu (.com, .my dan sebagainya), kemudian bertanya registry sambungan itu nameserver mana yang mengendalikan domain tertentu.
• Nameserver berkuasa. Resolver kemudian bertanya nameserver domain itu sendiri — yang ditetapkan di pendaftar — untuk rekod sebenar, seperti rekod A yang mengarah ke pelayan laman web.
• Jawapan dipulangkan dan disimpan dalam cache. Resolver memberikan jawapan kembali kepada pelayar, yang menyambung ke alamat pelayan itu, dan jawapan itu disimpan dalam cache untuk kali seterusnya, selama TTLnya membenarkan.

Semua ini biasanya selesai dalam masa kurang sesaat. Ia hanya kelihatan apabila satu langkah dalam rantaian itu memulangkan jawapan yang salah — biasanya kerana rekod baru sahaja ditukar dan jawapan lama yang disimpan dalam cache masih disajikan dari suatu tempat dalam rantaian itu.

Rekod DNS yang sebenarnya penting untuk perniagaan kecil

Kebanyakan domain hanya memerlukan segelintir jenis rekod dalam praktik. Rekod A mengarahkan domain — atau bahagian tertentu, seperti subdomain — terus ke alamat IP pelayan yang menghoskan laman web anda; inilah rekod yang menjadikan yourdomain.com memuatkan laman anda. Rekod CNAME mengarahkan satu nama domain ke domain lain berbanding ke alamat IP, paling biasa digunakan untuk menjadikan www.yourdomain.com menyelesaikan ke tempat yang sama seperti yourdomain.com. Rekod MX memberitahu internet pelayan mel mana yang mengendalikan e-mel untuk domain anda, jadi mesej yang dihantar ke [email protected] benar-benar sampai ke peti masuk anda. Rekod TXT menyimpan tetapan berasaskan teks berbanding menghala apa-apa — kegunaan paling biasa hari ini ialah SPF, DKIM dan DMARC, dibincangkan lebih lanjut di bawah, yang membantu pelayan mel penerima mengesahkan e-mel yang mendakwa daripada domain anda adalah tulen, bukan dipalsukan. Rekod NS sedikit berbeza daripada yang lain: ia rekod, disimpan di registry, yang menyatakan nameserver mana yang berkuasa bagi domain itu pada peringkat pertama.

Jenis rekod DNS pada pandangan pertama

Di mana DNS anda sebenarnya diuruskan

Bahagian ini paling mengelirukan orang berbanding mana-mana bahagian lain DNS: DNS tidak secara automatik terikat kepada di mana domain didaftarkan. Apa yang sebenarnya penting ialah nameserver mana yang sedang digunakan oleh domain itu. Jika domain masih menggunakan nameserver lalai pendaftar, DNS diuruskan daripada panel kawalan pendaftar. Jika ia telah diarahkan ke nameserver penyedia hosting pula — biasa apabila domain dan hosting berada dengan syarikat yang sama, atau selepas migrasi — DNS diuruskan daripada akaun hosting sebaliknya, dan tetapan DNS pendaftar sendiri secara berkesan diabaikan. Sebelum menukar apa-apa, berbaloi untuk mengesahkan nameserver mana yang sedang digunakan oleh domain itu, yang mana-mana panel kawalan pendaftar atau hos akan tunjukkan.

Nameserver berbanding rekod DNS: siapa kawal apa

Kedua-dua lapisan ini mudah dikelirukan kerana kedua-duanya berada di bawah perkataan "DNS." Nameserver ditetapkan sekali, pada peringkat registry, melalui pendaftar domain — ia menyatakan pelayan syarikat mana yang berkuasa bagi domain itu. Rekod — A, CNAME, MX, TXT dan selebihnya — berada dalam fail zon nameserver itu sendiri, dan di situlah perubahan harian berlaku. Mengarahkan domain ke nameserver baharu memindahkan seluruh fail zon ke tempat lain; mengedit satu rekod menukar satu baris dalam fail zon mana sahaja yang sedang berkuasa.

Kenapa perubahan DNS tidak muncul serta-merta

Setiap rekod DNS membawa TTL (time to live) — tempoh yang memberitahu setiap pelayan lain di internet berapa lama untuk terus guna jawapan yang sudah ada sebelum menyemak semula. TTL yang pendek, seperti 300 saat (lima minit), bermakna perubahan boleh muncul dengan pantas; yang lebih panjang, seperti 86,400 saat (24 jam) dan biasa pada rekod yang tidak dijangka berubah kerap, boleh mengambil masa sehingga 24–48 jam untuk kelihatan di mana-mana, kerana rangkaian berbeza di seluruh dunia menyegarkan cache tempatan mereka mengikut jadual sendiri berbanding sekali gus. Sebelum perubahan yang dirancang — migrasi laman web, menukar penyedia e-mel — adalah amalan baik untuk menurunkan TTL sehari atau dua lebih awal, supaya pertukaran akhirnya merebak lebih pantas sebaik ia dibuat.

Merancang perubahan DNS tanpa gangguan

Kebanyakan gangguan berkaitan DNS berlaku kerana perubahan dibuat pada masa yang sama perkara yang bergantung kepadanya belum sedia lagi. Urutan pendek dan terancang mengelakkan itu:

• Turunkan TTL dahulu. Sehari atau dua sebelum perubahan dirancang, kurangkan TTL pada rekod yang ingin anda sentuh, supaya pertukaran akhirnya kelihatan lebih cepat berbanding tersekat di belakang tempoh cache yang panjang.
• Sediakan destinasi sebelum mengarahkan apa-apa ke sana. Sahkan pelayan baharu sedang menghoskan laman web, atau penyedia mel baharu sedang menerima mel, sebelum sebarang rekod ditukar — bukan sebaliknya.
• Tukar satu rekod pada satu masa. Kemas kini rekod, sahkan ia menyelesaikan dengan betul menggunakan alat carian DNS, kemudian beralih ke rekod seterusnya berbanding mengedit beberapa rekod sekali duduk.
• Kekalkan destinasi lama berjalan untuk tempoh penampan. Jangan nyahaktifkan pelayan atau peti mel lama serta-merta — sesetengah pelawat dan pelayan mel masih akan menggunakan jawapan lama yang disimpan dalam cache buat seketika.
• Naikkan semula TTL sebaik keadaan stabil. TTL yang pendek berguna semasa migrasi; dibiarkan pendek secara kekal, ia menambah beban yang tidak perlu tanpa sebarang manfaat berterusan.

DNS dan kebolehhantaran e-mel: SPF, DKIM dan DMARC

Selain rekod MX yang menghala mel masuk, tiga rekod berasaskan TXT semakin menentukan sama ada mel keluar sampai ke peti masuk atau peti spam. Rekod SPF menyenaraikan pelayan mel mana yang dibenarkan menghantar e-mel bagi pihak domain, supaya pelayan penerima boleh menolak mesej yang mendakwa daripada domain itu tetapi sebenarnya dihantar dari tempat lain. DKIM melampirkan tandatangan kriptografi pada mel keluar yang membuktikan ia tidak diubah semasa dalam transit dan benar-benar datang daripada pelayan yang dibenarkan. DMARC dibina atas kedua-duanya, memberitahu pelayan mel penerima apa yang perlu dilakukan dengan mesej yang gagal semakan itu — kuarantin, tolak, atau sekadar laporkan. Tiada satu pun ini diperlukan untuk laman web berfungsi, tetapi penyedia peti mel utama semakin menganggap domain tanpanya lebih berkemungkinan spam, yang penting untuk mana-mana perniagaan yang menghantar invois, sebut harga atau e-mel pemasaran daripada domain sendiri.

Kesilapan biasa

• Menukar atau memadam rekod MX secara tidak sengaja. Ini adalah cara paling biasa perniagaan kehilangan e-mel masuk secara senyap — tanpa mesej ralat, kerana ia hanya berhenti sampai berbanding dipulangkan semula.
• Mengarahkan rekod A ke pelayan baharu sebelum ia sedia. Menukar domain ke pelayan baharu semasa migrasi sebelum pelayan itu benar-benar boleh menghoskan laman menyebabkan laman web langsung terputus tanpa sebab.
• Terlupa mengemas kini SPF selepas menukar penyedia e-mel. Rekod SPF lama yang tidak menyenaraikan pelayan penyedia baharu boleh menyebabkan e-mel sah ditanda sebagai spam atau ditolak sepenuhnya.
• Membiarkan TTL tinggi menjelang migrasi yang dirancang. TTL panjang yang ditetapkan pada hari pertukaran bermakna jawapan lama terus disajikan sehingga 24–48 jam selepas yang baharu aktif.
• Mengedit beberapa rekod sekali duduk tanpa pengesahan di antaranya. Satu kesilapan taip dalam sekumpulan perubahan sukar dikesan sehingga sesuatu — biasanya e-mel — sudah rosak selama berjam-jam.
• Menganggap DNS terikat kepada pendaftar. Mencari rekod dalam panel pendaftar sedangkan domain sebenarnya diarahkan ke nameserver hos membazirkan masa dan boleh menyebabkan fail zon yang salah dan tidak aktif diedit sepenuhnya.

Di mana Gotka Technologies berperanan

Sama ada domain atau hostingnya berada dengan Gotka, rekod DNS diuruskan daripada kawasan pelanggan yang sama yang sudah digunakan untuk bil dan sokongan — tiada log masuk atau alat berasingan diperlukan. Pendaftaran domain Gotka menyertakan kunci domain dan perlindungan privasi WHOIS sebagai piawai, dan pelan Hosting Awan — bermula dengan Go AI Lite pada RM17.80/bulan untuk tempoh 36 bulan — menyertakan migrasi percuma, jadi DNS diuruskan dengan betul sebagai sebahagian daripada memindahkan laman web berbanding dibiarkan untuk pemilik menguraikannya sendiri. Untuk bahagian pendaftaran secara khusus, panduan kami tentang memilih antara domain .my dan .com membincangkan apa yang perlu diputuskan sebelum DNS pun terlibat.

Istilah utama dalam panduan ini

• DNS (Domain Name System): sistem sejagat internet yang menterjemahkan nama domain kepada alamat pelayan yang sebenarnya digunakan komputer.
• Nameserver: pelayan, ditetapkan di pendaftar, yang berkuasa bagi domain dan menyimpan fail zon rekodnya.
• Fail zon: set rekod DNS — A, MX, TXT dan selebihnya — yang disimpan oleh nameserver semasa domain.
• Rekod A: mengarahkan domain atau subdomain terus ke alamat IP pelayan.
• Rekod CNAME: mengarahkan satu nama domain ke nama domain lain berbanding ke alamat IP.
• Rekod MX: memberitahu internet pelayan mel mana yang mengendalikan e-mel masuk untuk domain.
• TTL (time to live): berapa lama pelayan lain patut simpan jawapan DNS dalam cache sebelum menyemak semula yang baharu.
• Propagasi: tempoh semasa perubahan DNS menjadi kelihatan di seluruh rangkaian berbeza di dunia, dikawal oleh TTL.
• SPF / DKIM / DMARC: rekod berasaskan TXT yang membolehkan pelayan mel penerima mengesahkan e-mel benar-benar datang daripada domain yang didakwa.