Cara Cek Target CNAME yang Ketambahan Nama Domain karena Lupa Titik di Akhir

Record CNAME untuk subdomain sudah dibuat, panel bilang tersimpan, tapi subdomain tetap tidak bisa dibuka. Waktu dicek pakai dig, targetnya ternyata bukan shops.example.net. melainkan shops.example.net.example.com.. Penyebabnya hampir selalu satu karakter, yaitu titik di akhir nama yang tidak ditulis. Masalah yang sama bisa kena MX, NS, SRV, dan PTR, dan di MX efeknya lebih susah ketahuan karena email tidak langsung kelihatan rusak. Artikel ini membahas kenapa nama domain bisa ketambahan sendiri, apa yang terjadi di server DNS dan resolver saat record seperti itu di-query, dan cara memastikan target record benar lewat dig sebelum dan sesudah kamu mengubahnya.

Aturan nama relatif dan absolut di zone file

Di format zone file DNS (format master file dari RFC 1035), setiap nama domain bisa ditulis dalam dua bentuk. Nama absolut, atau FQDN (fully qualified domain name), diakhiri titik. Titik terakhir itu mewakili root DNS, jadi example.com. artinya nama lengkap yang tidak perlu ditambah apa-apa lagi. Nama tanpa titik di akhir dianggap relatif terhadap origin, yaitu nama zona yang sedang aktif. Origin biasanya diset lewat direktif $ORIGIN atau diambil dari nama zona di konfigurasi server. Yang sering terlewat, aturan ini tidak cuma berlaku untuk kolom nama di sebelah kiri (owner name). Aturan yang sama berlaku untuk data di sebelah kanan yang berisi nama domain: target CNAME, host MX, NS, target SRV, dan PTR. Data yang bukan nama domain, seperti alamat IP di A record atau isi TXT, tidak disentuh. Contoh zona untuk example.com:

TEXT

$ORIGIN example.com.
$TTL 3600
www    IN  CNAME  example.com.         ; absolut, target example.com.
blog   IN  CNAME  sites.example.net.   ; absolut, target sites.example.net.
shop   IN  CNAME  shops.example.net    ; relatif, target shops.example.net.example.com.
@      IN  MX 10  mail                 ; relatif, memang sengaja, target mail.example.com.
@      IN  MX 20  mail.example.com     ; relatif, target mail.example.com.example.com.

Perhatikan baris MX pertama. Ditulis mail tanpa titik, dan itu benar karena memang maksudnya relatif. Jadi tidak ada titik bukan berarti selalu salah. Kesalahannya muncul saat kamu menulis nama lengkap tapi lupa titiknya. Aturan praktisnya: kalau yang kamu ketik sudah berisi nama domain lengkap, tutup dengan titik. Kalau cuma label pendek di dalam zona yang sama, biarkan tanpa titik. Kesalahan yang sama juga bisa terjadi di kolom owner. Menulis www.example.com tanpa titik sebagai owner menghasilkan record untuk www.example.com.example.com.. Kebalikannya, menulis www. dengan titik membuat nama itu berada langsung di bawah root, di luar zona. Server seperti BIND biasanya menolak atau mengabaikan record seperti ini dengan peringatan out-of-zone data.

Apa yang dilakukan parser saat zona dimuat

