Công cụ phổ biến

Giao diện

Kiểm tra sức khỏe DNS

Kiểm tra DNS tên miền, hay xác thực tên miền cho DNS: ủy quyền tại cơ quan quản lý, từng nameserver được hỏi trực tiếp, SOA, DNSSEC và bản ghi email. 40 mục kiểm tra, mỗi mục kèm cách sửa.

Mức độ theo Zonemaster và các RFC · mọi nameserver được hỏi qua TCP · Google Public DNS · RDAP

Đi từ một máy chủ gốc đến cơ quan quản lý .nl, rồi hỏi trực tiếp từng nameserver của sidn.nl · 40 mục kiểm tra · khoảng 3 giâycơ quan quản lý .nl → từng nameserver · 40 mục kiểm tra

Thử
Ví dụGhi lại ngày 23 thg 10, 2026 · từ máy chủ của chúng tôi.nl3 NSDNSSEC đã ký

sidn.nl đạt mọi mục kiểm tra đã chạy, kể cả DNSSEC

đăng ký tại SIDN·2,9 giây

40 đạt

A+: không có gì trên mức thông tin. Mọi nameserver trả lời có thẩm quyền và thống nhất với nhau, các thông số thời gian nằm trong khoảng của Zonemaster, và Google Public DNS xác thực được chuỗi DNSSEC từ gốc.

Vấn đề trước tiên

Hỏi qua TCP từ máy chủ của chúng tôi tại edge của Cloudflare: máy chủ gốc, cơ quan quản lý .nl và trực tiếp từng nameserver; Google Public DNS và Cloudflare cho bản ghi email và việc xác thực. Chúng tôi không lưu nhật ký những gì bạn kiểm tra.

Kiểm tra DNS tên miền gồm những gì?

Bài kiểm tra sức khỏe DNS đi theo tên miền đúng như cách bộ phân giải tìm ra nó và kiểm tra từng bước: ủy quyền tại cơ quan quản lý, từng nameserver được hỏi trực tiếp, các máy chủ đó có thống nhất với nhau không, bản ghi SOA, DNSSEC và bản ghi email. Công cụ này chạy 40 mục kiểm tra trong bảy nhóm và chấm từng mục ở mức độ mà nguồn tham chiếu của nó quy định.

Hầu hết công cụ kiểm tra hỏi một bộ phân giải rồi chấm những gì nhận về. Cách đó che khuất các máy chủ phía sau: bộ phân giải trả lời từ bất kỳ nameserver nào còn chạy, nên một máy hỏng vẫn vô hình cho đến khi các máy khác cũng hỏng. Ở đây, mọi nameserver được hỏi qua TCP với đệ quy tắt, bản sao bản ghi NS tại cơ quan quản lý được đối chiếu với bản của chính vùng, và chuỗi DNSSEC được xác minh từ DS tại cơ quan quản lý đến các chữ ký trong vùng.

Hãy dùng nó như một lần kiểm toán DNS sau mỗi thay đổi: công cụ kiểm tra các bản ghi DNS mà tên miền phụ thuộc vào, không chỉ xem website có tải được không (việc đó thì Kiểm tra website sập xem xét chính website). Sao chép báo cáo biến kết quả thành một báo cáo DNS dạng văn bản thuần để bạn dán vào ticket.

Gốch.root-servers.net
.comCơ quan quản lý .comh.gtld-servers.net
8 nameserverRoute 53 + NS1
Vùng DNSgithub.com
  • DNSSEC7 mục kiểm trachuỗi tin cậy từ gốc: github.com dừng ở .com (không có DS)
  • Vùng cha & ủy quyền6 mục kiểm trareferral của cơ quan quản lý: 8 tên · 295 byte · không cần glue
  • Nameserver14 mục kiểm tratừng máy chủ được hỏi trực tiếp: 8 trên 8 có thẩm quyền · qua TCP · EDNS · không đệ quy
  • Tính nhất quán3 mục kiểm tracác máy chủ có thống nhất không: 2 serial SOA, mỗi nhà cung cấp DNS một serial · cùng MX và SPF
  • SOA4 mục kiểm trathông số thời gian dưới ngưỡng của Zonemaster: lưu ý
  • CAA1 mục kiểm tra7 bản ghi · 4 CA được phép
  • DNS email5 mục kiểm traMX tại Microsoft 365 · SPF 10 trên 10 lượt tra cứu · DMARC quarantine
