概述

在进行 DNS 设置的时候，我们通常都是指定一个域名的名字，然后配置 CNAME 或者 A/AAAA 记录，但是，最近因为工作的原因，我发现了两个特殊的用法，分别是：

• 域名后面加了个 .
• 域名是通配符

域名后面加点

用过 K8S 的应该都知道，我们可以直接通过 Service 的名字直接解析出这个 Service 的 IP，然后进行访问，但是，实际上，在 Pod 的 DNS 配置中我们可以看到：

[root@liqiang.io]# cat /etc/resolve.conf
nameserver 10.32.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

我们可以看到 search 的配置项，这里的意思就是如果我们访问一个名字（例如：envoy-proxy）的时候，如果需要 DNS 解析，那么它会尝试以下域名，直到找到有效的记录为止：

• envoy-proxy.default.svc.cluster.local
• envoy-proxy.svc.cluster.local
• envoy-proxy.cluster.local
• envoy-proxy

那么如果我们如果不希望 DNS 进行这样的顺序匹配，那么就可以尝试在域名后面加 . 的方式，告诉 DNS 解析器这已经是一个据对的 FQDN 了，不用给我拼接后缀了：

[root@liqiang.io]# curl envoy-proxy.

这样就可以避免遇到异常解析域名的问题。

通配符

除了绝对 FQDN 之外，有时我们可能会有需求就是对于同一个一级域名下的子域名都解析同一个 DNS 记录，例如在一些场景下会很常用，比如 S3 服务这种，不同的 bucket 可能最终解析到的 DNS 记录都是同一条：

• abc.s3.aws.com
• cba.s3.aws.com

还有，例如 FaaS 这种服务，可能也是有相同的需求，于是 DNS 支持通配符就很有意义了。在 RFC 1034 中介绍了 DNS 的基础概念，里面就包括了通配符的初始定义。它指出通配符可以用于匹配多个域名，但有特定的使用规则。RFC 4592 这份 RFC 更深入地探讨了通配符在 DNS 中的作用，特别是在复杂的域名结构中通配符的行为和限制。

这里归纳总结起来就是：

• * 比如是独占的，不能和其他子串复用，例如 abc*.google.com 和 *abc.google.com都是不合法的，只能是 *.google.com;
• * 只能匹配一层的域名，例如 *.google.com 只能匹配 a.google.com 和 b.google.com 这种，但是，不能匹配 a.b.google.com

小结

Ok，这就是关于域名和 DNS 解析的一点小知识，如果不是在工作中需要用到还真不知道需要这么搞，所以这里也简单小结一下做个笔记。