Công cụ phổ biến

Giao diện

Tra Cứu DNS

Công cụ tra cứu DNS (DNS lookup) miễn phí cho mọi tên miền, host hoặc IP: kiểm tra mọi bản ghi DNS lấy từ nameserver của chính tên miền, đặt cạnh những gì Google và Cloudflare đang lưu trong bộ nhớ đệm, để bạn thấy khi nào một thay đổi đã đến được với mọi người.

Nguồn: các nameserver có thẩm quyền của tên miền, lần theo từ một máy chủ gốc · Google Public DNS · Cloudflare 1.1.1.1

3 nguồn, hỏi mới

Tên miền, host, URL, email hoặc IP. Mỗi lần tra cứu đều hỏi lại máy chủ: không có gì lấy từ bộ nhớ đệm của chúng tôi.

Loại bản ghi
Thử

Cách chúng tôi tra cứu 4 bước · khoảng 1 giây

  1. Gốc13 máy chủ gốc
  2. TLDmáy chủ của cơ quan đăng ký
  3. Nameservermáy chủ riêng của tên miền
  4. Câu trả lờimọi loại bản ghi
  5. Google8.8.8.8
  6. Cloudflare1.1.1.1

Mỗi lần tra cứu tự đi hết đường: từ máy chủ gốc đến cơ quan đăng ký TLD, rồi tới nameserver riêng của tên miền để lấy bản ghi hiện tại, và hỏi Google cùng Cloudflare xem họ còn lưu đệm gì.

Tra cứu DNS cho biết những gì?

Tra cứu DNS (DNS lookup) hỏi Hệ thống Tên miền (Domain Name System) xem nó lưu gì cho một cái tên: địa chỉ IP của website (A và AAAA), máy chủ email (MX), nameserver (NS), bản ghi văn bản (TXT) và nhiều hơn nữa. Công cụ kiểm tra DNS này hỏi ba nơi cùng lúc: các nameserver có thẩm quyền của chính tên miền, nơi giữ dữ liệu hiện hành, và hai bộ phân giải công khai bận rộn nhất thế giới, Google Public DNS và Cloudflare 1.1.1.1, nơi trả về bản sao lưu đệm cho hàng triệu người.

Khi chúng không khớp nhau, bạn đã tìm ra lý do thường gặp khiến một thay đổi DNS “không có tác dụng”: một bộ phân giải vẫn giữ câu trả lời cũ và giữ nó cho đến khi TTL của bản ghi hết. Kết quả cho biết đó là bộ phân giải nào, nó vẫn trả về gì và còn bao lâu nữa thì làm mới.

Kết quả tra cứu DNS: bản ghi từ nameserver của tên miền cạnh bộ nhớ đệm của Google và Cloudflare, đường đi từ gốc và DNSSECKết quả tra cứu DNS: bản ghi từ nameserver của tên miền cạnh bộ nhớ đệm của Google và Cloudflare, đường đi từ gốc và DNSSECĐường điTừ máy chủ gốc đến TLD của tên miền và các nameserver của chính nó, kèm câu trả lời của từng máy chủ và tốc độ phản hồi.Mới và lưu đệmTừng loại bản ghi từ nameserver của tên miền đặt cạnh bản sao của Google và Cloudflare, kèm thời gian còn lại.Giải thích từng bản ghiÝ nghĩa của giá trị bằng lời: độ ưu tiên email, các bộ hẹn giờ SOA, quy tắc CAA, dịch vụ đứng sau một token TXT.DNSSEC và emailCâu trả lời có được ký và xác thực hay không, cùng thiết lập MX, SPF và DMARC của tên miền.
Tra cứu DNS cho github.com: đường đi từ máy chủ gốc, mọi loại bản ghi, và những gì Google và Cloudflare đang trả về. Chọn một số để xem từng phần thể hiện điều gì.

Giải thích các loại bản ghi DNS

Vùng DNS của một tên miền chứa nhiều loại bản ghi, mỗi bản ghi có tên, TTL và giá trị. Đây là những loại mà một lần tra cứu bản ghi DNS hiển thị:

