Công cụ phổ biến

Giao diện

Reverse DNS — Tra Cứu DNS Ngược

Tìm hostname đứng sau mọi địa chỉ IPv4 hoặc IPv6 bằng tra cứu reverse DNS: mọi bản ghi PTR lấy thẳng từ nameserver của chính vùng ngược, từng tên có trỏ ngược về địa chỉ hay không (FCrDNS), ai vận hành vùng, và địa chỉ có đạt các quy tắc của Gmail, Yahoo và Microsoft dành cho máy chủ email không.

Nguồn: nameserver của vùng ngược, lần theo từ một máy chủ gốc · Google Public DNS · Cloudflare 1.1.1.1 · Team Cymru

IPv4 hoặc IPv6 ở mọi cách viết, một hostname (được phân giải trước) hoặc một tên in-addr.arpa.

Thử

Reverse DNS (rDNS) là gì?

Reverse DNS (DNS ngược) chuyển một địa chỉ IP trở lại thành hostname: ngược với tra cứu thông thường (tra cứu xuôi), vốn chuyển tên thành địa chỉ. Câu trả lời là một bản ghi PTR mà bên nắm giữ địa chỉ công bố trong một phần của DNS dành riêng cho địa chỉ.

Tên DNS được đọc từ phải sang trái, nên một địa chỉ được viết ngược để tra cứu: 8.8.8.8 thành 8.8.8.8.in-addr.arpa và 203.0.113.7 thành 7.113.0.203.in-addr.arpa. Khi phần mạng nằm bên phải, mỗi khối địa chỉ có thể được giao cho bên đang nắm giữ nó (RFC 1035 §3.5).

IPv6 dùng ip6.arpa và cả 32 chữ số hex (nibble) của địa chỉ, chữ số cuối cùng trước: :: được khai triển trước khi các chữ số bị đảo ngược, nên 2001:4860:4860::8888 có tên gồm 32 nhãn (RFC 3596 §2.5). Công cụ hiển thị tên sẽ được hỏi ngay dưới ô nhập khi bạn gõ, và viết ra đủ 32 nibble trong đường đi ngược bên cạnh kết quả.

Cấu trúc của một tên ngượcdữ liệu thực 2026-10-23

Địa chỉ IPv4OpenDNS

208.67.222.222222.222.67.208.in-addr.arpa

Tên ngược của nó, được hỏi bản ghi PTRresolver1.opendns.com +3

Octet đảo ngược/8 đứng cuối: 208.in-addr.arpa là vùng của ARIN, 222.67.208.in-addr.arpa là vùng riêng của OpenDNS.
in-addr.arpaCây ngược của IPv4, do IANA quản lý và được phục vụ bởi a đến f.in-addr-servers.arpa.
PTRNhững gì tên này chứa: resolver1.opendns.com và ba hostname khác.

Địa chỉ IPv6, viết đầy đủGoogle

2001:4860:4860:0000:0000:0000:0000:8888

32 nibble, chữ số cuối cùng trước

8888 ở cuối đứng đầu, /32 2001:4860 của Google đứng cuối, và 16 số 0 mà :: che đi được viết ra đủ.

8.8.8.8.in-addr.arpaIPv4: bốn nhãn, đảo ngược
8.8.8.8.0.0.0.0…ip6.arpaIPv6: cả 32 chữ số, đảo ngược
8.8.8.8.0.6.8.4…ip6.arpaĐể :: ở dạng rút gọn: ra tên khác, và NXDOMAIN
8.8.8.8 đọc xuôi hay ngược đều như nhau, nên hình dùng 208.67.222.222, có các octet đổi chỗ rõ ràng. Đường đi ngược của công cụ vẽ cùng phép đảo đó cho mọi địa chỉ IPv4 nó tra cứu.

Cách tra cứu DNS ngược

Nhập một địa chỉ ở trên và nhấn Tra cứu PTR. Công cụ lần từ một máy chủ gốc xuống đến nameserver của chính vùng ngược và hỏi trực tiếp, rồi so sánh với bản sao lưu đệm của Google và Cloudflare. Từ terminal, dig -x 8.8.8.8 trên macOS và Linux, nslookup 8.8.8.8 trên Windows, hoặc host 8.8.8.8 đều làm được việc tương tự.

dig -x tự dựng tên in-addr.arpa hoặc ip6.arpa cho bạn; thêm @ và nameserver của vùng cùng +norecurse (dig -x 8.8.8.8 @ns1.google.com +norecurse) để đọc câu trả lời của chính vùng với TTL đầy đủ thay vì bộ nhớ đệm. Với PowerShell, dạng được Microsoft ghi trong tài liệu truyền vào tên đã đảo ngược: Resolve-DnsName -Name 8.8.8.8.in-addr.arpa -Type PTR.

dig -x 8.8.8.8 +noall +answer

dig tự dựng 8.8.8.8.in-addr.arpa. Con số trước IN là TTL mà bộ phân giải của bạn còn lại.

Đọc câu trả lời của digGoogle Public DNS, rồi máy chủ của chính Google · ghi lại ngày 2026-10-23
bash · zsh
$ dig -x 8.8.8.8 @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24160
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;8.8.8.8.in-addr.arpa.        IN   PTR

