Kenapa AutoSSL Gagal Gara-Gara Record AAAA Masih Mengarah ke Server Lama

Pola ini sering muncul setelah migrasi. Domain sudah dipindah ke server baru, record A sudah benar, website terbuka normal di browser, tapi AutoSSL atau Let's Encrypt tetap gagal validasi. Pemilik situs biasanya yakin DNS-nya sudah beres karena dig untuk record A menunjukkan IP baru. Yang terlewat adalah record AAAA, record DNS untuk alamat IPv6, yang masih menunjuk ke server lama. Catatan ini merangkum apa yang sebenarnya terjadi, bagian mana yang gampang salah paham, dan cara melatihnya dengan aman di VPS uji sebelum menghadapinya di server produksi.

Kenapa record A yang benar belum cukup

Satu nama domain bisa punya dua jenis alamat. Record A berisi alamat IPv4, record AAAA berisi alamat IPv6. Keduanya berdiri sendiri. Mengubah record A tidak otomatis mengubah atau menghapus record AAAA. Saat migrasi, record AAAA ini sering ikut tertinggal. Contohnya: zone DNS disalin utuh dari provider lama, server lama dulu punya IPv6 lalu template DNS-nya menambahkan AAAA secara otomatis, atau ada orang yang dulu menambahkannya manual lalu lupa. Yang diganti hanya record A karena itu yang ada di checklist migrasi. Lalu kenapa website kelihatan normal? Banyak koneksi pengunjung masih lewat IPv4. Browser modern juga memakai teknik yang disebut Happy Eyeballs, yaitu mencoba IPv6 dan IPv4 hampir bersamaan lalu memakai yang lebih cepat tersambung. Kalau IPv6 ke server lama tidak bisa tersambung, browser diam-diam memakai IPv4 dan pengunjung tidak sadar ada masalah. Kalau server lama masih hidup dan masih melayani domain itu lewat IPv6, sebagian pengunjung justru melihat versi lama situsnya. Ini tergantung jaringan masing-masing pengunjung, dan sering jadi penjelasan untuk keluhan "di HP saya kok beda".

Bagaimana validator memperlakukan IPv6

Untuk validasi HTTP-01, certificate authority (CA) mengambil file token di path /.well-known/acme-challenge/ pada domain kamu. CA adalah pihak yang menerbitkan sertifikat. File token ini dibuat oleh AutoSSL atau ACME client di server baru. Sesuai dokumentasi Let's Encrypt yang aku pahami, kalau domain punya record AAAA, validator mencoba IPv6 lebih dulu. Ada dua kemungkinan hasilnya, dan perbedaannya penting. Kemungkinan pertama, koneksi IPv6 gagal di level TCP: timeout atau ditolak. Dalam kasus ini Let's Encrypt biasanya mencoba ulang lewat IPv4. Kalau IPv4 benar, validasi bisa saja lolos. Karena itu record AAAA yang mati kadang tidak langsung ketahuan. Kemungkinan kedua, koneksi IPv6 berhasil tapi yang menjawab server lama. Server lama tidak punya file token yang baru dibuat, jadi biasanya membalas 404, menampilkan halaman default, atau melakukan redirect ke tempat lain. Dari sudut pandang validator, koneksinya sukses tapi isinya salah. Validator tidak punya alasan untuk mencoba IPv4, jadi validasi langsung gagal. Kasus kedua inilah yang paling membingungkan. Selama server lama masih menyala, misalnya karena belum dimatikan sambil menunggu masa transisi, AAAA yang salah justru "bekerja" dan terus menggagalkan validasi. Untuk provider lain di AutoSSL cPanel, misalnya Sectigo, cara validasinya bisa berbeda. Jangan langsung menganggap perilakunya sama. Cek dokumentasi provider yang kamu pakai.

Membaca tanda-tandanya di log dan di DNS

Petunjuk paling berguna ada di pesan error-nya. Pada Let's Encrypt, pesan kegagalan validasi biasanya menyebut alamat IP yang dihubungi validator. Kalau alamat itu berformat IPv6 (ada titik dua, misalnya 2001:db8::10) padahal server baru tidak memakai alamat tersebut, arah masalahnya sudah jelas. Di cPanel, log AutoSSL bisa dilihat dari WHM di bagian Manage AutoSSL. Struktur menu dan isi lognya bisa berbeda antarversi, jadi cari baris DCV untuk domain yang gagal. DCV (Domain Control Validation) adalah proses pembuktian bahwa kita memang mengontrol domain itu. Kalau penyebab DCV gagal ternyata bukan IPv6, artikel Kenapa AutoSSL Gagal Diperbarui Padahal Domain Sudah Mengarah ke Server membahas penyebab lain yang lebih umum. Setelah itu, cocokkan dengan DNS. Cek record A dan AAAA untuk domain utama sekaligus www, karena keduanya biasanya ikut masuk ke sertifikat yang sama:

BASH

# Lihat jawaban dari resolver yang dipakai mesin kamu
dig +short A example.com
dig +short AAAA example.com
dig +short A www.example.com
dig +short AAAA www.example.com

# Cari nameserver authoritative, lalu tanya langsung ke sana
# (ganti ns1.example-dns.net dengan hasil query NS)
dig +short NS example.com
dig @ns1.example-dns.net +short AAAA example.com

