Công cụ phổ biến

Giao diện

Tra Cứu NS — Kiểm Tra Nameserver Cho Bất Kỳ Tên Miền

Tra cứu NS cho mọi tên miền: các bản ghi NS mà cơ quan quản lý đưa ra, kèm glue và TTL, đặt cạnh những gì chính từng nameserver trả lời. Máy chủ lame, danh sách lệch nhau và glue lỗi thời đều được chỉ ra, kèm cách sửa.

Nguồn: máy chủ của cơ quan quản lý, lần theo từ một máy chủ gốc · địa chỉ IPv4 của từng nameserver, hỏi trực tiếp · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru · RDAP

Hỏi cơ quan quản lý trước, rồi đến từng nameserver mà nó nêu. URL, địa chỉ email hay tên miền phụ đều được.

Thử

NS là gì? Bản ghi NS là gì?

Bản ghi NS nêu tên một máy chủ giữ vùng DNS: nơi các bản ghi của tên miền được lưu. Một vùng liệt kê một bản ghi NS cho mỗi máy chủ, nên google.com có bốn bản ghi, từ ns1 đến ns4.google.com (RFC 1035 §3.3.11).

Cùng các bản ghi NS này tồn tại ở hai nơi. Vùng cha, ở đây là .com, giữ một bản sao tại điểm ủy quyền để chuyển các bộ phân giải đi tiếp; bản sao đó không có thẩm quyền. Vùng DNS giữ bản sao riêng ở đỉnh của nó, và bản sao đó mới có thẩm quyền (RFC 1034 §4.2.1, RFC 2181 §6.1). Hai bản sao phải giống hệt nhau.

Giá trị luôn là một tên host, không bao giờ là địa chỉ, và không bao giờ là bí danh: tên đó phải có bản ghi A hoặc AAAA riêng (RFC 2181 §10.3).

Một bản ghi NS, từng phần mộtgoogle.com · ghi lại ngày 2026-10-23
google.com.Chủ sở hữu345600TTLINLớpNSLoạins1.google.com.Giá trị
Chủ sở hữuVùng mà bản ghi thuộc về.
TTL · 4 ngàyBộ phân giải được giữ nó bao lâu. Bản sao ở .com nói 2 ngày.
NSLoại bản ghi 2: một nameserver của vùng này.
Giá trịMột tên host có bản ghi A hoặc AAAA riêng.
Bản sao của vùng cha · .comgoogle.com. 172800 NS ns1.google.com.ns1.google.com. 172800 A 216.239.32.10Không có thẩm quyền: một referral, kèm glue
Bản sao của chính vùng DNSgoogle.com. 345600 NS ns1.google.com.;; flags: qr aaCó thẩm quyền: thứ các bộ phân giải giữ lại
ns1.google.com.Một tên host có địa chỉ riêng
216.239.32.10Địa chỉ không phải giá trị hợp lệ
ns.example.com. → CNAMEKhông bao giờ là bí danh (RFC 2181 §10.3)
Cả hai bản sao đều được ghi lại trực tiếp: referral của cơ quan quản lý .com từ l.gtld-servers.net và câu trả lời của chính ns1.google.com.

Cách kiểm tra nameserver của một tên miền

Nhập tên miền ở trên rồi bấm Kiểm tra nameserver: chúng tôi hỏi cơ quan quản lý, rồi đến từng máy chủ mà nó nêu và máy chủ của chúng tôi kết nối được. Từ terminal: dig NS example.com trên macOS và Linux, nslookup -type=ns example.com trên Windows, Resolve-DnsName -Name example.com -Type NS trong PowerShell.

Ba lệnh đó hỏi bộ phân giải của chính bạn, nên cho thấy một bản sao lưu đệm. Để xem danh sách của cơ quan quản lý, hãy hỏi máy chủ của nó với đệ quy tắt: dig @a.gtld-servers.net example.com NS +norec. Để thử một nameserver, hãy hỏi SOA với +norec và tìm aa trong các cờ. whois cũng chỉ cho thấy danh sách của cơ quan quản lý, không phải của vùng DNS.