;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.  14003  IN   PTR   dns.google.

;; SERVER: 8.8.8.8#53(8.8.8.8)

$ dig -x 8.8.8.8 @ns1.google.com +norecurse
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
8.8.8.8.in-addr.arpa.  86400  IN   PTR   dns.google.
;; SERVER: 216.239.32.10#53(216.239.32.10)
  1. Trạng thái. NOERROR với một câu trả lời. NXDOMAIN nghĩa là chưa đặt PTR; SERVFAIL nghĩa là vùng ngược bị lỗi.
  2. Câu hỏi. dig dựng 8.8.8.8.in-addr.arpa từ địa chỉ và hỏi PTR của nó.
  3. TTL. Còn 14.003 giây trong bộ nhớ đệm của Google. Máy chủ của chính vùng cho TTL đầy đủ 86.400, tức một ngày.
  4. Hostname. Giá trị của PTR. Dấu chấm cuối kết thúc tên.
  5. Ai trả lời. 8.8.8.8, một bộ nhớ đệm. Trong câu trả lời thứ hai, cờ aa đánh dấu máy chủ của chính vùng.
Một PTR, hỏi hai lần: Google Public DNS trả lời từ bộ nhớ đệm, TTL đang đếm ngược; ns1.google.com, được hỏi với +norecurse, trả lời thay mặt vùng với TTL đầy đủ.

Cách đọc kết quả

Phần đầu cho biết trong một câu địa chỉ phân giải ngược thành gì và tên đó có trỏ ngược lại không, kèm TTL của vùng và máy chủ đã trả lời. Các ghi chú tô màu bên dưới cho biết ai có thể đổi tên và điều gì bất thường ở nó.

Chế độ xem PTR liệt kê mọi tên kèm TTL và kiểm tra xuôi; Email chấm điểm theo quy tắc của các bên nhận thư; Ủy quyền hiển thị từng máy chủ đã được hỏi; Bản sao so sánh câu trả lời lưu đệm của Google và Cloudflare; Lệnh đưa ra cùng lần tra cứu cho terminal. Bên phải, đường đi ngược vẽ ra toàn bộ quá trình.

Tra cứu reverse DNS cho 8.8.8.8: bản ghi PTR dns.google từ nameserver của Google, kiểm tra xuôi và đường ủy quyềnTra cứu reverse DNS cho 8.8.8.8: bản ghi PTR dns.google từ nameserver của Google, kiểm tra xuôi và đường ủy quyềnKết luậnĐịa chỉ phân giải ngược thành gì, tên đó có trỏ ngược lại không và ai đặt nó, kèm TTL và máy chủ đã trả lời.Các bản ghi PTRMọi tên mà vùng giữ cho địa chỉ, kèm TTL và các địa chỉ mà tra cứu xuôi của tên trả về.Các chế độ xemQuy tắc email, đường ủy quyền từng chặng, các bản sao lưu đệm với thời gian đếm ngược, và các lệnh.Đường đi ngượcĐịa chỉ được viết ngược thành tên DNS, rồi máy chủ gốc, IANA, cơ quan đăng ký và vùng đã trả lời.
Tra cứu DNS ngược cho 8.8.8.8: kết luận, bản ghi PTR với TTL và kiểm tra xuôi, và đường đi ngược từ gốc đến vùng của Google. Chọn một số để xem từng phần thể hiện điều gì.

Bản ghi PTR là gì?

Bản ghi PTR (pointer, con trỏ), loại DNS số 12, chứa một hostname cho địa chỉ mà nó nằm dưới: 8.8.8.8.in-addr.arpa. 86400 IN PTR dns.google. Đó chỉ là dữ liệu thuần: khác với CNAME, nó không chuyển hướng đi đâu cả (RFC 1035 §3.3.12).

Bên nắm giữ địa chỉ ghi nó, không phải chủ sở hữu của tên bên trong: vùng ngược của Google nói 8.8.8.8 là dns.google, và chỉ bản ghi A trong vùng dns.google mới nói chiều ngược lại. Một địa chỉ có thể mang nhiều bản ghi PTR (RFC 2181 §10.2): 208.67.222.222 có bốn. Tên phải là hostname thật, không bao giờ là bí danh.

PTR chứa một tên và không gì khác: không có chủ sở hữu, quốc gia hay thành phố. Vị trí hiển thị bên cạnh một lần tra cứu đến từ những từ mà đơn vị vận hành đặt vào tên, hoặc từ một cơ sở dữ liệu riêng.

Một tên, hai vùng8.8.8.8 và dns.google, dữ liệu thực 2026-10-23
Vùng xuôicủa tên miền: dns.google
dns.google. A 8.8.8.8dns.google. A 8.8.4.4dns.google. AAAA 2001:4860:4860::8888dns.google. AAAA 2001:4860:4860::8844

Được ns1.zdns.google phục vụ cho bên nắm giữ dns.google

hai vùng, hai nhóm máy chủ
Vùng ngượccủa khối địa chỉ: 8.8.8.0/24
8.8.8.8.in-addr.arpa. PTR dns.google.

