DNS tanpa jargon: rekod A, CNAME, MX dan TXT yang menentukan laman dan e-mel awak hidup

Hantar satu arahan — `dig +short MX thalhah.my @1.1.1.1` — dan jawapannya satu baris: `10 mail.thalhah.my.` Angka 10 itu keutamaan penghantaran mel, bukan nombor versi. Nilai MX itu sebuah nama hos, `mail.thalhah.my`, yang mempunyai rekod A sendiri pada 194.233.74.195. RFC 2181 seksyen 10.3 menetapkan nilai MX mesti nama hos yang boleh diselesaikan kepada alamat, dan tidak boleh jadi alias.

Empat rekod yang menjalankan kerja laman dan e-mel

Fail zon memuatkan berpuluh jenis rekod. Yang bersentuh dengan pemilik laman ada lima, dan had setiap satu sudah ditulis dalam dokumen piawai sejak 1987.

• ▸ A — alamat IPv4. RFC 1035 seksyen 3.4.1 menyebut medan alamat 32 bit; hos dengan beberapa alamat mempunyai beberapa rekod A.
• ▸ AAAA — alamat IPv6, ditambah kemudian dalam RFC 3596.
• ▸ CNAME — alias kepada nama lain. RFC 2181 seksyen 10.1: pada satu label hanya boleh ada satu CNAME, dan tiada data jenis lain di situ.
• ▸ MX — pelayan yang menerima mel bagi domain itu, bersama nombor keutamaan 16 bit (RFC 1035 seksyen 3.3.9).
• ▸ TXT — teks bebas untuk dibaca sistem lain (RFC 1035 seksyen 3.3.14).

A dan AAAA: alamat, dengan TTL sebagai had maksimum

Dua rekod A bermakna nama itu mempunyai dua alamat. Yang mengawal berapa lama jawapan lama dipegang ialah TTL. RFC 2181 seksyen 8 menjelaskan dua perkara yang kerap disalah faham: TTL ialah nombor tanpa tanda dengan nilai maksimum 2,147,483,647 saat, dan ia had maksimum, bukan tempoh wajib — penyelesai bebas menyimpan jawapan lebih pendek.

Zon thalhah.my memberi rekod A pada 194.233.74.195 dengan TTL 1800 saat (30 minit) daripada adam.musafirdom.net, pelayan autoritatifnya. Rekod www juga rekod A ke alamat yang sama, bukan CNAME — pilihan munasabah untuk laman kecil, kerana CNAME menambah satu pusingan carian.

Sebelum memindahkan pelayan, turunkan TTL kepada 300 saat sehari lebih awal, kemudian naikkan semula kepada 1800 atau 3600 selepas 24 jam stabil. Dengan TTL 86,400 saat, sebahagian pengunjung masih dihantar ke pelayan lama sehari selepas rekod ditukar.

CNAME: kuat, tetapi tidak boleh duduk di puncak zon

RFC 2181 seksyen 10.1 menetapkan pada satu nama hanya satu daripada empat keadaan boleh benar: satu rekod CNAME, atau rekod lain tanpa CNAME, atau nama wujud tanpa data, atau nama tidak wujud. Puncak zon mesti memegang SOA dan NS, jadi CNAME di situ bertembung dengan dua rekod wajib itu. Sebab itu CNAME paling berguna pada subdomain seperti www, mail atau kedai.

Penyedia DNS besar menawarkan jalan keluar bukan piawai seperti CNAME flattening, yang menyelesaikan alias di pihak pelayan pada masa pertanyaan. Ia berfungsi, tetapi ia mekanisme penyedia, bukan ciri protokol.

Kegunaan yang jarang disedari: pembaharuan sijil TLS melalui cabaran DNS-01 menulis rekod `_acme-challenge` sementara, kemudian memadamkannya. Kalau rekod itu tidak kelihatan dari luar, pembaharuan gagal walaupun sijil lama masih sah.

MX: nombor kecil, dan aturan bukan-alias

RFC 5321 seksyen 5.1 menetapkan keutamaan lebih kecil dicuba dahulu. Kalau dua rekod berkongsi keutamaan yang sama, penghantar mesti menyebarkan beban antara keduanya secara rawak. Kalau tiada rekod MX langsung, domain dianggap mempunyai MX tersirat dengan keutamaan 0 yang menunjuk kepada nama itu sendiri — sebab itu mel boleh sampai ke hos yang hanya ada rekod A.

Dua kesilapan yang mahal: MX yang menunjuk kepada alamat IP, sedangkan medan itu mesti nama hos, dan MX yang menunjuk kepada CNAME. RFC 2181 seksyen 10.3 menyatakan nilai NS dan MX tidak boleh menjadi alias, dan RFC 5321 menambah bahawa jawapan sebegitu berada di luar skop piawaian.

