【第102期】【免费域名15期】cloudns（be、ch、net后缀）的域名托管到cloudflare后的双向解析！活用泛域名解析，精简DNS记录，忘记场景1，2，符合平常添加cf域名的习惯！

★★★本系列持续更新中，敬请关注！★★★

该网站免费域名托管到cloudflare后需要双向解析！活用泛域名解析，可以避免在cloudns里添加太多DNS记录！主要适用于以下场景：

该网站免费域名托管到cloudflare后需要双向解析！活用泛域名解析，可以避免在cloudns里添加太多DNS记录！主要适用于以下场景：
1，域名绑定cloudflared tunnel：
添加一条隧道服务产生一条CNAME记录，泛域名解析到该CNAME记录！之后在cloudns侧加入双向解析的3条DNS记录！每添加一条隧道服务，都会在cloudflare侧自动生成一个CNAME记录，cloudns侧DNS记录不变！（★★★免费域名第9期★★★）

2，域名绑定云服务器等公网IP：（VPS侧有traefik的SNI服务）
添加一条A记录，指向VPS，泛域名解析到该A记录！之后在cloudns侧加入双向解析的3条DNS记录！随着VPS侧traefik的SNI服务的增加，cloudflare和cloudns的DNS记录不变！
（★★★免费域名第10期★★★）

→前两期视频做完后，因为场景1的*记录在场景2被修改（tunnel.swing.cloudns.be→isp.swing.cloudns.be），原以为修改后只有场景2的域名可访问，事后发现场景1，2出现的域名都能访问到！（★★★免费域名第11期★★★）

以前x10的免费域名时，两个场景是用了不同的域名后缀：
场景1：x10.mx
场景2：x10.elementfx
故而没有发现这个问题！而cloudns一个免费帐号目前只允许最多一个免费域名，是用一个域名做的两种场景展示，发现了这个现象！

另外，场景1中隧道中定义的几个服务与traefik中同名：
1，tunnel.swing.cloudns.be
2，nps.swing.cloudns.be
3，wg.swing.cloudns.be
→1，3实际上与traefik中并不是同一个服务！因为同名的问题，影响了cloudflare的域名解析，导致访问traefik的gost-tunnel服务时，走了隧道的CNAME记录，意外访问了隧道的tunnel（openwrt服务）！

为了消除上述同名引起的现象，特将traefik中的几个服务重新命名，加上-t便于区分，有助于后续的原因分析！（★★★免费域名第12期）
1，tunnel-t.swing.cloudns.be
2，nps-t.swing.cloudns.be
3，wg-t.swing.cloudns.be
4，frp-t.swing.cloudns.be

原因分析：（★★★免费域名第13期★★★）

■场景1的隧道服务tunnel.swing.cloudns.be可以访问，容易理解：
两边都添加了tunnel的DNS记录！
（cloudns侧：两条tunnel的NS记录，cloudflare侧：一条CNAME记录）

