Alat populer

Tema

Reverse DNS Lookup — Cek PTR Record

Temukan hostname di balik alamat IPv4 atau IPv6 apa pun dengan reverse DNS lookup: setiap PTR record langsung dari nameserver zona reverse itu sendiri, apakah setiap nama mengarah kembali ke alamatnya (FCrDNS), siapa yang menjalankan zonanya, dan apakah alamat itu lolos aturan Gmail, Yahoo, dan Microsoft untuk server email.

Sumber: nameserver zona reverse, dihubungi mulai dari server root · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru

IPv4 atau IPv6 dalam notasi apa pun, hostname (di-resolve lebih dulu), atau nama in-addr.arpa.

Coba

Apa itu reverse DNS (rDNS)?

Reverse DNS mengubah alamat IP kembali menjadi nama host: kebalikan dari lookup biasa (forward), yang mengubah nama menjadi alamat. Jawabannya adalah PTR record yang dipublikasikan pemegang alamat di bagian DNS yang khusus disediakan untuk alamat.

Nama DNS dibaca dari kanan ke kiri, jadi alamat ditulis terbalik agar bisa dicari: 8.8.8.8 menjadi 8.8.8.8.in-addr.arpa dan 203.0.113.7 menjadi 7.113.0.203.in-addr.arpa. Dengan bagian jaringan di sebelah kanan, setiap blok alamat bisa diserahkan kepada pemegangnya (RFC 1035 §3.5).

IPv6 memakai ip6.arpa dan ke-32 digit heksadesimal (nibble) alamatnya, dimulai dari digit terakhir: :: diuraikan dulu sebelum digitnya dibalik, sehingga 2001:4860:4860::8888 punya nama dengan 32 label (RFC 3596 §2.5). Alat ini menampilkan nama yang akan ditanyakannya di bawah kolom saat Anda mengetik, dan menuliskan ke-32 nibble di jalur reverse di samping hasil.

Anatomi nama reversedata langsung, 2026-10-23

Alamat IPv4OpenDNS

208.67.222.222222.222.67.208.in-addr.arpa

Nama reverse-nya, yang ditanya untuk PTRresolver1.opendns.com +3

Oktet dibalik/8 berada di akhir: 208.in-addr.arpa adalah zona ARIN, 222.67.208.in-addr.arpa milik OpenDNS sendiri.
in-addr.arpaPohon reverse IPv4, dikelola oleh IANA dan disajikan oleh a sampai f.in-addr-servers.arpa.
PTRIsi nama itu: resolver1.opendns.com dan tiga hostname lainnya.

Alamat IPv6, ditulis lengkapGoogle

2001:4860:4860:0000:0000:0000:0000:8888

32 nibble, dimulai dari digit terakhir

8888 di akhir muncul pertama, /32 milik Google, 2001:4860, muncul terakhir, dan 16 nol yang disembunyikan :: ditulis lengkap.

8.8.8.8.in-addr.arpaIPv4: empat label, dibalik
8.8.8.8.0.0.0.0…ip6.arpaIPv6: ke-32 digit, dibalik
8.8.8.8.0.6.8.4…ip6.arpa:: dibiarkan terkompresi: nama lain, dan NXDOMAIN
8.8.8.8 terbaca sama dari kedua arah, jadi gambar ini memakai 208.67.222.222, yang oktetnya jelas bertukar tempat. Jalur reverse di alat ini menggambarkan pertukaran yang sama untuk setiap alamat IPv4 yang dicarinya.

Cara melakukan reverse DNS lookup

Ketik alamat di atas lalu tekan Cek PTR. Alat ini menelusuri turun dari server root ke nameserver zona reverse itu sendiri dan bertanya langsung kepadanya, lalu membandingkan salinan cache Google dan Cloudflare. Dari terminal, dig -x 8.8.8.8 di macOS dan Linux, nslookup 8.8.8.8 di Windows, atau host 8.8.8.8 melakukan hal yang sama.

dig -x menyusun nama in-addr.arpa atau ip6.arpa untuk Anda; tambahkan @ dan nameserver zona dengan +norecurse (dig -x 8.8.8.8 @ns1.google.com +norecurse) untuk membaca jawaban zona itu sendiri dan TTL penuhnya, bukan cache. Untuk PowerShell, bentuk yang didokumentasikan Microsoft memakai nama yang dibalik: Resolve-DnsName -Name 8.8.8.8.in-addr.arpa -Type PTR.

dig -x 8.8.8.8 +noall +answer

dig menyusun 8.8.8.8.in-addr.arpa sendiri. Angka sebelum IN adalah TTL yang tersisa di resolver Anda.