dig NS example.com +short

Bản sao của bộ phân giải của bạn, mỗi dòng một nameserver. Thêm @a.gtld-servers.net và +norec để xem danh sách của chính cơ quan quản lý .com.

Đọc hai câu trả lời của diggoogle.com · ghi lại ngày 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. Không có aa: một referral. Cơ quan quản lý không phục vụ google.com; nó chỉ nơi cần hỏi tiếp.
  2. Danh sách của vùng cha và TTL của nó: 2 ngày, do cơ quan quản lý .com đặt.
  3. Glue: ns1.google.com nằm trong google.com, nên .com đưa ra địa chỉ của nó.
  4. aa: chính vùng DNS. Một câu trả lời có thẩm quyền từ máy chủ.
  5. TTL của chính vùng: 4 ngày, do Google đặt, không phải cơ quan quản lý.
nslookup · hỏi 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
# bản sao của bộ phân giải của bạn
PS> Resolve-DnsName -Name google.com -Type NS

# một máy chủ, tắt đệ quy
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
Ghi lại ngày 2026-10-23. "Non-authoritative answer" nghĩa là bản sao lưu đệm của một bộ phân giải, ở đây là Google Public DNS, nơi giữ bản ghi NS tối đa 6 giờ. whois in ra danh sách của cơ quan quản lý. Cả hai đều không cho thấy từng máy chủ nói gì.

Đọc kết quả

Phần kết luận nêu nhà cung cấp DNS và nhà đăng ký; chế độ xem Ủy quyền đặt danh sách của cơ quan quản lý cạnh danh sách của vùng DNS, từng máy chủ một, kèm câu trả lời và thời gian qua TCP của mỗi máy chủ (đã gồm thiết lập kết nối, nên khoảng hai vòng đi về).

Cột màu xanh navy là đường đi của một bộ phân giải: máy chủ gốc, cơ quan quản lý kèm TTL và DS, rồi từng nameserver. Máy chủ không phục vụ vùng sẽ bị ngắt khỏi đường đó.

Kết quả tra cứu NS của github.com: tám nameserver tại NS1 và Route 53, câu trả lời của từng máy chủ và ủy quyền từ .comKết quả tra cứu NS của github.com: tám nameserver tại NS1 và Route 53, câu trả lời của từng máy chủ và ủy quyền từ .comKết luậnAi phục vụ vùng, ai đã đăng ký nó, và cơ quan quản lý với vùng DNS có khớp nhau không.Cơ quan quản lý cạnh vùng DNSTừng tên trong danh sách của cơ quan quản lý và của chính vùng, kèm glue và câu trả lời.Câu trả lời của từng máy chủAA và thời gian qua TCP, mã mà máy chủ từ chối đã gửi, hoặc qua 1.1.1.1 khi máy chủ của chúng tôi không kết nối được.Ủy quyềnGốc, cơ quan quản lý, rồi câu trả lời của từng máy chủ, đúng như một bộ phân giải lần theo.
Tra cứu NS cho github.com: kết luận, tám nameserver của cơ quan quản lý cạnh danh sách của chính vùng DNS, câu trả lời của từng máy chủ và ủy quyền từ cơ quan quản lý .com. Chọn một số để xem từng phần thể hiện điều gì.

Nameserver của vùng cha và vùng con: vì sao khác nhau

Hai danh sách do hai bên khác nhau giữ. Cơ quan quản lý công bố danh sách của vùng cha khi nhà đăng ký của bạn yêu cầu; nhà cung cấp DNS của bạn phục vụ danh sách của chính vùng. Đổi bên này mà không đổi bên kia thì hai danh sách sẽ lệch nhau.