Nơi mỗi nhóm mục kiểm tra xem xét, trên đường đi thực của github.com (23 tháng 10, 2026): từ gốc qua cơ quan quản lý .com đến các nameserver của vùng tại Route 53 và NS1.
Kết quả kiểm tra DNS cho github.com: điểm A, 40 mục kiểm tra trong bảy nhóm và đường đi từ gốc đến 8 nameserverKết quả kiểm tra DNS cho github.com: điểm A, 40 mục kiểm tra trong bảy nhóm và đường đi từ gốc đến 8 nameserverĐiểmChỉ dựa trên mức độ: không có vấn đề nghiêm trọng, không có lỗi, hai cảnh báo cho điểm A. Vòng tròn thể hiện điểm số, 90 trên 100.40 mục kiểm tra, mỗi mục một ôĐược nhóm theo thứ tự trên trang. Ô màu hổ phách và xanh lam là cảnh báo và lưu ý; ô gạch chéo là mục không chạy được.Vấn đề trước tiênCác nhóm có điều cần sửa được mở ở trên cùng, mỗi dòng kèm nguồn tham chiếu và cách sửa.Đường điMột máy chủ gốc, cơ quan quản lý .com do Verisign vận hành, rồi từng nameserver được hỏi trực tiếp: câu trả lời, serial và EDNS của nó.Chuỗi tin cậyDải DNSSEC bên cạnh đường đi: xanh lá nơi chuỗi còn nguyên, nét đứt nơi chuỗi dừng, đỏ nơi chuỗi bị đứt.
Kiểm tra sức khỏe DNS cho github.com. Chọn một số để xem từng phần thể hiện điều gì.

Điểm được tính như thế nào?

Chữ cái chỉ đến từ mức độ của những gì không đạt, không bao giờ từ bảng cộng điểm: bất kỳ vấn đề nghiêm trọng nào là F, từ hai lỗi trở lên là D, một lỗi hoặc từ năm cảnh báo trở lên là C, ba hoặc bốn cảnh báo là B, một hoặc hai cảnh báo (hoặc chỉ có lưu ý) là A, và không có gì trên mức thông tin là A+.

Các mức độ là của chính nguồn tham chiếu được trích dẫn: hồ sơ mặc định của Zonemaster khi Zonemaster định nghĩa bài kiểm tra đó, MUST hoặc SHOULD của RFC khi không có. Con số trên thang 100 chỉ dùng để xếp hạng các tên miền trong cùng một chữ cái (100 − 30 mỗi vấn đề nghiêm trọng, 12 mỗi lỗi, 4 mỗi cảnh báo, 1 mỗi lưu ý). Các mục máy chủ của chúng tôi không chạy được không bao giờ bị tính cho tên miền; khi từ một phần tư số mục trở lên không chạy được, điểm sẽ ghi một phần.

  1. A+100không có gì trên mức thông tinINFO “chắc chắn không cho thấy vấn đề nào”sidn.nl100
  2. A90–991–2 cảnh báo, hoặc chỉ có lưu ýNOTICE “quản trị viên vùng nên biết, nhưng không nhất thiết là vấn đề”github.com90example.com95bücher.de90
  3. B75–893–4 cảnh báoWARNING “trong một số trường hợp sẽ là vấn đề, nhưng người dùng thông thường khó nhận ra”cloudflare.com87google.com83
  4. C60–741 lỗi, hoặc từ 5 cảnh báo trở lênERROR “rất có thể (hoặc gần như chắc chắn) ảnh hưởng xấu đến hoạt động của vùng”không có trong mẫu
  5. D45–59từ 2 lỗi trở lêndnssec-failed.org55
  6. F0–44bất kỳ vấn đề nghiêm trọng nàoCRITICAL “có thể coi một cách hợp lý là không tồn tại”một tên miền .com44