Kalau ada dua pelayan mel, jangan letak kedua-duanya pada keutamaan 10; gunakan 10 dan 20 supaya pelayan utama dicuba dahulu. Google Workspace, misalnya, menerbitkan satu rekod sahaja: smtp.google.com pada keutamaan 1.

TXT: medan bebas untuk pengesahan dan polisi mel

RFC 1035 seksyen 3.3.14 menyatakan TXT memegang satu atau lebih character-string, setiap rentetan sehingga 256 aksara termasuk bait panjang. Di puncak zon ini ada dua TXT: `v=spf1 mx -all` untuk SPF (RFC 7208) dan satu token google-site-verification. SPF di sini bermaksud hanya pelayan yang disenaraikan dalam rekod MX dibenarkan menghantar mel bagi pihak domain; yang lain ditolak kerana simbol -all.

Pada `_dmarc.thalhah.my` ada `v=DMARC1; p=quarantine; rua=mailto:postmaster@thalhah.my` (RFC 7489): laporan agregat dihantar ke alamat itu, dan mel yang gagal pengesahan dikuarantin, bukan terus ditolak. Menerbitkannya tanpa menyenaraikan penyedia yang menghantar mel bagi pihak awak ialah cara paling cepat kehilangan e-mel pelanggan.

NS: siapa yang berhak menjawab tentang zon awak

`dig +trace +nodnssec thalhah.my A` menunjukkan rantaian penuh: pelayan .my (c.mynic.centralnic-dns.com) menghantar delegasi dengan TTL 86,400 saat, kemudian adam.musafirdom.net menjawab rekod A dengan TTL 1800 saat. Dua nombor itu menerangkan mengapa perubahan di peringkat pendaftar boleh mengambil masa lebih lama daripada perubahan di dalam zon.

MYNIC membenarkan sehingga enam pelayan nama bagi satu domain. Dua atau lebih pada rangkaian berbeza menjadikan zon tahan kegagalan: kalau satu mati, penyelesai bertanya kepada yang lain.

Empat punca 'masih tidak jumpa' selepas awak tukar rekod

• ▸ Cache negatif. RFC 2308 seksyen 5: TTL jawapan negatif ialah minimum antara medan MINIMUM pada SOA dan TTL rekod SOA itu sendiri. Pada zon ini kedua-duanya 1800 saat, jadi nama yang tidak wujud boleh kekal begitu selama 30 minit walaupun rekod baharu sudah wujud.
• ▸ Jawapan lama belum luput. Pelawat yang bertanya sebelum perubahan masih berpegang pada jawapan lama sehingga TTL tamat.
• ▸ Rantaian delegasi tidak berubah. TTL 86,400 saat pada rekod NS peringkat .my bermakna rujukan lama boleh kekal sehingga 24 jam.
• ▸ Dibetulkan di tempat yang salah. Kalau nameserver domain awak bukan milik pendaftar, menukar rekod di panel pendaftar tidak mengubah apa-apa.

DNS menyelesaikan nama, bukan laluan

DNS bekerja pada nama hos. Awak tidak boleh menghantar `domain.com/shop` ke pelayan lain melalui DNS, kerana laluan bukan sebahagian daripada pertanyaan DNS. Pada laman ini, laman utama, /blog, /alat dan /aplikasi berkongsi satu nama domain dan satu alamat IP; pemisahan berlaku di pelayan web. Masalah 'halaman tertentu kosong tetapi laman utama elok' hampir selalu masalah konfigurasi laluan.

Arahan mengesahkan dari luar

dig +short A thalhah.my @1.1.1.1
dig +short MX thalhah.my @8.8.8.8
dig +short TXT _dmarc.thalhah.my @1.1.1.1
dig +noall +answer NS thalhah.my
dig +trace +nodnssec thalhah.my A

Tanya dua penyelesai awam — Cloudflare 1.1.1.1 dan Google Public DNS di 8.8.8.8 serta 8.8.4.4 — supaya perbezaan cache kelihatan. Jangan harap `dig ANY` memberi senarai penuh: RFC 8482 membenarkan jawapan minimum untuk QTYPE=ANY, dan pertanyaan seumpama itu dijawab REFUSED pada zon ini. Perisian dig datang bersama BIND 9 versi 9.18.39.

Senarai semak sebelum menutup panel DNS

• ▸ A atau AAAA menunjuk ke alamat yang awak jangkakan, disemak daripada dua penyelesai berbeza.
• ▸ Puncak zon tidak mengandungi CNAME; www pula sama ada rekod A atau CNAME, bukan kedua-duanya.
• ▸ Setiap nilai MX ialah nama hos yang mempunyai rekod A, dan dua pelayan mel tidak berkongsi keutamaan.
• ▸ Tiada dua rekod SPF pada nama yang sama; SPF lama yang tertinggal ialah punca biasa mel jatuh ke spam.