Các bộ phân giải tin câu trả lời của chính vùng hơn referral (RFC 2181 §5.4.1), nên khi đã hỏi vùng, chúng giữ danh sách và TTL của vùng. Ngày 2026-10-23, bộ phân giải của Cloudflare giữ bộ NS của google.com với 340.859 giây còn lại: nhiều hơn 172.800 của .com, nên bản sao đó đến từ TTL 4 ngày của vùng.

Một tên chỉ có trong danh sách của cơ quan quản lý vẫn nhận lưu lượng từ các bộ phân giải bắt đầu từ đầu. Một tên chỉ có trong vùng thì họ không thấy. Cả hai đều đáng sửa; riêng từng cái không gây sự cố.

Danh sách của cơ quan quản lý cạnh danh sách của vùng DNSghi lại ngày 2026-10-23
xserver.ne.jp5 so với 3

Cơ quan quản lý .jp1 ngày

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp
  • ns4.xserver.jpchỉ ở cơ quan quản lý
  • ns5.xserver.jpchỉ ở cơ quan quản lý

Vùng DNS1 giờ

  • ns1.xserver.jp
  • ns2.xserver.jp
  • ns3.xserver.jp

ns4.xserver.jp và ns5.xserver.jp chỉ có ở cơ quan quản lý. Cả hai đều trả lời có thẩm quyền, nên không có gì hỏng; các danh sách vẫn khác nhau.

github.comcùng 8 máy chủ

Cơ quan quản lý .com2 ngày

  • 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

Vùng DNS15 phút · 1 giờ

  • 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

Cùng tên, khác đồng hồ: bản sao của cơ quan quản lý tồn tại 2 ngày, của Route 53 là 15 phút, của NS1 là 1 giờ.

Một tên miền .net(tên được giấu)không có tên chung

Cơ quan quản lý .net2 ngày

  • ns1.domaindirect.comchỉ ở cơ quan quản lý
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.comchỉ ở cơ quan quản lý

Vùng DNS15 phút

  • ns1.hover.comchỉ trong vùng DNS
  • ns2.hover.comchỉ trong vùng DNS

Cơ quan quản lý vẫn liệt kê các tên cũ. Hai trong số đó dùng chung địa chỉ với máy chủ của Hover và trả lời; cái thứ ba từ chối.

Các đường nối những tên mà cả hai danh sách đều có; đường đứt nối hai tên dùng chung một địa chỉ. Trường hợp thứ ba là một bản đăng ký có thật, tìm thấy khi quét ngẫu nhiên; tên của nó được giấu.

Bản ghi glue là gì?

Glue là một địa chỉ mà vùng cha đưa ra kèm referral, để bộ phân giải tới được nameserver có tên nằm trong chính vùng mà nó phục vụ. Nếu không có glue, tìm ns1.google.com sẽ phải hỏi các máy chủ của google.com, tức là chính câu hỏi bạn bắt đầu (RFC 1034 §4.2.1).

RFC 9471 biến điều này thành quy tắc: một referral PHẢI mang glue của mọi máy chủ cùng miền (ns1.google.com cho google.com), và NÊN mang glue cho các máy chủ cùng cấp dưới cùng vùng cha (ns-421.awsdns-52.com cho github.com). Một tên không liên quan như ns-520.awsdns-01.net được tra riêng.

Glue được đặt tại nhà đăng ký, dưới dạng host record, child nameserver hoặc personal DNS server. Khi một máy chủ chuyển đi, glue cũng phải chuyển theo: glue lỗi thời đưa các bộ phân giải tới một địa chỉ không còn trả lời.

Glue, và khi nào cầnghi lại tại .com, 2026-10-23

Cùng miền · google.com

  1. .com: hỏi ns1.google.com
  2. Địa chỉ của nó nằm ngay trong google.com
  3. không có glue, việc tra cứu quay vòng
  4. Nên .com thêm ns1.google.com A 216.239.32.10 · PHẢI: bắt buộc