Bertanya langsung ke nameserver authoritative itu penting. Nameserver authoritative adalah server DNS yang memegang zone asli domain tersebut. Resolver biasa bisa masih menyimpan cache jawaban lama selama TTL (Time To Live, lama sebuah jawaban DNS boleh disimpan) belum habis. Jadi kalau kamu baru menghapus AAAA, dig biasa mungkin masih menampilkannya sebentar. Sebaliknya, kalau authoritative masih mengembalikan AAAA, berarti record-nya memang masih ada di zone. Hati-hati juga kalau nameserver domain masih di provider lama. Mengedit zone di server baru tidak berpengaruh sama sekali selama domain belum mengarah ke nameserver tersebut. Langkah berikutnya: buktikan jalur mana yang dijawab oleh server mana. Tes yang sederhana adalah meminta path challenge lewat IPv4 dan IPv6 secara terpisah:

BASH

# Paksa koneksi lewat IPv4, lalu lewat IPv6
# Nama file tidak perlu ada; yang dibandingkan adalah siapa yang menjawab
curl -4 -sI http://example.com/.well-known/acme-challenge/tes-jalur
curl -6 -sI http://example.com/.well-known/acme-challenge/tes-jalur

Bandingkan kedua respons: status code, header Server, dan header lain yang khas, seperti Location kalau ada redirect. Kalau keduanya terlihat berasal dari stack yang berbeda, kamu sedang melihat dua server yang berbeda. Perintah curl -6 hanya jalan kalau mesin yang menjalankannya punya konektivitas IPv6. Kalau tidak, jalankan dari mesin lain yang punya IPv6. Kalau ternyata jalur IPv6 sampai ke server baru tapi tetap gagal karena redirect, masalahnya bergeser ke konfigurasi web server. Pembahasannya ada di Kenapa Redirect HTTPS Global Bikin Perpanjangan Otomatis ACME Gagal.

Memutuskan: perbaiki atau hapus record AAAA

Keputusannya bergantung pada satu pertanyaan: apakah server baru memang siap melayani domain ini lewat IPv6? Kalau server baru punya alamat IPv6 dan web server-nya sudah dikonfigurasi untuk menerima koneksi di alamat itu, perbaiki record AAAA agar menunjuk ke IPv6 server baru. Jangan berhenti di DNS. Pastikan vhost domain itu benar-benar menjawab di IPv6, misalnya dengan mengulang tes curl -6 di atas setelah TTL habis. Mengarahkan AAAA ke IPv6 yang belum di-bind web server hanya memindahkan masalah ke tempat lain. Kalau server baru tidak punya IPv6, atau punya tapi belum disiapkan untuk domain ini, menghapus record AAAA biasanya pilihan yang paling aman. Setelah dihapus, domain hanya punya jalur IPv4, dan validator serta pengunjung sama-sama memakai jalur itu. Konsekuensinya, pengunjung yang hanya punya IPv6 tanpa mekanisme translasi tidak bisa mengakses situs. Bagi kebanyakan situs ini trade-off yang wajar, tapi tetap perlu disadari. Apa pun pilihannya, setelah mengubah DNS:

Tunggu sampai TTL lama record AAAA habis.
Cek ulang ke nameserver authoritative dan ke resolver publik.
Jalankan ulang AutoSSL untuk domain tersebut atau tunggu jadwal berikutnya.

Jangan menekan tombol run berkali-kali sebelum DNS benar-benar berubah. Selain membuang waktu, CA punya rate limit untuk validasi yang gagal. Satu hal lagi yang menurutku sering dilupakan: matikan atau bersihkan domain itu di server lama setelah migrasi selesai. Selama server lama masih melayani domain tersebut, AAAA yang salah akan terus menghasilkan respons yang tampak valid tapi salah isi. Kalau server lama sudah tidak menjawab, setidaknya validator punya kesempatan fallback ke IPv4.

Latihan aman di VPS uji

Cara paling cepat memahami perilaku ini adalah mereproduksinya sendiri dengan domain atau subdomain uji, bukan domain milik orang lain. Siapkan subdomain dengan record A ke VPS uji yang menjalankan web server dan ACME client seperti certbot. Lalu tambahkan record AAAA ke alamat yang tidak kamu layani dari VPS itu. Kalau AAAA menunjuk ke alamat yang tidak bisa dijangkau, kamu bisa mengamati skenario koneksi gagal yang biasanya berakhir dengan fallback ke IPv4. Kalau kamu punya mesin kedua dengan IPv6 dan web server aktif, arahkan AAAA ke mesin itu untuk melihat skenario yang lebih sering terjadi di lapangan: koneksi sukses, isinya salah, validasi gagal. Untuk latihan, gunakan mode uji ACME client, misalnya opsi --dry-run di certbot yang memakai lingkungan staging Let's Encrypt. Dengan begitu kamu tidak terkena rate limit produksi saat sengaja membuat validasi gagal berulang kali. Perhatikan alamat IP yang disebut di pesan error pada tiap skenario. Setelah melihatnya sendiri dua tiga kali, membaca log AutoSSL di server produksi jadi jauh lebih cepat. Di meja support, urutan cek yang paling hemat waktu biasanya begini:

Lihat IP yang disebut di error validasi.
Bandingkan dengan hasil dig untuk A dan AAAA dari nameserver authoritative.
Uji jalur IPv4 dan IPv6 dengan curl.

Kalau IP di error berformat IPv6 dan tidak cocok dengan server baru, hampir pasti penyebabnya record AAAA sisa migrasi. Perbaiki kalau server baru memang siap melayani IPv6. Hapus kalau belum. Lalu tunggu TTL habis sebelum menjalankan ulang validasi.