ARIN ủy quyền cho Google, được ns1.google.com phục vụ

8.8.8.8.in-addr.arpa.Tên ngược86400TTL · 1 ngàyINLớpPTRLoạidns.google.Hostname
1 địa chỉ, 4 tên208.67.222.222: resolver1.opendns.com và ba tên khác
1 địa chỉ, 48 tên17.253.144.10, địa chỉ của apple.com, mỗi tên có TTL 5 phút
1 tên, 4 địa chỉdns.google: 8.8.8.8, 8.8.4.4 và hai địa chỉ IPv6
PTR cho biết 8.8.8.8 tên là gì; các bản ghi A cho biết dns.google trỏ đến đâu. Google tình cờ vận hành cả hai vùng, trên các máy chủ khác nhau.

DNS ngược được xác nhận chiều xuôi (FCrDNS) là gì?

DNS ngược được xác nhận chiều xuôi nghĩa là tên trong PTR phân giải về lại đúng địa chỉ đó: 8.8.8.8 → dns.google → 8.8.8.8. Máy chủ email gọi bước kiểm tra này là iprev (RFC 8601 §3): tra các tên PTR của địa chỉ, tra bản ghi A hoặc AAAA của từng tên, và đạt khi địa chỉ nằm trong số đó.

Bước thứ hai quan trọng vì bên nắm giữ một địa chỉ có thể ghi bất kỳ tên nào vào PTR của nó, kể cả google.com. Tên chỉ chứng minh được điều gì đó khi chủ sở hữu tên miền trỏ nó ngược lại. Công cụ kiểm tra mọi tên PTR, tối đa mười tên, và vẽ vòng lặp ở bên phải: màu xanh khi vòng khép lại, màu hổ phách khi tên trỏ đi nơi khác.

Khi có nhiều bản ghi PTR, chỉ cần một tên trỏ ngược lại là đủ. Một tên có bản ghi A liệt kê thêm các địa chỉ khác vẫn đạt, miễn là địa chỉ này nằm trong số đó.

Ba địa chỉ, ba vòng lặpdữ liệu thực 2026-10-23
Đã xác nhận chiều xuôiGoogle
8.8.8.8dns.google8.8.8.8: cùng địa chỉ
Trỏ ngược lạidns.google cũng trả về 8.8.4.4
Trỏ đi nơi khácAdGuard
94.140.14.14dns.adguard-dns.com185.113.30.30: địa chỉ khác
Chưa xác nhậnbản ghi A của nó là 185.113.30.30
Không có PTRCloudflare
104.18.0.1NXDOMAIN: không có tên
Không có gì để xác nhậnNXDOMAIN từ vùng của Cloudflare
Cùng vòng lặp đó chạy dọc mép phải của mọi kết quả: xanh khi tên dẫn về lại, hổ phách khi tên dẫn đi nơi khác.

Kiểm tra DNS ngược cho máy chủ email: Gmail, Yahoo và Outlook.com yêu cầu gì

Cả ba đều muốn mọi IP gửi thư có bản ghi PTR. Gmail còn yêu cầu tên đó phân giải về lại đúng IP, và Yahoo yêu cầu "bản ghi DNS xuôi và ngược hợp lệ", cả hai áp dụng cho mọi người gửi từ tháng 2 năm 2024. Chính sách của Outlook.com yêu cầu DNS ngược hợp lệ và không nói gì về bước kiểm tra xuôi.

Một tên chung chung như ec2-3-80-0-1.compute-1.amazonaws.com không vi phạm quy tắc nào: Yahoo chỉ khuyến nghị một tên có ý nghĩa, không chung chung, phản ánh tên miền của bạn. Outlook.com cảnh báo rằng kết nối từ dải IP động có thể không được chấp nhận, điều này nhắm vào tên pool của nhà mạng, không phải tên mặc định tĩnh của máy chủ đám mây. Chế độ xem Email hiển thị những điểm đó là cảnh báo, còn các yêu cầu là đạt hoặc không đạt; một bước kiểm tra chưa hoàn tất thì không thuộc loại nào.

Hai điều không bao giờ là lỗi: nhiều bản ghi PTR, điều RFC 2181 cho phép, và PTR khác với tên HELO của máy chủ: RFC 5321 §4.1.4 nói máy chủ không được từ chối thư vì lý do đó. Gmail giới hạn tốc độ bằng 421 4.7.0 hoặc 451 4.7.23 và chặn bằng 550 5.7.25 khi PTR bị thiếu hoặc không trỏ ngược lại.

Bắt buộc, khuyến nghị, không nêutrang của chính từng bên nhận thư, kiểm tra ngày 2026-10-23
Tiêu chíGmailhướng dẫn cho người gửiYahoo Mailthực hành tốt nhất cho người gửiOutlook.comchính sách postmaster
Có bản ghi PTRbắt buộcbắt buộcbắt buộc
Tên trỏ ngược lạibắt buộcbắt buộckhông nêu
Không chung chung hoặc độngkhông nêukhuyến nghịcó thể từ chối IP động
Bốn máy chủ gửi thực tế, kiểm tra trực tiếp
mail-sor-f41.google.com209.85.220.41 · máy chủ gửi thư của chính Gmailđạtđạtđạt
ec2-3-80-0-1.compute-1.amazonaws.com3.80.0.1 · tên mặc định của AWSđạtđạtcảnh báođạtcảnh báo
dns.adguard-dns.com94.140.14.14 · trỏ đến 185.113.30.30không đạtkhông đạtđạt
Không có PTR104.18.0.1 · NXDOMAINkhông đạtkhông đạtkhông đạt