Cùng cấp và không liên quan · github.com

  1. .com: hỏi ns-421.awsdns-52.com, ns-520.awsdns-01.net, …
  2. awsdns-52.com cũng nằm dưới .com: glue 205.251.193.165 · NÊN: được kèm theo
  3. awsdns-01.net nằm ở nơi khác: bộ phân giải tra nó trong .net · không có glue
Glue lỗi thời · trực tiếp64.69.208.141glue của .com cho ns1.register.com · không trả lời, đã hỏi hai lần162.214.41.25bản ghi A của nó hôm nay · trả lời có thẩm quyền
Host object của ns1.register.com tại .com, đọc qua rdap.verisign.com ngày 2026-10-23: cơ quan quản lý vẫn giữ một địa chỉ mà máy chủ đã bỏ, và vẫn đưa nó ra làm glue.

Ủy quyền lame là gì và cách sửa

Một ủy quyền là lame khi vùng cha gửi các bộ phân giải tới một máy chủ không phục vụ vùng đó: nó từ chối, không nói gì, hoặc trả lời không có thẩm quyền. Nếu mọi máy chủ được liệt kê đều lame, tên miền ngừng phân giải; nếu chỉ một trong số nhiều máy chủ lame, các lượt tra cứu chậm đi khi bộ phân giải thử lại.

RFC 9499 ghi nhận rằng "lame delegation" đã dùng để chỉ nhiều lỗi khác nhau, nên công cụ gọi tên từng lỗi: từ chối vùng (REFUSED), không trả lời (đã hỏi hai lần), trả lời không có thẩm quyền (không aa), lỗi máy chủ (SERVFAIL). Chỉ im lặng qua TCP thì không bị gọi là lame khi Google và Cloudflare vẫn phân giải được tên miền: nó được gọi là không trả lời qua TCP, vì máy chủ đó có thể trả lời qua UDP.

Cách sửa luôn nằm ở một trong hai phía: thêm vùng tại nhà cung cấp DNS mà cơ quan quản lý trỏ tới, hoặc trỏ cơ quan quản lý tới nhà cung cấp đang giữ vùng. Các bộ phân giải có thể nhớ lỗi tối đa 5 phút sau khi sửa (RFC 9520).

Ba máy chủ lame, đã ghi lại2026-10-23 · tên miền được giấu

Từ chối vùng

ns63 · ns64.domaincontrol.com

Cả hai máy chủ GoDaddy do .com nêu đều trả lời REFUSED: vùng chưa được thiết lập ở đó.

bash
$ dig @ns63.domaincontrol.com \
    example.com SOA +norec
;; … status: REFUSED
;; flags: qr; … ANSWER: 0

Hết thời gian chờ, rồi REFUSED

ns1 · ns2.eftydns.com

Một máy chủ hết thời gian chờ một lần, rồi trả lời REFUSED khi được hỏi lại. Một lần hết thời gian chờ chưa phải kết luận: công cụ hỏi lại trước khi gọi tên một trạng thái.

bash
$ dig @ns1.eftydns.com \
    example.com SOA +norec
;; connection timed out
# đã hỏi lại
;; … status: REFUSED

Một trong ba

ns1 · ns2 · ns3.domaindirect.com

Hai máy chủ trả lời có thẩm quyền; máy thứ ba từ chối. Tên miền vẫn chạy, nhưng chậm hơn.

bash
$ dig @ns2.domaindirect.com \
    example.net SOA +norec
;; … status: REFUSED
# ns1, ns3: NOERROR, flags qr aa
  1. Xem cơ quan quản lý trỏ tới đâuChế độ xem Ủy quyền liệt kê các máy chủ của cơ quan quản lý và câu trả lời của từng máy.
  2. Sửa một phíaThêm vùng tại nhà cung cấp đó, hoặc đổi nameserver tại nhà đăng ký.
  3. Kiểm tra lạiCâu trả lời trở lại ngay; một lỗi đã lưu đệm kéo dài tối đa 5 phút.

Những gì người truy cập nhận được khi mọi máy chủ đều lame:Google SERVFAILCloudflare SERVFAIL