Membaca jawaban digGoogle Public DNS, lalu server Google sendiri · direkam 2026-10-23
bash · zsh
$ dig -x 8.8.8.8 @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24160
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.        IN   PTR

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.  14003  IN   PTR   dns.google.

;; SERVER: 8.8.8.8#53(8.8.8.8)

$ dig -x 8.8.8.8 @ns1.google.com +norecurse
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
8.8.8.8.in-addr.arpa.  86400  IN   PTR   dns.google.
;; SERVER: 216.239.32.10#53(216.239.32.10)
  1. Status. NOERROR dengan satu jawaban. NXDOMAIN berarti tidak ada PTR yang dipasang; SERVFAIL berarti zona reverse rusak.
  2. Pertanyaan. dig menyusun 8.8.8.8.in-addr.arpa dari alamatnya dan menanyakan PTR-nya.
  3. TTL. 14.003 detik tersisa di cache Google. Server zona itu sendiri memberi TTL penuh 86.400, yaitu satu hari.
  4. Hostname. Nilai PTR. Titik di akhir menutup nama.
  5. Yang menjawab. 8.8.8.8, sebuah cache. Di jawaban kedua, flag aa menandai server zona itu sendiri.
Satu PTR, ditanyakan dua kali: Google Public DNS menjawab dari cache-nya, sambil menghitung mundur; ns1.google.com, yang ditanya dengan +norecurse, menjawab untuk zona dengan TTL penuh.

Cara membaca hasilnya

Bagian atas menyatakan dalam satu kalimat nama PTR alamat itu dan apakah nama itu mengarah kembali, dengan TTL zona dan server yang menjawab. Catatan berwarna di bawahnya menyebut siapa yang bisa mengubah nama itu dan apa yang tidak biasa darinya.

Tampilan PTR mencantumkan setiap nama dengan TTL dan cek forward-nya; Email menilainya berdasarkan aturan penerima; Delegasi menampilkan setiap server yang ditanya; Salinan membandingkan jawaban cache Google dan Cloudflare; Perintah memberi pencarian yang sama untuk terminal. Di sebelah kanan, jalur reverse menggambarkan seluruh penelusurannya.

Reverse DNS lookup 8.8.8.8: PTR record dns.google dari nameserver Google, cek forward-nya, dan jalur delegasinyaReverse DNS lookup 8.8.8.8: PTR record dns.google dari nameserver Google, cek forward-nya, dan jalur delegasinyaKesimpulanNama PTR alamat itu, apakah nama itu mengarah kembali, dan siapa yang memasangnya, dengan TTL dan server yang menjawab.PTR recordSetiap nama yang disimpan zona untuk alamat itu, dengan TTL-nya dan alamat yang dihasilkan lookup forward-nya.TampilanAturan email, delegasi hop demi hop, salinan cache dengan hitung mundurnya, dan perintahnya.Jalur reverseAlamat yang dibalik menjadi nama DNS-nya, lalu root, IANA, registri, dan zona yang menjawab.
Reverse DNS lookup untuk 8.8.8.8: kesimpulan, PTR record dengan TTL dan cek forward-nya, serta jalur reverse dari root ke zona Google. Pilih sebuah nomor untuk melihat arti setiap bagian.

Apa itu PTR record?

PTR (pointer) record, tipe DNS 12, menyimpan satu nama host untuk alamat tempatnya berada: 8.8.8.8.in-addr.arpa. 86400 IN PTR dns.google. Record ini hanya data: tidak seperti CNAME, record ini tidak mengarahkan ke mana pun (RFC 1035 §3.3.12).

Yang menulisnya adalah pemegang alamat, bukan pemilik nama di dalamnya: zona reverse Google menyatakan 8.8.8.8 adalah dns.google, dan hanya record A di zona dns.google yang menyatakan sebaliknya. Satu alamat bisa punya beberapa PTR record (RFC 2181 §10.2): 208.67.222.222 punya empat. Nama itu harus berupa nama host sungguhan, tidak pernah alias.

PTR hanya berisi nama, tidak ada yang lain: tidak ada pemilik, negara, atau kota. Lokasi yang tampil di samping hasil pencarian berasal dari kata yang dimasukkan operator ke dalam nama itu, atau dari database terpisah.

Satu nama, dua zona8.8.8.8 dan dns.google, data langsung 2026-10-23
Zona forwardmilik domain: dns.google
dns.google. A 8.8.8.8dns.google. A 8.8.4.4dns.google. AAAA 2001:4860:4860::8888dns.google. AAAA 2001:4860:4860::8844

Disajikan oleh ns1.zdns.google untuk pemegang dns.google

dua zona, dua set server
Zona reversemilik blok alamat: 8.8.8.0/24
8.8.8.8.in-addr.arpa. PTR dns.google.

