Registrar Lockdown vs Layered Defense: Mana yang Tepat?

Bayangkan bangun pagi dan mendapati semua domain milik perusahaan Anda, mulai dari production, staging, sampai yang menyimpan MX record Anda, ditangguhkan oleh registrar domain semalam. Tidak ada deploy yang rusak. Tidak ada server yang crash. Seseorang di tim trust-and-safety (atau, lebih mungkin, pipeline abuse otomatis) menekan sebuah saklar, dan seluruh kehadiran internet Anda hilang. Ini bukan skenario hipotetis: kejadiannya cukup sering sehingga forum sysadmin dipenuhi cerita horor tentang registrar yang menonaktifkan akun karena laporan abuse yang belum terverifikasi, tweet yang ambigu, atau satu gambar bermasalah di antara jutaan unggahan pengguna.

Saya sudah bertahun-tahun menangani incident response untuk tim infrastruktur, dan polanya selalu sama. Engineer mendesain redundansi yang rumit untuk compute seperti multi-AZ, multi-region, dan runbook failover, lalu membiarkan satu aset yang tidak bisa di-redeploy, yaitu nama domain itu sendiri, berada di satu akun yang hanya dilindungi password dan mungkin kode SMS. Artikel ini membandingkan dua filosofi untuk menangani risiko tersebut: pendekatan tradisional registrar lockdown (pilih registrar yang solid, perketat akun, dan percayakan pada mereka) versus pendekatan layered defense (asumsikan registrar Anda akan mengecewakan dan rancang sistem untuk mengatasinya). Intinya, Anda butuh keduanya, tapi yang kedua itulah yang benar-benar menyelamatkan Anda jam 3 pagi.

Mengapa Registrar Anda Adalah Jenis Single Point of Failure yang Berbeda

Sebagian besar single point of failure di stack Anda adalah hal yang bisa Anda kendalikan. Database primary, NAT gateway, message broker: Anda bisa mereplikasinya, dan rencana failover-nya Anda tulis sendiri. Registrar berbeda karena tiga alasan. Pertama, ini adalah dependensi control-plane yang tidak bisa direplikasi. Anda tidak bisa menjalankan dua registrar untuk domain yang sama karena registry hanya mengakui satu sponsor. Kedua, mode kegagalan registrar cenderung lambat. Transfer domain dalam kondisi normal memakan waktu lima sampai tujuh hari, dan jika registrar saat ini sudah menonaktifkan akun Anda, Anda bahkan mungkin tidak bisa mendapatkan auth code untuk memulainya. Ketiga, kegagalannya bersifat adversarial dengan cara yang aneh: bukan penyerang yang melakukannya, melainkan penyedia itu sendiri yang bertindak melawan Anda berdasarkan laporan abuse yang tidak pernah Anda lihat.

Dampaknya juga lebih buruk dari yang orang kira. Ketika registrar menangguhkan domain, biasanya mereka mengarahkan record NS ke halaman takedown atau sekadar berhenti menjawab. Tentu saja website Anda mati. Tapi email juga ikut mati (record MX ada di DNS), begitu pula SSO jika callback-nya merujuk ke domain Anda, API client, status page jika berada di domain yang sama, dan yang menjadi favorit pribadi saya, alamat email yang akan Anda gunakan untuk menerima instruksi pemulihan. Jika email akun registrar Anda adalah admin@domainanda.com dan domainanda.com ditangguhkan, Anda sekarang harus membuktikan identitas ke support dari alamat yang tidak mereka percaya. Saya pernah melihat lingkaran setan ini menghabiskan seharian penuh dalam sebuah insiden.

Dan insentif ekonominya juga bergerak melawan Anda. Ketika registrar diakuisisi private equity, seperti beberapa registrar besar yang sudah mengalaminya, polanya bisa ditebak: support manusia dipangkas, penanganan abuse diotomatisasi, harga dinaikkan. Sistem abuse otomatis mengoptimalkan risiko mereka, bukan risiko Anda. Menangguhkan domain yang kemudian terbukti tidak bersalah tidak merugikan mereka sama sekali. Membiarkan domain yang kemudian terbukti bersalah tetap aktif berarti masalah dengan registry dan pemberitaan buruk. Tebak ke arah mana otomatisasi cenderung membuat kesalahan.

Pendekatan Pertama: Registrar Lockdown, Perkuat Titik Tunggal