Ghi lại từ các bản đăng ký tìm thấy khi quét ngẫu nhiên; tên của chúng được giấu và thể hiện là example.com và example.net.

Một tên miền cần bao nhiêu nameserver?

Ít nhất hai: "The DNS specification and domain name registration rules require at least two servers for every zone" (RFC 2182 §5, BCP 16). Cùng mục đó khuyến nghị ba máy chủ cho hầu hết tổ chức, trong đó một máy ở xa hẳn các máy còn lại, và bốn hoặc năm máy khi độ tin cậy quan trọng hơn.

Hãy đếm mạng, không đếm tên. Các máy chủ nên đặt ở nơi một sự cố không thể ảnh hưởng tất cả (RFC 2182 §3.1): sáu máy chủ trong cùng một /22 chung một số phận định tuyến. Anycast trải một địa chỉ ra nhiều địa điểm và là cách thường dùng, nhưng vẫn là một nhà vận hành; một nhà cung cấp thứ hai vượt qua được sự cố của nhà vận hành đó (RFC 8901).

Nhiều hơn cũng không sao. Giới hạn bảy máy chủ cũ của RFC 1912 xuất phát từ các câu trả lời UDP 512 byte; các vùng lớn ngày nay chạy tám máy (github.com, bbc.co.uk).

Máy chủ, nhóm theo mạngghi lại ngày 2026-10-23
Tên miềnMáy chủ theo mạngNSMạngNhận định
google.comGoogle · AS15169 · anycast41Anycast, một nhà vận hành
github.comNS1 · AS62597Route 53 · AS16509 · anycast82Hai nhà cung cấp
bbc.co.ukNetActuate · AS63911NS1 · AS6259782Hai mạng
xserver.ne.jpXserver · AS131965Amazon · AS1650952Hai mạng
craigslist.orgcraigslist · AS2241461Một /22

"Nên cung cấp ba máy chủ cho hầu hết các vùng ở cấp tổ chức, trong đó phải có ít nhất một máy ở xa hẳn các máy còn lại."

RFC 2182 §5 · BCP 16, tháng 7 năm 1997 · bắt buộc hai, khuyến nghị ba
Một ô là một mạng (AS); ô có nền màu là nhà cung cấp anycast: nhiều địa điểm, một nhà vận hành. Mạng thứ hai của xserver.ne.jp là ns2.xserver.jp trên mạng của Amazon; sáu máy chủ của craigslist.org dùng chung một /22.

Cách đổi nameserver và mất bao lâu

Hãy đổi tại nơi tên miền được đăng ký, không phải tại nhà cung cấp DNS: nhà đăng ký gửi danh sách mới cho cơ quan quản lý, và cơ quan quản lý công bố nó. Hãy thêm vùng tại nhà cung cấp mới trước, với đầy đủ bản ghi, để các máy chủ mới trả lời ngay khi được nêu tên.

Sau đó có hai đồng hồ chạy. Các bộ phân giải đã lưu đệm referral của cơ quan quản lý giữ danh sách cũ tối đa bằng TTL của vùng cha: 2 ngày ở .com, 1 ngày ở .de và .jp, 1 giờ ở .org. Các bộ phân giải đã hỏi vùng giữ bộ NS cũ của chính vùng cũ trong thời gian TTL của nó, có thể dài hơn: của google.com là 4 ngày. Google Public DNS giữ NS tối đa 6 giờ.

Vì vậy không bao giờ có chuyện "24–48 giờ" cố định. Hãy giữ nhà cung cấp DNS cũ trả lời cùng các bản ghi cho đến khi đồng hồ dài hơn chạy hết, và với tên miền đã ký, hãy xóa DS trước khi chuyển (RFC 6781).

Đổi ở đâu, và các đồng hồTTL đo ngày 2026-10-23

Tại nhà đăng ký: hướng dẫn riêng của từng nơi