Didelegasikan ARIN ke Google, disajikan oleh ns1.google.com

8.8.8.8.in-addr.arpa.Nama reverse86400TTL · 1 hariINKelasPTRTipedns.google.Hostname
1 alamat, 4 nama208.67.222.222: resolver1.opendns.com dan tiga lainnya
1 alamat, 48 nama17.253.144.10, alamat apple.com, masing-masing dengan TTL 5 menit
1 nama, 4 alamatdns.google: 8.8.8.8, 8.8.4.4, dan dua IPv6
PTR menyatakan nama 8.8.8.8; record A menyatakan ke mana dns.google mengarah. Kebetulan Google menjalankan kedua zona, di server yang berbeda.

Apa itu forward-confirmed reverse DNS (FCrDNS)?

Forward-confirmed reverse DNS berarti nama PTR di-resolve kembali ke alamat yang sama: 8.8.8.8 → dns.google → 8.8.8.8. Server email menyebut pengecekan ini iprev (RFC 8601 §3): cari nama PTR alamat itu, cari record A atau AAAA setiap nama, dan lolos jika alamat tersebut ada di antaranya.

Langkah kedua penting karena siapa pun yang memegang sebuah alamat bisa menulis nama apa saja di PTR-nya, termasuk google.com. Nama itu baru membuktikan sesuatu jika pemilik domainnya mengarahkannya kembali. Alat ini mengecek setiap nama PTR, hingga sepuluh, dan menggambar lingkarannya di sebelah kanan: hijau jika lingkaran tertutup, kuning jika nama itu mengarah ke tempat lain.

Jika ada beberapa PTR record, satu yang mengarah kembali sudah cukup. Nama yang record A-nya juga mencantumkan alamat lain tetap lolos, selama alamat ini termasuk di antaranya.

Tiga alamat, tiga lingkarandata langsung, 2026-10-23
Terkonfirmasi forwardGoogle
8.8.8.8dns.google8.8.8.8: alamat yang sama
Mengarah kembalidns.google juga menghasilkan 8.8.4.4
Mengarah ke tempat lainAdGuard
94.140.14.14dns.adguard-dns.com185.113.30.30: alamat lain
Tidak terkonfirmasirecord A-nya 185.113.30.30
Tanpa PTRCloudflare
104.18.0.1NXDOMAIN: tanpa nama
Tidak ada yang dikonfirmasiNXDOMAIN dari zona Cloudflare
Lingkaran yang sama berjalan di sisi kanan setiap hasil: hijau jika nama itu kembali ke alamatnya, kuning jika mengarah ke tempat lain.

Cek reverse DNS untuk server email: syarat Gmail, Yahoo, dan Outlook.com

Ketiganya menginginkan PTR record di setiap IP pengirim. Gmail juga mewajibkan nama itu di-resolve kembali ke IP yang sama, dan Yahoo mewajibkan "record DNS forward dan reverse yang valid", keduanya untuk setiap pengirim sejak Februari 2024. Kebijakan Outlook.com meminta reverse DNS yang valid dan tidak menyebut apa pun tentang langkah forward.

Nama generik seperti ec2-3-80-0-1.compute-1.amazonaws.com tidak melanggar aturan apa pun: Yahoo hanya menyarankan nama yang bermakna, tidak generik, dan mencerminkan domain Anda. Outlook.com memperingatkan bahwa koneksi dari ruang IP dinamis mungkin tidak diterima, dan itu mengenai nama pool milik ISP, bukan nama default statis milik server cloud. Tampilan Email menunjukkan hal-hal itu sebagai peringatan dan persyaratan sebagai lolos atau gagal; pengecekan yang tidak selesai bukan keduanya.

Dua hal tidak pernah menjadi kegagalan: beberapa PTR record, yang diizinkan RFC 2181, dan PTR yang berbeda dari nama HELO server: RFC 5321 §4.1.4 menyatakan server tidak boleh menolak email karena hal itu. Gmail membatasi laju dengan 421 4.7.0 atau 451 4.7.23 dan memblokir dengan 550 5.7.25 jika PTR tidak ada atau tidak mengarah kembali.

Wajib, disarankan, tidak disebutkanhalaman masing-masing penerima, dicek 2026-10-23
PengecekanGmailpanduan pengirimYahoo Mailpraktik terbaik pengirimOutlook.comkebijakan postmaster
Punya PTR recordwajibwajibwajib
Nama mengarah kembaliwajibwajibtidak disebutkan
Tidak generik atau dinamistidak disebutkanmenyarankanbisa menolak IP dinamis
Empat pengirim nyata, dicek langsung
mail-sor-f41.google.com209.85.220.41 · server keluar Gmail sendirilolosloloslolos
ec2-3-80-0-1.compute-1.amazonaws.com3.80.0.1 · nama default AWSloloslolosperingatanlolosperingatan
dns.adguard-dns.com94.140.14.14 · mengarah ke 185.113.30.30gagalgagallolos
Tanpa PTR104.18.0.1 · NXDOMAINgagalgagalgagal