Phản hồi của Gmail

421 4.7.0 · 451 4.7.23Bị giới hạn tốc độ: không có PTR, hoặc mục xuôi của nó không khớp với IP gửi
550 5.7.25Bị chặn: không có PTR, hoặc mục xuôi không tham chiếu đến IP gửi
550-5.7.1Qua IPv6: thư không đáp ứng hướng dẫn gửi qua IPv6 về bản ghi PTR và xác thực
Chỉ các yêu cầu mới dẫn đến không đạt. Khuyến nghị của Yahoo và cảnh báo về IP động của Outlook.com hiển thị là cảnh báo. Các mã của Gmail lấy từ trang tham chiếu lỗi SMTP của Gmail.

Ai kiểm soát DNS ngược, và cách đặt bản ghi PTR

Bên nắm giữ khối địa chỉ, không bao giờ là chủ sở hữu tên miền. IANA ủy quyền vùng ngược của mỗi khối cho cơ quan đăng ký internet khu vực của nó, và cơ quan đăng ký ủy quyền tiếp cho mạng đang nắm giữ các địa chỉ, nơi tự vận hành vùng hoặc giao tiếp cho bên khác (RFC 3172). Sở hữu example.com không cho phép bạn đặt tên cho một địa chỉ: nhà cung cấp hosting hoặc nhà mạng của bạn mới làm được.

Các nền tảng đám mây cho khách hàng tự đặt, mỗi nơi một quy tắc: AWS cần bản ghi A xuôi trước, Azure chỉ đặt cho IPv4 và không làm trong portal, DigitalOcean tạo PTR từ tên Droplet, Google Cloud yêu cầu bạn chứng minh quyền với tên miền. Với đường truyền gia đình, thường chỉ gói doanh nghiệp có IP tĩnh mới được PTR tùy chỉnh: hãy hỏi nhà mạng. Các khối nhỏ hơn /24 thường được giao tiếp bằng CNAME (RFC 2317), và công cụ lần theo chúng đến bất cứ đâu chúng trỏ tới.

Một thay đổi đến được với mọi người khi các bộ nhớ đệm bỏ câu trả lời cũ: TTL của bản ghi cũ quyết định, hoặc thời gian lưu đệm câu “không có PTR” nếu trước đó chưa có bản ghi (RFC 2308), không phải con số cố định 24 đến 48 giờ. Vultr cho biết thay đổi của chính họ mất 6 đến 12 giờ.

Ai giao vùng xuốngcác lần lần theo được ghi lại, 2026-10-23
  1. in-addr.arpaDo IANA quản lý, được phục vụ bởi a đến f.in-addr-servers.arpa
  2. 8.in-addr.arpa · 208.in-addr.arpaCơ quan đăng ký khu vực của khối: ARIN cho 8.0.0.0/8 và 208.0.0.0/8ARINRIPE NCCAPNICLACNICAFRINIC
  3. 8.8.8.in-addr.arpaBên nắm giữ 8.8.8.0/24: Google ghi PTR, trên ns1 đến ns4.google.com