Saat server authoritative seperti BIND atau NSD memuat zone file, parser membaca baris demi baris dan memecahnya jadi token. Setiap token yang posisinya adalah nama domain dicek: kalau diakhiri titik, dipakai apa adanya. Kalau tidak, parser menempelkan origin yang aktif di posisi itu. Hasilnya disimpan di memori dalam bentuk nama lengkap. Setelah tahap ini, server tidak menyimpan informasi bahwa nama itu awalnya relatif. Server tidak punya cara untuk tahu bahwa kamu sebenarnya ingin menunjuk ke domain di luar zona. Yang tersimpan hanyalah record CNAME yang sah dengan target shops.example.net.example.com.. Secara sintaks, record itu juga tidak salah. Parser dan alat seperti named-checkzone tidak mengecek apakah target CNAME benar-benar ada, karena target CNAME boleh menunjuk ke mana saja. Jadi zona lolos validasi, reload sukses, dan tidak ada error di log. Untuk melihat bentuk final setelah semua nama relatif diekspansi, kamu bisa memakai named-compilezone di server BIND (perintahnya ada di bagian cek di bawah). Panel DNS menambah satu lapisan lagi. Banyak panel web menyimpan input ke zone file atau database di belakang layar, dan cara mereka menangani titik berbeda-beda. Ada yang otomatis menambahkan titik ke input yang berisi titik di tengah, ada yang memperlakukan semua input sebagai relatif, ada juga yang menampilkan nama lengkap di antarmuka tapi menyimpannya dalam bentuk lain. Di meja support, masalah ini sering muncul saat target CNAME di-copy dari dokumentasi layanan pihak ketiga ke panel yang perilakunya beda dengan panel yang biasa dipakai pelanggan. Jangan menebak perilaku panel. Cek hasil akhirnya lewat dig.

Jalur query saat resolver mengikuti CNAME yang salah

Misalkan pengunjung membuka shop.example.com. Urutannya kira-kira seperti ini:

Browser meminta resolver (recursive resolver, misalnya milik ISP atau resolver publik) mencari A record shop.example.com.
Resolver bertanya ke nameserver authoritative example.com. Server menemukan CNAME ke shops.example.net.example.com..
Karena target itu masih berada di dalam zona example.com, server authoritative biasanya langsung mengikuti CNAME tersebut di zonanya sendiri. Nama itu tidak ada, jadi server mengembalikan respons berisi record CNAME di answer section, kode respons NXDOMAIN, dan record SOA di authority section.
Resolver menyimpan hasil NXDOMAIN itu di cache selama negative TTL. Menurut RFC 2308, nilainya diambil dari yang terkecil antara TTL record SOA dan field minimum di SOA.
Browser menerima jawaban bahwa nama tidak ditemukan. Di browser berbasis Chromium, pesannya biasanya DNS_PROBE_FINISHED_NXDOMAIN.

Langkah keempat menjelaskan kenapa perbaikan kadang terasa tidak langsung berpengaruh. Setelah record dibetulkan, resolver yang sudah menyimpan NXDOMAIN tetap menjawab dari cache sampai negative TTL habis. Itulah alasan pengecekan sebaiknya dilakukan langsung ke nameserver authoritative, bukan ke resolver biasa. Ada satu kasus yang gejalanya berbeda: zona yang punya wildcard seperti *.example.com. Target salah shops.example.net.example.com. tidak punya node yang lebih spesifik di zona, sehingga wildcard ikut menjawab. Hasilnya bukan NXDOMAIN, tapi IP milik wildcard. Situs yang muncul jadi situs yang salah, atau browser menampilkan peringatan SSL karena sertifikat tidak cocok dengan nama yang diminta. Kalau gejalanya seperti ini dan zona punya wildcard, kemungkinan lupa titik tetap perlu dicek. CNAME yang menunjuk ke nama tidak ada di zona sendiri berbeda dengan CNAME yang menunjuk ke layanan pihak ketiga yang sudah tidak dipakai. Kasus kedua punya risiko keamanan sendiri, dibahas di Memilih Cek Dangling DNS atau Celah CMS Saat Subdomain Kena Deface.

Kenapa MX yang salah lebih susah ketahuan