Balasan Gmail

421 4.7.0 · 451 4.7.23Dibatasi lajunya: tidak ada PTR, atau entri forward-nya tidak cocok dengan IP pengirim
550 5.7.25Diblokir: tidak ada PTR, atau entri forward tidak merujuk ke IP pengirim
550-5.7.1Lewat IPv6: pesan tidak memenuhi panduan pengiriman IPv6 untuk PTR record dan autentikasi
Hanya persyaratan yang bisa gagal. Saran Yahoo dan peringatan IP dinamis Outlook.com tampil sebagai peringatan. Kode Gmail berasal dari referensi error SMTP-nya.

Siapa yang mengendalikan reverse DNS, dan cara memasang PTR record

Pemegang blok alamat, tidak pernah pemilik domain. IANA mendelegasikan zona reverse setiap blok ke Regional Internet Registry-nya, dan registri itu ke jaringan yang memegang alamatnya, yang menjalankan zona itu atau menyerahkannya lagi (RFC 3172). Memiliki example.com tidak membuat Anda bisa menamai sebuah alamat: host atau ISP Anda yang harus melakukannya.

Layanan cloud membiarkan pelanggan mengaturnya sendiri, masing-masing dengan aturannya: AWS meminta record A forward lebih dulu, Azure hanya untuk IPv4 dan tidak lewat portalnya, DigitalOcean membuat PTR dari nama Droplet, Google Cloud meminta Anda membuktikan kepemilikan domain. Di koneksi rumahan, biasanya hanya paket bisnis dengan IP statis yang bisa mendapat PTR kustom: tanyakan ke ISP. Blok yang lebih kecil dari /24 sering diserahkan lewat CNAME (RFC 2317), yang diikuti alat ini ke mana pun arahnya.

Perubahan sampai ke semua orang begitu cache membuang jawaban lama: TTL record lama yang menentukan, atau waktu cache "tidak ada PTR" jika sebelumnya belum ada record (RFC 2308), bukan angka tetap 24 sampai 48 jam. Vultr menyatakan perubahan di layanannya butuh 6 sampai 12 jam.

Siapa yang menyerahkan zona ke bawahpenelusuran yang direkam, 2026-10-23
  1. in-addr.arpaDikelola oleh IANA, disajikan oleh a sampai f.in-addr-servers.arpa
  2. 8.in-addr.arpa · 208.in-addr.arpaRegistri regional blok itu: ARIN untuk 8.0.0.0/8 dan 208.0.0.0/8ARINRIPE NCCAPNICLACNICAFRINIC
  3. 8.8.8.in-addr.arpaPemegang 8.8.8.0/24: Google menulis PTR-nya, di ns1 sampai ns4.google.com