Filosofi lockdown berkata: terima bahwa registrar adalah single point of failure, lalu jadikan titik itu sekuat mungkin. Ini strategi yang paling banyak dijalankan perusahaan, entah mereka sudah merumuskannya atau belum. Jika dilakukan dengan benar, bentuknya seperti ini:

• Pilih registrar berdasarkan kualitas support, bukan harga. Penghematan $3 per tahun per domain tidak ada artinya dibanding satu hari downtime. Anda membutuhkan support telepon, account rep khusus untuk portofolio besar, dan perusahaan yang bisa Anda gugat di yurisdiksi sendiri jika situasinya memang sampai ke sana.
• Aktifkan registrar lock (clientTransferProhibited) untuk setiap domain, dan registry lock untuk domain yang kritis. Registry lock mewajibkan verifikasi out-of-band, biasanya panggilan telepon dengan passphrase, sebelum perubahan nameserver atau transfer apa pun. Memang merepotkan, dan justru itulah tujuannya.
• Gunakan autentikasi dua faktor berbasis hardware key atau TOTP, jangan pernah SMS. Cerita tentang agen support yang menghapus 2FA setelah dibujuk lewat chat sudah tak terhitung jumlahnya. Beberapa registrar kini menawarkan kebijakan 'tidak ada perubahan akun tanpa hardware key'. Ambil kebijakan itu.
• Gunakan alamat email khusus berbasis peran untuk akun registrar yang TIDAK berada di domain yang didaftarkan di registrar tersebut, misalnya domains-admin@example.org yang didaftarkan di tempat lain sama sekali.
• Batasi siapa saja yang punya akses. Pilih dua atau tiga orang yang jelas, simpan kredensial di vault perusahaan, bukan login bersama di spreadsheet.
• Dokumentasikan semuanya: nomor akun, PIN, jalur eskalasi support, dan dokumen identitas persis yang dipakai untuk verifikasi akun. Masukkan ke runbook insiden Anda.

Lockdown punya kekuatan nyata. Ia mencegah bencana registrar yang paling umum, yang sebenarnya bukan penyitaan melainkan pembajakan. Transfer hasil social engineering dan pengambilalihan akun sudah mencuri domain bernilai tinggi selama bertahun-tahun, dan registry lock ditambah 2FA hardware menghentikan hampir semuanya. Selain itu, biayanya murah dan tidak membutuhkan kerja engineering yang berkelanjutan.

Tapi inilah kebenaran yang tidak nyaman: lockdown melindungi Anda dari penyerang, bukan dari registrar itu sendiri. Setiap kontrol di atas dijalankan oleh registrar. Jika otomatisasi abuse mereka menonaktifkan akun Anda, registrar lock Anda justru mengunci Anda di luar, PIN support Anda tersimpan di sistem yang tidak bisa Anda jangkau, dan orang yang bisa membatalkan semuanya mungkin sudah tidak ada karena support 'dioptimalkan' kuartal lalu. Praktisi melaporkan waktu pemulihan lebih dari enam jam bahkan dalam kasus false positive yang sederhana, dan berhari-hari jika penangguhan terjadi saat akhir pekan. Lockdown itu perlu. Tapi tidak cukup.

Pendekatan Kedua: Layered Defense, Asumsikan Registrar Akan Mengkhianati Anda

Filosofi layered dimulai dari premis yang lebih gelap: suatu hari, entah karena niat jahat, otomatisasi, atau kesalahan, registrar Anda akan menurunkan domain Anda, dan Anda harus sudah kembali online sebelum antrean support sampai ke Anda. Ini pola pikir yang sama dengan defensive engineering terhadap kegagalan katastrofik. Anda tidak mencegah bencana, Anda membuatnya bisa dilewati.

Teknik intinya adalah memisahkan lapisan yang biasanya dibundel jadi satu. Kebanyakan perusahaan kecil membeli domain, memakai DNS dari registrar, meng-host di layanan hosting registrar, dan mengurus email di sana juga. Itu empat single point of failure yang ditumpuk dalam satu akun. Pisahkan:

