Pendaftar Domain atau Penyedia DNS: Masa Tenggang Penukaran Domain Kedaluwarsa, DNSSEC SERVFAIL Perangkap, dan Migrasi Server Nama Darurat¶

Bangun dan temukan bahwa situs web utama perusahaan Anda, titik akhir API (api.example.com), dan email perusahaan (MX data untuk Google Workspace atau Microsoft 365) sama sekali tidak dapat dijangkau di seluruh dunia (DNS_PROBE_FINISHED_NXDOMAIN atau SERVFAIL) adalah krisis infrastruktur yang menyebabkan pemadaman listrik total. Berbeda dengan server web tunggal yang mogok yang mempengaruhi satu layanan, Sistem Nama Domain (DNS) atau kegagalan pendaftaran domain memutuskan setiap layanan di bawah domain root Anda secara bersamaan, termasuk Sistem Masuk Tunggal (SSO), portal dukungan pelanggan, dan email respons insiden yang masuk. Dalam praktiknya, pemadaman domain global disebabkan oleh tiga pemicu berbeda: (1) kedaluwarsa domain yang tidak disengaja yaitu kartu kredit yang tercatat telah kedaluwarsa dan registrar membajak domain Anda. NS catatan untuk menunjuk ke halaman parkir bayar per klik 24 to 48 hours sebelum tanggal kadaluwarsa sebenarnya; (2) serangan DDoS atau pemadaman sarana kontrol di penyedia DNS resmi Anda (Route 53, Cloudflare, GoDaddy, Namecheap, DNSimple, NS1); atau (3) rusak DNSSEC (DS catatan) rantai kepercayaan selama peralihan server nama yang terburu-buru yang menyebabkan penyelesai validasi (8.8.8.8, 1.1.1.1, pemecah masalah ISP) untuk menurunkan 100 persen lalu lintas Anda SERVFAIL. Jika penyerang membobol kredensial login registrar Anda dan mentransfer atau mengubah domain Anda dengan jahat, beralihlah ke pembajakan nama domain, DNS kadaluwarsa, dan pengambilalihan situs web; jika sertifikat TLS Anda kedaluwarsa atau rusak setelah DNS dipulihkan, lihat Sertifikat SSL/TLS telah habis masa berlakunya dalam produksi, penguncian pramuat HSTS, dan perpanjangan darurat dan Penguncian admin domain khusus Google Workspace atau Microsoft 365 dan verifikasi DNS. Jika pemadaman listrik ini menonaktifkan komunikasi klinis rumah sakit, rute pengiriman darurat 911/112, atau utilitas publik penting, hubungi nomor darurat lokal Anda (911 di Amerika Serikat dan Kanada, 112 di seluruh Uni Eropa, 999 di Inggris) atau lihat direktori kami nomor darurat.

Lakukan ini sekarang¶

1. Diagnosis dalam 10 detik apakah kegagalannya adalah Domain Kedaluwarsa/Ditangguhkan (EPP Status), Gangguan Penyedia DNS Resmi, atau a DNSSEC Kegagalan Validasi:
2. Jalankan whois yourdomain.com | grep -iE "Status|Expiry|Name Server" dan dig +trace yourdomain.com.
3. Uji apakah melewati DNSSEC validasi (+cd = Centang Dinonaktifkan) membuat domain Anda terselesaikan kembali:

   dig @8.8.8.8 yourdomain.com A
   dig @8.8.8.8 yourdomain.com A +cd
   

   Jika perintah pertama kembali status: SERVFAILsedangkan perintah kedua (+cd) segera kembali status: NOERROR dengan alamat IP server Anda, server DNS Anda TIDAK down: milik Anda DNSSEC (DS catatan di registrar) rusak. Segera lompat ke Fase 3 untuk menghapus basi DS catatan di registrar Anda.