Bản sao của cơ quan quản lý tồn tại bao lâu (TTL NS của vùng cha)

  • .ru4 ngày345.600 s
  • .com2 ngày172.800 s
  • .uk2 ngày172.800 s
  • .de1 ngày86.400 s
  • .jp1 ngày86.400 s
  • .tr12 giờ43.200 s
  • .vn12 giờ43.200 s
  • .dev3 giờ10.800 s
  • .org1 giờ3.600 s
  • .io1 giờ3.600 s
  • .in15 phút900 s

Các đồng hồ sau khi đổi

  • Referral cũ trong bộ nhớ đệmTTL của vùng cha.com: tối đa 2 ngày
  • Bộ NS cũ của vùng trong bộ nhớ đệmTTL của vùng cũgoogle.com: tối đa 4 ngày
  • Google Public DNSmức giới hạn của nó cho NStối đa 6 giờ
TTL của vùng cha lấy từ chính các máy chủ của từng cơ quan quản lý (dig +norec); .io trả lời 3.600 giây, không phải 300 giây thường được nhắc đến. Các nhà đăng ký vẫn nêu thời gian cố định: GoDaddy "up to 48 hours", Namecheap "up to 24 hours".

NS, SOA và bản ghi glue khác nhau thế nào

Ba loại bản ghi gặp nhau tại một điểm ủy quyền. NS nêu tên các máy chủ: bản sao của vùng cha chỉ đường, bản sao của vùng DNS là thẩm quyền. Glue là bản ghi A hoặc AAAA mà vùng cha chỉ giữ cho các máy chủ có tên nằm trong vùng. SOA chỉ có một cho mỗi vùng, ở đỉnh của nó: máy chủ chính, địa chỉ liên hệ, serial và các bộ đếm thời gian.

Một máy chủ trả lời SOA kèm cờ aa là máy chủ giữ vùng, đó là lý do công cụ hỏi mọi máy chủ về nó. Serial cho biết các máy chủ có cùng một phiên bản hay không; Route 53 bắt đầu từ 1 và không bao giờ tự đổi, và một vùng đặt ở hai nhà cung cấp có hai serial, cả hai đều bình thường.

Hai vùng, một điểm ủy quyềngoogle.com · ghi lại ngày 2026-10-23

Vùng .comdo Verisign vận hành

  • NSgoogle.com. 172800 NS ns1.google.com.Ủy quyền: nơi cần hỏi tiếp · không có thẩm quyền
  • Ans1.google.com. 172800 A 216.239.32.10Glue: địa chỉ của máy chủ, để tới được nó
  • DSkhông có DS: google.com chưa kýDS: trỏ tới khóa ký của vùng con; chỉ có ở vùng đã ký (cloudflare.com DS 2371 13 2)

điểm ủy quyền · google.com

Vùng google.comdo Google vận hành

  • NSgoogle.com. 345600 NS ns1.google.com.Danh sách của chính vùng · có thẩm quyền
  • SOAns1.google.com. dns-admin.google.com. 1003797344 900 900 1800 60Một cho mỗi vùng: máy chủ chính, liên hệ, serial, bộ đếm
  • Ans1.google.com. 345600 A 216.239.32.10Địa chỉ của chính máy chủ: glue phải khớp với nó
Glue và bản ghi A của chính máy chủ là hai bản sao của một sự thật; khi chúng khác nhau, glue đã lỗi thời.

NS lookup và lệnh nslookup

Người ta tìm "ns lookup" vì hai việc: nameserver của một tên miền, và lệnh nslookup có sẵn trên Windows, macOS và Linux. nslookup hỏi bộ phân giải của bạn và in ra những gì nó đã lưu đệm; với -type=ns nó liệt kê bộ NS của vùng đúng như bộ phân giải của bạn đang giữ.

Bản sao đó có thể đã cũ hàng giờ, và nó không bao giờ cho thấy danh sách của cơ quan quản lý, glue, hay việc từng máy chủ có giữ vùng hay không. Trang này hỏi trực tiếp từng máy chủ mà nó kết nối được.

