隨著組織的互聯網基礎設施不斷擴展，其對配置、設置和決策的需求也隨之增加——從選擇一個可靠的名稱服務器，到確定合適的 DNS 記錄類型以及設置合適的 TTL（生存時間）值。其中一項關鍵決策就是是否要創建通配符 DNS 記錄，這是一項大多數主機服務商、注冊商和 DNS 提供商都支持的功能。
在本文中，我們將介紹什么是通配符 DNS 記錄、它的作用以及可能存在的風險。
什么是通配符 DNS 記錄？
通配符 DNS 記錄是一種特殊的 DNS 記錄，允許域名管理員將不存在或隨機的子域名指向特定的 IP 地址或其他 DNS 資源數據。舉個例子，如果某人嘗試訪問一個未在域名 DNS 設置中定義的子域名，系統仍會返回響應，而不是報錯——用戶將被引導至通配符 A 記錄中定義的 IP 地址。
簡而言之，通配符 DNS 記錄是一個“兜底”機制，用于自動處理無效的子域名請求。定義通配符域名很簡單，但也有一些規則需要注意：
-
只有一個星號（*）會被視為通配符操作符，DNS 通配符記錄不支持其他字符或表達式。例如，
*.example.com是正確的通配符記錄，而*1.example.com則不是。 -
星號必須出現在域名的最左側標簽中。例如，
*.example.com是正確的，而example.*com則不是。 -
每條記錄只能有一個星號，不能在多層級中使用通配符。例如，
*.*.example.com大多數 DNS 提供商會認為無效。同時，*.example.com無法匹配a.b.example.com，通配符只作用于一個層級。 -
已存在的 DNS 記錄優先于通配符記錄。例如，如果為
blog.example.com設置了具體的 DNS 記錄，即使存在*.example.com通配符記錄，系統也會優先使用指定的記錄。
如何創建通配符 DNS 記錄？
不同 DNS 提供商的具體操作步驟可能略有不同，但大致流程如下：
-
登錄賬戶并進入 DNS 管理控制臺；
-
添加一條新的 DNS 記錄并選擇記錄類型；
-
輸入通配符子域名（如
*.example.com）及其指向的目標地址，可能是 IP 地址、URL 或另一個子域； -
新的 DNS 記錄生效時間可能從幾分鐘到 48 小時不等。
需要注意的是，并非所有類型的 DNS 記錄都支持通配符。A、AAAA 和 TXT 記錄支持得較廣；而 CNAME、ALIAS、URL 重定向、HTTP 重定向和 MX 雖技術上支持，但不常見；NS、SOA 和 PTR 記錄則完全不支持通配符。
通配符 DNS 的常見應用場景
現在你知道如何創建通配符 DNS 記錄了，那么是否有必要使用呢？以下是一些合法且常見的使用場景：
多租戶應用
多租戶軟件中，一個應用實例服務多個客戶，每個客戶有獨立子域名，如 customer1.sampleapp.com、customer2.sampleapp.com 等。
通過使用 *.sampleapp.com 通配符 DNS，應用可統一處理所有子域名，而無需為每一個單獨配置 DNS。
博客平臺
像 WordPress.com 這樣的博客平臺允許用戶創建自定義子域名，如 mydailyblog.wordpress.com。這類平臺通常使用如 *.wordpress.com 的通配符 DNS，使任意子域名自動解析到共享 IP 地址。
DNS 查詢時，通配符記錄會返回相同 IP，服務器通過 HTTP Host 頭（如 mydailyblog.wordpress.com）識別要展示的博客內容，從而實現動態渲染每位用戶的個性化博客。
新頂級域（TLD）的臨時用途
互聯網名稱與數字地址分配機構（ICANN）要求新推出的 gTLD 在上線初期的最少 90 天內返回特殊 DNS 響應，用以管理名稱沖突（Name Collision: ICANN Approves Name Collision Occurrence Management Framework | Special IP Address (127.0.53.53) Alerts System Administrators of Potential Issue），類似通配符機制但不直接使用通配符記錄。
通常情況下，ICANN 禁止注冊局為不存在或未注冊的域名設置通配符 DNS，而是要求返回 NXDOMAIN（域名不存在）。但上述框架是一個例外，用于防止名稱沖突——即內部網絡中使用的域名與公共互聯網上的名稱發生沖突。
為避免此類沖突，可設置一個類似通配符的 A 記錄，指向 127.0.53.53（保留地址），一旦觸發，在日志中警示管理員。
使用通配符 DNS 的風險
通配符 DNS 可以提升用戶體驗，讓用戶訪問未定義子域名時不會報錯，但使用時也需謹慎。總原則是：沒有正當用途就不要用通配符 DNS。 原因包括：
DNS 錯誤風險
在使用通配符 DNS 的網絡環境中可能出現意外流量路由。例如，若某設備名為 computer.example.com，系統可能自動將 example.com 設置為搜索域。此時訪問 www.google.com 失敗時，系統可能會嘗試 www.google.com.example.com，若啟用了通配符記錄，系統將錯誤地解析至內部資源，造成功能異常、流量誤導及難以診斷的錯誤。
子域接管
如果 *.company1.com 通配符記錄將所有子域都指向某云服務資源，而該資源被刪除但記錄未移除，攻擊者可注冊相同資源地址，接管如 login.company1.com 等子域，進而托管惡意內容。
釣魚攻擊
通配符記錄使拼寫錯誤的子域（如 logln.company1.com）依然能解析為真實主頁或默認頁。攻擊者可以用這類看似合法的鏈接誤導用戶點擊，通過后續提示跳轉至真正的釣魚頁面，收集用戶信息。
通配符 DNS 與通配符 SSL 的區別
通配符 DNS 控制子域名的解析，而通配符 SSL 則用于加密多個子域的 HTTPS 連接（如 *.example.com）。雖然便捷，但如果某子域被攻破，攻擊者可利用通配符證書托管惡意內容，仍顯示 HTTPS 小鎖，容易誤導用戶和繞過安全防護。
如何查找通配符 DNS 記錄？
安全專家經常需要識別通配符 DNS 的使用情況，用于攻擊面評估。WhoisXML API 提供多種 DNS 產品，可基于被動 DNS 和實時 DNS 數據判斷記錄是否為通配符。
使用?DNS Chronicle API | WhoisXML API獲取通配符信息
該 API 可查詢域名的歷史 A 和 AAAA 記錄，并返回是否為通配符記錄。例如：
curl --location 'https://dns-history.whoisxmlapi.com/api/v1' \
????????--header 'Content-Type: application/json' \
????????--data '{
????????"apiKey": "<your_API_key>",
? ? ? ? "searchType": "forward",
????????"recordType": "a",
????????"domainName": "0-2nask-us.turbotaxweb.profile.basecamp.app"
????????}' >> dns_chronicle_sample.json
結果中字段 wildcard: true 表示該記錄屬于通配符。如果為 false，則不是；若為 null，說明尚未檢查。
使用 Reverse DNS API 獲取更多信息
此工具可進一步確認某條記錄是否屬于通配符，可查詢 SOA、TXT 或 CNAME 記錄。
curl --location 'https://reverse-dns.whoisxmlapi.com/api/v1' \
????????--header 'Content-Type: application/json' \
????????--data '{
????????"apiKey": "<your_API_key>",
????????"limit": 1000,
????????"includeAdditionalChecks": 1,
????????"recordType": "soa",
????????"terms": [ { "field": "domain", "term": "example.com" } ] }'
總結
通配符 DNS 記錄是一種兜底機制，使對未定義子域的請求仍能指向有效的資源。在多租戶應用、博客平臺以及新 gTLD 初期階段具有實用價值。但大多數系統管理員會避免使用通配符 DNS，因為它可能引起路由錯誤，并可能被濫用用于釣魚或子域接管。
如需確認某域是否使用了通配符 DNS，可使用DNS Chronicle API 或 Reverse DNS API 進行查詢。