17.in-addr.arpaMột /8 legacy, được in-addr.arpa ủy quyền thẳng cho các máy chủ riêng của Apple
129.2.0.192.in-addr.arpa CNAME 129.128/26.2.0.192.in-addr.arpaVí dụ của chính RFC 2317: với khối dưới 256 địa chỉ, vùng cha giữ một CNAME trỏ vào vùng do bên nắm giữ khối vận hành. Tên của vùng con chỉ là quy ước.
Mỗi chặng là một tham chiếu ghi lại ngày 2026-10-23, trừ chặng của RFC 2317, vốn là ví dụ của chính RFC trên một khối dành cho tài liệu.
Nơi mỗi nhà cung cấp đặt PTRtài liệu của chính từng nhà cung cấp, kiểm tra ngày 2026-10-23
Nhà cung cấpCách đặtGiới hạn
AWSTài liệuChỉ áp dụng cho Elastic IP. Hãy công bố một bản ghi A cho tên của bạn trỏ đến Elastic IP, rồi vào EC2 console › Elastic IPs › địa chỉ đó › Actions › Update reverse DNS, hoặc dùng aws ec2 modify-address-attribute --allocation-id … --domain-name mail.example.com.Bản ghi A xuôi phải có trước. Khi đang có bản ghi ngược, Elastic IP bị khóa vào tài khoản của bạn. Ở GovCloud (US), chỉ AWS Support mới đặt được. Giới hạn cổng 25 được gỡ bằng một yêu cầu riêng.
Microsoft AzureTài liệuĐặt ReverseFqdn của IP công cộng: az network public-ip update --resource-group RG --name PublicIp --reverse-fqdn mail.example.com. (tên kết thúc bằng dấu chấm), hoặc Set-AzPublicIpAddress trong PowerShell.Chỉ IPv4: địa chỉ IPv6 thuộc Azure không có PTR. Không làm được trong Azure portal. Tên phải phân giải về IP đó hoặc thuộc subscription của bạn. Mỗi địa chỉ một PTR, mặc định không có, và không có cho App Service hay Application Gateway.
Google CloudTài liệuXác minh tên miền trước (Search Console, hoặc một bản ghi A trỏ đến IP ngoài của VM). Sau đó vào VM instances › instance đó › Edit › giao diện mạng chính › Public DNS PTR record, hoặc dùng gcloud compute instances update-access-config INSTANCE --public-ptr --public-ptr-domain mail.example.com.Chỉ giao diện mạng chính; không có PTR cho load balancer hay Cloud NAT. PTR IPv6 cần subnet dual-stack hoặc chỉ IPv6 có IPv6 ngoài. Tên mặc định là <reversed-ip>.bc.googleusercontent.com.
HetznerTài liệuCloud: Hetzner Console › máy chủ (hoặc Primary IP, Floating IP) › Networking › sửa rDNS bên cạnh IP; với IPv6 chỉ nhập phần interface, như ::1. Dedicated: Robot › máy chủ › IPs, ô bên cạnh mỗi IP.Hetzner vận hành vùng ngược. Hetzner chỉ coi một mục rDNS là hợp lệ khi nó phân giải được cả hai chiều (FCrDNS). Mặc định là static.<reversed-ip>.clients.your-server.de.
DigitalOceanTài liệuKhông có trình chỉnh sửa PTR: hãy đặt hoặc đổi tên Droplet thành tên đầy đủ bạn muốn, như mail.example.com, và DigitalOcean tạo PTR từ tên đó.Tên phải là FQDN hợp lệ (my-droplet không tạo ra PTR). Chỉ địa chỉ IPv6 đầu tiên của Droplet có PTR. Không thể tạo PTR thủ công.
OVHcloudTài liệuTrỏ một bản ghi A hoặc AAAA đến IP trước. Sau đó vào Control Panel › Network › Public IP Addresses › nút hành động trên dòng của IP › Configure the reverse DNS (Public Cloud: dự án của bạn › Public IPs).OVHcloud kiểm tra ngay rằng tên trỏ ngược về đúng IP đó, nên bản ghi phải đang hoạt động sẵn. Tên phải viết thường và kết thúc bằng dấu chấm.
VultrTài liệuProducts › Compute › instance đó › Settings › IPv4 hoặc IPv6 › Public Network: nhấp vào tên trong cột Reverse DNS, nhập tên đầy đủ rồi lưu.Vultr yêu cầu tên phân giải về lại đúng IP đó, và cho biết thay đổi mất 6 đến 12 giờ mới hiện ra. Mặc định là <ip>.vultrusercontent.com.
Akamai Cloud (Linode)Tài liệuThêm bản ghi A (và AAAA) trước. Sau đó vào Cloud Manager › Linodes › Linode đó › Network › menu dấu ba chấm của IP › Edit RDNS, rồi nhập tên đầy đủ; để trống ô sẽ đặt lại tên mặc định.Báo lỗi cho đến khi bản ghi A khớp với IP. Dải IPv6: Edit rDNS trên dải, rồi trên từng địa chỉ. Mặc định: <ip-with-dashes>.ip.linodeusercontent.com, trước đây là li<n>-<n>.members.linode.com.
Oracle CloudTài liệuTạo bản ghi A hoặc AAAA trước, rồi mở một yêu cầu hỗ trợ (service request) kèm IP, tên bạn muốn đặt trong PTR và tên của bản ghi xuôi; Oracle kiểm tra rồi tạo PTR.Mỗi IP một PTR, chỉ qua yêu cầu hỗ trợ; bản ghi xuôi phải phân giải về IP đó.
Nhà mạng của bạnRFC 8501Hãy hỏi nhà mạng của bạn: chỉ nhà mạng, bên nắm giữ địa chỉ, mới đặt được PTR của nó. Trên thực tế, điều đó cần IP tĩnh trên gói doanh nghiệp.Đường truyền gia đình giữ tên pool của nhà mạng, và các bên nhận thư như Comcast coi những tên đó là IP động và từ chối thư gửi trực tiếp từ chúng.
Thay đổi mất bao lâu: cho đến khi bộ nhớ đệm bỏ PTR cũ (theo TTL của nó) hoặc câu trả lời “không có PTR” đã lưu đệm (RFC 2308). TTL thực tế: 1 ngày cho 8.8.8.8, 7 ngày cho resolver1.opendns.com, 5 phút cho tên mặc định của EC2.

Vì sao phần lớn địa chỉ IPv6 không có bản ghi PTR

Vì có quá nhiều địa chỉ để đặt tên từng cái một. Nhà mạng có thể điền sẵn PTR cho mọi địa chỉ IPv4 họ cấp, nhưng chỉ một /48 đã chứa 2⁸⁰ địa chỉ, và thiết bị tự chọn địa chỉ của mình, thường chỉ dùng trong thời gian ngắn (RFC 8501).