• Registrasi: di registrar A, dipilih karena stabilitas dan support.
• DNS otoritatif: di penyedia DNS independen B (atau dua penyedia dalam konfigurasi dual-primary), dikelola sebagai kode.
• Hosting: di mana pun yang masuk akal untuk workload-nya, tidak terkait dengan keduanya.
• Email: penyedia khusus, dengan alamat pemulihan akun untuk A dan B berada di domain lain lagi.
• Domain cadangan: domain fallback yang sudah disiapkan di registrar berbeda, dengan sertifikat TLS sudah diterbitkan dan versi minimal dari layanan paling kritis Anda sudah merespons di sana.

Domain cadangan layak mendapat penekanan karena hampir tidak ada yang melakukannya, dan ini adalah langkah dengan leverage tertinggi. Ketika domain utama ditangguhkan, TTL DNS dan cache resolver berarti Anda tidak bisa begitu saja 'pindah ke cadangan'. Cadangan itu harus sudah ada, sudah dipanaskan, dan sudah bisa di-resolve sebelum insiden terjadi. Fallback seperti example-status.net, yang didaftarkan di tempat lain, membawa status page, komunikasi insiden, dan record MX darurat Anda. Hasilnya, outage yang bisa mematikan perusahaan berubah menjadi Selasa yang memalukan saja.

DNS sebagai Kode: Lapisan yang Selalu Terlewat

Ini kegagalan yang sudah dua kali saya lihat dalam insiden nyata: tim berhasil mendapatkan kembali domain setelah penangguhan registrar, menyalakan semuanya lagi, dan ternyata DNS-nya salah. Penyebabnya, 'sumber kebenaran' untuk zone mereka adalah UI web registrar, yang tidak bisa diakses selama insiden dan memang sudah tidak sinkron dengan ingatan siapa pun. Membangun ulang zone file berisi 200 record dari ingatan di tengah outage adalah penderitaan tersendiri. Seperti yang sudah pernah kami tulis, kesalahan konfigurasi DNS terus merusak production bahkan dalam kondisi normal. Saat insiden registrar, dampaknya bencana.

Solusinya membosankan: kelola zone DNS sebagai kode, di version control, dan di-deploy oleh CI. Tools seperti dnscontrol atau provider DNS di Terraform memungkinkan Anda mendeskripsikan zone secara deklaratif dan mendorongnya ke banyak penyedia. Sekarang state DNS Anda bertahan meski control plane penyedia mana pun hilang, dan 'failover ke penyedia DNS B' hanya menjadi perubahan satu baris dan satu deploy, bukan sesi copy-paste yang heroik.

# dnsconfig.js — one zone, two providers, deployed by CI
var REG_NONE = NewRegistrar('none');
var DSP_CLOUDFLARE = NewDnsProvider('cloudflare');
var DSP_ROUTE53 = NewDnsProvider('route53');
D('example.com', REG_NONE,
DnsProvider(DSP_CLOUDFLARE),
DnsProvider(DSP_ROUTE53),   // dual-authoritative: either can die
A('@', '203.0.113.10'),
A('www', '203.0.113.10'),
MX('@', 10, 'mail.example.net.'),   // MX on a DIFFERENT TLD/provider domain
TXT('@', 'v=spf1 include:_spf.example.net -all'),
CNAME('status', 'statuspage.example.net.')
);

DNS otoritatif ganda itu underrated. Sebagian besar resolver akan dengan senang hati mencoba semua nameserver yang tercantum, jadi jika satu penyedia mengalami outage (dan penyedia DNS besar memang pernah mengalaminya), resolusi tetap berjalan. Tantangannya adalah menjaga kedua penyedia tetap sinkron, dan justru di sinilah DNS-as-code memberi Anda semuanya secara gratis. Tanpa itu, DNS dari dua penyedia adalah pabrik drift dan bisa dibilang lebih buruk daripada satu penyedia saja.

Satu catatan soal TTL: tim suka menaikkan TTL ke 86400 'demi performa', lalu baru sadar saat insiden bahwa seperempat internet menyimpan cache record nameserver lama mereka selama sehari penuh. Untuk record yang terkait nameserver dan apa pun yang mungkin perlu Anda ubah dalam keadaan darurat, pertahankan TTL di 300–900 detik. Biaya volume query-nya sepele dibanding kelincahan yang Anda dapatkan.

Head to Head: Kapan Masing-masing Pendekatan Menang

Mari kita bicara terus terang soal trade-off-nya, karena kedua strategi ini mengoptimalkan ancaman dan organisasi yang berbeda.

