【第108期】【免费域名21期】cloudns(be、ch、net后缀)的域名托管到cloudflare后的双向解析!活用泛域名解析!引入代理IP&再次精简DNS记录后,测试优选IP!结果会如何呢?
HTML-код
- Опубликовано: 10 сен 2024
- →★★★本系列持续更新中,敬请关注!★★★
该网站免费域名托管到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域名的习惯!
(★★★免费域名第15期★★★)
cloudflare侧:
*的泛域名解析:保留(指向isp.swing.cloudns.be)
isp.swing.cloudns.be的A记录:保留(随意一个公网IP)
cloudflare侧:
*的泛域名解析:保留(指向isp.swing.cloudns.be)
isp.swing.cloudns.be的两条NS记录:保留(跟cloudflare侧保持一致)
swing.cloudns的两条NS记录:保留(为了托管到cloudflare)
_acme-challenge的两条NS记录:保留(为了激活cloudflare边缘证书)
■Cloudflare代理模式(开启小云朵)下的限制(★★★免费域名第16期★★★)
developers.clo...
解决办法:
1,端口转发到cloudflare允许的指定端口(参照上面的URL)
2,前置代理软件(如traefik)工作在允许的端口(如8443)下,绑定到后台服务(跟办法1类似)
3,两边都添加DNS记录
→如果你不需要cloudflare家的附加服务:
1,小云朵
2,隧道服务
3,worker(page支持CF托管以外的域名)
4,其它
可按正常域名的用法,只在cloudns侧添加记录即可!(★★★免费域名第17期★★★)
(其实之前的场景2,就可以只在cloudns侧添加记录)
■开启小云朵时,直接绑定PING命令显示的代理IP(★★★免费域名第18期★★★)
→代理IP和traefik工作机制的对比,一个巨大版的traefik?(★★★免费域名第19期★★★)
→引入代理IP后再次精简DNS记录(★★★免费域名第20期★★★)
→用优选IP替换cloudflare自动分配的代理IP(★★★本期★★★)
前提:
1,cloudflare帐号
2,cloudns免费域名
3,cloudns免费域名托管到cloudflare,并激活(2条NS记录)
4,cloudflare边缘证书激活 (2条NS记录或TXT记录)
5,下载好优选IP批处理
筛选程序:
gitlab.com/Mis...
■执行优选IP批处理,选1(IPV4):
打开生成的result.csv,找到第一行的优选IP
■修改cloudns侧的*泛解析记录:
主机名:*
指向到:162.159.192.17(优选IP)
等待15分左右,DNS记录生效!
(★★★因为DNS缓存的问题,部分DNS记录还没有生效,我们用另一台PC测试★★★)
■浏览器中验证cloudflare中的DNS记录:(特别是在cloudns侧不存在的DNS记录)
yahoo1.cloudns... (成功)
yahoo2.cloudns... (成功)
yahoo3.cloudns... (成功)
yahoo4.cloudns... (成功)
nps.swing.clou...(成功)※场景1中隧道服务添加的CNAME记录
frp-t.swing.cl... (失败) ※场景2中的的主机名
(★★★在录屏机可以访问,应该是因为DNS缓存的问题★★★)
traefik2.swing.... (失败) ※之前视频演示端口限制添加的记录
(★★★端口转发:gost -L tcp://:8880/:51831★★★)
(★★★演示时协议错误:https。http才是对的!但http其实也访问不了!★★★)
traefik.swing.c... (成功) ※cloudns侧存在的DNS记录
(★★★演示时进行了协议更正:https→http★★★)