Ba cách tra nameserver
Tra cứu NS nàydnsrobot.netnslookup-type=nsdigNS · +norec
Hỏicơ quan quản lý, rồi mọi máy chủbộ phân giải của bạnmột máy chủ bạn chỉ định
Cơ quan quản lý và vùng DNScả hai, từng tên mộtbản sao lưu đệmmột danh sách mỗi lệnh
aa của từng máy chủtừng địa chỉ IPv4 (A và glue)Khôngmột máy chủ mỗi lệnh
Glue và TTLcả hai TTLvới -debugtrong kết quả
Chẩn đoánđược gọi tên, kèm cách sửaKhôngKhông
Chạy trênmọi trình duyệtWindowsmacOSLinuxmacOSLinux

Tra cứu NS: câu hỏi thường gặp

NS lookup là gì?

NS lookup hỏi DNS xem nameserver nào giữ vùng của một tên miền. Công cụ này hỏi cơ quan quản lý trước để lấy danh sách của vùng cha kèm glue và TTL, rồi hỏi trực tiếp từng địa chỉ IPv4 của nameserver qua TCP để lấy SOA và bộ NS của chính vùng, rồi so sánh hai bên. Bạn thấy ai host DNS, máy chủ nào trả lời có thẩm quyền, và mọi thứ có thể khiến bộ phân giải lỗi hoặc chậm.

Làm sao biết nhà cung cấp DNS của tôi là ai?

Hãy nhìn tên nameserver: ns1.google.com là Google, *.ns.cloudflare.com là Cloudflare, ns-*.awsdns-* là Amazon Route 53, 01.dnsv.jp là Onamae.com. Công cụ nhận diện nhà cung cấp DNS từ mẫu tên đã được công bố của từng nhà cung cấp và cho thấy mạng đứng sau mỗi địa chỉ một cách riêng, vì một số nhà cung cấp chạy trên mạng của công ty khác: Porkbun và Hostinger trên Cloudflare, Vercel trên NS1.

Vì sao cơ quan quản lý và vùng DNS liệt kê nameserver khác nhau?

Danh sách của cơ quan quản lý, đặt tại nhà đăng ký, và các bản ghi NS của chính vùng, đặt tại nhà cung cấp DNS, là hai bản sao riêng biệt, và RFC 1034 nói chúng phải giống hệt nhau. Chúng lệch nhau khi ai đó đổi bên này mà không đổi bên kia, thường sau khi chuyển giữa các nhà cung cấp DNS. Bộ phân giải bắt đầu từ cơ quan quản lý dùng danh sách của nó, còn bộ đã hỏi vùng thì giữ danh sách của vùng.

Ủy quyền lame là gì?

Ủy quyền lame là khi cơ quan quản lý liệt kê một nameserver không phục vụ vùng: nó trả lời REFUSED hoặc SERVFAIL, trả lời không có thẩm quyền, hoặc không trả lời. Nếu mọi máy chủ được liệt kê đều lame, tên miền ngừng phân giải và Google, Cloudflare trả lời SERVFAIL. Hãy sửa bằng cách thêm vùng tại nhà cung cấp DNS đó, hoặc đổi nameserver tại nhà đăng ký sang nhà cung cấp đang giữ vùng.

Đổi nameserver mất bao lâu để có hiệu lực?

Tối đa bằng đồng hồ dài hơn trong hai đồng hồ: TTL NS của cơ quan quản lý (2 ngày cho .com và .net, 4 ngày cho .ru, 1 ngày cho .de và .jp, 1 giờ cho .org và .io, 15 phút cho .in) và TTL NS riêng của vùng cũ, mà các bộ phân giải đã hỏi nhà cung cấp cũ sẽ giữ. Google Public DNS giới hạn ở khoảng 6 giờ. Con số cố định "24–48 giờ" là sai theo cả hai hướng.

Một tên miền nên có bao nhiêu nameserver?