4. Jika masa berlaku domain Anda habis (Auto-Renew Grace Period atau Redemption Grace Period), segera masuk ke registrar Anda saat ini dan bayar biaya perpanjangan/penukaran; JANGAN menunggu domain "drop" agar Anda dapat mendaftar ulang dengan biaya murah:
5. Selama 1 hingga 45 hari pertama setelah habis masa berlakunya (Auto-Renew Grace Period), memperbarui di dasbor registrar Anda akan memulihkan server nama asli Anda dengan biaya perpanjangan standar ($10 to $30).
6. Selama 30 hari Redemption Grace Period (RGP / redemptionPeriod), Anda harus membayar biaya penebusan registrasi wajib ($80 to $250) melalui registrar Anda saat ini. Jika Anda menunggu domain selesai 5 hari Pending Delete fase untuk menyimpan $100, bot penembak jitu penangkap jatuh otomatis (DropCatch, SnapNames, NameJet) akan mengambil domain Anda di dalamnya 5 milliseconds melepaskannya dan melelangnya seharga ribuan dolar.
7. JANGAN PERNAH mengubah Server Nama Anda (NS) jauh dari penyedia DNS yang mendukung DNSSEC (seperti Cloudflare, Route 53, atau Google Cloud DNS) tanpa menghapus DS rekam di registrar Anda terlebih dahulu: Jika DNSSEC diaktifkan dan Anda menukar NS catatan ke penyedia DNS penyelamat selama pemadaman tanpa menghapus induknya DS (Delegation Signer) mencatat di .com / .org Zona TLD pertama, setiap penyelesai yang memvalidasi di Bumi akan menolak tanggapan tidak ditandatangani penyedia DNS baru sebagai serangan spoofing kriptografi (SERVFAIL).
8. Jika Anda terkunci dari perusahaan Anda @yourdomain.com email karena domain Anda MX catatannya tidak aktif, JANGAN klik "Kirim kode setel ulang kata sandi ke admin@yourdomain.com" di registrar Anda: Sementara domain Anda NS atau MX catatan sedang offline, email verifikasi apa pun dikirimkan ke @yourdomain.com memantul atau hilang ke dalam antrian. Gunakan SMS/MFA Authenticator registrar Anda, email cadangan out-of-band (@gmail.com / @proton.me), atau alur verifikasi identitas telepon.
9. Setelah memperbarui domain yang sudah habis masa berlakunya, verifikasi secara manual bahwa Registrar Anda memulihkan Server Nama Kustom asli Anda (NS) alih-alih membiarkan domain tetap aktif sedoparking.com / renewyourname.net: Saat domain kedaluwarsa, registrar akan menimpa kustom Anda NS catatan dengan server nama parkir (ns1.parklogic.com, dns1.name-services.com). Terkadang membayar perpanjangan memperbarui tanggal kedaluwarsa ke tahun depan sambil membiarkan server nama parkir aktif hingga Anda mengalihkannya kembali secara manual.
10. Hapus cache DNS rekursif publik global (Google 8.8.8.8, Cloudflare 1.1.1.1, OpenDNS) yang kedua milikmu NS atau DS catatan dipulihkan: Daripada menunggu 24 hingga 48 jam untuk di-cache NXDOMAIN atau halaman parkir NS catatan akan kedaluwarsa secara alami, memicu pembersihan cache global instan di Google Public DNS (developers.google.com/speed/public-dns/cache) dan Cloudflare 1.1.1.1 (one.one.one.one/purge-cache/).

Pohon keputusan: triase darurat pemadaman domain global atau DNS¶

Gunakan diagram alur ini untuk menentukan dengan tepat lapisan hierarki DNS (TLD Registry, Registrar EPP Status, DNSSEC DS Chain, atau Authoritative Nameserver) jika resolusi gagal:

flowchart TD
    Start["Pemadaman Global: Web Domain & Email Gagal Diselesaikan (NXDOMAIN / SERVFAIL)"] --> RunDiag["Jalankan: whois domain.com DAN gali @8.8.8.8 domain.com +cd"]

    RunDiag --> CheckCD{"Apakah dig @8.8.8.8 domain.com Gagal, Saat Menambahkan +cd Berhasil?"}

    CheckCD -->|"Ya: Bekerja dengan +cd, Gagal Tanpa +cd"| DnssecBreak["Rantai Kepercayaan DNSSEC Rusak: Hapus Catatan DS Basi di Registrar ATAU Re-Sign Zone -> Flush 8.8.8.8 & 1.1.1.1"]

    CheckCD -->|"Tidak: IP Parkir Gagal atau Kembali"| CheckWhois{"Periksa Status & Tanggal Kedaluwarsa Domain WHOIS EPP"}

    CheckWhois -->|"Status: clientHold atau serverHold"| HoldState["Penangguhan Registrar / Registry: Segera Selesaikan Verifikasi Email ICANN RAA ATAU Tiket Penyalahgunaan/Penagihan"]

    CheckWhois -->|"Tanggal Kedaluwarsa Berlalu (Status: autoRenewPeriod)"| GraceRenew["Hari 1 hingga 45 Pasca Kedaluwarsa: Bayar Perpanjangan Standar di Portal Registrar -> Verifikasi Custom NS Dipulihkan"]

    CheckWhois -->|"Status: Periode Penukaran (RGP)"| RgpRestore["Hari ke 45 hingga 75 Pasca Kedaluwarsa: Buka Tiket Dukungan Registrar Mendesak / Bayar Biaya Pemulihan RGP ($80-$250) Segera"]

    CheckWhois -->|"Status: tertundaHapus"| PendingDel["Penguncian 5 Hari Terakhir: Tidak Dapat Diperbarui di Registrar -> Tempatkan Pemesanan di Awal di Semua Drop-Catcher Utama Sekarang"]

    CheckWhois -->|"Status: ok / clientTransferProhibited DAN Kedaluwarsa di Masa Mendatang"| AuthDown["Pendaftaran Domain Sehat -> Gangguan Penyedia DNS Resmi atau Zona Hilang"]

    AuthDown --> MigrateNS["Impor File Zona (`BIND` / Terraform) ke Penyedia DNS Sekunder -> Hapus Catatan DS jika DNSSEC Aktif -> Perbarui NS di Registrar"]

