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.

Sumber: server registri, dihubungi mulai dari server root · alamat IPv4 setiap nameserver, ditanyai langsung · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · RDAP

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).

Sebuah NS record, bagian demi bagiangoogle.com · direkam 2026-10-23
google.com.Pemilik345600TTLINKelasNSTipens1.google.com.Nilai
PemilikZona tempat record ini berada.
TTL · 4 hariBerapa lama resolver boleh menyimpannya. Salinan .com menyebut 2 hari.
NSTipe record 2: sebuah nameserver untuk zona ini.
NilaiNama host dengan record A atau AAAA sendiri.
Salinan induk · .comgoogle.com. 172800 NS ns1.google.com.ns1.google.com. 172800 A 216.239.32.10Tidak otoritatif: sebuah referral, dengan glue
Salinan milik zona itu sendirigoogle.com. 345600 NS ns1.google.com.;; flags: qr aaOtoritatif: yang disimpan resolver
ns1.google.com.Nama host dengan alamat sendiri
216.239.32.10Alamat bukan nilai yang valid
ns.example.com. → CNAMETidak pernah berupa alias (RFC 2181 §10.3)
Kedua salinan direkam langsung: referral registri .com dari l.gtld-servers.net dan jawaban ns1.google.com sendiri.

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 +short

Salinan dari resolver Anda, satu nameserver per baris. Tambahkan @a.gtld-servers.net dan +norec untuk daftar milik registri .com sendiri.

Membaca dua jawaban diggoogle.com · direkam 2026-10-23
dig · macOS, Linux
$ 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
…
  1. Tanpa aa: sebuah referral. Registri tidak melayani google.com; ia menunjukkan ke mana harus pergi.
  2. Daftar milik induk dan TTL-nya: 2 hari, ditetapkan oleh registri .com.
  3. Glue: ns1.google.com ada di dalam google.com, jadi .com memberikan alamatnya.
  4. aa: zona itu sendiri. Jawaban otoritatif dari server.
  5. TTL milik zona sendiri: 4 hari, ditetapkan oleh Google, bukan oleh registri.
nslookup · bertanya ke 8.8.8.8
$ 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.
…
PowerShell
# 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
$ whois google.com
Registrar: MarkMonitor Inc.
Name Server: NS1.GOOGLE.COM
…
DNSSEC: unsigned
Direkam pada 2026-10-23. "Non-authoritative answer" berarti salinan cache dari resolver, di sini Google Public DNS, yang menyimpan NS record paling lama 6 jam. whois mencetak daftar milik registri. Keduanya tidak menunjukkan apa yang dikatakan setiap server.

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.

NS lookup untuk github.com: delapan nameserver di NS1 dan Route 53, jawaban setiap server, dan delegasi dari .comNS lookup untuk github.com: delapan nameserver di NS1 dan Route 53, jawaban setiap server, dan delegasi dari .comKesimpulanSiapa 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.
NS lookup untuk github.com: kesimpulan, delapan nameserver dari registri berdampingan dengan daftar milik zona, jawaban setiap server, dan delegasi dari registri .com. Pilih sebuah nomor untuk melihat arti setiap bagian.

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.

Daftar registri di samping daftar zonadirekam 2026-10-23
xserver.ne.jp5 vs 3

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.

github.com8 yang sama

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.

Domain .net(nama dirahasiakan)tidak ada nama yang sama

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.

Garis menghubungkan nama yang sama di kedua daftar; garis putus-putus menghubungkan dua nama pada satu alamat. Kasus ketiga adalah pendaftaran nyata yang ditemukan dalam pemindaian acak; namanya dirahasiakan.

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.

Glue, dan kapan dibutuhkandirekam di .com, 2026-10-23

Di dalam domain · google.com

  1. .com: tanyakan ns1.google.com
  2. Alamatnya ada di dalam google.com itu sendiri
  3. tanpa glue, pencarian berputar-putar
  4. Jadi .com menambahkan ns1.google.com A 216.239.32.10 · HARUS: wajib

Sibling dan tidak terkait · github.com

  1. .com: tanyakan ns-421.awsdns-52.com, ns-520.awsdns-01.net, …
  2. awsdns-52.com juga di bawah .com: glue 205.251.193.165 · SEBAIKNYA: disertakan
  3. awsdns-01.net ada di tempat lain: resolver mencarinya di .net · tanpa glue
Glue usang · langsung64.69.208.141glue .com untuk ns1.register.com · tidak ada jawaban, ditanyai dua kali162.214.41.25record A-nya hari ini · menjawab dengan otoritas
Host object ns1.register.com di .com, dibaca lewat rdap.verisign.com pada 2026-10-23: registri masih menyimpan alamat yang sudah ditinggalkan server itu, dan memberikannya sebagai 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).