Ít nhất hai: RFC 2182 yêu cầu hai, khuyến nghị ba cho hầu hết tổ chức với ít nhất một máy ở xa hẳn các máy còn lại, và bốn hoặc năm để đáng tin cậy hơn. Điều quan trọng hơn con số là một sự cố không thể ảnh hưởng tất cả: các mạng hoặc nhà cung cấp khác nhau. Máy chủ anycast do một nhà vận hành chạy, như Cloudflare hay Route 53, là nhiều địa điểm nhưng vẫn là một nhà vận hành.

Bản ghi glue là gì, và khi nào tôi cần chúng?

Glue là địa chỉ mà cơ quan quản lý đưa ra kèm referral cho một nameserver có tên nằm trong chính vùng, như ns1.example.com cho example.com: nếu không có nó, bộ phân giải sẽ cần địa chỉ của máy chủ để tìm ra máy chủ. RFC 9471 quy định glue là bắt buộc với các tên cùng miền như vậy. Hãy đặt nó tại nhà đăng ký, nơi nó được gọi là host record, child nameserver hoặc personal DNS server.

Vì sao các công cụ khác nhau cho thấy nameserver khác nhau?

Hầu hết công cụ kiểm tra nameserver hỏi một bộ phân giải, nên cho thấy một bản sao lưu đệm có thể đã cũ nhiều ngày sau khi đổi, trong khi cơ quan quản lý và vùng DNS tự trả lời cho mình. Một số công cụ chỉ cho thấy danh sách của chính vùng. Công cụ này cho thấy danh sách của cơ quan quản lý, câu trả lời của từng máy chủ, và bản sao lưu đệm của Google và Cloudflare cạnh nhau, kèm thời gian còn lại của mỗi bản sao.

"Không kiểm tra trực tiếp" nghĩa là gì?

Máy chủ của chúng tôi chạy trên mạng của Cloudflare, và một Cloudflare Worker không mở được kết nối tới địa chỉ trên mạng đó. Nameserver ở đó, của chính Cloudflare và của các nhà cung cấp chạy trên nó như Porkbun, Hostinger và DigitalOcean, được đọc qua bộ phân giải 1.1.1.1 của Cloudflare: bộ NS và TTL của nó, nhưng không có bit AA, serial hay thời gian phản hồi của từng máy chủ.

NS lookup có giống nslookup không?

Không. nslookup là công cụ dòng lệnh trên Windows, macOS và Linux, hỏi một bộ phân giải về mọi loại bản ghi, kể cả NS (nslookup -type=ns example.com). NS lookup là chính câu hỏi: nameserver nào phục vụ một tên miền. Giống dig NS, nslookup cho thấy bản sao lưu đệm của bộ phân giải của bạn; hỏi cơ quan quản lý và từng máy chủ trực tiếp, như công cụ này, cho thấy chúng có khớp nhau không.

Vì sao thay đổi nameserver của tôi chưa hiện ra?

Hãy kiểm tra ba nơi: cơ quan quản lý đã liệt kê các máy chủ mới chưa (nếu chưa, thay đổi chưa rời khỏi nhà đăng ký của bạn), vùng mới có trả lời có thẩm quyền không, và các bản sao cũ còn tồn tại bao lâu trong bộ phân giải. Chế độ "Tôi vừa đổi nameserver" nhận các máy chủ mới của bạn, so sánh từng bản sao với chúng và đếm ngược đến khi mọi bộ phân giải đều có chúng.

Tôi có nên gỡ DNSSEC trước khi đổi nameserver không?

Có, trừ khi nhà cung cấp DNS cũ và mới phối hợp với nhau. Nếu cơ quan quản lý giữ một DS mà khóa của nhà cung cấp mới không khớp, các bộ phân giải có xác thực như Google và Cloudflare trả lời SERVFAIL và tên miền tắt với người dùng của chúng. Hãy xóa DS tại nhà đăng ký, chờ hết TTL của nó, đổi nameserver, rồi công bố DS mới của nhà cung cấp mới.

Các công cụ DNS liên quan