Fase 1: Siklus Hidup Kedaluwarsa Domain ICANN (Auto-Renew vs. Redemption vs. Pending Delete)¶

Ketika Domain Tingkat Atas generik (gTLD seperti .com, .net, .org, .io, .ai, .co, .app, .dev) kedaluwarsa karena kartu kredit perpanjangan otomatis gagal atau kartu keuangan dibatalkan setelah karyawan keluar, domain melewati siklus hidup multi-tahap ketat yang diatur oleh Kebijakan Pemulihan Pendaftaran Kedaluwarsa ICANN (ERRP) dan perjanjian operator registri (Verisign untuk .com/.net, PIR untuk .org, Identity Digital).

Bagaimana domain mati dan mengapa domain tersebut offline SEBELUM atau PADA Hari ke-1 masa berlakunya habis¶

+-------------------------------------------------------------------------+
| ICANN gTLD EXPIRATION TIMELINE (.com / .net / .org example)             |
|                                                                         |
| [Active Domain]                                                         |
|       |                                                                 |
|       v  (Expiration Date Reached: Day 0)                               |
| +---------------------------------------------------------------------+ |
| | STAGE 1: Auto-Renew Grace Period (Day 1 to Day 30-45)               | |
| | - EPP Status: ok or clientHold (Registrar swaps your NS to parking) | |
| | - Production Impact: 100% OFFLINE within 0 to 48 hours of expiry    | |
| | - Recovery: Log into registrar & pay normal renewal ($10-$30).      | |
| +---------------------------------------------------------------------+ |
|       |  (Registrar sends Delete command to Registry at Day 30-45)      |
|       v                                                                 |
| +---------------------------------------------------------------------+ |
| | STAGE 2: Redemption Grace Period [RGP] (Exactly 30 Calendar Days)   | |
| | - EPP Status: redemptionPeriod (Domain removed from TLD Root Zone)  | |
| | - Recovery: Still 100% guaranteed to original owner, MUST pay       | |
| |   Registry RGP Redemption Fee ($80-$250) + renewal via registrar.   | |
| +---------------------------------------------------------------------+ |
|       |  (30-Day RGP expires without redemption payment)                |
|       v                                                                 |
| +---------------------------------------------------------------------+ |
| | STAGE 3: Pending Delete (Exactly 5 Calendar Days)                   | |
| | - EPP Status: pendingDelete                                         | |
| | - Recovery: IMPOSSIBLE to renew or redeem at any price. Registry    | |
| |   rejects all registrar commands until public drop at Day 5 (~18:00 | |
| |   UTC for Verisign .com/.net).                                      | |
| +---------------------------------------------------------------------+ |
+-------------------------------------------------------------------------+

Bandingkan hak, biaya, dan tindakan pemulihan Anda di setiap tahap habis masa berlakunya, termasuk Domain Tingkat Atas kode negara (ccTLDs seperti .uk, .de, .eu, .ca, .au), yang tidak mengikuti ICANN gTLD aturan:

Fase 2: Pemulihan selangkah demi selangkah dari file yang sudah kadaluwarsa atau RedemptionPeriod domain¶

Ikuti urutan yang tepat berikut untuk mengembalikan domain kedaluwarsa online dalam waktu sesingkat mungkin:

Langkah 1: Dapatkan kembali akses ke Akun Registrar Anda kapan @yourdomain.com emailnya sudah mati¶

Berikut adalah Catch-22 klasik dari domain kadaluwarsa: - Domain Anda (company.com) kadaluwarsa, jadi MX catatan untuk company.com berhenti menyelesaikan. - Anda mencoba masuk ke registrar domain Anda (GoDaddy, Namecheap, Cloudflare, Porkbun, Hover, Network Solutions, Gandi), dan registrar mengatakan: "Kami mengirimkan kode verifikasi 6 digit ke admin@company.com." - Karena company.com sudah habis masa berlakunya, email itu tidak akan pernah sampai.