điểm số = 100 − 30 × nghiêm trọng − 12 × lỗi − 4 × cảnh báo − 1 × lưu ý, giữ trong khoảng của chữ cái

một phầntừ một phần tư số mục kiểm tra trở lên không chạy được từ máy chủ của chúng tôi, nên điểm ghi rõ điều đó

Thang điểm, với các tên miền chúng tôi đã kiểm tra ngày 23 tháng 10, 2026 được đặt theo điểm đã ghi lại. Các mức độ trích từ định nghĩa mức độ nghiêm trọng của Zonemaster.

Bản ghi NS ở vùng cha và vùng con có khớp nhau không?

Chúng nên khớp: cơ quan quản lý (vùng cha) và vùng DNS (vùng con) đều công bố một bộ NS, và RFC 1912 §2.8 yêu cầu giữ chúng giống nhau. Khi cơ quan quản lý trỏ tới một máy chủ không trả lời cho vùng, đó là ủy quyền lame: máy chủ trả lời REFUSED, hoặc trả lời mà không có cờ có thẩm quyền (AA).

Bộ phân giải chuyển sang máy chủ tiếp theo, nên một máy chủ lame làm mất thời gian; khi mọi máy chủ được liệt kê đều lame, tên miền ngừng phân giải. Zonemaster xếp các tên chỉ cơ quan quản lý liệt kê là lỗi (EXTRA_NAME_PARENT), các tên chỉ vùng DNS liệt kê là lưu ý, và việc không có máy chủ nào hoạt động là nghiêm trọng.

github.comkhớp

Cơ quan quản lý .com
  • ns-520.awsdns-01.net
  • ns-421.awsdns-52.com
  • ns-1707.awsdns-21.co.uk
  • ns-1283.awsdns-32.org
  • dns1–4.p08.nsone.net
Vùng DNS
  • cùng 8 tên

8 trên 8 trả lời có AA

một tên miền .netlệch

Cơ quan quản lý .net
  • ns1.domaindirect.com
  • ns2.domaindirect.comREFUSED
  • ns3.domaindirect.com
Vùng DNS
  • ns1.hover.com
  • ns2.hover.com

không có tên chung · ns2.domaindirect.com REFUSED · 2 lỗi

một tên miền .comủy quyền lame

Cơ quan quản lý .com
  • ns63.domaincontrol.comREFUSED
  • ns64.domaincontrol.comREFUSED
Vùng DNS
  • không ai trả lờiSERVFAIL

mọi máy chủ đều REFUSED · bộ phân giải trả lời SERVFAIL · CRITICAL

Ba ủy quyền được ghi lại ngày 23 tháng 10, 2026. Tên của hai ủy quyền bị hỏng được giấu; nameserver và câu trả lời của chúng là thật.

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

Ít nhất hai, và khuyến nghị là ba. RFC 1034 §4.1 yêu cầu mọi vùng phải có mặt trên ít nhất hai máy chủ, và RFC 2182 §5 khuyến nghị ba cho hầu hết các vùng cấp tổ chức. Một nameserver là lỗi trong Zonemaster; hai thì đạt kèm một ghi chú thông tin.

Vị trí của chúng quan trọng hơn số lượng, nên bài kiểm tra nameserver cũng xem xét mạng của chúng. Các máy chủ trong một mạng hỏng cùng nhau: Zonemaster cảnh báo khi mọi địa chỉ nằm trong một hệ thống tự trị (IPV4_ONE_ASN), kể cả với các máy chủ anycast như Google, Cloudflare hay Akamai, nơi mỗi địa chỉ trả lời từ nhiều địa điểm. Anycast phân tán tải; nó vẫn chỉ là một nhà vận hành.

  • google.com4 NS · 1 mạngmột mạng
  • github.com8 NS · 2 mạngphân tán
  • sidn.nl3 NS · 2 mạngphân tán
  • cloudflare.com5 NS · 1 mạngmột mạng
  • nasa.gov6 NS · 1 mạngmột mạng
  • example.com2 NS · 1 mạngmột mạng