LoạiNội dungGiá trị ví dụ
AĐịa chỉ IPv4 của tên: nơi trình duyệt kết nối đến.203.0.113.20
AAAAĐịa chỉ IPv6 của tên.2001:db8::20
CNAMEBí danh: tên này là một tên khác, hãy tra cứu tên đó. Nó không thể nằm cạnh các bản ghi khác, nên không dùng được ở gốc tên miền (apex).www.example.com → example.com
MXMáy chủ email của tên miền, kèm độ ưu tiên: số nhỏ nhất được thử trước. Một MX duy nhất với 0 và “.” nghĩa là tên miền không nhận thư.10 mail.example.com
NSCác nameserver giữ bản ghi của tên miền.ns1.example.net
TXTVăn bản tự do: SPF, DMARC và DKIM cho email, và các token chứng minh quyền sở hữu tên miền với Google, Microsoft và các bên khác.v=spf1 include:_spf.example.net -all
SOAĐiểm bắt đầu thẩm quyền (start of authority) của vùng: máy chủ chính, liên hệ, số serial và các bộ hẹn giờ làm mới, thử lại, hết hạn và lưu đệm phủ định.ns1.example.com hostmaster.example.com 2026102001 7200 3600 1209600 300
CAANhững tổ chức cấp chứng chỉ (CA) nào được phép cấp chứng chỉ cho tên miền.0 issue "letsencrypt.org"
HTTPSCách kết nối trước yêu cầu đầu tiên: hỗ trợ HTTP/3, cổng và gợi ý địa chỉ. Chrome, Firefox và các hệ thống của Apple đều hỏi bản ghi này.1 . alpn=h3,h2
SRVNơi một dịch vụ chạy (độ ưu tiên, trọng số, cổng, host), dưới các tên như _sip._tcp.10 5 5060 sip.example.com
PTRTên đứng sau một địa chỉ IP: DNS ngược.20.113.0.203.in-addr.arpa → host.example.com
DSDNSKEYDNSSEC: các khóa công khai của vùng (DNSKEY) và dấu vân tay của chúng ở vùng cha (DS), giúp nối chuỗi chữ ký lên đến gốc.2371 13 2 3299…

Tra cứu DNS hoạt động như thế nào?

Thiết bị của bạn không tìm kiếm khắp internet. Nó hỏi một bộ phân giải, thường là của ISP hoặc một bộ phân giải công khai như Google hay Cloudflare, và bộ phân giải đi theo các tham chiếu xuống dần theo tên cho đến khi một máy chủ giữ câu trả lời phản hồi:

  1. 1

    Hỏi máy chủ gốc

    Khi chưa có gì trong bộ nhớ đệm, bộ phân giải bắt đầu từ một trong 13 máy chủ gốc, từ a đến m, do 12 tổ chức vận hành. Máy chủ gốc không biết example.com, nhưng biết ai vận hành .com. Một bộ phân giải bận rộn đã biết sẵn điều đó và bỏ qua bước này.

  2. 2

    Đi theo tham chiếu đến TLD

    Các máy chủ .com cũng không giữ bản ghi của example.com. Chúng chỉ bộ phân giải đến nameserver của chính tên miền, những máy chủ có trong bản ghi NS của nó.

  3. 3

    Nhận câu trả lời có thẩm quyền

    Nameserver của tên miền trả lời với cờ AA (authoritative answer) được bật: đây là bản ghi đúng như chủ sở hữu đã công bố.

  4. 4

    Lưu đệm theo TTL

    Bộ phân giải giữ câu trả lời trong khoảng thời gian TTL cho phép và trao cùng bản sao đó, với TTL đang đếm ngược, cho mọi người hỏi đến cho đến khi TTL hết.

Công cụ này tự đi theo đường đó từ mạng của Cloudflare, nên bạn thấy từng bước. Sau đó nó hỏi Google và Cloudflare để xem bộ nhớ đệm của họ đang giữ gì.

Đường đi từ gốc

  1. Gốca.root-servers.net16 ms · tham chiếu: 13 máy chủ .com
  2. .COMa.gtld-servers.netVerisign · 150 ms · tham chiếu: ns1–ns2.example.com
  3. Nameserverns1.example.comexample.com · 203.0.113.53 · 20 mscâu trả lời có thẩm quyền (AA) · 11 loại trên một kết nối TCP
  4. Câu trả lời8 bản ghi trong 7 loạiNOERROR trong 31 ms · 4 loại trống (CNAME, HTTPS, DNSKEY, DS)
  1. Google Public DNS8.8.8.8cùng bản ghi · bản sao cũ nhất làm mới sau 2:58
  2. Cloudflare DNS1.1.1.1cùng bản ghi · bản sao cũ nhất làm mới sau 4:04