Cara segera keluar dari loop email domain kadaluwarsa: 1. JANGAN mentransfer atau memodifikasi apa pun dulu: periksa apakah Anda dapat menjalankan penangkap email darurat sementara HANYA jika domain tersebut belum kedaluwarsa (jika domain itu sendiri telah kedaluwarsa pada tingkat TLD, MX tidak dapat diselesaikan di mana pun hingga diperbarui). 2. Gunakan Saluran Pemulihan Akun "Akses Email yang Hilang / Domain Kedaluwarsa" dari Registrar: - Hampir semua registrar terakreditasi ICANN menyediakan telepon khusus atau alur kerja verifikasi ID pemerintah/dokumen pendirian perusahaan khusus untuk pelanggan yang email loginnya berada @ domain kedaluwarsa di dalam akun. - Siapkan tiga item sebelum menghubungi dukungan registrar: (a) 4 digit terakhir kartu kredit atau ID transaksi PayPal yang digunakan pada faktur perpanjangan sebelumnya, (b) ID Akun Pendaftar / PIN Pelanggan Anda, dan © tanda pengenal berfoto pemerintah + Anggaran Dasar/tagihan utilitas yang cocok dengan Organisasi Pendaftar WHOIS (Tech / Admin / Registrant). 3. Setelah login, segera ubah alamat email Akun Registrar Anda ke domain eksternal (@gmail.com, @proton.me, atau domain darurat terpisah yang Anda miliki) dan aktifkan Kunci Keamanan Perangkat Keras (FIDO2) atau Aplikasi TOTP Authenticator MFA sehingga login tidak pernah bergantung pada @company.com email lagi.

Langkah 2: Jalankan Pembaruan atau RedemptionPeriod (RGP) Memulihkan¶

1. Jika domain berada di Tahap 1 (Auto-Renew Grace Period, Hari 1 hingga 30/45):
2. Buka Penagihan -> Perpanjangan atau Daftar Domain -> Filter Kedaluwarsa dan bayar faktur perpanjangan.
3. Pemeriksaan Kritis 60 detik setelah pembayaran: Buka Server Nama (NS) pengaturan di dasbor registrar. Periksa apakah registrar secara otomatis mengembalikan server nama asli Anda (misalnya, ns-123.awsdns-15.com atau ada.ns.cloudflare.com) atau membiarkan domain menunjuk ke server parkirnya yang sudah habis masa berlakunya (ns1.sedoparking.com / dns1.registrar-servers.com). Jika server parkir masih terdaftar, masukkan kembali server nama produksi Anda secara manual dan simpan.
4. Jika domain berada di Tahap 2 (Redemption Grace Period / redemptionPeriod, Hari 30/45 hingga 75):
5. Lihat di tab terpisah di dalam dasbor registrar Anda yang sering diberi label Domain Kedaluwarsa -> Penukaran, Sampah / Pemulihan, atau Tagihan Grace/Penukaran.
6. Bayar biaya Pemulihan RGP + perpanjangan 1 tahun.
7. Bagaimana cara kerja restorasi RGP di Registry (Verisign / PIR)? Saat Anda membayar biaya RGP, registrar Anda mengirimkan EPP <update><restore op="request"> perintah ke TLD Registry. Registri segera mengubah status domain dari redemptionPeriod untuk pendingRestore dan menempatkan domain Anda NS catatan kembali ke Zona Root TLD dalam waktu 15 hingga 60 menit sementara registrar Anda mengirimkannya restore op="report" konfirmasi kepatuhan.

Langkah 3: Lewati penundaan cache ISP lokal dengan membersihkan 8.8.8.8 dan 1.1.1.1¶

