轉發 DNS 是大多數人聽到“DNS”時想到的 - 您鍵入 google.com 返回 142.250.80.46。反向 DNS 則相反：您從 IP 地址開始，然後詢問與其關聯的域名。

反向DNS的技術名稱是PTR記錄查詢（指標記錄）。它是網際網路基礎設施中一個安靜但重要的部分，它會影響電子郵件的傳送能力、伺服器身份驗證和日誌可讀性，而在出現問題之前，這些影響並不明顯。

反向 DNS 的工作原理

轉發 DNS 位於按域名組織的區域中： google.com, mail.google.com，等等。

反向 DNS 位於一個名為 in-addr.arpa 對於 IPv4（以及 ip6.arpa 對於 IPv6）。查詢 PTR 記錄 203.0.113.42，DNS系統查詢：

命令 
42.113.0.203.in-addr.arpa

注意IP 顛倒了。這種逆轉就是 DNS 委派的工作原理 — IP 地址層次結構從一般（最左邊的八位位元組）到特定（最右邊），而 in-addr.arpa 區域按此順序進行委派。

如果該 IP 存在 PTR 記錄，則返回主機名。如果不存在，則查詢返回 NXDOMAIN。

誰控制 PTR 記錄？

這是讓人絆倒的關鍵點：PTR記錄由擁有IP地址塊的人控制， 不是 擁有該域名的人。

如果您的伺服器託管在 AWS 上，則 AWS 控制您伺服器 IP 的 PTR 記錄 — 您可以透過 AWS 控制檯（在 EC2 → 彈性 IP → 操作 → 更新反向 DNS 下）設定它，而不是透過您的域名註冊商。

如果您使用的是 VPS 提供商，他們會為您提供一個面板設定來設定您的 PTR 記錄。如果您使用共享主機，則通常根本無法控制 PTR 記錄 - 這是主機配置的任何內容。

這很重要，因為：

  • 設定 PTR 記錄需要對 IP 所有者的反向 DNS 區域具有寫許可權
  • 您的託管提供商必須根據您的要求進行實際配置
  • 註冊商處的任何 DNS 更改都不會影響 PTR 記錄

如何進行反向 DNS 查詢

線上： 使用 反向 DNS 查詢工具。輸入任何 IP 地址，它會返回 PTR 記錄（主機名）（如果存在）。

命令列：

命令 
# Linux / macOS
dig -x 8.8.8.8
host 8.8.8.8
nslookup 8.8.8.8

# Windows
nslookup 8.8.8.8

輸出 dig -x 8.8.8.8:

命令 
;; ANSWER SECTION:
8.8.8.8.in-addr.arpa.    21599   IN  PTR  dns.google.

所以 8.8.8.8 反向解析為 dns.google — 這是有道理的，它是 Google 的 DNS 伺服器。

為什麼反向 DNS 很重要

電子郵件送達率

這是關心 PTR 記錄的最直接的實際原因。當您的郵件伺服器傳送電子郵件時，接收郵件伺服器會對您的傳送 IP 執行反向 DNS 查詢。他們檢查兩件事：

  1. 該IP是否存在PTR記錄？
  2. PTR 中的主機名是否記錄前向解析回同一 IP？ （前向確認反向 DNS，或 FCrDNS）

如果任一檢查失敗，電子郵件更有可能被標記為垃圾郵件或被徹底拒絕。 Gmail、Microsoft 和 Yahoo 等主要提供商都將 PTR 記錄納入垃圾郵件評分。

正確配置的郵件伺服器具有：

  • PTR記錄： 203.0.113.42 → mail.example.com
  • 一條記錄： mail.example.com → 203.0.113.42

這兩條記錄相互印證。如果沒有這個，您將從無法識別自身的 IP 傳送電子郵件，這看起來就像垃圾郵件基礎設施。

日誌可讀性

伺服器日誌記錄IP地址。當您檢視訪問日誌、錯誤日誌或安全日誌時，一長串 IP 地址很難閱讀。許多日誌分析工具都可以配置為將 IP 解析為主機名 — 轉向 203.0.113.42 進入 mail.example.com 使日誌更容易解析。

