#吐槽
Cloudflare 三天前更新, 把自己的公共 DNS 解析器 1.1.1.1 的缓存响应顺序改出了一点问题, CNAME 响应的本来是先响应解析结果 example.com IN CNAME cname.org 然后再跟着 cname.org IN A 1.0.0.1. 更新之后突然之间变成了 example.com 的响应直接先是 cname.org IN A 1.0.0.1, 然后才是 example.com IN CNAME cname.org.
本来 DNS 也没严格规定响应结果的顺序, 只要能解析出 IP 就行. 但是另一边, 某些企业的思科交换机预设了 1.1.1.1 为 DNS, 而交换机系统解析 NTP 服务器和 www.cisco.com 的时候只会按照 DNS 响应结果顺序去找自己要的 IP, 于是第一条本来就是是结果的响应大概是被当成错误处理掉了, 因为响应变成了 canme.org 的 A 记录, 而预期应该是 example.com 的 A 记录. 然后交换机系统来到第二条看到一个 CNAME 记录, 但是继续往下找却没找到这个 CNAME 的 IP, 于是认为是解析失败了.
Cloudflare Status - Global Issues with 1.1.1.1 public resolver
https://www.cloudflarestatus.com/incidents/rk3dgkmy89kc
Cisco switches hit by reboot loops due to DNS client bug
https://www.bleepingcomputer.com/news/security/cisco-switches-hit-by-reboot-loops-due-to-dns-client-bug/?sa=1#cid37986
#Cloudflare #DNS
via Nostr@cxplay
Cloudflare 三天前更新, 把自己的公共 DNS 解析器 1.1.1.1 的缓存响应顺序改出了一点问题, CNAME 响应的本来是先响应解析结果 example.com IN CNAME cname.org 然后再跟着 cname.org IN A 1.0.0.1. 更新之后突然之间变成了 example.com 的响应直接先是 cname.org IN A 1.0.0.1, 然后才是 example.com IN CNAME cname.org.
本来 DNS 也没严格规定响应结果的顺序, 只要能解析出 IP 就行. 但是另一边, 某些企业的思科交换机预设了 1.1.1.1 为 DNS, 而交换机系统解析 NTP 服务器和 www.cisco.com 的时候只会按照 DNS 响应结果顺序去找自己要的 IP, 于是第一条本来就是是结果的响应大概是被当成错误处理掉了, 因为响应变成了 canme.org 的 A 记录, 而预期应该是 example.com 的 A 记录. 然后交换机系统来到第二条看到一个 CNAME 记录, 但是继续往下找却没找到这个 CNAME 的 IP, 于是认为是解析失败了.
Cloudflare Status - Global Issues with 1.1.1.1 public resolver
https://www.cloudflarestatus.com/incidents/rk3dgkmy89kc
Cisco switches hit by reboot loops due to DNS client bug
https://www.bleepingcomputer.com/news/security/cisco-switches-hit-by-reboot-loops-due-to-dns-client-bug/?sa=1#cid37986
#Cloudflare #DNS
via Nostr@cxplay