17.in-addr.arpaSebuah /8 lama (legacy), didelegasikan in-addr.arpa langsung ke server Apple sendiri
129.2.0.192.in-addr.arpa CNAME 129.128/26.2.0.192.in-addr.arpaContoh dari RFC 2317 sendiri: untuk blok di bawah 256 alamat, zona induk menyimpan CNAME ke zona yang dijalankan pemegang blok itu. Nama zona anak hanyalah konvensi.
Setiap hop adalah rujukan yang direkam pada 2026-10-23, kecuali milik RFC 2317, yang merupakan contoh dari RFC itu sendiri pada blok dokumentasi.
Tempat setiap penyedia memasang PTRdokumentasi masing-masing penyedia, dicek 2026-10-23
PenyediaCara memasangnyaBatasan
AWSDokumentasiHanya Elastic IP. Publikasikan record A untuk nama Anda yang mengarah ke Elastic IP itu, lalu EC2 console › Elastic IPs › alamatnya › Actions › Update reverse DNS, atau aws ec2 modify-address-attribute --allocation-id … --domain-name mail.example.com.Record A forward harus sudah ada lebih dulu. Selama punya reverse record, Elastic IP itu terkunci ke akun Anda. Di GovCloud (US), hanya AWS Support yang bisa memasangnya. Batasan port 25 dicabut lewat permintaan terpisah.
Microsoft AzureDokumentasiAtur ReverseFqdn milik IP publik: az network public-ip update --resource-group RG --name PublicIp --reverse-fqdn mail.example.com. (nama diakhiri titik), atau Set-AzPublicIpAddress di PowerShell.Hanya IPv4: alamat IPv6 milik Azure tidak mendapat PTR. Tidak tersedia di portal Azure. Nama harus di-resolve ke IP itu atau milik langganan Anda. Satu PTR per alamat, tidak ada secara default, dan tidak ada untuk App Service atau Application Gateway.
Google CloudDokumentasiVerifikasi domain lebih dulu (Search Console, atau record A ke IP eksternal VM). Lalu VM instances › instance-nya › Edit › antarmuka jaringan utama › Public DNS PTR record, atau gcloud compute instances update-access-config INSTANCE --public-ptr --public-ptr-domain mail.example.com.Hanya antarmuka jaringan utama; tidak ada PTR untuk load balancer atau Cloud NAT. PTR IPv6 membutuhkan subnet dual-stack atau khusus IPv6 dengan IPv6 eksternal. Nama default-nya <reversed-ip>.bc.googleusercontent.com.
HetznerDokumentasiCloud: Hetzner Console › server-nya (atau Primary IP, Floating IP) › Networking › edit rDNS di samping IP; untuk IPv6 masukkan bagian antarmukanya saja, seperti ::1. Dedicated: Robot › server-nya › IPs, kotak di samping setiap IP.Hetzner menjalankan zona reverse-nya. Entri rDNS dianggap valid hanya jika di-resolve ke dua arah (FCrDNS). Default-nya static.<reversed-ip>.clients.your-server.de.
DigitalOceanDokumentasiTidak ada editor PTR: beri nama atau ganti nama Droplet dengan nama lengkap yang Anda inginkan, seperti mail.example.com, dan DigitalOcean membuat PTR dari nama itu.Nama harus berupa FQDN yang valid (my-droplet tidak menghasilkan PTR). Hanya alamat IPv6 pertama Droplet yang mendapat PTR. PTR tidak bisa dibuat secara manual.
OVHcloudDokumentasiArahkan record A atau AAAA ke IP itu lebih dulu. Lalu Control Panel › Network › Public IP Addresses › tombol aksi di baris IP › Configure the reverse DNS (Public Cloud: proyek Anda › Public IPs).OVHcloud langsung mengecek bahwa nama itu mengarah kembali ke IP yang sama, jadi record-nya harus sudah aktif. Nama harus huruf kecil dan diakhiri titik.
VultrDokumentasiProducts › Compute › instance-nya › Settings › IPv4 atau IPv6 › Public Network: klik nama di kolom Reverse DNS, masukkan nama lengkap, lalu simpan.Vultr meminta agar nama itu di-resolve kembali ke IP yang sama, dan menyatakan perubahan butuh 6 sampai 12 jam untuk terlihat. Default-nya <ip>.vultrusercontent.com.
Akamai Cloud (Linode)DokumentasiTambahkan record A (dan AAAA) lebih dulu. Lalu Cloud Manager › Linodes › Linode-nya › Network › menu elipsis IP › Edit RDNS, lalu masukkan nama lengkap; kolom kosong mengembalikan nama default.Gagal dengan error sampai record A cocok dengan IP. Rentang IPv6: Edit rDNS pada rentangnya, lalu pada setiap alamat. Default: <ip-with-dashes>.ip.linodeusercontent.com, yang lebih lama li<n>-<n>.members.linode.com.
Oracle CloudDokumentasiBuat record A atau AAAA lebih dulu, lalu buka service request dengan IP, nama yang Anda inginkan di PTR, dan nama record forward-nya; Oracle mengeceknya lalu membuat PTR.Satu PTR per IP, hanya lewat permintaan ke support; record forward harus di-resolve ke IP itu.
Penyedia internet AndaRFC 8501Tanyakan ke penyedia internet Anda: hanya penyedia, sebagai pemegang alamat, yang bisa memasang PTR-nya. Dalam praktiknya, itu membutuhkan IP statis dengan paket bisnis.Koneksi rumahan tetap memakai nama pool penyedia, dan penerima seperti Comcast menganggap nama seperti itu dinamis dan menolak email langsung darinya.
Berapa lama perubahan berlaku: sampai cache membuang PTR lama (TTL-nya) atau jawaban “tidak ada PTR” yang di-cache (RFC 2308). TTL aktif: 1 hari untuk 8.8.8.8, 7 hari untuk resolver1.opendns.com, 5 menit untuk nama default EC2.

Mengapa sebagian besar alamat IPv6 tidak punya PTR record

Karena jumlahnya terlalu banyak untuk diberi nama satu per satu. ISP bisa mengisi PTR terlebih dahulu untuk setiap alamat IPv4 yang dibagikannya, tetapi satu /48 berisi 2⁸⁰ alamat, dan perangkat memilih alamatnya sendiri, sering kali berumur pendek (RFC 8501).