• Threat model: Lockdown menang melawan pembajakan dan social engineering, yaitu bencana yang secara statistik paling sering terjadi. Layered defense menang melawan kegagalan dari sisi registrar: otomatisasi abuse, penyitaan akun, kebangkrutan, atau runtuhnya support.
• Biaya: Lockdown hampir tanpa biaya, cukup biaya registry lock, hardware key, dan disiplin. Layered defense membutuhkan tagihan penyedia kedua, domain cadangan, perangkat CI, dan perhatian berkelanjutan untuk mencegah drift.
• Waktu pemulihan: Dalam skenario penyitaan, tim yang hanya mengandalkan lockdown bergantung pada antrean support (berjam-jam hingga berhari-hari, sesuai cerita yang saya dengar). Tim layered dengan domain cadangan yang sudah hangat kembali online dalam hitungan menit hingga jam.
• Beban operasional: Lockdown itu pasang-dan-lupakan. Layered defense membusuk jika tidak dirawat, dan fallback yang tidak pernah diuji dengan sertifikat kedaluwarsa hanyalah teater keamanan.
• Kecocokan organisasi: Startup lima orang dengan satu produk SaaS sebaiknya menjalankan lockdown penuh plus dua langkah layered termurah (DNS-as-code di luar, dan email pemulihan di luar domain). Perusahaan yang pendapatannya mati bersama domainnya membutuhkan seluruh stack layered.

Lockdown melindungi domain Anda dari penyerang. Layered defense melindungi bisnis Anda dari registrar Anda. Anda terekspos pada keduanya, jadi Anda butuh keduanya.

Runbook Pemulihan yang Baru Ditulis Orang Saat Sudah Terlambat

Apa pun posturnya, tulis runbook penyitaan sekarang. Insiden yang saya lihat berjalan baik semuanya punya runbook, sedangkan bencana terjadi ketika orang harus improvisasi. Runbook Anda sebaiknya mencakup, secara berurutan: pastikan cakupan (apakah satu domain atau seluruh akun, dengan mengecek kode status whois seperti clientHold atau serverHold), buka tiket support dengan identifier akun yang sudah didokumentasikan, aktifkan domain fallback dan perbarui komunikasi status, beri tahu pelanggan lewat kanal yang tidak bergantung pada domain yang mati, dan mulai proses transfer keluar secara paralel. Jangan menunggu resolusi untuk memutuskan bahwa Anda akan pindah.

Latih juga bagian-bagian yang membosankan. Bisakah Anda benar-benar login ke registrar dari perangkat bersih, dengan hardware key, tanpa password manager yang berada di balik SSO di domain yang ditangguhkan? Apakah passphrase registry lock ada di tempat yang bisa ditemukan on-call? Tim menguji failover database setiap kuartal, tapi pemulihan registrar tidak pernah. Mengingat kegagalan registrar juga mematikan SSO yang Anda pakai untuk mengakses semua hal lain, prioritas ini terbalik.

Rekomendasi Saya

Lakukan lockdown sepenuhnya. Ini pekerjaan setengah hari dan menghentikan serangan yang paling mungkin terjadi. Lalu terapkan tepat tiga bagian layered defense, berurutan: pindahkan DNS otoritatif dari registrar Anda dan kelola sebagai kode; pindahkan email pemulihan akun registrar Anda ke domain di registrar yang berbeda; dan siapkan domain fallback yang sudah hangat dengan sertifikat, status page, dan MX darurat. Ketiganya menutup mode kegagalan yang dominan dengan biaya beberapa ratus dolar per tahun. Arsitektur dual-registrar dan dual-DNS yang lengkap sebaiknya disediakan untuk organisasi yang bisa merumuskan berapa biaya satu hari kehilangan domain secara total. Jika angkanya sudah enam digit, Anda sudah tahu apa yang harus dilakukan.

Dan jika Anda masih memilih registrar terutama karena harga, berhentilah. Pasar registrar murah sedang terkonsolidasi di bawah pemilik yang insentifnya adalah mengganti penilaian manusia dengan otomatisasi yang dengan senang hati menangguhkan Anda karena false positive, lalu baru membalas tiket Anda hari Kamis. Domain Anda adalah satu-satunya infrastruktur yang tidak bisa Anda deploy ulang dari container image. Perlakukan ia seperti itu.