Tiga server lame, direkam2026-10-23 · domain dirahasiakan

Menolak zona

ns63 · ns64.domaincontrol.com

Kedua server GoDaddy yang disebut oleh .com menjawab REFUSED: zona belum diatur di sana.

bash
$ 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.

bash
$ 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.

bash
$ dig @ns2.domaindirect.com \
    example.net SOA +norec
;; … status: REFUSED
# ns1, ns3: NOERROR, flags qr aa
  1. Lihat ke mana registri menunjukTampilan Delegasi mencantumkan server registri dan jawaban masing-masing.
  2. Perbaiki satu sisiTambahkan zona di penyedia itu, atau ganti nameserver di registrar.
  3. Cek lagiJawaban kembali seketika; kegagalan yang di-cache bertahan hingga 5 menit.

Yang didapat pengunjung saat setiap server lame:Google SERVFAILCloudflare SERVFAIL

Direkam dari pendaftaran yang ditemukan dalam pemindaian acak; namanya dirahasiakan dan ditampilkan sebagai example.com dan example.net.

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).

Server, dikelompokkan per jaringandirekam 2026-10-23
DomainServer per jaringanNSJaringanPembacaan
google.comGoogle · AS15169 · anycast41Anycast, satu operator
github.comNS1 · AS62597Route 53 · AS16509 · anycast82Dua penyedia
bbc.co.ukNetActuate · AS63911NS1 · AS6259782Dua jaringan
xserver.ne.jpXserver · AS131965Amazon · AS1650952Dua jaringan
craigslist.orgcraigslist · AS2241461Satu /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
Satu kotak adalah satu jaringan (AS); kotak berwarna adalah penyedia anycast: banyak lokasi, satu operator. Jaringan kedua xserver.ne.jp adalah ns2.xserver.jp di Amazon; enam server craigslist.org berbagi satu /22.

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 mana mengganti, dan jam-jamnyaTTL diukur 2026-10-23

Di registrar: panduan masing-masing

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
TTL induk dari server setiap registri sendiri (dig +norec); .io menjawab 3.600 detik, bukan 300 detik yang sering dikutip. Registrar masih menyebut waktu yang rata: GoDaddy "up to 48 hours", Namecheap "up to 24 hours".

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.

Dua zona, satu titik pemisahgoogle.com · direkam 2026-10-23

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
Glue dan record A milik server adalah dua salinan dari satu fakta; jika berbeda, glue-nya usang.

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.

Tiga cara mengecek nameserver
NS Lookup inidnsrobot.netnslookup-type=nsdigNS · +norec
Bertanya keregistri, lalu setiap serverresolver Andasatu server yang Anda sebut
Registri vs zonakeduanya, nama demi namasalinan cachesatu daftar per perintah
aa setiap serversetiap alamat IPv4 (A dan glue)Tidaksatu server per perintah
Glue dan TTLkedua TTLdengan -debugdi output
Diagnosisdisebut, lengkap dengan perbaikannyaTidakTidak
Berjalan dibrowser apa punWindowsmacOSLinuxmacOSLinux

NS lookup: pertanyaan yang sering diajukan

Apa itu NS lookup?

NS lookup menanyakan ke DNS nameserver mana yang menyimpan zona sebuah domain. Alat ini bertanya ke registri lebih dulu, untuk daftar induk dengan glue dan TTL-nya, lalu ke alamat IPv4 setiap nameserver secara langsung lewat TCP untuk SOA zona dan set NS miliknya sendiri, dan membandingkan keduanya. Anda melihat siapa yang menjalankan DNS, server mana yang menjawab dengan otoritas, dan apa pun yang membuat resolver gagal atau melambat.

Bagaimana cara tahu siapa penyedia DNS saya?

Lihat nama nameserver-nya: ns1.google.com adalah Google, *.ns.cloudflare.com adalah Cloudflare, ns-*.awsdns-* adalah Amazon Route 53, 01.dnsv.jp adalah Onamae.com. Cek NS ini menyebut penyedia DNS dari pola nama resmi tiap penyedia dan menampilkan jaringan di balik setiap alamat secara terpisah, karena sebagian penyedia berjalan di jaringan perusahaan lain: Porkbun dan Hostinger di jaringan Cloudflare, Vercel di jaringan NS1.

Mengapa registri dan zona mencantumkan nameserver yang berbeda?

Daftar registri, yang diatur di registrar Anda, dan NS record milik zona, yang diatur di penyedia DNS Anda, adalah dua salinan terpisah, dan RFC 1034 menyatakan keduanya seharusnya persis sama. Keduanya menyimpang saat seseorang mengubah salah satunya saja, sering kali setelah pindah penyedia DNS. Resolver yang mulai dari registri memakai daftarnya, sedangkan yang sudah bertanya ke zona menyimpan daftar milik zona.