RFC 8501 mencantumkan pilihan untuk ISP: menjawab NXDOMAIN (tanpa PTR, paling akurat), PTR wildcard untuk prefiks setiap pelanggan, DNS dinamis, mendelegasikan zona ke pelanggan, atau membuat PTR dan record AAAA yang cocok seketika saat diminta. Hanya wildcard yang merusak pengecekan forward; untuk pengguna rumahan, NXDOMAIN yang bersih tidak masalah, timeout tidak.

Server yang mengirim email lewat IPv6 tetap membutuhkan PTR yang terkonfirmasi forward: Gmail menolak email IPv6 tanpa PTR seperti itu dengan 550-5.7.1 Message does not meet IPv6 sending guidelines regarding PTR records and authentication. Azure sama sekali tidak memberi PTR untuk alamat IPv6 miliknya sendiri.

Satu PTR per alamat, dalam skala IPv4 dan IPv6RFC 8501
/24satu blok IPv428 = 256
/64satu subnet IPv6264 = 18.446.744.073.709.551.616
/48satu situs IPv6280 = 1.208.925.819.614.629.174.706.176

Panjang batang: jumlah bit ruang alamat. Setiap bit menggandakan jumlahnya.

Dengan 1.000 PTR record per detik, satu /48 masih belum selesai setelah 38 triliun tahun (RFC 8501).

Pilihan untuk ISP menurut RFC 8501

NXDOMAINtanpa namaSama sekali tanpa PTR: jawaban paling akurat, tetapi server email cenderung menolak pengirim seperti ini.
Wildcardtidak cocokSatu nama untuk seluruh prefiks: lookup forward-nya tidak bisa kembali ke setiap alamat.
DNS dinamiscocokSetiap host mengirim pembaruan AAAA dan PTR-nya sendiri begitu alamatnya ditetapkan.
Delegasikan zonatergantung pelangganPelanggan yang menjalankan server DNS mendapat zona reverse untuk prefiksnya; sebagian besar rumah tidak bisa.
Dibuat seketikacocokServer membuat PTR saat ditanya, dengan AAAA yang cocok.

Server email tetap membutuhkan PTR sendiri yang terkonfirmasi forward:2001:4860:4860::8888 → dns.google → 2001:4860:4860::8888

Cara memverifikasi Googlebot dan crawler lain

Cari alamat pengunjung, cek bahwa nama PTR-nya berakhiran domain yang didokumentasikan untuk crawler itu, lalu cari nama itu secara forward dan pastikan hasilnya alamat yang sama: 66.249.66.1 → crawl-66-249-66-1.googlebot.com → 66.249.66.1. Atau cocokkan alamat itu dengan daftar yang dipublikasikan operatornya (metode Google).

Domain yang didokumentasikan: googlebot.com dan google.com untuk Google, search.msn.com untuk Bingbot, applebot.apple.com untuk Applebot, serta yandex.ru, yandex.net, dan yandex.com untuk Yandex. DuckDuckBot hanya memublikasikan daftar alamat.

googleusercontent.com tidak membuktikan apa pun dengan sendirinya: setiap VM Google Compute Engine mendapat nama di bawahnya secara default, jadi alat ini menghitungnya sebagai Google hanya jika alamatnya ada di daftar yang dipublikasikan Google. Nama dengan akhiran yang benar tetapi tidak mengarah kembali adalah palsu, dan alat ini menyatakannya.

Dua lookup yang menentukan66.249.66.1, data langsung 2026-10-23
  1. Lookup reversePTR dari alamat pengunjung.66.249.66.1 → crawl-66-249-66-1.googlebot.com
  2. Domain Google?Berakhiran googlebot.com. Nama googleusercontent.com juga memerlukan alamatnya ada di daftar Google.
  3. Lookup forwardcrawl-66-249-66-1.googlebot.com → 66.249.66.1Alamat yang sama: Googlebot asli.
Palsu: “Googlebot” di user agent, dari 203.0.113.9Lookup reverse-nya menjawab NXDOMAIN, jadi pengecekan berhenti di langkah 1. (Alamat dokumentasi, RFC 5737.)
CrawlerNama PTR berakhiranDaftar IP yang dipublikasikan
GooglebotPTR dan lookup forward, atau daftarnyagooglebot.comcommon-crawlers.json
Crawler kasus khusus GooglePTR dan lookup forward, atau daftarnyarate-limited-proxy-….google.comspecial-crawlers.json
Fetcher Google yang dipicu penggunaPTR dan lookup forward, atau daftarnyagoogle-proxy-….google.com….gae.googleusercontent.comhanya dengan daftarnyauser-triggered-fetchers-google.jsonuser-triggered-fetchers.jsonuser-triggered-agents.json
BingbotPTR dan lookup forward, atau daftarnyasearch.msn.combingbot.json
ApplebotPTR dan lookup forward, atau daftarnyaapplebot.apple.comapplebot.json
YandexBotPTR dan lookup forwardyandex.ruyandex.netyandex.comtidak ada
DuckDuckBotHanya daftar IPtidak adaduckduckbot.json