Untuk MX, alurnya mirip tapi pelakunya mail server pengirim, atau MTA (mail transfer agent). MTA mencari MX example.com, mendapat host mail.example.com.example.com., lalu mencari A atau AAAA record untuk host itu dan gagal. Di titik ini banyak orang mengira pengirim akan fallback ke A record example.com. Tidak begitu. Menurut RFC 5321, fallback ke A record domain (implicit MX) hanya berlaku kalau domain sama sekali tidak punya MX record. Selama MX record ada, pengirim harus memakai host di MX itu, meskipun host-nya tidak bisa di-resolve. Biasanya email ditahan di queue pengirim dan dicoba ulang, lalu di-bounce setelah batas waktu antrian habis. Detailnya tergantung software dan konfigurasi MTA pengirim, ada yang langsung bounce kalau semua host MX jelas tidak ada. Yang membuatnya licin adalah zona dengan lebih dari satu MX, seperti contoh di atas. Kalau MX prioritas 10 benar dan prioritas 20 salah, email tetap terkirim lewat host yang benar. Kesalahannya baru terasa saat host utama bermasalah dan pengirim mencoba host cadangan yang ternyata tidak pernah ada.

Cara cek target record lewat dig sebelum dan sesudah perubahan

Kuncinya ada dua: tanya langsung ke nameserver authoritative supaya tidak tertipu cache, dan baca nama yang dikembalikan sampai karakter terakhir. Dig selalu menampilkan nama dalam bentuk absolut dengan titik di akhir, jadi pola yang dicari adalah nama domainmu muncul dua kali di ujung.

BASH

# Cari nameserver authoritative domain
dig +short NS example.com

# Lihat target CNAME dan MX langsung dari authoritative, tanpa rekursi
dig +norecurse CNAME shop.example.com @ns1.example.com
dig +short CNAME shop.example.com @ns1.example.com
dig +short MX example.com @ns1.example.com

# Pastikan target itu sendiri benar-benar resolve
dig +short A shops.example.net

# Bandingkan serial SOA di setiap nameserver setelah perubahan
dig +short SOA example.com @ns1.example.com
dig +short SOA example.com @ns2.example.com

# Di server BIND: tampilkan zona dalam bentuk final, semua nama sudah diekspansi
named-compilezone -o - example.com /var/named/example.com.db

Berikut contoh format output saat target ketambahan nama domain. Ini ilustrasi, bukan dari insiden nyata:

TEXT

$ dig +short CNAME shop.example.com @ns1.example.com
shops.example.net.example.com.

$ dig +short MX example.com @ns1.example.com
10 mail.example.com.
20 mail.example.com.example.com.

Sebelum mengubah apa pun, simpan hasil dig untuk record yang mau disentuh. Catatan ini berguna sebagai pembanding dan sebagai bahan rollback kalau perubahan malah merusak record lain. Setelah perubahan, jalankan perintah yang sama ke setiap nameserver authoritative, bukan hanya ns1. Kalau serial SOA di nameserver sekunder belum sama dengan primer, berarti transfer zona belum selesai dan sebagian query masih mendapat versi lama. Perintah named-compilezone di atas hanya membaca file dan menulis hasilnya ke layar, jadi aman dijalankan. Path zone file di contoh umum ditemui di server cPanel dengan BIND, tapi bisa berbeda tergantung distro dan panel. Hasilnya berguna untuk mencari nama ganda di seluruh zona sekaligus, bukan hanya record yang dilaporkan. Kalau hasil dig ke authoritative sudah benar tapi pengguna masih melihat error, kemungkinan besar resolver mereka masih memegang NXDOMAIN dari cache. Tidak ada yang perlu diubah lagi di zona. Tunggu negative TTL habis, atau minta pengguna mencoba resolver lain untuk memastikan. Kebiasaan yang paling menghemat waktu: setiap kali menambah atau mengubah CNAME, MX, NS, atau SRV, langsung jalankan dig +short ke nameserver authoritative dan baca ujung namanya. Kalau domainmu muncul dua kali, tambahkan titik di akhir target atau ganti dengan label pendek, lalu cek lagi di semua nameserver sebelum tiket ditutup.