---
title: "Subdomain Takeover, Celah dari DNS yang Terlupakan"
description: "Penjelasan subdomain takeover akibat record CNAME yang menggantung, contoh skenarionya, dan langkah mengaudit DNS agar subdomain tidak direbut orang."
url: "https://nivelva.com/insight/subdomain-takeover-celah-dns-terlupakan"
category: "Keamanan/Cyber Security"
tags: ["subdomain takeover","dns","cname","keamanan website","domain"]
author: "Theresia Candiawan"
published: "2026-11-07T09:32:00+07:00"
updated: "2026-11-07T09:32:00+07:00"
language: "id"
publisher: "Nivelva (https://nivelva.com)"
---

# Subdomain Takeover, Celah dari DNS yang Terlupakan

> **Jawaban singkat:** Subdomain takeover terjadi saat record DNS masih menunjuk ke layanan pihak ketiga yang sudah dihapus, sehingga orang lain bisa mengklaimnya dan menguasai subdomainmu. Cegah dengan inventaris DNS, hapus record yang menggantung, dan hapus DNS lebih dulu saat mematikan layanan.

Kapan terakhir kali kamu memeriksa daftar record DNS domain bisnismu satu per satu? Bagi banyak tim, jawabannya "waktu pertama kali setting", lalu record terus bertambah setiap ada kampanye, landing page, atau uji coba layanan baru.

Di tumpukan record lama itulah subdomain takeover bersembunyi. Celah ini muncul saat sebuah subdomain, misalnya `promo.domainmu.com`, masih menunjuk ke layanan pihak ketiga yang sudah tidak kamu pakai. Bila layanan itu mengizinkan siapa pun mengklaim nama yang sama, orang lain bisa memasang kontennya sendiri di subdomainmu, lengkap dengan nama domain resmi di address bar.

## Bagaimana subdomain takeover terjadi?

Skenario umumnya seperti ini. Tim marketing membuat landing page di sebuah platform hosting statis atau layanan cloud, lalu menambahkan record CNAME:

```
promo.domainmu.com.  CNAME  kampanye-domainmu.platform-contoh.net.
```

Kampanye selesai, akun di platform itu dihapus, tetapi record CNAME di DNS tetap ada. Record seperti ini disebut **dangling** (menggantung): menunjuk ke sesuatu yang sudah tidak ada.

Penyerang yang memindai DNS menemukan bahwa `kampanye-domainmu.platform-contoh.net` kosong. Ia mendaftar di platform yang sama, mengklaim nama itu, dan sekarang `promo.domainmu.com` menampilkan halaman miliknya. Pada sebagian layanan, ia juga bisa menerbitkan sertifikat SSL yang sah untuk subdomain tersebut.

Dampaknya bisa serius:

- Halaman phishing atau toko palsu di bawah domain resmimu.
- Pencurian cookie bila cookie situs utama diset untuk seluruh `.domainmu.com`.
- Reputasi domain rusak di mata mesin pencari dan filter email.

Selain CNAME, record A yang menunjuk ke IP cloud yang sudah dilepas juga berisiko, karena IP itu bisa dialokasikan ke pelanggan lain. Record NS dan MX yang menunjuk ke layanan yang sudah mati juga perlu diperiksa.

## Kenapa record lama mudah terlupakan?

Subdomain biasanya dibuat oleh banyak orang di waktu yang berbeda. Agensi pernah memasang landing page, developer menambah subdomain staging, tim support memakai layanan helpdesk dengan domain kustom, lalu semua itu ditinggalkan saat vendor berganti. Panel DNS tidak memberi tahu bahwa sebuah record sudah tidak berguna.