Aktif hari ini, masing-masing mengarah kembali:crawl-66-249-66-1.googlebot.commsnbot-157-55-39-1.search.msn.com17-58-101-179.applebot.apple.com

Domain dan daftar dari halaman masing-masing operator, dicek 2026-10-23. Bing meminta daftarnya diperbarui setiap hari.

Penjelasan error reverse DNS

NXDOMAIN berarti nama reverse tidak ada: belum ada yang memasang PTR untuk alamat itu. NOERROR tanpa jawaban (NODATA) berarti nama itu ada tetapi tidak berisi PTR. Resolver menyimpan kedua jawaban itu selama waktu negative cache zona dari SOA-nya (RFC 2308), jadi PTR baru bisa butuh waktu selama itu untuk muncul.

SERVFAIL berarti zona rusak, paling sering karena delegasi lame: server yang disebut untuk zona itu tidak menyajikannya, dan setiap resolver menyerah. REFUSED datang dari server yang sama sekali tidak mau menjawab untuk zona itu. Alamat privat dan alamat dokumentasi tidak pernah mendapat PTR publik: alat ini menjawabnya dari registri IANA tanpa bertanya ke siapa pun.

Setiap jawaban, contoh nyatadata langsung, 2026-10-23
NOERROR8.8.8.8Nama terpasang: PTR kembali dengan TTL-nya.PTR dns.google. · TTL 86400ns1.google.com · aa
NXDOMAIN104.18.0.1Nama itu tidak ada: zona Cloudflare tidak menyimpan PTR untuknya, dan menyatakannya.SOA 18.104.in-addr.arpacruz.ns.cloudflare.com … 3600
NODATANOERROR, 0 answers2001:4860:4860::/48Nama itu ada, tanpa PTR: nama /48 milik Google, yang punya nama-nama di bawahnya.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpaSOA ns1.google.com … 60
SERVFAIL203.0.113.50contoh buatan, alamat dokumentasiDelegasi lame: registri menyebut dua server yang tidak menyajikan zona itu, jadi resolver menyerah.APNIC → ns1, ns2.example.net: lameEDE 22: No Reachable Authority
NXDOMAINAS112192.168.1.1Alamat privat: pohon publik menyerahkan 168.192.in-addr.arpa ke server AS112 milik IANA, yang menjawab NXDOMAIN.blackhole-1.iana.orgSOA prisoner.iana.org … 604800
Jawaban “tidak” di-cache selama waktu negatif dari SOA (RFC 2308): 1 jam di Cloudflare, 60 detik di Google, 7 hari dari AS112.

Reverse DNS lookup: pertanyaan yang sering diajukan

Apa itu reverse DNS lookup?

Reverse DNS lookup mencari nama host di balik sebuah alamat IP dengan membaca PTR record-nya, kebalikan dari lookup biasa yang mengubah nama menjadi alamat. Alamat itu dibalik menjadi nama khusus, seperti 8.8.8.8.in-addr.arpa, lalu ditanyakan ke nameserver yang menyimpannya. Untuk 8.8.8.8, jawabannya dns.google. Alat ini juga mengecek bahwa nama itu mengarah kembali.

Bagaimana cara cek PTR record dengan dig atau nslookup?

Jalankan dig -x 8.8.8.8 di macOS atau Linux: dig membalik alamatnya sendiri dan PTR muncul di bagian answer. Di Windows, nslookup 8.8.8.8 menampilkannya di baris Name:. Untuk melewati semua cache, tanyakan ke nameserver zona itu sendiri: dig -x 8.8.8.8 @ns1.google.com +norecurse. Tampilan Perintah di sini mengisi setiap perintah dengan alamat Anda dan server zonanya.

Mengapa alamat IP saya tidak punya reverse DNS?

Karena belum ada yang memasang PTR record untuknya. Hanya pemegang blok alamat yang bisa, jadi jawabannya NXDOMAIN sampai penyedia hosting atau ISP Anda menambahkannya. Sebagian besar koneksi rumahan dan sebagian besar alamat IPv6 tidak punya PTR. Jika hasilnya justru SERVFAIL, zona reverse itu sendiri yang rusak, biasanya karena delegasi lame yang harus diperbaiki penyedia.

Bagaimana cara memasang atau mengubah PTR record?