AS1921 ipcomAS13335 CloudflareAS15169 GoogleAS16509 AmazonAS21342 AkamaiAS48283 SIDNAS62597 NS1

“Khuyến nghị cung cấp ba máy chủ cho hầu hết các vùng cấp tổ chức, với ít nhất một máy phải đặt ở xa hẳn các máy còn lại.” RFC 2182 §5
Mỗi chấm là một nameserver, tô màu theo mạng (AS) công bố địa chỉ của nó, từ các lượt chạy ghi lại ngày 23 tháng 10, 2026. Chỉ một mạng là cảnh báo IPV4_ONE_ASN của Zonemaster, dù có anycast hay không.

Giá trị bản ghi SOA của bạn có đúng không?

Nếu một nhà cung cấp DNS lớn đặt chúng, gần như chắc chắn chúng ổn, kể cả khi một công cụ kiểm tra gắn cờ. Refresh, retry và expire chỉ điều khiển các máy chủ phụ sao chép vùng bằng chuyển vùng. Minimum là TTL lưu đệm phủ định (RFC 2308): khoảng thời gian bộ phân giải nhớ rằng một tên không tồn tại.

RIPE-203 (1999) khuyến nghị refresh 86400, retry 7200, expire 3600000 và minimum 172800, giá trị cuối có từ trước RFC 2308. Zonemaster đặt các ngưỡng tối thiểu thấp hơn: refresh 14400 và retry 3600 (lưu ý), expire 604800 (cảnh báo duy nhất), minimum trong khoảng 300 đến 86400 (lưu ý). Giá trị mặc định của Cloudflare, Route 53 và Azure nằm dưới ngưỡng refresh và retry; expire 3 ngày của Google Cloud DNS là cảnh báo duy nhất trong số các nhà cung cấp lớn.

refreshZonemaster ≥ 4 giờ · ◆ 1 ngàyretryZonemaster ≥ 1 giờ · ◆ 2 giờexpireZonemaster ≥ 7 ngày · ◆ 41,7 ngàyminimumZonemaster 5 phút – 1 ngày · ◆ 2 ngày
Cloudflare2,8 giờ40 phút7 ngày30 phút2 lưu ý
Amazon Route 532 giờ15 phút14 ngày1 ngày2 lưu ý
Google Cloud DNS6 giờ1 giờ3 ngày5 phút1 cảnh báo
Azure DNS1 giờ5 phút28 ngày5 phút2 lưu ý
GoDaddy8 giờ2 giờ7 ngày1 giờđạt
Namecheap BasicDNS12 giờ1 giờ7 ngày1 giờđạt
google.com (tự vận hành)15 phút15 phút30 phút1 phút1 cảnh báo · 3 lưu ý

dưới ngưỡng của Zonemasterđạtlưu ýcảnh báoRIPE-203 (1999)

Giá trị của từng nhà cung cấp theo những gì các vùng của họ trả về qua dig ngày 23 tháng 10, 2026: Cloudflare, Route 53 và Google Cloud DNS khớp với tài liệu của họ; trang trợ giúp của GoDaddy ghi minimum 600, nhưng các vùng mẫu của họ trả về 3600; chúng tôi không tìm thấy giá trị mặc định được công bố cho Azure DNS hay Namecheap BasicDNS, nên giá trị của họ lấy từ các vùng của họ. Thang logarit từ 1 phút đến 6 tuần.

Kiểm tra DNSSEC: DS, DNSKEY và chữ ký

Kiểm tra DNSSEC đi theo chuỗi tin cậy: bản ghi DS tại cơ quan quản lý phải là digest của một khóa (DNSKEY) trong vùng, khóa đó phải ký bộ khóa của vùng, và mọi chữ ký (RRSIG) phải xác minh được và còn trong thời hạn hiệu lực. Công cụ này tự tính digest và tự xác minh từng chữ ký, rồi hỏi Google Public DNS xem vùng có xác thực được không.