Cùng đường đi như kết quả vẽ ra: tra cứu example.com

Vì sao tôi vẫn thấy bản ghi DNS cũ?

Vì một bộ phân giải đã lưu nó vào bộ nhớ đệm. Mỗi bản ghi mang một TTL (time to live, thời gian tồn tại) tính bằng giây, và bộ phân giải đã lấy bản ghi sẽ tiếp tục trả về bản sao của mình cho đến khi thời gian đó hết, rồi mới hỏi lại. Thay đổi bản ghi tại nhà cung cấp DNS sẽ thay đổi câu trả lời có thẩm quyền ngay lập tức; các bộ phân giải đã giữ bản ghi cũ vẫn giữ nó cho đến khi hết hạn.

Vì vậy, một thay đổi mất thời gian bằng TTL của bản ghi cũ, chứ không phải cố định 24 đến 48 giờ, và thường ít hơn: TTL là mức tối đa, và Google Public DNS giữ bản ghi tối đa khoảng sáu giờ. Bản ghi không tồn tại cũng được lưu đệm: “không có tên này” hoặc “không có bản ghi loại đó” được giữ theo giá trị nhỏ hơn giữa TTL của bản ghi SOA và trường cuối cùng của nó, MINIMUM. Ngay cả một lỗi cũng được lưu đệm, tối đa 5 phút.

Bạn có thể làm gì

  • Kiểm tra câu trả lời có thẩm quyền tại đây. Nếu nameserver của chính tên miền hiển thị giá trị mới, thay đổi đã hoàn tất; chỉ các bộ nhớ đệm là chưa cập nhật.
  • Hạ TTL trước một thay đổi đã lên kế hoạch, sớm ít nhất bằng một TTL cũ, để các bộ nhớ đệm bỏ giá trị cũ nhanh. Sau đó tăng lại.
  • Yêu cầu Google và Cloudflare bỏ bản sao của họ: cả hai đều có trang công khai để làm mới một tên trong bộ nhớ đệm (Google, Cloudflare).
  • Xóa bộ nhớ đệm của máy tính: trên Windows, chạy ipconfig /flushdns.
  • Có thẩm quyềnns1.example.com · cờ AA

    Nameserver của chính tên miền. Nó trả lời gì thì đó là bản ghi hiện tại: thay đổi ở đây và phần còn lại sẽ theo sau.

  • Lưu đệm8.8.8.8 · TTL đang đếm ngược

    Bản sao của bộ phân giải, được trả về cho đến khi TTL hết. Đây là những gì phần lớn thế giới nhìn thấy, và là lý do một thay đổi có vẻ “không có tác dụng”.

  • Bộ nhớ đệm của bạnmáy tính của bạn · router của bạn

    Máy tính và router của bạn cũng giữ bản sao. Xóa bộ nhớ đệm (flush) sẽ dọn bản của máy tính; bản của router tự hết hạn.

nslookup và dig: các lệnh tra cứu DNS

Cùng các lần tra cứu đó từ terminal: nslookup có sẵn trên Windows, macOS và Linux, dig trên macOS và hầu hết hệ thống Linux, và Resolve-DnsName trong PowerShell trên Windows. Kết quả ở trên đưa ra các lệnh cho đúng lần tra cứu bạn vừa chạy.

Để tra cứunslookupdig
Bản ghi Anslookup example.comdig example.com
Máy chủ emailnslookup -type=MX example.comdig example.com MX
Bản ghi văn bảnnslookup -type=TXT example.comdig example.com TXT
Hỏi một bộ phân giải cụ thểnslookup example.com 8.8.8.8dig @8.8.8.8 example.com
DNS ngượcnslookup 8.8.8.8dig -x 8.8.8.8
Chỉ lấy giá trị—dig +short example.com
Đường đi từ gốc—dig +trace example.com

