NS Lookup — Cek NS dan Nameserver Domain
Cek NS dan cek name server untuk domain apa pun: record NS yang diberikan registrinya, lengkap dengan glue dan TTL, berdampingan dengan jawaban setiap nameserver tentang dirinya sendiri. Server lame, ketidakcocokan, dan glue usang ditandai, lengkap dengan cara memperbaikinya.
Bertanya ke registri lebih dulu, lalu ke setiap nameserver yang disebutnya. URL, alamat email, atau subdomain boleh dimasukkan.
Apa itu NS record?
NS record menyebut sebuah server yang menyimpan sebuah zona: tempat record sebuah domain berada. Sebuah zona mencantumkan satu NS record per server, jadi google.com punya empat, ns1 sampai ns4.google.com (RFC 1035 §3.3.11).
NS record yang sama ada dua kali. Zona induk, di sini .com, menyimpan salinan di titik pemisah agar bisa mengarahkan resolver ke tujuan berikutnya; salinan itu tidak otoritatif. Zona itu sendiri menyimpan salinannya di bagian atasnya, dan salinan itulah yang otoritatif (RFC 1034 §4.2.1, RFC 2181 §6.1). Keduanya seharusnya persis sama.
Nilainya selalu berupa nama host, bukan alamat, dan bukan alias: nama itu harus punya record A atau AAAA sendiri (RFC 2181 §10.3).
Cara cek nameserver sebuah domain
Ketik domain di atas lalu tekan Cek nameserver: kami bertanya ke registri, lalu ke setiap server yang disebutnya dan bisa dijangkau server kami. Dari terminal: dig NS example.com di macOS dan Linux, nslookup -type=ns example.com di Windows, Resolve-DnsName -Name example.com -Type NS di PowerShell.
Ketiganya bertanya ke resolver Anda sendiri, jadi menampilkan salinan cache. Untuk melihat daftar milik registri, tanyai servernya dengan rekursi mati: dig @a.gtld-servers.net example.com NS +norec. Untuk menguji satu nameserver, minta SOA-nya dengan +norec dan cari aa di flag. whois juga menampilkan daftar milik registri, bukan milik zona.
dig NS example.com +shortSalinan dari resolver Anda, satu nameserver per baris. Tambahkan @a.gtld-servers.net dan +norec untuk daftar milik registri .com sendiri.
$ dig @l.gtld-servers.net google.com NS +norec ;; ->>HEADER<<- opcode: QUERY, status: NOERROR ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 91 ;; AUTHORITY SECTION: google.com. 172800 IN NS ns2.google.com.2 google.com. 172800 IN NS ns1.google.com. … ;; ADDITIONAL SECTION: ns1.google.com. 172800 IN A 216.239.32.103 … $ dig @216.239.32.10 google.com NS +norec ;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 04 google.com. 345600 IN NS ns1.google.com.5 …
- Tanpa aa: sebuah referral. Registri tidak melayani google.com; ia menunjukkan ke mana harus pergi.
- Daftar milik induk dan TTL-nya: 2 hari, ditetapkan oleh registri .com.
- Glue: ns1.google.com ada di dalam google.com, jadi .com memberikan alamatnya.
- aa: zona itu sendiri. Jawaban otoritatif dari server.
- TTL milik zona sendiri: 4 hari, ditetapkan oleh Google, bukan oleh registri.
$ nslookup -type=ns google.com 8.8.8.8 Server: 8.8.8.8 Address: 8.8.8.8#53 Non-authoritative answer: google.com nameserver = ns3.google.com. google.com nameserver = ns1.google.com. …
# salinan dari resolver Anda PS> Resolve-DnsName -Name google.com -Type NS # satu server, rekursi mati PS> Resolve-DnsName -Name google.com -Type SOA -Server ns1.google.com -NoRecursion
$ whois google.com Registrar: MarkMonitor Inc. Name Server: NS1.GOOGLE.COM … DNSSEC: unsigned
Membaca hasilnya
Kesimpulan menyebut penyedia DNS dan registrar; tampilan Delegasi menaruh daftar registri di samping daftar zona, server demi server, dengan jawaban dan waktu setiap server lewat TCP (termasuk pembukaan koneksi, jadi sekitar dua kali bolak-balik).
Kolom biru tua adalah jalur yang ditempuh resolver: root, registri dengan TTL dan DS-nya, lalu setiap nameserver. Server yang tidak melayani zona digambarkan terputus.