Chỉ cần đứt một mắt xích, các bộ phân giải có xác thực sẽ trả lời SERVFAIL: tên miền biến mất với mọi người dùng phía sau chúng. dnssec-failed.org, một vùng thử nghiệm cố ý để hỏng, cho thấy hai chỗ đứt cùng lúc. Thuật toán được đánh giá theo sổ đăng ký của IANA (RFC 9904): 8, 13 và 15 được khuyến nghị, còn 5 và 7, vốn ký bằng SHA-1, không được dùng nữa (RFC 9905) và bị Zonemaster xếp là lỗi.

cloudflare.coman toàn

  1. DS 2371 tại .comthuật toán 13 · SHA-256 · 329968…26F2B9
  2. digest khớp với khóa 2371
  3. DNSKEY 2371 · KSKcờ 257 · ECDSA P-256 (13)
  4. ký bộ khóa · còn 50,8 ngày trên tổng 61 ngày
  5. DNSKEY 34505 · ZSKcờ 256 · ECDSA P-256 (13)
  6. ký các bản ghi · SOA: còn 1 ngày trên tổng 2 ngày
  7. Google Public DNSđã bật cờ AD: an toàn

dnssec-failed.orgkhông hợp lệ

  1. DS 42069 tại .orgthuật toán 13 · SHA-256
  2. không có khóa 42069 trong vùng
  3. DNSKEY 50719 · KSKkhóa ký khóa (KSK) thật của vùng
  4. chữ ký của nó trên bộ khóa đã hết hạn cách đây 112 ngày
  5. DNSKEY 32784 · ZSKký SOA: hợp lệ, còn 5,7 ngày trên tổng 7 ngày
  6. không có gì đáng tin cậy dẫn tới nó
  7. Google Public DNSSERVFAIL; có câu trả lời khi bật CD: không hợp lệ

Thuật toán ký (sổ đăng ký IANA, RFC 9904)

  • RECOMMENDED8 RSASHA256 · 13 ECDSAP256SHA256 · 15 ED25519nên dùng
  • MAY14 ECDSAP384SHA384 · 16 ED448được phép
  • NOT RECOMMENDED10 RSASHA512Zonemaster WARNING
  • MUST NOT5 RSASHA1 · 7 RSASHA1-NSEC3-SHA1 · 1 · 3 · 6 · 12RFC 9905 · Zonemaster ERROR

cả hai chuỗi ở trên đều ký bằng 13

Hai chuỗi được ghi lại ngày 23 tháng 10, 2026: chuỗi của cloudflare.com còn nguyên; chuỗi của dnssec-failed.org đứt ở DS và đứt thêm lần nữa ở một chữ ký đã hết hạn.

DNS email: MX, SPF và DMARC

Các mục kiểm tra email đọc đúng những gì máy chủ nhận thư đọc: bản ghi MX (hoặc null MX cho biết tên miền không nhận thư, RFC 7505), một bản ghi SPF trong giới hạn 10 lượt tra cứu DNS của RFC 7208, và một chính sách DMARC (RFC 9989, thay thế RFC 7489 từ tháng 5 năm 2026).

SPF được đánh giá, không chỉ được tìm thấy: mọi include đều được lần theo và đếm. Bản ghi của github.com cần đúng 10 lượt tra cứu cộng một lượt tra cứu rỗng: hợp lệ, nhưng không còn chỗ trống. Một tên miền không bao giờ gửi thư nên nói rõ điều đó: example.com công bố bộ bản ghi cho tên miền để trống (parked), gồm null MX, v=spf1 -all và p=reject. Để xem chi tiết, Kiểm tra SPF và Kiểm tra DMARC đi sâu hơn.

github.comgửi và nhận thư

