通常，我们针对域名管理，以及其下NGINX配置文件的管理，大多都是分散的，这种分散并不是刻意为之，而是随着业务发展以及需求的对接，不知不觉中，发现域名加了一个又一个，配置文件更是各不相同，这对标准化而言是个灾难，对未来的操作更是注入了不稳定因素。

所谓天下大势，分分合合。

形如hosts到dns，jenkinsfile到share library，我统一把这种思路归到初中时的一个数学思路：提取公因式。

那么对于域名解析方面的实践，这里要介绍的，其实也是一次提取公因式。

1，CNAME

1，分析

通过CNAME的方式，我们能够轻松的将一些相对集中的域名进行更加优雅统一的管理，这种方案的思路大概如下：

假如我们的测试环境所有的域名有一个统一的入口NGINX，此后所有的测试域名都在这里解析，如果按照传统的思路，那么一个域名对应一条A记录，那么如果测试环境有100个域名，就会需要添加100个A记录，这看起来似乎也没什么问题，但是，如果这个时候因为一些原因，此入口NGINX需要迁移，或者外网IP不得不更换，此时即便是有工具能够批量修改100个A记录，也是一个不够优雅便捷的方案。

我们稍微调整一下方案：解析一个统一的A记录在入口处，然后其他域名都通过CNAME的方式解析到统一的A记录上，这样一来，就算是测试入口需要变更，也只需要更改一条记录即可解决此问题，而不需要考虑那100个了。

2，示例

此时我拿个人域名eryajf.net举例，当前wiki站点域名解析如下：

$ dig wiki.eryajf.net

; <<>> DiG 9.10.6 <<>> wiki.eryajf.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15687
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;wiki.eryajf.net.		IN	A

;; ANSWER SECTION:
wiki.eryajf.net.	599	IN	A	8.136.215.57

;; Query time: 253 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jun 22 23:24:33 CST 2021
;; MSG SIZE  rcvd: 60

可以看到是直接A记录解析到 8.136.215.57。

现在，我在DNS解析中做一些调整：

• 先加一条A记录 prod.eryajf.net:

  

• 然后添加一条CNAME记录作为正常的服务域名 wiki.eryajf.net:

  

这个时候我们可以将域名CNAME到上边定义的A记录，那么就能把100个域名进行统一解析管理了。

注意：CNAME记录值中域名最后位的点可带可不带。

此时该域名的解析链路如下：

$ dig wiki.eryajf.net

; <<>> DiG 9.10.6 <<>> wiki.eryajf.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40403
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;wiki.eryajf.net.		IN	A

;; ANSWER SECTION:
wiki.eryajf.net.	599	IN	CNAME	prod.eryajf.net.
prod.eryajf.net.	599	IN	A	8.136.215.57

;; Query time: 440 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Jun 22 23:33:39 CST 2021
;; MSG SIZE  rcvd: 79

其中的 ANSWER SECTION很清晰地列出了整个链路解析流程。