“Non-authoritative answer” trong kết quả của nslookup nghĩa là câu trả lời đến từ một bộ phân giải, không phải từ nameserver của chính tên miền. Để có câu trả lời có thẩm quyền, hãy chỉ định một nameserver của tên miền làm máy chủ: nslookup example.com ns1.example.net.

ANY không có nghĩa là tất cả bản ghi: máy chủ có thể chỉ trả lời một loại, hoặc một bản ghi giữ chỗ chỉ ghi “RFC8482”, và 1.1.1.1 từ chối truy vấn này. Công cụ này hỏi từng loại riêng. Bản dig đi kèm macOS không biết bản ghi HTTPS: hãy hỏi TYPE65 thay thế.

Lỗi DNS: NXDOMAIN, SERVFAIL và REFUSED

Mọi câu trả lời DNS đều mang một mã phản hồi. Kết quả trống không phải lúc nào cũng là lỗi, và mã phản hồi cho biết cần xem ở đâu:

Câu trả lờiÝ nghĩaCần kiểm tra
NOERRORTên tồn tại và có bản ghi của loại đó được trả về.Không cần gì; hãy so sánh các giá trị.
NODATATên tồn tại nhưng không có bản ghi loại này: NOERROR với câu trả lời trống, không phải một mã riêng.Thêm bản ghi tại nhà cung cấp DNS nếu nó cần tồn tại.
NXDOMAINTên hoàn toàn không tồn tại, và không có tên nào bên dưới nó tồn tại.Chính tả, tên miền đã được đăng ký và chưa hết hạn, và với tên miền phụ thì nó đã được tạo chưa.
SERVFAILBộ phân giải không lấy được câu trả lời hợp lệ: nameserver gặp lỗi, hoặc xác thực DNSSEC thất bại.Kết luận DNSSEC, và nameserver của tên miền có trả lời hay không.
REFUSEDMáy chủ không trả lời câu hỏi này: nó không có thẩm quyền với tên miền và không truy vấn đệ quy giúp bạn.Bản ghi NS có trỏ đến các máy chủ đang lưu trữ vùng DNS hay không.
TimeoutHoàn toàn không có trả lời.Nameserver đang sập, bị chặn hoặc có địa chỉ sai.

DNSSEC: an toàn, chưa ký hay bị lỗi?

DNSSEC ký các bản ghi của một vùng để bộ phân giải có thể chứng minh chúng không bị giả mạo. Vùng cha công bố một bản ghi DS, là dấu vân tay của khóa tên miền, còn tên miền công bố các khóa của mình trong bản ghi DNSKEY, để chữ ký nối thành chuỗi lên đến gốc. Google Public DNS và Cloudflare 1.1.1.1 đều xác thực DNSSEC.

  • DNSSEC an toàn

    An toàn

    Đã ký, và bộ phân giải có xác thực của Google đã kiểm tra chữ ký: câu trả lời của nó mang bit AD (authenticated data), tức là nó xác nhận câu trả lời đã được xác thực.

  • DNSSEC chưa ký

    Chưa ký

    Không có bản ghi DS ở vùng cha: vùng chưa được ký. Nó vẫn phân giải bình thường; chỉ là câu trả lời không thể được chứng minh là thật.

  • DNSSEC bị lỗi

    Bị lỗi

    Xác thực thất bại, nên các bộ phân giải có xác thực trả lời SERVFAIL và người dùng của họ không truy cập được tên miền, trong khi dữ liệu vẫn có khi tắt kiểm tra. Nguyên nhân thường gặp là bản ghi DS ở vùng cha không khớp khóa nào của vùng, sau khi chuyển sang nhà cung cấp DNS mới.

Bản ghi email trong tra cứu DNS

Thư gửi đến một tên miền đi tới các máy chủ MX của nó, và máy chủ nhận kiểm tra bản ghi TXT trước khi tin thư đó: SPF liệt kê các máy chủ được phép gửi thư cho tên miền, trong một bản ghi chỉ được gây ra tối đa 10 lượt tra cứu DNS; DMARC tại _dmarc cho biết phải làm gì với thư không đạt kiểm tra, được tìm bằng cách đi ngược lên theo tên khi tên miền phụ không có bản ghi riêng (RFC 9989, từ tháng 5 năm 2026); MTA-STS tại _mta-sts yêu cầu máy chủ gửi chuyển thư qua TLS. Kết quả đọc tất cả các bản ghi này và cho biết nhà cung cấp email đứng sau các host MX.