MX
0 github-com.mail.protection.outlook.comMicrosoft 365 · 1 máy chủ · không phải bí danh
SPF
v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.227.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all10 trên 10 lượt tra cứu DNS1 trên 2 lượt tra cứu rỗng · hợp lệ, không còn chỗ trống
DMARC
p=quarantine; sp=rejectbáo cáo tới 1 địa chỉ · tên miền con: reject

example.combộ bản ghi tên miền để trống

MX
0 .null MX: không nhận thư (RFC 7505)
SPF
v=spf1 -allkhông gửi thư · 0 lượt tra cứu
DMARC
p=reject; sp=rejectmọi thư tự nhận là example.com đều bị từ chối
github.com và example.com, như được công bố ngày 23 tháng 10, 2026.

Kiểm tra DNS bằng dòng lệnh (dig)

Bốn bước với dig và delv lặp lại phần cốt lõi của bài kiểm tra này: lần theo ủy quyền từ gốc, hỏi trực tiếp một nameserver với đệ quy tắt, đối chiếu DS tại cơ quan quản lý với các khóa của vùng, và để một bộ phân giải có xác thực đánh giá chuỗi.

Thêm +tcp để thấy những gì máy chủ của chúng tôi thấy; bỏ nó đi để kiểm tra UDP, điều mà một công cụ web trên mạng của Cloudflare không làm được. Trong phần header của câu trả lời, aa đánh dấu câu trả lời có thẩm quyền; REFUSED, hoặc không có cờ aa từ một máy chủ mà cơ quan quản lý liệt kê, là ủy quyền lame.

Terminal · dig 9.20

$ dig +trace +tcp github.com NS
;; (đã rút gọn)
com.          172800 IN NS a.gtld-servers.net.   ;; từ h.root-servers.net 1
github.com.   172800 IN NS ns-520.awsdns-01.net. ;; từ h.gtld-servers.net: 8 NS 2

$ dig @ns-421.awsdns-52.com github.com SOA +norec +tcp
;; flags: qr aa; QUERY: 1, ANSWER: 1 3
github.com.   900 IN SOA ns-1707.awsdns-21.co.uk. awsdns-hostmaster.amazon.com.
              1 7200 900 1209600 86400 4

$ dig @a.gtld-servers.net github.com DS +norec
;; status: NOERROR, ANSWER: 0 ;; không có DS: chưa ký 5

$ delv @8.8.8.8 cloudflare.com SOA
; fully validated 6
cloudflare.com. 300 IN SOA ns3.cloudflare.com. dns.cloudflare.com.
                2417999975 10000 2400 604800 300
  1. Máy chủ gốc chỉ .com tới 13 máy chủ của nó
  2. Bộ NS của cơ quan quản lý cho github.com, giữ 2 ngày
  3. aa: một câu trả lời có thẩm quyền, không phải bộ nhớ đệm
  4. SOA: serial 1, rồi refresh, retry, expire, minimum
  5. Không có DS tại .com: không có gì để DNSSEC xác minh
  6. delv đã xác thực chuỗi từ gốc
Câu trả lời thật cho github.com và cloudflare.com (23 tháng 10, 2026), đã rút gọn. Các dấu đánh số tương ứng với ghi chú.

Vì sao các công cụ kiểm tra DNS cho kết quả khác nhau?

Vì chúng chấm theo những con số khác nhau. Các công cụ kiểu cũ gắn cờ giá trị mặc định của nhà cung cấp: intoDNS gọi expire 1800 giây của google.com là “NOT OK” và báo lỗi với hai serial của github.com, vốn bình thường khi dùng hai nhà cung cấp DNS. Zonemaster xếp hai serial đó là cảnh báo và nhận ra null MX; phiên bản đầu tiên của chính chúng tôi đã sai ở cả hai.

