泛域名解析, 又被称作Wildcard DNS Resolution, 这指的是在DNS系统里面, 通过建立一个带有通配符性质的记录, 比如那个被标签包裹好的.example.com前面加点号的写法, 从而使得目标域名下面那些还没有单独进行具体配置的子域名, 全部都统一地被指明去指向同一个IP地址或者是相同的解析目标。
它所具备的核心特点非常明显, 也就是只需要用到一条记录, 就能够把数量上不设上限的子域名情况全部都覆盖住, 这就完全不用去一条条地手动添加了。
工作原理
当用户去访问那个a.example.com这个域名的的时候, 系统里面的DNS解析过程是会遵守一个所谓的最长匹配优先的那个原则的。如果在那个DNS数据库里面找不到这个完全精确的记录的, 那么解析器就会开始往上去进行回溯的一个操作的。
最后一步是会匹配到那个被.example.com给包含进去的这种通配符记录的。一旦匹配成功之后, 它就会把这个记录对应的IP地址或者是CNAME的目标给返回出来。
如果在同一个域名之下, 已经存在一个精确的记录的情况是这样的话, 比如邮件点example点com指向10点0点1点5这样的结果, 那么这个精确的记录总是会比通配符的优先级更高一点, 通配符是不会去覆盖掉它的。
典型应用场景
1. 企业为了给像 shop、blog、api 这样的子域名提供一个统一的访问入口, 会为这些子域名配置泛解析记录, 让它们全部指向同一个入口服务器的 IP 地址。接下来, 系统会在应用层检查 HTTP 请求的 Host 头信息, 然后根据这个信息把流量分发到不同的业务模块进行处理。
2. 对于开发和测试的环境, 我们会给每一个单独的项目去分配一个单独的子域名, 就像dev1.project.com和qa2.project.com这样的例子一样的情况, 这样的话就完全不需要大家再去一条条地添加DNS记录这样比较麻烦的操作了。
3. 我们采用通配符证书的方式, 具体来说就是签发针对.example.com的这样一张通配符证书, 这样做的一个直接结果就是用一次操作, 全面覆盖了所有子域名在HTTPS加密方面的具体需求。
4. 把域名example.com解析到CDN的边缘节点IP上去, 然后这个域名下的所有子域名的流量, 统一走加速网络再回到源站。
配置方法
请你到那个用于管理DNS的网页界面里面去, 进行添加一条记录的操作, 然后具体要填写的那些字段的详细情况, 就是下面这些内容。
记录名（主机名）：\
记录的类型包括A记录, 这个是用来对应IPv4地址的；还有AAAA记录, 这个是跟IPv6相关的；另外也可以是CNAME记录, 这指的是一个域名去指向另一个域名。
记录的数值, 指的是目标的IP地址, 例如203.0.113.10, 或者指的则是目标的域名, 例如cdn.provider.com。
TTL：建议 3600 秒
在保存操作成功生效之后, 所有那些没有被精确记录给覆盖住的内容的子域名, 它们都会自动地去解析到那个被指定的值上面去。
就拿 gname.xin 这个例子来作为示范吧, 它的管理后台这个位置, 提供了一个能够让使用者用可视化的方式来进行配置的一个入口地方, 这个地方支持对像 A、AAAA、CNAME、TXT 这一类非常常见的记录类型进行泛解析上的设置, 其具体的操作流程路径应当选择“域名管理”这个选项, 接着点击其中的“DNS解析”, 然后找到“添加记录”这个按钮, 最后在记录名那一栏里面填写内容, 但是要注意最后的结尾部分显示的是 \这样的代码标识。
注意事项与限制
通配符这条记录它是没办法去覆盖掉那些已经存在的精确规则的记录的, 毕竟, 精确规则本身的优先级它是一直处于更高这个水平的啦。
MX记录这个邮件路由的东西, 它是不支持用通配符的, 所以对于每一个邮件域都得一个一个去具体定义。
有一部分云DNS服务提供商, 他们在通配符记录方面, 是存在着层级或者是数量的限制的, 所以在进行配置操作之前, 你得去查阅一下那些相对应的服务商所提供的技术文档。
如果只需要让少数的几个子域名有效果, 那么建议你直接用那种精确匹配的记录方式, 这样一来呢，就可以避免那些没有需要关系的子域名, 它们被不小心指到了错误的那个地址上面去。
当你修改通配符记录的时候呢, 全球DNS缓存里面的数据刷新需要花一个多少秒的时间, 这个时间是多少完全取决于那个TTL的设定值是什么情况, 所以在比较短的某个时间段之内, 处在不同地理位置的那些用户有可能看到的是不一样的域名解析结果。
精确解析与泛域名解析对比
常见疑问
要问泛解析会不会影响到SEO, 得知道DNS的解析功能本身是不直接决定搜索引擎会不会把你的站点收录进去的。但是呢, 如果出现了大量根本没有实际内容价值的子域名, 结果它们却都被指向到了同一个单独的页面这种情况会发生的话, 就会生成一大堆不被看重的无效URL链接条目了。
所以说咱们最好还是应该去配合使用那个叫做robots.txt的文件来对部分路径进行屏蔽操作, 或者干脆让服务器对于那些不存在的有效性的子域名访问请求直接给出一个返回状态码是404的提示信息这样才行。
这个问题是能否通过一定的手段来把某些特定的子域名排除掉, 从而让它们不加入到泛解析的这个过程之内, 对于这种想法是不能够直接予以排除的, 因为通配符的这个机制本质上体现出来的是一种全有或者全无的特征, 所以如果需要实现将那些需要被排除的子域名单独对待这样的目的的话, 就必须针对这些特定的子域名单独再附加上一条精确对应的记录内容信息, 以此来借助于优先级更高的这个设定去把原先的通配符所设定的规则给覆盖到才行。
很多人会问, 通配符能不能进行嵌套, 比如像是这样写的..example.com这样的形式。
在目前的DNS服务商的情况来看, 绝大多数都不支持那种多级的通配符设置, 仅仅只是支持一级的配置, 像\*.example.com这种模式。如果用户确实需要多级通配符的话, 就必须去依靠CNAME链或者是应用层的逻辑来实现功能了。