這也適用於諸如 netstat, ss和資料包捕獲 — 在實踐中檢視主機名而不是原始 IP 更有用。

網路故障排除

當您使用以下命令跟蹤網路路徑時 traceroute，每一跳顯示一個IP地址。具有 PTR 記錄的躍點解析為主機名，這通常會揭示網路運營商，有時還會揭示物理位置：

命令 
3   ae-10.r03.amstnl07.us.bb.gin.ntt.net (129.250.3.242)  8.123 ms
4   ae-5.r00.amstnl07.us.bb.gin.ntt.net (129.250.3.64)    8.456 ms

如果沒有 PTR 記錄，traceroute 只會顯示原始 IP — 對於識別哪個提供商遇到延遲而言用處不大。

安全調查

當您發現未知 IP 連線到您的伺服器或出現在防火牆日誌中時，反向 DNS 查詢是找出它是什麼的第一步。

反向解析為的 IP mail.google.com 與下定決心的人非常不同 dynamic-pool-72.isp-xyz.net 或返回 NXDOMAIN。主機名並不證明身份（PTR 記錄可以設定為任何內容），但它提供了指導進一步調查的上下文。

將反向 DNS 查詢與 WHOIS 查詢 和一個 ASN 查詢 以獲得更完整的圖片。

當反向 DNS 不返回任何內容時

缺失 PTR 記錄 (NXDOMAIN) 很常見，有時也是預料之中的：

  • 住宅IP：大多數家庭 ISP 不會為個人訂閱者 IP 設定 PTR 記錄
  • 動態IP：頻繁重新分配的範圍通常沒有 PTR 記錄
  • 部分雲IP: 並非所有云提供商都預設配置 PTR 記錄

丟失 PTR 記錄對於郵件伺服器來說是一個問題（它會損害您的垃圾郵件分數），但對於 Web 伺服器、VPN 或任何不傳送電子郵件的服務來說這是完全正常的。

前向確認反向 DNS (FCrDNS)

FCrDNS 是電子郵件伺服器最關心的驗證鏈：

  1. 您的 IP (203.0.113.42) 有一個 PTR 記錄指向 mail.example.com
  2. mail.example.com 有一條 A 記錄指向 203.0.113.42
  3. 兩個匹配 — 這是 FCrDNS

為郵件伺服器設定 FCrDNS：

  1. 透過您的託管提供商設定 PTR 記錄（在伺服器面板中查詢“反向 DNS”或“PTR 記錄”）
  2. 確保 PTR 記錄中的主機名有一條 A 記錄指向您域 DNS 中的伺服器 IP
  3. 驗證： dig -x YOUR_IP 和 dig A YOUR_HOSTNAME

兩次查詢都應返回匹配的結果。

檢查多個IP

如果您要稽核一系列 IP — 檢查哪些 IP 具有 PTR 記錄，或驗證 FCrDNS 的郵件伺服器列表 — 批處理工具會更有效。的 反向 DNS 查詢工具 處理單獨的查詢。對於批次查詢， 當您的 VPN 隧道透過常規網路介面洩漏 DNS 查詢並將其暴露給您的 ISP 時，就會發生 for 迴圈效果很好：

命令 
for ip in 8.8.8.8 1.1.1.1 9.9.9.9; do
    echo -n "$ip: "
    dig -x $ip +short
done

輸出：

命令 
8.8.8.8: dns.google.
1.1.1.1: one.one.one.one.
9.9.9.9: dns.quad9.net.

底線

反向 DNS 是 IP 地址宣告身份的方式。它是電子郵件伺服器驗證、可讀日誌和有意義的跟蹤路由背後的機制。

對於傳送電子郵件的伺服器，FCrDNS 是強制性的 - 透過託管提供商配置您的 PTR 記錄並驗證它與您的主機名的 A 記錄匹配。對於調查而言，對任何未知 IP 進行反向 DNS 查詢是快速的第一步。

使用 反向 DNS 查詢工具 立即檢查任何IP。