Để kiểm tra kỹ hơn một bản ghi, hãy dùng Tra cứu MX, Kiểm tra SPF và Kiểm tra DMARC.

API tra cứu DNS

Hai endpoint miễn phí, hỗ trợ CORS cho trình duyệt. /api/dns-query hỏi một bộ phân giải về một loại bản ghi và giữ nguyên các trường của API cũ của chúng tôi; /api/dns-lookup truyền toàn bộ lần tra cứu của trang này dưới dạng các dòng JSON.

Một loại từ một bộ phân giải
$ curl -X POST https://dnsrobot.net/api/dns-query \
    -H "Content-Type: application/json" \
    -d '{"domain": "google.com", "recordType": "MX", "dnsServer": "8.8.8.8"}'
{
  "status": "success", "responseTime": 4,
  "resolvedIPs": ["10 smtp.google.com"],
  "dnsServer": "8.8.8.8", "recordType": "MX", "domain": "google.com", …
}
Toàn bộ lần tra cứu, truyền dạng luồng
$ curl "https://dnsrobot.net/api/dns-lookup?domain=google.com"
{"t":"start","name":"google.com","kind":"name","types":["A","AAAA","CNAME","MX",…]}
{"t":"hop","hop":{"zone":".","server":"a.root-servers.net","ms":16,"outcome":"referral",…}}
{"t":"answers","source":"google","server":"dns.google","sets":[{"type":"A",…}]}
{"t":"answers","source":"auth","server":"ns1.google.com","sets":[…]}
{"t":"dnssec","verdict":"unsigned",…}
{"t":"done","ms":57}

Câu hỏi thường gặp về tra cứu DNS

DNS lookup là gì?

DNS lookup (tra cứu DNS) là việc hỏi Hệ thống Tên miền về các bản ghi của một tên: địa chỉ IP của website, máy chủ email, nameserver, bản ghi văn bản và hơn thế. Thiết bị của bạn tra cứu như vậy mỗi khi bạn mở một trang web. Công cụ này hiển thị mọi loại bản ghi cùng lúc, từ nameserver của chính tên miền và từ bộ phân giải công khai của Google và Cloudflare.

Làm sao kiểm tra bản ghi DNS của một tên miền?

Nhập tên miền ở trên và chọn Tất cả: công cụ hỏi các nameserver có thẩm quyền của tên miền về từng loại bản ghi (A, AAAA, CNAME, MX, NS, TXT, SOA, CAA, HTTPS, DNSKEY và DS) và hiển thị bản sao lưu đệm của Google và Cloudflare bên cạnh từng loại. Chọn một loại để chỉ xem loại đó, hoặc sao chép lệnh dig và nslookup để tự chạy cùng lần tra cứu.

Có thể chạy nslookup online không?

Có: trang này là một công cụ nslookup online, với nhiều chi tiết hơn. nslookup hỏi một máy chủ về một loại bản ghi; ở đây bạn nhận được mọi loại cùng lúc, câu trả lời có thẩm quyền và bộ nhớ đệm của hai bộ phân giải, TTL, và đường đi từ máy chủ gốc. Kết quả cũng hiển thị chính xác các lệnh nslookup, dig và Resolve-DnsName cho lần tra cứu của bạn để chạy trong terminal.

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

Bằng TTL của bản ghi cũ. Nameserver của tên miền trả về giá trị mới ngay lập tức, nhưng các bộ phân giải đã lưu đệm giá trị cũ sẽ giữ nó cho đến khi TTL hết: 300 giây là năm phút, 86400 là một ngày. Kết quả hiển thị thời gian còn lại trên bản sao của Google và Cloudflare. Hãy hạ TTL một ngày trước một thay đổi đã lên kế hoạch.

“Non-authoritative answer” (câu trả lời không có thẩm quyền) là gì?