RFC 8501 liệt kê các lựa chọn của nhà mạng: trả lời NXDOMAIN (không có PTR, chính xác nhất), một PTR wildcard cho tiền tố của mỗi khách hàng, DNS động, ủy quyền vùng cho khách hàng, hoặc tạo PTR và AAAA khớp nhau ngay khi được hỏi. Chỉ wildcard làm hỏng bước kiểm tra xuôi; với người dùng gia đình, một NXDOMAIN rõ ràng là ổn, còn hết thời gian chờ thì không.

Máy chủ gửi thư qua IPv6 vẫn cần PTR được xác nhận chiều xuôi: Gmail từ chối thư IPv6 không có PTR như vậy với 550-5.7.1 Message does not meet IPv6 sending guidelines regarding PTR records and authentication. Azure không cấp PTR nào cho địa chỉ IPv6 của chính mình.

Mỗi địa chỉ một PTR, ở quy mô IPv4 và IPv6RFC 8501
/24một khối IPv428 = 256
/64một subnet IPv6264 = 18.446.744.073.709.551.616
/48một site IPv6280 = 1.208.925.819.614.629.174.706.176

Độ dài thanh: số bit của không gian địa chỉ. Mỗi bit nhân đôi số lượng.

Với tốc độ 1.000 bản ghi PTR mỗi giây, sau 38 nghìn tỷ năm một /48 vẫn chưa xong (RFC 8501).

Các lựa chọn của nhà mạng theo RFC 8501

NXDOMAINkhông có tênHoàn toàn không có PTR: câu trả lời chính xác nhất, nhưng máy chủ email nhiều khả năng từ chối những người gửi như vậy.
Wildcardkhông khớpMột tên cho cả tiền tố: tra cứu xuôi của nó không thể dẫn về từng địa chỉ.
DNS độngkhớpMỗi host tự gửi cập nhật AAAA và PTR của mình khi địa chỉ đã được đặt.
Ủy quyền vùngtùy khách hàngKhách hàng chạy máy chủ DNS được nhận vùng ngược của tiền tố mình; phần lớn hộ gia đình không làm được.
Tạo khi được hỏikhớpMáy chủ tạo PTR khi được hỏi, kèm AAAA khớp với nó.

Máy chủ email vẫn cần PTR riêng, được xác nhận chiều xuôi:2001:4860:4860::8888 → dns.google → 2001:4860:4860::8888

Cách xác minh Googlebot và các crawler khác

Tra ngược địa chỉ của khách truy cập, kiểm tra tên PTR có kết thúc bằng tên miền mà crawler đó công bố không, rồi tra xuôi tên đó và xác nhận nó trả về đúng địa chỉ: 66.249.66.1 → crawl-66-249-66-1.googlebot.com → 66.249.66.1. Hoặc đối chiếu địa chỉ với danh sách do bên vận hành công bố (phương pháp của Google).

Các tên miền được công bố: googlebot.com và google.com cho Google, search.msn.com cho Bingbot, applebot.apple.com cho Applebot, yandex.ru, yandex.net và yandex.com cho Yandex. DuckDuckBot chỉ công bố danh sách địa chỉ.

googleusercontent.com tự nó không chứng minh được gì: mọi VM Google Compute Engine đều mặc định nhận một tên dưới tên miền này, nên công cụ chỉ tính là Google khi địa chỉ có trong danh sách Google công bố. Một tên có đuôi đúng nhưng không trỏ ngược lại là giả mạo, và công cụ nói rõ điều đó.

Hai lần tra cứu quyết định66.249.66.1, dữ liệu thực 2026-10-23
  1. Tra cứu ngượcPTR của địa chỉ đang truy cập.66.249.66.1 → crawl-66-249-66-1.googlebot.com
  2. Tên miền của Google?Nó kết thúc bằng googlebot.com. Một tên googleusercontent.com còn cần địa chỉ nằm trong danh sách của Google.
  3. Tra cứu xuôicrawl-66-249-66-1.googlebot.com → 66.249.66.1Cùng địa chỉ: đúng là Googlebot.
Giả mạo: “Googlebot” trong user agent, từ 203.0.113.9Tra cứu ngược của nó trả lời NXDOMAIN, nên việc kiểm tra dừng ở bước 1. (Một địa chỉ dành cho tài liệu, RFC 5737.)
CrawlerTên PTR kết thúc bằngDanh sách IP công bố
GooglebotPTR và tra cứu xuôi, hoặc danh sáchgooglebot.comcommon-crawlers.json
Trình thu thập dữ liệu trường hợp đặc biệt của GooglePTR và tra cứu xuôi, hoặc danh sáchrate-limited-proxy-….google.comspecial-crawlers.json
Trình tìm nạp do người dùng kích hoạt của GooglePTR và tra cứu xuôi, hoặc danh sáchgoogle-proxy-….google.com….gae.googleusercontent.comchỉ khi có danh sáchuser-triggered-fetchers-google.jsonuser-triggered-fetchers.jsonuser-triggered-agents.json
BingbotPTR và tra cứu xuôi, hoặc danh sáchsearch.msn.combingbot.json
ApplebotPTR và tra cứu xuôi, hoặc danh sáchapplebot.apple.comapplebot.json
YandexBotPTR và tra cứu xuôiyandex.ruyandex.netyandex.comkhông có
DuckDuckBotChỉ danh sách IPkhông códuckduckbot.json