Di pihak yang memberi Anda alamat itu. Di AWS, publikasikan record A forward lebih dulu, lalu perbarui reverse DNS Elastic IP. Azure mengatur ReverseFqdn pada IP publik, DigitalOcean memakai nama Droplet, sedangkan Hetzner, OVHcloud, Vultr, dan Linode punya kolom rDNS di samping setiap alamat. Untuk koneksi rumah atau kantor, tanyakan ke ISP Anda: biasanya hanya paket bisnis dengan IP statis yang memenuhi syarat.

Berapa lama perubahan PTR record berlaku?

Selama cache menyimpan jawaban lama. Setiap resolver boleh menyajikan PTR lama sampai TTL-nya habis, sering satu jam sampai satu hari, atau jawaban "tidak ada PTR" yang di-cache selama waktu negative cache zona. Tidak ada angka tetap 24 sampai 48 jam. Tampilan Salinan menunjukkan berapa lama lagi salinan Google dan Cloudflare berlaku.

Bisakah satu alamat IP punya lebih dari satu PTR record?

Bisa. DNS mengizinkan beberapa PTR record untuk satu alamat, dan RFC 2181 menyatakan tidak boleh diasumsikan ada batasnya: 208.67.222.222 punya empat. Pengecekan email lolos jika salah satunya mengarah kembali ke alamat itu. Sebagian alat hanya membaca nama pertama, jadi nama yang Anda pakai untuk email sebaiknya terkonfirmasi forward. Satu PTR adalah penyiapan paling sederhana, bukan keharusan.

Apa itu FCrDNS?

Forward-confirmed reverse DNS: nama PTR, jika dicari secara forward, menghasilkan alamat yang sama. PTR 8.8.8.8 adalah dns.google, dan dns.google di-resolve ke 8.8.8.8, jadi lolos. Server email menyebut pengecekan ini iprev. Ini penting karena siapa pun yang memegang sebuah alamat bisa menulis nama apa saja di PTR-nya; hanya lookup forward yang menunjukkan bahwa pemilik domain setuju.

Apakah saya butuh reverse DNS untuk mengirim email?

Ya, untuk setiap server yang mengirim email secara langsung. Gmail mewajibkan setiap IP pengirim punya PTR yang di-resolve kembali ke IP itu, Yahoo mewajibkan DNS forward dan reverse yang valid, dan Outlook.com mewajibkan reverse DNS yang valid. Tanpa itu, email dibatasi lajunya atau ditolak, misalnya dengan kode 550 5.7.25 dari Gmail. Nama generik dari penyedia lolos aturan, tetapi memunculkan peringatan.

Apa arti "reverse DNS is not a valid hostname"?

Alat uji server email menampilkannya jika nama PTR dari IP pengirim tidak berfungsi sebagai nama host untuk IP itu: paling sering tidak ada PTR sama sekali, atau nama itu tidak punya record A yang mengarah kembali ke alamat yang sama. Cek IP pengirim di sini: tampilan PTR menunjukkan nama dan cek forward-nya, dan tampilan Email menyebut aturan yang dilanggarnya.

Apakah reverse DNS sama dengan reverse IP lookup?

Tidak. Reverse DNS membaca satu atau beberapa nama yang dipublikasikan pemegang alamat di PTR record-nya. Reverse IP lookup mencoba mencantumkan setiap situs web yang di-hosting di sebuah alamat, dan itu membutuhkan data passive DNS yang dikumpulkan dari banyak resolver dalam waktu lama. Banyak situs memakai kedua istilah ini secara longgar. Halaman IP ke Hostname kami menjelaskan apa yang bisa ditemukan setiap metode.

Apakah reverse DNS berfungsi untuk IPv6?

Ya. Alamat IPv6 dicari di bawah ip6.arpa dengan ke-32 digit heksadesimalnya dibalik, sehingga 2001:4860:4860::8888 menghasilkan nama dengan 32 label yang disusun dan ditanyakan alat ini untuk Anda. Sebagian besar alamat IPv6 tidak punya PTR, karena ISP tidak bisa mengisi nama terlebih dahulu untuk alamat sebanyak itu, tetapi server yang mengirim email lewat IPv6 membutuhkannya.

Mengapa alamat IP privat tidak punya PTR?

Alamat privat seperti 192.168.1.1 atau 10.0.0.1 dipakai di banyak jaringan sekaligus, jadi DNS publik tidak bisa menamainya. Reverse lookup-nya menjadi urusan resolver jaringan Anda sendiri; yang bocor keluar berakhir di server AS112, yang menjawab bahwa nama itu tidak ada. Alat ini menjelaskan setiap rentang khusus beserta RFC-nya tanpa bertanya ke siapa pun.

Ada yang kurang?Usulkan fitur atau alat baru

Alat DNS, IP, dan email lainnya