通配符 DNS 记录:应用场景与相关风险
随着组织的互联网基础设施不断扩展,其对配置、设置和决策的需求也随之增加——从选择一个可靠的名称服务器,到确定合适的 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 进行查询。