Thực tế hôm nay, mỗi tên đều trỏ ngược lại:crawl-66-249-66-1.googlebot.commsnbot-157-55-39-1.search.msn.com17-58-101-179.applebot.apple.com

Tên miền và danh sách lấy từ trang của chính từng bên vận hành, kiểm tra ngày 2026-10-23. Bing yêu cầu làm mới danh sách của mình hằng ngày.

Giải thích các lỗi DNS ngược

NXDOMAIN nghĩa là tên ngược không tồn tại: chưa ai đặt PTR cho địa chỉ. NOERROR không có câu trả lời (NODATA) nghĩa là tên tồn tại nhưng không chứa PTR. Bộ phân giải giữ cả hai câu trả lời này trong thời gian lưu đệm phủ định lấy từ SOA của vùng (RFC 2308), nên PTR mới có thể mất chừng ấy thời gian mới hiện ra.

SERVFAIL nghĩa là vùng bị lỗi, thường gặp nhất là ủy quyền hỏng (lame delegation): các máy chủ được chỉ định cho vùng lại không phục vụ nó, và mọi bộ phân giải đều bỏ cuộc. REFUSED đến từ một máy chủ hoàn toàn không chịu trả lời cho vùng. Địa chỉ private và địa chỉ dành cho tài liệu không bao giờ có PTR công khai: công cụ trả lời chúng từ sổ đăng ký của IANA mà không hỏi ai cả.

Mỗi câu trả lời, một ví dụ thậtdữ liệu thực 2026-10-23
NOERROR8.8.8.8Có tên: PTR trả về kèm TTL.PTR dns.google. · TTL 86400ns1.google.com · aa
NXDOMAIN104.18.0.1Không có tên này: vùng của Cloudflare không chứa PTR cho nó, và nói rõ như vậy.SOA 18.104.in-addr.arpacruz.ns.cloudflare.com … 3600
NODATANOERROR, 0 answers2001:4860:4860::/48Tên tồn tại, nhưng không có PTR: tên của /48 của Google, có các tên khác bên dưới.0.6.8.4.0.6.8.4.1.0.0.2.ip6.arpaSOA ns1.google.com … 60
SERVFAIL203.0.113.50giả định, địa chỉ dành cho tài liệuỦy quyền hỏng: cơ quan đăng ký chỉ định hai máy chủ không phục vụ vùng, nên bộ phân giải bỏ cuộc.APNIC → ns1, ns2.example.net: lameEDE 22: No Reachable Authority
NXDOMAINAS112192.168.1.1Một địa chỉ private: cây công khai giao 168.192.in-addr.arpa cho các máy chủ AS112 của IANA, nơi trả lời NXDOMAIN.blackhole-1.iana.orgSOA prisoner.iana.org … 604800
Câu “không” được lưu đệm trong thời gian phủ định của SOA (RFC 2308): 1 giờ ở Cloudflare, 60 giây ở Google, 7 ngày từ AS112.

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

Tra cứu DNS ngược (reverse DNS lookup) là gì?

Tra cứu DNS ngược tìm hostname đứng sau một địa chỉ IP bằng cách đọc bản ghi PTR của nó, ngược với tra cứu thông thường vốn chuyển tên thành địa chỉ. Địa chỉ được viết ngược thành một tên đặc biệt, như 8.8.8.8.in-addr.arpa, rồi được hỏi tại các nameserver giữ tên đó. Với 8.8.8.8, câu trả lời là dns.google. Công cụ này còn kiểm tra tên đó có trỏ ngược lại không.

Làm sao kiểm tra bản ghi PTR bằng dig hoặc nslookup?

Chạy dig -x 8.8.8.8 trên macOS hoặc Linux: dig tự đảo ngược địa chỉ và PTR xuất hiện trong phần answer. Trên Windows, nslookup 8.8.8.8 in nó trên dòng Name:. Để bỏ qua mọi bộ nhớ đệm, hãy hỏi nameserver của chính vùng: dig -x 8.8.8.8 @ns1.google.com +norecurse. Chế độ xem Lệnh ở đây điền sẵn từng lệnh với địa chỉ của bạn và máy chủ của vùng chứa nó.

Vì sao địa chỉ IP của tôi không có DNS ngược?

Vì chưa ai đặt bản ghi PTR cho nó. Chỉ bên nắm giữ khối địa chỉ mới đặt được, nên câu trả lời là NXDOMAIN cho đến khi nhà cung cấp hosting hoặc nhà mạng của bạn thêm một bản ghi. Phần lớn kết nối gia đình và phần lớn địa chỉ IPv6 không có. Nếu tra cứu hiển thị SERVFAIL, thì chính vùng ngược bị lỗi, thường là ủy quyền hỏng mà nhà cung cấp phải sửa.

Làm sao thiết lập hoặc thay đổi bản ghi PTR?

