随着组织的互联网基础设施不断扩展，其对配置、设置和决策的需求也随之增加——从选择一个可靠的名称服务器，到确定合适的 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 进行查询。