Và chúng nhìn mạng từ những vị trí khác nhau. Zonemaster (AFNIC và Swedish Internet Foundation) hỏi qua UDP và TCP, trên IPv4 và IPv6. Bài kiểm tra này chạy trên edge của Cloudflare: nó chỉ hỏi qua TCP, không dùng IPv6 và không kết nối được tới các địa chỉ của chính Cloudflare, nên những máy chủ đó được đọc qua 1.1.1.1 và các mục kiểm tra của chúng được đánh dấu chưa kiểm tra, không bao giờ là không đạt. Là một lựa chọn thay thế intoDNS, công cụ cho thấy nguồn tham chiếu đứng sau mỗi mức độ thay vì chỉ một chữ OK hay NOT OK.

Trường hợpintoDNSZonemasterDNS Robot v1Bài kiểm tra này
github.comhai serial SOA (hai nhà cung cấp DNS)lỗi“Looks like your nameservers do not agree on the SOA serial.”cảnh báoMULTIPLE_SOA_SERIALSkhông đạt“Serial mismatch detected: 1656468023 vs 1.”cảnh báocó giải thích: mỗi nhà cung cấp DNS một serial
google.comexpire SOA 1.800 giâykhông ổn“Your SOA EXPIRE number is: 1800. That is NOT OK”cảnh báoEXPIRE_MINIMUM_VALUE_LOWERkhông đạt“too low (min recommended: 14 days)”cảnh báokèm những gì expire ảnh hưởng
example.comnull MX (0 .)lỗi“0 No A Record (no glue either)”thông tinZ09_VALID_NULL_MXđạt“Found 1 MX record(s)”đạtnhận ra null MX
cloudflare.comretry SOA 2.400 giây—không trích dẫnlưu ýRETRY_MINIMUM_VALUE_LOWERkhông đạt“too high (max recommended: 15min)”lưu ýgiá trị mặc định của Cloudflare
cloudflare.comđã ký DNSSECkhông kiểm trakhông kiểm tra DNSSECđạtDNSSEC02 · 05 · 08: chuỗi đã được xác minhchú ý“DNSSEC does not appear to be enabled for this domain.”đạtDS → KSK → RRSIG đã xác minh, Google xác thực
Cùng các tên miền trên bốn công cụ kiểm tra. Kết quả của intoDNS và v1 trích từ trang và câu trả lời của chúng ngày 22 – 23 tháng 10, 2026; mức độ của Zonemaster lấy từ đặc tả bài kiểm tra. Cột cuối là bài kiểm tra này: một lựa chọn thay thế intoDNS chấm mỗi phát hiện ở mức độ mà nguồn tham chiếu của nó quy định.

Kiểm tra sức khỏe DNS: câu hỏi thường gặp

Kiểm tra sức khỏe DNS là gì?

Kiểm tra sức khỏe DNS, hay xác thực DNS, xem DNS của một tên miền có được thiết lập để cả internet truy cập được không: ủy quyền tại cơ quan quản lý, từng nameserver, bản ghi SOA, DNSSEC và bản ghi email. Mỗi phát hiện được chấm theo mức độ gây hại, từ thông tin đến nghiêm trọng, và công cụ xác thực DNS này cho thấy quy tắc nó áp dụng (một bài kiểm tra Zonemaster hoặc một mục RFC) cùng cách sửa.

Xác thực tên miền có giống kiểm tra sức khỏe DNS không?

Không hẳn. “Xác thực tên miền” còn chỉ bước kiểm tra mà tổ chức cấp chứng chỉ thực hiện trước khi cấp chứng chỉ DV, và bản ghi TXT mà Google Workspace hay Microsoft 365 yêu cầu để chứng minh bạn sở hữu tên miền. Công cụ xác thực tên miền này kiểm tra DNS của tên miền: ủy quyền, nameserver, SOA, DNSSEC và bản ghi email. Với chứng chỉ, hãy xem Kiểm tra SSL.

Ủy quyền lame là gì và sửa thế nào?

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

Nhà cung cấp DNS của tôi dùng anycast. Sao vẫn bị cảnh báo một mạng?