Tại nơi đã cấp địa chỉ cho bạn. Trên AWS, hãy công bố bản ghi A xuôi trước, rồi cập nhật reverse DNS của Elastic IP. Azure đặt ReverseFqdn trên IP công cộng, DigitalOcean dùng tên của Droplet, còn Hetzner, OVHcloud, Vultr và Linode có ô rDNS bên cạnh mỗi địa chỉ. Với đường truyền gia đình hoặc văn phòng, hãy hỏi nhà mạng: thường chỉ gói doanh nghiệp có IP tĩnh mới đủ điều kiện.

Thay đổi bản ghi PTR mất bao lâu?

Bằng thời gian bộ nhớ đệm còn giữ câu trả lời cũ. Mỗi bộ phân giải có thể tiếp tục trả về PTR cũ cho đến khi TTL của nó hết, thường từ một giờ đến một ngày, hoặc trả về câu “không có PTR” đã lưu đệm trong thời gian lưu đệm phủ định của vùng. Không có con số cố định 24 đến 48 giờ. Chế độ xem Bản sao cho biết bản sao của Google và Cloudflare còn bao lâu.

Một địa chỉ IP có thể có nhiều bản ghi PTR không?

Có. DNS cho phép nhiều bản ghi PTR cho một địa chỉ, và RFC 2181 nói không nên giả định có giới hạn nào: 208.67.222.222 có bốn. Kiểm tra email đạt khi bất kỳ tên nào trỏ ngược về địa chỉ. Một số công cụ chỉ đọc tên đầu tiên, nên tên bạn dùng cho email phải được xác nhận chiều xuôi. Một PTR là thiết lập đơn giản nhất, không phải yêu cầu bắt buộc.

FCrDNS là gì?

FCrDNS (forward-confirmed reverse DNS) là DNS ngược được xác nhận chiều xuôi: tên trong PTR, khi tra xuôi, trả về đúng địa chỉ đó. 8.8.8.8 phân giải ngược thành dns.google, và dns.google phân giải thành 8.8.8.8, nên nó đạt. Máy chủ email gọi bước kiểm tra này là iprev. Điều này quan trọng vì bất kỳ ai nắm giữ một địa chỉ đều có thể ghi bất kỳ tên nào vào PTR của nó; chỉ tra cứu xuôi mới cho thấy chủ sở hữu tên miền đồng ý.

Gửi email có cần DNS ngược không?

Có, với mọi máy chủ gửi thư trực tiếp. Gmail yêu cầu mọi IP gửi thư có PTR phân giải về lại chính nó, Yahoo yêu cầu DNS xuôi và ngược hợp lệ, và Outlook.com yêu cầu DNS ngược hợp lệ. Thiếu nó, thư bị giới hạn tốc độ hoặc bị từ chối, ví dụ với mã 550 5.7.25 của Gmail. Một tên chung chung của nhà cung cấp vẫn đạt các quy tắc nhưng bị cảnh báo.

Thông báo "reverse DNS is not a valid hostname" nghĩa là gì?

Các công cụ kiểm tra máy chủ email in thông báo này khi tên PTR của IP gửi thư không dùng được làm hostname cho IP đó: thường gặp nhất là hoàn toàn không có PTR, hoặc tên không có bản ghi A trỏ về đúng địa chỉ. Hãy tra cứu IP gửi thư ở đây: chế độ xem PTR hiển thị tên và kiểm tra xuôi của nó, còn chế độ xem Email nêu rõ quy tắc bị vi phạm.

DNS ngược có giống tra cứu reverse IP không?

Không. DNS ngược đọc một hoặc nhiều tên mà bên nắm giữ địa chỉ công bố trong bản ghi PTR. Tra cứu reverse IP cố liệt kê mọi website được host trên một địa chỉ, việc này cần dữ liệu passive DNS thu thập từ nhiều bộ phân giải theo thời gian. Nhiều trang dùng lẫn lộn hai thuật ngữ này. Trang IP Sang Hostname của chúng tôi giải thích mỗi phương pháp tìm được gì.

DNS ngược có hoạt động với IPv6 không?

Có. Địa chỉ IPv6 được tra cứu dưới ip6.arpa với cả 32 chữ số hex đảo ngược, nên 2001:4860:4860::8888 cho ra một tên gồm 32 nhãn mà công cụ này tự dựng và hỏi giúp bạn. Phần lớn địa chỉ IPv6 không có PTR, vì nhà mạng không thể điền sẵn tên cho quá nhiều địa chỉ như vậy, nhưng máy chủ gửi thư qua IPv6 thì cần có.

Vì sao địa chỉ IP private không có PTR?

Địa chỉ private như 192.168.1.1 hay 10.0.0.1 được dùng cùng lúc bên trong rất nhiều mạng, nên DNS công khai không thể đặt tên cho chúng. Tra cứu ngược của chúng thuộc về bộ phân giải của chính mạng bạn; những truy vấn bị rò ra ngoài dừng ở các máy chủ AS112, nơi trả lời rằng không có tên như vậy. Công cụ giải thích từng dải dùng cho mục đích đặc biệt kèm RFC mà không hỏi ai cả.

Các công cụ DNS, IP và email khác