■场景2的frp-t.swing.cloudns.be等4条记录可以访问，也容易理解：
(以frp-t.swing.cloudns.be为例）
1，frp-t.swing.cloudns.be匹配了cloudns侧*绑定的isp.swing.cloudns.be（2条NS记录）
2，cloudflare侧isp.swing.cloudns.be是一条A记录，指向VPS

■场景1的隧道服务nps.swing.cloudns.be、wg.swing.cloudns.be：
1，匹配了cloudns侧*绑定的isp.swing.cloudns.be（2条NS记录）
2，再来到cloudflare侧找时，因为nps和*的CNAME记录同时存在，优先匹配nps记录

估计很多观众与我有过类似经历：
申请了可以托管到cloudflare上的二级域名，兴奋冲冲地托管到cloudflare上添加了DNS记录，结果发现解析不了，上网一查发现要双向解析！在域名原申请网站也添加DNS记录后才解析生效！
→由此可见，这种域名在解析时是有一个先后顺序的，先看原申请网站的DNS记录，后看cloudflare侧的DNS记录！

所以，场景1的nps.swing.cloudns.be：
1，先看cloudns侧，因为没有nps的DNS记录，匹配了*泛域名解析，找到了isp.swing.cloudns.be的NS记录，指向cloudflare！
2，因为cloudflare侧存在一条nps的CNAME记录，相比*指向的A记录（isp.swing.cloudns.be），优先匹配！也就是说在cloudflare侧，找不到nps.swing.cloudns.be的时候，才会匹配*泛域名解析！

→故而，我们访问到了场景1的nps.swing.cloudns.be指向的隧道服务！（CNAME记录）
虽然它在cloudns侧没有定义，匹配了cloudns*泛域名解析的isp.swing.cloudns.be指向的A记录！

■结论：
1，匹配*的泛域名解析之前，如果该域名存在，优先匹配！
2，cloudns和cloudlare侧的DNS记录可以有差别！
→基于以上结论，在cloudflare侧做点小动作：（★★★免费域名第14期★★★）

以上小动作有如下好处：
1，通过泛域名解析，我们不需要在cloudns测不停添加DNS记录！
2，突破50条记录的限制。之后只在cloudflare侧添加！即使超过50条，理论上应该也没有问题！

■DNS记录精简：
关于场景1的隧道服务，场景2的SNI多域名指向同一个IP的用法，许多人可能并不需要，我们对DNS记录作一下精简，以符合平常添加cf域名的习惯！（★★★本期★★★）

前提：
1，cloudflare帐号
2，cloudns免费域名
3，cloudns免费域名托管到cloudflare，并激活（2条NS记录）
4，cloudflare边缘证书激活 （2条NS记录或TXT记录）

cloudflare侧：

1，删除隧道服务：
tunnel.swing.cloudns.be
nps.swing.cloudns.be
wg.swing.cloudns.be

查看DNS记录，确认以上三个隧道服务对应的CNAME记录是否已经自动删除！

2，手动修改isp的A记录：
名称：isp（根据需要换成自己的域名）
内容：8.8.8.8（随意一个公网IP）

保留*的泛域名解析，仍然指向上述A记录：isp.swing.cloudns.be

cloudns侧：

1，删除tunnel.swing.cloudns.be的两条NS记录
（因为cloudflare侧该隧道服务已删除）

isp.swing.cloudns.be的两条NS记录：保留（跟cloudflare侧保持一致）
swing.cloudns的两条NS记录：保留（为了托管到cloudflare）
_acme-challenge的两条NS记录：保留（为了激活cloudflare边缘证书）

■浏览器中验证：yahoo1，yahoo2
https://yahoo1.swing.cloudns.be（成功）
https://yahoo2.swing.cloudns.be（成功）
（可访问，只是不用www.yahoo.co.jp域名访问时，会显示不存在的错误提示，不显示网站首页！）

■在cloudflare侧添加两条CNAME记录：
名称：yahoo3
内容：www.yahoo.co.jp
代理：开启小云朵

名称：yahoo4
内容：www.yahoo.co.jp
代理：关闭小云朵（仅DNS解析）

■浏览器中验证yahoo3，yahoo4：
https://yahoo3.swing.cloudns.be（成功）
https://yahoo4.swing.cloudns.be（成功）
（可访问，只是不用www.yahoo.co.jp域名访问时，会显示不存在的错误提示，不显示网站首页！）

★★★结论：在cloudflare侧，加入cloudns侧没有的CNAME记录，不管有没有启用小云朵，都可以访问到CNAME记录指向的域名！★★★

■浏览器中再次验证：yahoo1，yahoo2
https://yahoo1.swing.cloudns.be（成功）
https://yahoo2.swing.cloudns.be（成功）
（可访问，只是不用www.yahoo.co.jp域名访问时，会显示不存在的错误提示，不显示网站首页！）

■ping命令验证：
ping yahoo3.swing.cloudns.be
→正在 Ping isp.swing.cloudns.be [172.67.193.181] 具有 32 字节的数据:

ping yahoo4.swing.cloudns.be
→正在 Ping isp.swing.cloudns.be [104.21.12.60] 具有 32 字节的数据:

显示走了cloudns侧*绑定的isp.swing.cloudns.be（NS记录）！后面cloudflare解析时，因为已经存在yahoo3，yahoo4，故而优先匹配了yahoo3，yahoo4的CNAME记录！