Vì một nhà vận hành là một điểm lỗi chung. Anycast cho mỗi địa chỉ trả lời từ nhiều địa điểm, giúp chống lại việc một địa điểm ngừng hoạt động, chứ không chống được sự cố của chính nhà cung cấp hay lỗi trong cấu hình của họ. Vì vậy Zonemaster giữ IPV4_ONE_ASN ở mức cảnh báo, và RFC 2182 yêu cầu máy chủ trên các mạng đa dạng. Một nhà cung cấp DNS thứ hai trên mạng khác sẽ xóa cảnh báo này.

Thông số thời gian SOA của tôi bị gắn cờ. Có cần đổi không?

Thường là không. Refresh, retry và expire chỉ có ý nghĩa với các máy chủ phụ sao chép vùng của bạn bằng chuyển vùng; các nhà cung cấp lớn như Cloudflare và Route 53 không dùng chúng cho vùng của bạn, và giá trị mặc định của họ vẫn ổn. Expire dưới một tuần là giá trị duy nhất Zonemaster gọi là cảnh báo. Chỉ đổi khi bạn tự vận hành máy chủ chính và các máy chủ phụ.

Vì sao một số mục được đánh dấu “chưa kiểm tra”?

Vì máy chủ của chúng tôi không chạy được chúng, không phải vì có gì sai. Máy chủ chạy trên mạng của Cloudflare, vốn không mở được kết nối tới các địa chỉ của chính Cloudflare, và nó chỉ hỏi qua TCP, không dùng IPv6. Những máy chủ đó được đọc qua bộ phân giải 1.1.1.1 của Cloudflare thay thế. Các mục chưa kiểm tra không bao giờ làm giảm điểm; từ một phần tư số mục trở lên thì điểm được ghi là một phần.

Vì sao các nameserver của tôi báo serial SOA khác nhau?

Hoặc một máy chủ phụ chưa bắt kịp thay đổi, hoặc tên miền của bạn dùng hai nhà cung cấp DNS không chuyển vùng cho nhau, nên mỗi bên giữ serial riêng. Trường hợp thứ hai là bình thường: các máy chủ Route 53 của github.com báo 1, còn các máy chủ NS1 báo 1656468023. Zonemaster liệt kê mọi khác biệt là cảnh báo; chúng tôi giải thích đó là trường hợp nào.

Đây có phải công cụ kiểm tra DNSSEC không, và không có DNSSEC có bị trừ điểm không?

Có: nó đối chiếu DS tại cơ quan quản lý với các khóa của vùng và xác minh mọi chữ ký, rồi hỏi Google Public DNS. Một vùng chưa ký là một cảnh báo của Zonemaster (DS07_NOT_SIGNED), nên điểm cao nhất chỉ là A. Một chuỗi bị đứt tệ hơn nhiều so với không có: các bộ phân giải có xác thực từ chối tên miền, một lỗi kéo điểm xuống C hoặc thấp hơn.

Nên kiểm tra DNS tên miền bao lâu một lần?

Sau mỗi thay đổi về nameserver, DNSSEC hoặc bản ghi email, và trước cũng như sau khi chuyển sang nhà cung cấp DNS hoặc nhà đăng ký mới. Ngoài ra, mỗi tháng một lần là đủ để phát hiện một chữ ký sắp hết hạn, một nameserver ngừng trả lời hoặc một thay đổi tại cơ quan quản lý mà bạn không thực hiện. Mỗi kết quả có liên kết riêng, nên bạn có thể so sánh các lần chạy.

Các bạn có lưu những tên miền tôi kiểm tra không?

Không. Bài kiểm tra chạy trên máy chủ của chúng tôi tại edge của Cloudflare và hỏi máy chủ gốc, cơ quan quản lý, các nameserver của bạn, Google Public DNS và bộ phân giải của Cloudflare; không có gì được ghi lại kèm địa chỉ của bạn. Kết quả được giữ 10 phút để lần chạy lại hoặc liên kết chia sẻ có ngay, rồi bị xóa. Mỗi lần chạy, nameserver của bạn nhận khoảng 20 câu hỏi từ máy chủ của chúng tôi.

Công cụ liên quan