Ketika domain Anda telah kedaluwarsa, penyelesai DNS rekursif di seluruh dunia menyimpan cache server nama parkir atau yang negatif NXDOMAIN respon (diatur oleh TLD's SOA Minimum TTL, biasanya 900 untuk 3,600 detik, atau 86,400 detik untuk NS catatan). Saat ini dig @a.gtld-servers.net yourdomain.com NS (menanyakan .com server root secara langsung) menampilkan lagi server nama produksi Anda yang sebenarnya: 1. Buka Cache Siram DNS Publik Google (https://developers.google.com/speed/public-dns/cache): - Jenis siram NS pertama untuk yourdomain.com, lalu siram SOA, A, AAAA, MX, dan TXT. 2. Buka Cloudflare 1.1.1.1 Bersihkan Cache (https://one.one.one.one/purge-cache/): - Pembersihan NS, A, AAAA, dan MX untuk yourdomain.com.

Fase 3: Server Nama Darurat (NS) Migrasi Selama Gangguan Penyedia DNS (Dan DNSSEC Perangkap)¶

Bagaimana jika pendaftaran domain Anda 100 persen valid dan belum habis masa berlakunya, namun Penyedia DNS Resmi Anda (Route 53, Cloudflare, GoDaddy DNS, DigitalOcean DNS, Azure DNS, DNSimple, Dyn) mengalami gangguan besar atau serangan DDoS, dan Anda perlu memigrasikan Server Nama domain Anda (NS) ke penyedia DNS cadangan sekarang?

Pembunuh Migrasi #1: Peralihan NS Sementara DNSSEC (DS Rekam) Diaktifkan¶

Sebelum mengganti satu pun NS rekam di registrar Anda, jalankan perintah ini untuk memeriksa apakah DNSSEC diaktifkan di domain Anda di registri TLD induk:

dig +short yourdomain.com DS @8.8.8.8

+-------------------------------------------------------------------------+
| WHY CHANGING NS RECORDS WITH AN ACTIVE DS RECORD BREAKS THE INTERNET    |
|                                                                         |
| 1. Parent TLD (.com) holds your old DNS provider's DS Record (Key #2371)|
| 2. Old DNS Provider goes down. You import zone to New DNS Provider      |
|    (unsigned, or signed with a brand-new Key #9910) and swap NS.        |
| 3. Validating Resolver (8.8.8.8 / 1.1.1.1 / Comcast / ISP) queries      |
|    New DNS Provider, sees signature does NOT match DS Key #2371.        |
| 4. Resolver assumes an active MITM Spoofing Attack -> Returns SERVFAIL  |
| 5. RESULT: Your domain stays 100% dead worldwide even though the new    |
|    DNS servers are up and answering cleanly.                            |
+-------------------------------------------------------------------------+

Daftar Periksa Migrasi Server Nama Darurat yang Aman (Nol SERVFAIL Prosedur)¶

1. Rekonstruksi atau impor File Zona DNS lengkap Anda di penyedia DNS baru terlebih dahulu:
2. Jangan pernah menebak catatan DNS Anda dari memori (@, www, dan api jarang merupakan satu-satunya catatan; lupa MX, SPF/TXT, DKIM, _dmarc, autodiscover, atau CAA menghentikan pengiriman email dan perpanjangan TLS).
3. Di mana menemukan zona DNS lengkap Anda saat dasbor penyedia DNS utama Anda tidak aktif:
   • Periksa Infrastruktur sebagai Kode (Terraform, Pulumi, OctoDNS, DNSControl) di repositori Git Anda.
   • Periksa ekspor zona terkini (BIND .zone file) atau cari database DNS historis (SecurityTrails, ViewDNS.info, DNSDumpster, atau Censys / crt.sh untuk subdomain).
   • Catatan cache kueri masih tersimpan di dalam penyelesai rekursif publik (dig @8.8.8.8 yourdomain.com MX, dig @1.1.1.1 yourdomain.com TXT, dig @9.9.9.9 api.yourdomain.com A) sebelum TTL-nya habis masa berlakunya.
4. Pastikan penyedia DNS baru menjawab secara resmi untuk setiap catatan penting SEBELUM menghubungi registrar Anda: Misalkan penyedia baru Anda menugaskan Anda ns1.rescuedns.com dan ns2.rescuedns.com. Uji langsung dengan dig:

   dig @ns1.rescuedns.com yourdomain.com SOA +norecurse
   dig @ns1.rescuedns.com yourdomain.com A +norecurse
   dig @ns1.rescuedns.com yourdomain.com MX +norecurse
   

   Tunggu sampai flags: garis di dig header secara eksplisit menyertakan aa (Authoritative Answer) dan kembali status: NOERROR.
5. Jika dig +short yourdomain.com DS kembali a DS rekam, tangani DNSSEC di registrar:
6. Selama pemadaman aktif saat penyedia DNS lama benar-benar tidak dapat dijangkau: Masuk ke Pendaftar Domain Anda (tempat Anda membeli domain), buka bagian Catatan DNSSEC / DS, dan hapus semua DS catatan sehingga domain kembali ke unsigned (Insecure) mode di zona induk TLD. Tunggu sampai dig +short yourdomain.com DS @a.gtld-servers.net kembali kosong (dan siram DS di 8.8.8.8 / 1.1.1.1), atau tambahkan penyedia DNS baru DS catatan di samping yang lama jika melakukan migrasi multi-penanda tangan yang direncanakan.
7. Perbarui Server Nama (NS) di Pendaftar Domain Anda: Ganti nameserver yang mati dengan ns1.rescuedns.com dan ns2.rescuedns.com di panel Custom Nameserver registrar Anda (catatan: berubah NS catatan di dalam editor zona tidak melakukan apa pun ketika server lama mati; Anda harus mengubah Server Nama Delegasi Lem/Orang Tua di tingkat Registrar).
8. Pembersihan NS dan DS cache di Google (8.8.8.8) dan Cloudflare (1.1.1.1): Gunakan alat pembersihan cache publik dari Tahap 2 Langkah 3 untuk memaksa adopsi segera server nama baru.

Fase 4: Bertahan dari Kunci Transfer Registrar ICANN 60 Hari selama keadaan darurat¶

Bagaimana jika Anda perlu mentransfer domain Anda ke registrar baru (ICANN Inter-Registrar Transfer), hanya untuk diblokir oleh Domain Status: clientTransferProhibited dan pesan yang mengatakan: "Domain ini berada di bawah Kunci Transfer ICANN 60 hari karena informasi kontak baru saja diperbarui"?

1. Mengapa penguncian 60 hari dipicu: Berdasarkan Kebijakan Transfer ICANN (Bagian II.C.1), registrar melakukan kunci transfer 60 hari setiap kali domain baru didaftarkan, ditransfer antar registrar, atau mengalami "Perubahan Pendaftar" (memperbarui Nama Depan, Nama Belakang, Nama Organisasi, atau Alamat Email kontak Pendaftar).
2. Cara melewati atau memilih keluar dari kunci 60 hari Perubahan Pendaftar:
3. Sebelum mengedit detail kontak WHOIS: Hampir semua registrar besar menyediakan kotak centang tepat di layar edit kontak berlabel: "Memilih keluar dari kunci transfer 60 hari setelah pembaruan kontak ini." Mencentang kotak itu memungkinkan Anda memperbarui alamat email admin/pendaftar dan tetap menghasilkan EPP Auth-Code (Transfer Secret) untuk mentransfer domain pada hari yang sama.
4. Ingat bahwa Anda TIDAK perlu mentransfer pendaftaran domain untuk mengubah penyedia DNS: Meskipun domain dikunci selama 60 hari terhadap Transfer Registrar (clientTransferProhibited), Anda masih dapat mengubah Nameservernya (NS catatan) di registrar saat ini kapan saja tanpa masa tunggu; peralihan DNS membutuhkan waktu beberapa menit, sedangkan transfer registrar penuh memerlukan waktu hingga 5 hingga 7 hari kecuali registrar yang kalah langsung mengklik Setujui Transfer Keluar (FOa) tombol.

Fase 5: Memperkuat pendaftaran domain dan DNS terhadap pemadaman di masa mendatang¶

Setelah resolusi domain dan DNS Anda pulih 100 persen, selesaikan daftar periksa ketahanan berikut:

• Aktifkan Registry Lock (serverDeleteProhibited, serverUpdateProhibited, serverTransferProhibited) pada domain produksi yang sangat penting: Standar Registrar Lock (clientTransferProhibited) dapat dimatikan dengan satu klik jika penyerang membajak login registrar Anda. Kunci Registri (ditawarkan oleh Verisign, PIR, Cloudflare, CSC, MarkMonitor, Gandi, dan Porkbun/Namecheap untuk domain perusahaan) mengunci domain langsung di tingkat Registri TLD, yang memerlukan verifikasi suara/kriptografi multi-orang di luar pita sebelum melakukan apa pun NS catatan dapat diubah atau domain dihapus.
• Memperbarui domain produksi selama 5 hingga 10 tahun sebelumnya (ICANN maximum horizon is 10 years): Jangan pernah meninggalkan domain bisnis penting pada perpanjangan tahun ke tahun karena satu kartu kredit perusahaan yang masa berlakunya sudah habis dapat memicu penghentian masa berlaku. Prabayar 5 hingga 10 tahun sekaligus.
• Jangan pernah menggunakan @yourdomain.com alamat email sebagai kontak login atau notifikasi penagihan pada pengelola registrar yourdomain.com: Gunakan daftar distribusi keamanan khusus pada domain administratif independen atau akun eksternal yang diperkuat, dan pantau RDAP / WHOIS tanggal kedaluwarsa melalui monitor Prometheus/Uptime eksternal otomatis (domain_expiry_days < 60).
• Lebih rendah NS dan DS TTL (300 untuk 3600 detik) 48 jam sebelum migrasi DNS yang direncanakan: Menurunkan TTL terlebih dahulu memastikan penyelesai beralih dalam waktu 5 menit setelah peralihan yang direncanakan.

Nomor darurat regional dan protokol lembaga¶

Jika pemadaman domain atau DNS berdampak pada fasilitas kesehatan, layanan darurat, utilitas kota, atau infrastruktur pemerintah, ikuti saluran eskalasi regional berikut:

• Amerika Serikat dan Kanada: Hubungi 911 jika pemadaman domain/DNS menonaktifkan telemetri rumah sakit klinis, pengiriman ambulans, atau sistem keselamatan jiwa. Laporkan serangan DDoS pada infrastruktur DNS atau pembajakan BGP/DNS ke CISA (1-844-Say-CISA / cisa.gov/report), FBI IC3 (ic3.gov), atau Pusat Keamanan Siber Kanada (1-833-CYBER-88). Untuk .gov domain, hubungi CISA .gov Meja Bantuan Pendaftar.
• Inggris Raya: Hubungi 999 untuk ancaman terhadap nyawa atau gangguan NHS akut. Laporkan pemadaman DNS kritis atau pembajakan domain ke NCSC (ncsc.gov.uk), dan hubungi Nominet (01865 332244) langsung untuk mendesak .uk / .gov.uk / .nhs.uk masalah registri.
• Uni Eropa: Hubungi 112 di seluruh negara anggota UE. Penyedia layanan DNS dan pendaftar nama TLD diatur berdasarkan Petunjuk EU NIS2 (Directive 2022/2555) dan harus melaporkan insiden ketersediaan yang signifikan ke CSIRT nasionalnya dalam waktu 24 jam.
• Australia dan Selandia Baru: Hubungi 000 di Australia atau 111 di Selandia Baru; laporkan insiden DNS atau domain penting ke ACSC (1300 CYBER1), auDA (untuk .au), atau Komisi Nama Domain NZ (untuk .nz).
• India dan Asia-Pasifik: Hubungi 112 di India untuk tanggap darurat; laporkan serangan infrastruktur DNS/domain ke CERT-In (incident@cert-in.org.in) dalam waktu 6 jam atau NIXI untuk .in eskalasi registri.

Pertanyaan yang sering diajukan¶

Mengapa domain saya berhenti berfungsi 24 jam SEBELUM stempel waktu kedaluwarsa WHOIS resminya?¶

Pertama, periksa zona waktu: WHOIS `Registry Expiry Date` selalu dicetak dalam **UTC (`Z`)**, yaitu 4 hingga 8 jam lebih cepat dari zona waktu Amerika Utara (artinya domain akan habis masa berlakunya pada `2026-11-01T04:00:00Z` sebenarnya habis masa berlakunya pada `8:00 PM PDT` pada tanggal 31 Oktober). Kedua, jika Anda `NS` catatan memiliki a `24-hour` atau `48-hour` TTL dan registrar menukarnya di `00:00 UTC` pada hari habis masa berlakunya, pengguna yang penyelesainya disegarkan lebih awal akan segera membuka halaman parkir sementara pengguna lain tetap menyimpan cache selama berjam-jam.

Registrar saya benar-benar gulung tikar atau tidak responsif (Dead / De-accredited Registrar), dan masa berlaku domain saya sudah habis. Bagaimana cara menyelamatkannya?¶

Ketika ICANN menghentikan atau mendeakreditasi registrar yang gagal berdasarkan **Prosedur Transisi Registrar yang Dibatalkan Terakreditasi (`DARTP`)**, ICANN secara otomatis mentransfer semua domain secara massal ke registrar kustodian yang memperolehnya tanpa biaya apa pun kepada pendaftar. Periksa `whois yourdomain.com` (atau `lookup.icann.org`) untuk melihat **Registrar** dan **IANA ID** mana yang saat ini memegang domain Anda, atau ajukan **Keluhan Perpanjangan Domain/Transfer** yang mendesak secara langsung ke **ICANN Contractual Compliance (`icann.org/compliance/complaint`)**.

Mengapa situs web saya berfungsi untuk beberapa pelanggan dengan data seluler, namun masih menampilkan halaman parkir yang kedaluwarsa di Wi-Fi kantor kami 6 jam setelah saya memperbarui domain?¶

Jaringan kantor Anda atau penyelesai DNS rekursif ISP lokal menyimpan cache halaman parkir registrar `NS` dan `A` catatan saat domain telah kedaluwarsa, dan server nama parkir terkenal menetapkan TTL tinggi (`3,600` untuk `86,400` detik / 24 jam) sehingga halaman iklan tetap disimpan dalam cache lebih lama. Siram Google (`8.8.8.8`) dan Cloudflare (`1.1.1.1`) menggunakan alat pembersih web mereka, lalu dijalankan di komputer lokal Anda `ipconfig /flushdns` (jendela), `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` (macOS), atau `sudo resolvectl flush-caches` (Linux).

Apa yang Terjadi pada Email yang Dikirim ke @yourdomain.com Sedangkan Domain atau DNS Kita Kedaluwarsa 18 Jam? Apakah Mereka Hilang Selamanya?¶

Dalam kebanyakan kasus, email sah yang dikirim selama 12 hingga 48 jam pertama pemadaman DNS TIDAK hilang: email tersebut dimasukkan dalam antrean di server email pengirim dan akan tiba secara otomatis selama beberapa jam berikutnya. Di bawah **`RFC 5321` (Protokol Transfer Surat Sederhana, Bagian 4.5.4.1)**, ketika server surat pengirim (`Gmail`, `Microsoft Exchange Online`, `Postfix`) mendapat kegagalan pencarian DNS sementara (`SERVFAIL`) atau tidak dapat terhubung ke `MX` host, ia menempatkan pesan dalam antrian coba lagi selama **4 hingga 5 hari (`96 to 120 hours`)**, mencoba ulang dengan backoff eksponensial. Namun, jika halaman parkir registrar yang kedaluwarsa menyertakan **wildcard null `MX` catatan (`0 .`)** atau server email parkir yang menolak email dengan keras `550 5.1.1 User Unknown` pentalan permanen, pengirim tersebut menerima pemberitahuan pentalan segera dan harus mengirim ulang email mereka.

Bisakah saya mengatur dua penyedia DNS secara bersamaan (Cloudflare + Route 53) cukup dengan mencantumkan dua Cloudflare NS catatan dan dua Route 53 NS catatan di registrar saya?¶

Ya, selama `DNSSEC` dinonaktifkan (atau dikonfigurasi dengan benar dengan `RFC 8901` Multi-Signer DNSSEC) dan kedua penyedia menyajikan data DNS yang identik. Resolver rekursif menanyakan semua induk yang terdaftar `NS` catatan menggunakan pemilihan latensi round-robin/RTT (`SRTT`). Jika Anda daftar `ns1.providerA.com`, `ns2.providerA.com`, `ns1.providerB.com`, dan `ns2.providerB.com` di Server Nama Khusus registrar Anda dan jaga agar kedua zona tetap tersinkronisasi menggunakan **OctoDNS**, **DNSControl**, **Terraform**, atau `AXFR / IXFR` transfer zona, domain Anda secara otomatis bertahan jika terjadi pemadaman 100 persen pada salah satu penyedia DNS.

Apa perbedaan antara clientHold dan serverHold di WHOIS?¶

Kode status EPP dimulai dengan **`client...`** (`clientHold`, `clientTransferProhibited`) ditetapkan oleh **Pendaftar Domain** Anda (pengecer tempat Anda mengelola akun, seperti Namecheap atau GoDaddy) dan dapat segera dihapus oleh dukungan atau sistem penagihan registrar Anda. Kode status dimulai dengan **`server...`** (`serverHold`, `serverTransferProhibited`) diatur langsung oleh **Operator Registri TLD** (`Verisign`, `PIR`, `Nominet`) karena perintah pengadilan, sengketa UDRP, penangguhan penyalahgunaan tingkat registri, atau **Kunci Registri** perangkat keras, dan mengharuskan Anda menghubungi Registri melalui registrar Anda untuk mencabutnya.

Panduan terkait¶

• Pembajakan nama domain, DNS kadaluwarsa, dan pengambilalihan situs web
• Sertifikat SSL/TLS kedaluwarsa dalam produksi, penguncian pramuat HSTS, blok catatan CA CAA, dan pembaruan darurat
• Penguncian admin domain kustom Google Workspace atau Microsoft 365, verifikasi DNS TXT, dan penyelamatan penyewa
• Pembajakan DNS, konfigurasi ulang WAN router ISP, dan spoofing portal captive
• Krisis hosting web, migrasi, dan pemulihan cadangan
• Nomor darurat menurut negara

Sumber dan panduan resmi¶

• Perusahaan Internet untuk Nama dan Nomor yang Ditugaskan (ICANN): Kebijakan Pemulihan Pendaftaran Kedaluwarsa (ERRP), Kebijakan Penghapusan Domain Kedaluwarsa (EDDP), Kebijakan Transfer Antar Pendaftar (Penguncian Perubahan Pendaftar 60 Hari), dan Referensi Kode Status EPP (clientHold, redemptionPeriod, pendingDelete).
• Satgas Rekayasa Internet (IETF): RFC 6781 (Praktik Operasional DNSSEC: Key Rollover dan Darurat DS Penghapusan) & RFC 8901 (Model DNSSEC Multi-Penandatangan untuk DNS Resmi Multi-Penyedia).
• Institut Standar dan Teknologi Nasional (NIST) (Amerika Serikat): Publikasi Khusus 800-81-2: Sistem Nama Domain Aman (DNS) Panduan Penerapan.
• Badan Keamanan Siber dan Infrastruktur (CISA) (Amerika Serikat): Petunjuk Darurat 19-01: Mitigasi Gangguan Infrastruktur DNS.
• Badan Keamanan Siber Uni Eropa (ENISA): Panduan Teknis NIS2 untuk Penyedia Layanan DNS dan Registri Nama TLD.