KesimpulanSiapa yang melayani zona, siapa yang mendaftarkannya, dan apakah registri dan zona sepakat.Registri di samping zonaSetiap nama di daftar registri dan di daftar zona, dengan glue dan jawabannya.Jawaban setiap serverAA dan waktunya lewat TCP, kode yang dikirim server yang menolak, atau lewat 1.1.1.1 jika server kami tidak bisa terhubung.DelegasiRoot, registri, lalu jawaban setiap server sendiri, seperti yang ditelusuri resolver.Nameserver induk vs anak: mengapa berbeda
Dua pihak berbeda menyimpan kedua daftar itu. Registri mempublikasikan daftar induk saat registrar Anda memintanya; penyedia DNS Anda melayani daftar milik zona. Ubah salah satu tanpa yang lain dan keduanya akan menyimpang.
Resolver lebih memercayai jawaban milik zona daripada referral (RFC 2181 §5.4.1), jadi setelah bertanya ke zona, mereka menyimpan daftar dan TTL-nya. Pada 2026-10-23, resolver Cloudflare menyimpan set NS google.com dengan sisa 340.859 detik: lebih dari 172.800 milik .com, jadi salinannya berasal dari TTL 4 hari milik zona.
Nama yang hanya ada di daftar registri tetap mendapat lalu lintas dari resolver yang mulai dari nol. Nama yang hanya ada di zona tidak terlihat oleh mereka. Keduanya layak diperbaiki; tidak satu pun menyebabkan gangguan dengan sendirinya.
Registri .jp1 hr
- ns1.xserver.jp
- ns2.xserver.jp
- ns3.xserver.jp
- ns4.xserver.jphanya di registri
- ns5.xserver.jphanya di registri
Zona1 j
- ns1.xserver.jp
- ns2.xserver.jp
- ns3.xserver.jp
ns4.xserver.jp dan ns5.xserver.jp hanya ada di registri. Keduanya menjawab dengan otoritas, jadi tidak ada yang rusak; daftarnya tetap berbeda.
Registri .com2 hr
- dns1.p08.nsone.net
- dns2.p08.nsone.net
- dns3.p08.nsone.net
- dns4.p08.nsone.net
- ns-1283.awsdns-32.org
- ns-1707.awsdns-21.co.uk
- ns-421.awsdns-52.com
- ns-520.awsdns-01.net
Zona15 mnt · 1 j
- dns1.p08.nsone.net
- dns2.p08.nsone.net
- dns3.p08.nsone.net
- dns4.p08.nsone.net
- ns-1283.awsdns-32.org
- ns-1707.awsdns-21.co.uk
- ns-421.awsdns-52.com
- ns-520.awsdns-01.net
Nama sama, jam berbeda: salinan registri bertahan 2 hari, milik Route 53 15 menit, milik NS1 1 jam.
Registri .net2 hr
- ns1.domaindirect.comhanya di registri
- ns2.domaindirect.comREFUSED
- ns3.domaindirect.comhanya di registri
Zona15 mnt
- ns1.hover.comhanya di zona
- ns2.hover.comhanya di zona
Registri masih mencantumkan nama lama. Dua di antaranya memakai alamat yang sama dengan server Hover dan menjawab; yang ketiga menolak.
Apa itu glue record?
Glue adalah alamat yang diberikan induk bersama referral-nya, agar resolver bisa menjangkau nameserver yang namanya berada di dalam zona yang dilayaninya. Tanpa glue, mencari ns1.google.com berarti bertanya ke server google.com, yang justru pertanyaan awal Anda (RFC 1034 §4.2.1).
RFC 9471 menjadikannya aturan: referral HARUS membawa glue untuk setiap server in-domain (ns1.google.com untuk google.com), dan SEBAIKNYA membawanya untuk server sibling di bawah induk yang sama (ns-421.awsdns-52.com untuk github.com). Nama yang tidak terkait seperti ns-520.awsdns-01.net dicari sendiri.
Glue diatur di registrar, sebagai host record, child nameserver, atau personal DNS server. Saat server berpindah, glue juga harus berpindah: glue usang mengarahkan resolver ke alamat yang tidak lagi menjawab.
Di dalam domain · google.com
- .com: tanyakan ns1.google.com
- Alamatnya ada di dalam google.com itu sendiri
- tanpa glue, pencarian berputar-putar
- Jadi .com menambahkan ns1.google.com A 216.239.32.10 · HARUS: wajib
Sibling dan tidak terkait · github.com
- .com: tanyakan ns-421.awsdns-52.com, ns-520.awsdns-01.net, …
- awsdns-52.com juga di bawah .com: glue 205.251.193.165 · SEBAIKNYA: disertakan
- awsdns-01.net ada di tempat lain: resolver mencarinya di .net · tanpa glue
Apa itu delegasi lame, dan cara memperbaikinya
Delegasi disebut lame jika induk mengarahkan resolver ke server yang tidak melayani zona: server itu menolak, diam saja, atau menjawab tanpa otoritas. Jika setiap server yang tercantum lame, domain berhenti ter-resolve; jika hanya satu dari beberapa, pencarian jadi lebih lambat selagi resolver mencoba ulang.
RFC 9499 mencatat bahwa "lame delegation" kini mencakup beberapa jenis kesalahan, jadi alat ini menyebut masing-masing: menolak zona (REFUSED), tidak ada jawaban (ditanyai dua kali), menjawab tanpa otoritas (tanpa aa), error server (SERVFAIL). Diam di TCP saja tidak disebut lame selama Google dan Cloudflare masih me-resolve domain itu: disebut tidak ada jawaban TCP, karena server itu mungkin menjawab lewat UDP.
Perbaikannya selalu di salah satu dari dua sisi: tambahkan zona di penyedia DNS yang ditunjuk registri, atau arahkan registri ke penyedia yang punya zonanya. Resolver mungkin mengingat kegagalan itu hingga 5 menit setelah perbaikan (RFC 9520).
Menolak zona
ns63 · ns64.domaincontrol.com
Kedua server GoDaddy yang disebut oleh .com menjawab REFUSED: zona belum diatur di sana.
$ dig @ns63.domaincontrol.com \ example.com SOA +norec ;; … status: REFUSED ;; flags: qr; … ANSWER: 0
Timeout, lalu REFUSED
ns1 · ns2.eftydns.com
Satu server timeout sekali, lalu menjawab REFUSED saat ditanya lagi. Satu timeout bukan vonis: alat ini bertanya lagi sebelum menyebut sebuah status.
$ dig @ns1.eftydns.com \ example.com SOA +norec ;; connection timed out # ditanyai lagi ;; … status: REFUSED
Satu dari tiga
ns1 · ns2 · ns3.domaindirect.com
Dua server menjawab dengan otoritas; yang ketiga menolak. Domain berfungsi, hanya lebih lambat.
$ dig @ns2.domaindirect.com \ example.net SOA +norec ;; … status: REFUSED # ns1, ns3: NOERROR, flags qr aa
- Lihat ke mana registri menunjukTampilan Delegasi mencantumkan server registri dan jawaban masing-masing.
- Perbaiki satu sisiTambahkan zona di penyedia itu, atau ganti nameserver di registrar.
- Cek lagiJawaban kembali seketika; kegagalan yang di-cache bertahan hingga 5 menit.
Yang didapat pengunjung saat setiap server lame:Google SERVFAILCloudflare SERVFAIL
Berapa banyak nameserver yang dibutuhkan?
Minimal dua: "Spesifikasi DNS dan aturan pendaftaran nama domain mewajibkan setidaknya dua server untuk setiap zona" (RFC 2182 §5, BCP 16). Bagian yang sama menyarankan tiga untuk kebanyakan organisasi, dengan satu yang berada jauh dari yang lain, dan empat atau lima jika keandalan lebih penting.
Hitung jaringannya, bukan namanya. Server harus berada di tempat yang tidak bisa dijangkau satu kegagalan sekaligus (RFC 2182 §3.1): enam server dalam satu /22 punya nasib routing yang sama. Anycast menyebarkan satu alamat ke banyak lokasi dan menjadi jawaban yang lazim, tetapi tetap satu operator; penyedia kedua bertahan saat operator itu mengalami gangguan (RFC 8901).
Lebih banyak tidak masalah. Batas tujuh dari RFC 1912 yang lama berasal dari jawaban UDP 512 byte; zona besar kini menjalankan delapan (github.com, bbc.co.uk).
| Domain | Server per jaringan | NS | Jaringan | Pembacaan |
|---|---|---|---|---|
| google.com | Google · AS15169 · anycast | 4 | 1 | Anycast, satu operator |
| github.com | NS1 · AS62597Route 53 · AS16509 · anycast | 8 | 2 | Dua penyedia |
| bbc.co.uk | NetActuate · AS63911NS1 · AS62597 | 8 | 2 | Dua jaringan |
| xserver.ne.jp | Xserver · AS131965Amazon · AS16509 | 5 | 2 | Dua jaringan |
| craigslist.org | craigslist · AS22414 | 6 | 1 | Satu /22 |
"Disarankan agar tiga server disediakan untuk sebagian besar zona tingkat organisasi, dengan setidaknya satu yang harus berada jauh dari yang lain."
RFC 2182 §5 · BCP 16, Juli 1997 · dua wajib, tiga disarankan
Cara mengganti nameserver, dan berapa lama prosesnya
Ganti di tempat domain didaftarkan, bukan di penyedia DNS: registrar mengirim daftar baru ke registri, dan registri mempublikasikannya. Tambahkan zona di penyedia baru lebih dulu, lengkap dengan semua record, supaya server baru langsung menjawab begitu namanya dipakai.
Lalu dua jam berjalan. Resolver yang menyimpan referral registri memegang daftar lama hingga TTL induk: 2 hari di .com, 1 hari di .de dan .jp, 1 jam di .org. Resolver yang sudah bertanya ke zona memegang set NS milik zona lama selama TTL-nya, yang bisa lebih lama: milik google.com 4 hari. Google Public DNS menyimpan NS paling lama 6 jam.
Jadi tidak pernah "24–48 jam" yang rata. Biarkan penyedia DNS lama menjawab record yang sama sampai jam yang lebih lama habis, dan pada domain yang bertanda tangan, hapus DS sebelum pindah (RFC 6781).
Di registrar: panduan masing-masing
- GoDaddyDNS → Nameservers
- NamecheapDomain List → Manage → Nameservers
- Squarespace DomainsDNS → Domain Nameservers
- PorkbunDetails → Nameservers
- Onamae.comネームサーバー/DNS → ネームサーバー設定
- XServer Domainネームサーバー設定
- MuuMuu Domainドメイン管理 → ネームサーバー設定変更
- Cloudflare Registrartetap di nameserver Cloudflare
Berapa lama salinan registri bertahan (TTL NS induk)
- .ru4 hari345.600 s
- .com2 hari172.800 s
- .uk2 hari172.800 s
- .de1 hari86.400 s
- .jp1 hari86.400 s
- .tr12 jam43.200 s
- .dev3 jam10.800 s
- .org1 jam3.600 s
- .io1 jam3.600 s
- .id1 jam3.600 s
- .in15 menit900 s
Jam-jam setelah perubahan
- Referral lama di cacheTTL induk.com: paling lama 2 hari
- Set NS zona lama di cacheTTL zona lamagoogle.com: paling lama 4 hari
- Google Public DNSbatasnya untuk NSpaling lama 6 jam
NS vs SOA vs glue record
Tiga record bertemu di sebuah delegasi. NS menyebut server: salinan induk menunjukkan jalan, salinan zona adalah otoritasnya. Glue adalah record A atau AAAA yang disimpan induk hanya untuk server yang bernama di dalam zona. SOA ada satu per zona, di bagian atasnya: server primer, alamat kontak, serial, dan timer.
Server yang menjawab SOA dengan flag aa memegang zonanya, itulah sebabnya alat ini menanyakannya ke setiap server. Serial menunjukkan apakah server memegang versi yang sama; Route 53 mulai dari 1 dan tidak pernah mengubahnya sendiri, dan zona di dua penyedia membawa dua serial, keduanya wajar.
Zona .comdijalankan oleh Verisign
- NSgoogle.com. 172800 NS ns1.google.com.Delegasi: ke mana harus pergi berikutnya · tidak otoritatif
- Ans1.google.com. 172800 A 216.239.32.10Glue: alamat server, agar bisa dijangkau
- DStanpa DS: google.com tidak ditandatanganiDS: menunjuk ke kunci penandatangan milik anak; hanya untuk zona bertanda tangan (cloudflare.com DS 2371 13 2)
titik pemisah zona · google.com
Zona google.comdijalankan oleh Google
- NSgoogle.com. 345600 NS ns1.google.com.Daftar milik zona itu sendiri · otoritatif
- SOAns1.google.com. dns-admin.google.com. 1003797344 900 900 1800 60Satu per zona: primer, kontak, serial, timer
- Ans1.google.com. 345600 A 216.239.32.10Alamat milik server itu sendiri: glue seharusnya cocok dengannya
NS lookup vs perintah nslookup
Orang mencari "ns lookup" untuk dua hal: nameserver sebuah domain, dan perintah nslookup yang disertakan di Windows, macOS, dan Linux. nslookup bertanya ke resolver Anda dan mencetak yang ada di cache-nya; dengan -type=ns ia mencantumkan set NS zona seperti yang dipegang resolver Anda.
Salinan itu bisa berumur berjam-jam, dan tidak pernah menunjukkan daftar registri, glue, atau apakah setiap server memegang zonanya. Halaman ini bertanya langsung ke setiap server yang bisa dijangkau.
| NS Lookup inidnsrobot.net | nslookup-type=ns | digNS · +norec | |
|---|---|---|---|
| Bertanya ke | registri, lalu setiap server | resolver Anda | satu server yang Anda sebut |
| Registri vs zona | keduanya, nama demi nama | salinan cache | satu daftar per perintah |
| aa setiap server | setiap alamat IPv4 (A dan glue) | Tidak | satu server per perintah |
| Glue dan TTL | kedua TTL | dengan -debug | di output |
| Diagnosis | disebut, lengkap dengan perbaikannya | Tidak | Tidak |
| Berjalan di | browser apa pun | WindowsmacOSLinux | macOSLinux |
NS lookup: pertanyaan yang sering diajukan
Apa itu NS lookup?
Bagaimana cara tahu siapa penyedia DNS saya?
Mengapa registri dan zona mencantumkan nameserver yang berbeda?
Apa itu delegasi lame?
Berapa lama perubahan nameserver menyebar?
Berapa banyak nameserver yang sebaiknya dimiliki sebuah domain?
Apa itu glue record, dan kapan saya membutuhkannya?
Mengapa alat yang berbeda menampilkan nameserver yang berbeda?
Apa arti "tidak diperiksa langsung"?
Apakah NS lookup sama dengan nslookup?
Mengapa perubahan nameserver saya belum terlihat?
Haruskah saya menghapus DNSSEC sebelum mengganti nameserver?
Ada yang kurang?Usulkan fitur atau alat baru
Alat DNS terkait
Cek DNS
Semua DNS record langsung dari nameserver domain, berdampingan dengan cache Google dan Cloudflare
Pencarian WHOIS
Cari detail pendaftaran domain, registrar, dan pemilik via RDAP
Cek Hosting Website
Cari tahu siapa yang meng-hosting website mana pun: hosting, CDN, CMS, penyedia email, registrar, dan penerbit SSL
Pencarian MX
Temukan rekaman mail exchange dan detail server email
Domain ke IP
Konversi nama domain ke alamat IP dengan geolokasi dan deteksi CDN
Pencarian DNS Terbalik
Temukan hostname terkait alamat IP melalui rekaman PTR
Pencari Subdomain
Temukan semua subdomain dari domain apa pun
Pemeriksa Usia Domain
Periksa tanggal pendaftaran domain, usia, kedaluwarsa, dan detail registrar via WHOIS