Layanan yang sering terlibat adalah yang memakai domain kustom lewat CNAME: hosting statis, penyimpanan objek cloud, platform landing page, toko online, helpdesk, dan dokumentasi. Tidak semuanya rentan, tetapi semuanya perlu dicatat. Masalah yang sama muncul saat [subdomain dibuat](https://nivelva.com/insight/cara-membuat-subdomain-dipakai) tanpa pencatatan siapa pemilik dan sampai kapan dipakai.

## Langkah mengaudit DNS dari subdomain yang menggantung

1. **Ekspor semua record DNS.** Buka panel DNS (registrar, Cloudflare, atau cPanel) dan unduh atau salin seluruh record ke spreadsheet. Bila DNS dikelola di beberapa tempat, gabungkan semuanya.
2. **Tambahkan subdomain yang tidak tercatat.** Cari subdomain yang pernah punya sertifikat SSL di log Certificate Transparency, misalnya lewat crt.sh dengan kueri `%.domainmu.com`. Hasilnya sering mengungkap subdomain lama yang sudah dilupakan.
3. **Cek tujuan setiap CNAME.** Jalankan `dig +short CNAME promo.domainmu.com`, lalu cek apakah target itu masih ada dengan `dig +short kampanye-domainmu.platform-contoh.net`. Jawaban kosong atau status NXDOMAIN pada target adalah tanda bahaya.
4. **Buka subdomain di browser.** Pesan seperti "No such app", "There isn't a site here", atau "NoSuchBucket" sering menandakan layanan di belakangnya sudah dihapus. Daftar pesan khas tiap layanan dikumpulkan komunitas di repositori can-i-take-over-xyz.
5. **Cocokkan dengan pemilik layanan.** Tanyakan ke tim terkait apakah subdomain itu masih dipakai. Tandai pemilik setiap record di spreadsheet.
6. **Hapus record yang tidak dipakai.** Jangan menunggu. Record yang menggantung bisa diklaim kapan saja.
7. **Periksa record A ke IP cloud.** Pastikan IP masih milik server atau akunmu. Bila server sudah dimatikan, hapus recordnya.

Untuk memahami arti tiap jenis record dan cara membacanya, lihat [apa itu DNS dan record A, CNAME, MX, TXT](https://nivelva.com/insight/apa-itu-dns).

## Bagaimana mencegahnya terulang?

Audit sekali tidak cukup karena record baru terus ditambahkan. Pencegahan yang paling efektif justru soal urutan kerja.

### Hapus DNS dulu, baru layanan

Saat mematikan layanan, hapus record DNS **sebelum** menghapus akun atau resource di platform pihak ketiga. Bila urutannya terbalik, ada jeda waktu ketika subdomain menunjuk ke sesuatu yang kosong.

### Batasi siapa yang bisa menambah record

Tidak semua orang perlu akses ke panel DNS. Bila tim marketing butuh subdomain, ajukan lewat satu orang atau satu tim yang mencatat pemilik dan tujuan record.

### Pakai verifikasi domain bila tersedia

Banyak platform kini meminta record TXT verifikasi sebelum domain kustom bisa dipasang. Aktifkan fitur ini dan jangan hapus record verifikasinya selama layanan masih dipakai.

### Pindai berkala

Masukkan pengecekan subdomain ke jadwal pemeriksaan keamanan rutin, misalnya bersama vulnerability scan bulanan. Uji subdomain takeover juga termasuk dalam panduan pengujian OWASP Web Security Testing Guide.

> **Wildcard DNS:**
>
> Record wildcard seperti `*.domainmu.com` yang menunjuk ke layanan pihak ketiga membuat setiap subdomain acak ikut mengarah ke sana. Bila layanan itu dihapus, risikonya berlipat. Pakai wildcard hanya bila memang perlu.

## Ringkasan jenis record yang perlu diperiksa

| Record | Risiko bila menggantung | Cara cek cepat |
|:--|:--|:--|
| CNAME ke platform pihak ketiga | Nama di platform diklaim orang lain | Target CNAME tidak resolve atau halaman error khas |
| A ke IP cloud | IP dialokasikan ke pelanggan lain | IP tidak lagi tercatat di akun cloud kamu |
| NS ke zona yang dihapus | Orang lain bisa membuat zona dan menguasai DNS subdomain | Nameserver menjawab REFUSED atau SERVFAIL |
| MX ke layanan email lama | Email masuk bisa diterima pihak lain | Layanan email lama sudah tidak berlangganan |

## Pertanyaan yang sering diajukan

### Apakah semua CNAME yang menggantung pasti bisa diambil alih?

Tidak. Itu bergantung pada layanan tujuannya. Sebagian platform mencegah klaim nama yang pernah dipakai atau mewajibkan verifikasi, sebagian lagi tidak. Karena sulit memastikan, record yang tidak dipakai lebih aman dihapus.

### Apakah HTTPS di situs utama melindungi subdomain?

Tidak. Sertifikat situs utama tidak mencegah orang lain memasang konten di subdomain yang sudah direbut, dan di beberapa layanan penyerang bisa menerbitkan sertifikat sendiri.

### Seberapa sering audit DNS perlu dilakukan?

Idealnya setiap kali layanan dimatikan, ditambah pemeriksaan menyeluruh berkala, misalnya tiap tiga bulan untuk domain dengan banyak subdomain.

### Apakah record DNS lama memperlambat website?

Tidak berpengaruh ke kecepatan situs utama. Masalahnya ada di keamanan dan kerapian, bukan performa.

Checklist singkat sebelum menutup tab:

- Semua record DNS sudah tercatat beserta pemiliknya.
- CNAME ke layanan yang sudah dihapus sudah dibuang.
- Record A ke IP cloud lama sudah dibersihkan.
- Prosedur mematikan layanan mencantumkan "hapus DNS dulu".
- Ada jadwal audit berikutnya di kalender.

## Sumber

- <https://github.com/EdOverflow/can-i-take-over-xyz>
- <https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/10-Test_for_Subdomain_Takeover>

---

Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/subdomain-takeover-celah-dns-terlupakan
Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com