Apa itu delegasi lame?

Delegasi lame adalah nameserver yang dicantumkan registri tetapi tidak melayani zona: ia menjawab REFUSED atau SERVFAIL, menjawab tanpa otoritas, atau tidak menjawab sama sekali. Jika setiap server yang tercantum lame, domain berhenti ter-resolve dan Google serta Cloudflare menjawab SERVFAIL. Perbaiki dengan menambahkan zona di penyedia DNS itu, atau mengganti nameserver di registrar ke penyedia yang punya zonanya.

Berapa lama perubahan nameserver menyebar?

Paling lama sepanjang yang lebih panjang dari dua jam: TTL NS registri (2 hari untuk .com dan .net, 4 hari untuk .ru, 1 hari untuk .de dan .jp, 1 jam untuk .org dan .io, 15 menit untuk .in) dan TTL NS zona lama sendiri, yang dipegang resolver yang sudah bertanya ke penyedia lama. Google Public DNS membatasinya sekitar 6 jam. "24–48 jam" yang rata keliru di kedua arah.

Berapa banyak nameserver yang sebaiknya dimiliki sebuah domain?

Minimal dua: RFC 2182 mewajibkan dua, menyarankan tiga untuk kebanyakan organisasi dengan setidaknya satu yang berada jauh dari yang lain, dan empat atau lima untuk keandalan lebih tinggi. Yang lebih penting daripada jumlahnya adalah satu kegagalan tidak bisa menjangkau semuanya: jaringan atau penyedia yang berbeda. Server anycast dari satu operator, seperti Cloudflare atau Route 53, adalah banyak lokasi, tetapi tetap satu operator.

Apa itu glue record, dan kapan saya membutuhkannya?

Glue adalah alamat yang diberikan registri bersama referral-nya untuk nameserver yang bernama di dalam zona, seperti ns1.example.com untuk example.com: tanpanya, resolver membutuhkan alamat server untuk menemukan server itu. RFC 9471 mewajibkan glue untuk nama in-domain seperti itu. Atur di registrar Anda, tempat ia disebut host record, child nameserver, atau personal DNS server.

Mengapa alat yang berbeda menampilkan nameserver yang berbeda?

Kebanyakan pemeriksa nameserver bertanya ke resolver, yang menampilkan salinan cache yang bisa berumur berhari-hari setelah perubahan, sementara registri dan zona menjawab untuk dirinya sendiri. Sebagian alat hanya menampilkan daftar milik zona. Cek name server ini menampilkan daftar registri, jawaban setiap server sendiri, dan salinan cache Google serta Cloudflare berdampingan, dengan sisa waktu setiap salinan.

Apa arti "tidak diperiksa langsung"?

Server kami berjalan di jaringan Cloudflare, dan sebuah Cloudflare Worker tidak bisa membuka koneksi ke alamat di jaringan itu. Nameserver di sana, milik Cloudflare sendiri dan milik penyedia yang berjalan di atasnya seperti Porkbun, Hostinger, dan DigitalOcean, dibaca lewat resolver Cloudflare 1.1.1.1: set NS dan TTL-nya, tetapi bukan bit AA, serial, atau waktu respons setiap server.

Apakah NS lookup sama dengan nslookup?

Tidak. nslookup adalah alat baris perintah di Windows, macOS, dan Linux yang bertanya ke resolver untuk jenis record apa pun, termasuk NS (nslookup -type=ns example.com). NS lookup adalah pertanyaannya sendiri: nameserver mana yang melayani sebuah domain. Seperti dig NS, nslookup menampilkan salinan cache resolver Anda; bertanya ke registri dan setiap server secara langsung, seperti alat ini, menunjukkan apakah keduanya sepakat.

Mengapa perubahan nameserver saya belum terlihat?

Periksa tiga tempat: apakah registri mencantumkan server baru (jika tidak, perubahannya belum keluar dari registrar Anda), apakah zona baru menjawab dengan otoritas, dan berapa lama salinan lama bertahan di resolver. Mode "Saya mengganti nameserver" menerima server baru Anda, membandingkan setiap salinan dengannya, dan menghitung mundur sampai semua resolver memakainya.

Haruskah saya menghapus DNSSEC sebelum mengganti nameserver?

Ya, kecuali penyedia DNS lama dan baru bekerja sama. Jika registri menyimpan DS yang tidak cocok dengan kunci penyedia baru, resolver yang memvalidasi seperti Google dan Cloudflare menjawab SERVFAIL dan domain mati bagi penggunanya. Hapus DS di registrar, tunggu TTL-nya habis, ganti nameserver, lalu publikasikan DS milik penyedia baru.

Ada yang kurang?Usulkan fitur atau alat baru