Là câu trả lời lấy từ bộ nhớ đệm của bộ phân giải thay vì từ nameserver của chính tên miền. nslookup in ra “Non-authoritative answer” mỗi khi bạn hỏi một bộ phân giải, tức gần như luôn vậy. Nó thường đúng, nhưng có thể đã cũ cho đến khi TTL hết. Câu trả lời có thẩm quyền đến từ nameserver của vùng với cờ AA được bật; công cụ này lấy nó bằng cách đi từ gốc xuống.

NXDOMAIN nghĩa là gì?

NXDOMAIN nghĩa là tên đó không tồn tại trong DNS. Với một tên miền, hãy kiểm tra chính tả, và xem tên miền đã được đăng ký và chưa hết hạn; Tra Cứu WHOIS hiển thị trạng thái của nó. Với tên miền phụ, bản ghi chưa từng được tạo hoặc đã bị xóa. Tên tồn tại nhưng không có bản ghi thuộc loại bạn hỏi sẽ nhận NOERROR với câu trả lời trống, thường gọi là NODATA.

SERVFAIL nghĩa là gì?

SERVFAIL nghĩa là bộ phân giải không lấy được câu trả lời hợp lệ. Hoặc nameserver của tên miền đang sập hay cấu hình sai, hoặc xác thực DNSSEC thất bại, khiến các bộ phân giải có xác thực như Google và Cloudflare từ chối câu trả lời. Công cụ này phân biệt hai trường hợp: khi dữ liệu trả về lúc tắt kiểm tra, kết luận DNSSEC sẽ là Bị lỗi.

TTL trong DNS là gì?

TTL (time to live, thời gian tồn tại) là số giây một bộ phân giải được giữ bản ghi trong bộ nhớ đệm trước khi hỏi lại. Mỗi bản ghi có TTL riêng. TTL ngắn như 300 giây giúp thay đổi lan nhanh nhưng tốn thêm truy vấn; TTL dài như 86400 giây, tức một ngày, tiết kiệm hơn nhưng thay đổi chậm. Bản sao lưu đệm đếm ngược, nên TTL của Google và Cloudflare ở đây thấp hơn.

Làm sao tra cứu DNS ngược?

Nhập địa chỉ IP ở trên. Công cụ chuyển nó thành tên ngược (8.8.8.8 thành 8.8.8.8.in-addr.arpa), hỏi bản ghi PTR rồi kiểm tra tên đó theo chiều xuôi: khi tên đó phân giải về lại đúng IP, DNS ngược được xác nhận, điều mà máy chủ email tìm kiếm. Từ terminal: nslookup 8.8.8.8 hoặc dig -x 8.8.8.8.

Làm sao tìm nameserver của một tên miền?

Tra cứu tên miền và đọc bản ghi NS, hoặc xem đường đi bên phải: nó hiển thị các nameserver mà TLD của tên miền trỏ đến và đánh dấu nếu bản ghi NS của chính tên miền liệt kê các máy chủ khác. Kết quả cũng nêu tên công ty vận hành chúng, như Cloudflare, AWS Route 53 hoặc nhà đăng ký tên miền.

Tra cứu DNS và kiểm tra lan truyền DNS khác nhau thế nào?

Tra cứu DNS hiển thị mọi bản ghi của tên miền kèm chi tiết, từ nameserver của chính nó và hai bộ phân giải lớn. Kiểm tra lan truyền hỏi một loại bản ghi ở hàng chục bộ phân giải toàn cầu để xem thay đổi đã đến đâu. Bắt đầu ở đây để thấy giá trị thật và bản lưu đệm, rồi dùng công cụ kiểm tra lan truyền DNS trên trang chủ để xem toàn cảnh.

Tra cứu DNS này có miễn phí không, và các bạn có lưu những gì tôi tra cứu không?

Miễn phí, không cần tài khoản và không có CAPTCHA; để bảo vệ các máy chủ được hỏi, mỗi mạng có thể chạy 20 lượt tra cứu mỗi phút. Tra cứu chạy trên máy chủ của chúng tôi trong mạng Cloudflare, nên nameserver của tên miền thấy địa chỉ của chúng tôi, không phải của bạn. Không lưu đệm gì: mỗi lần tra cứu đều hỏi lại. Chúng tôi không ghi nhật ký ai đã tra cứu gì.

Công cụ DNS khác