许多网站使用来自 CDN 的 DNS 服务器（例如 Cloudflare），这些服务器通过反向代理隐藏其原始 IP。在这些情况下，DNS 缓存服务器如何工作？因为许多网站可以显示使用相同的 IP 地址（Cloudflare 的 IP 地址），所以我认为这会导致 DNS 缓存服务的客户端/用户出现许多错误，例如 Windows 操作系统中的错误。
答案1
对于既是 CDN 又是权威 DNS 服务器的 Cloudflare，Windows 内置的 DNS 缓存服务或其他缓存服务器软件如何知道哪个 IP 地址属于哪个域？
他们不需要知道这一点。所有 DNS 缓存，就像 DNS 本身一样，只映射域名到值（“A”记录）——永远不会反过来。
例如，如果 DNS 缓存软件记得 1.2.3.4 指向 facebook.com，并且该 IP 指向 google.com、bing.com 等，则缓存毫无用处，那么我遗漏了什么？
不，这根本不是 DNS 缓存软件所记住的。它的作用恰恰相反——无论是 DNS 缓存还是整个 DNS 系统，都只关心指向 的地址google.com，1.2.3.4而不关心该地址“指向”回的地址。
DNS 缓存中的条目与权威 DNS 服务器中的条目完全相同，以域名作为查找键。（事实上，除了 Windows，大多数 DNS 缓存是只是接受标准查询并做出回答的普通 DNS 服务器。
多个 DNS 条目解析到同一个地址也不是什么新鲜事。（例如，即使没有 CDN，每个人都在使用 HTTP“虚拟主机”在同一台服务器上托管数十或数百个不同的网站 - 因此数百个 DNS 名称解析到同一个服务器地址。）
因此 DNS 缓存服务会缓存 DNS 查询的最终结果，即原始服务器 IP 地址
一般来说是的，但是，当你使用 Cloudflare 等 CDN 时，该 DNS 查询的最终结果不是不再是原始服务器 – 它是 CDN 服务器。
尤其是对于 Cloudflare，您在 Cloudflare 的“控制面板”中看到的 DNS 记录表实际上并不是 Cloudflare 向用户提供的 DNS 记录。只要您为域名启用代理，Cloudflare 的权威 DNS 服务器就会开始回复CDN 自己的IP 地址，而不是您输入的地址。
（其他 CDN 的工作方式相同，因为使用 CDN 的全部意义在于您的客户端与其对话。例如，域superuser.com使用 Fastly CDN，因此它始终解析为附近的 Fastly 节点的 IP 地址。）
因此，CDN 的短 TTL 的目的不是保护，而是负载平衡（CDN 的权威服务器会动态地响应当前的“最佳”节点，包括负载和地理位置）。
当多个 DNS 条目解析为同一个 IP 地址时，例如 google.com 和 facebook.com 都解析为 1.2.3.4，网络中的哪个元素/组件负责将用户带到正确的网站？
实际上是客户端和服务器，而不是网络。
每个 HTTP 客户端都会将请求的域指定为 HTTP 请求的一部分 - 这是 HTTP/1.1 中的“Host”标头（或 HTTP/2 中的“:authority”伪标头）。Web 服务器或反向代理会将收到的 Host 值映射到相应的 <VirtualHost> 或类似配置。
（您可以使用F12浏览器中的“开发人员工具”查看所有请求标头 - 打开“网络”选项卡开始收集数据，然后返回浏览器并按 F5 重新加载网页，然后返回“网络”部分。）
类似地，TLS 客户端还在 TLS ClientHello 中将请求的域指定为“服务器名称指示”扩展，以便服务器可以发送正确的证书。
一般来说，每种协议都有自己的方式来实现这一点，而且并非所有协议都能真正区分不同的域名。（例如，SSH 不会向服务器提供此类信息，因为其目标不是连接到“域”，而是连接到机器本身。）
但网络（在 IP 层）根本不关心域名（或网站）——它的唯一工作是将数据包传送到 1.2.3.4，如果 IP 地址相同，则目标服务器也相同。（在本例中，“目标服务器”是 CDN 反向代理前端。）
答案2
使用CDN的公司会在世界各地设置重复的服务器，这些服务器是所有CDN服务器都知道的。
您提到的同一个 IP 地址指向一个属于 CDN 的 DNS 服务器。
此 DNS 服务器只会将 DNS 请求转发给另一个 DNS 服务器，该服务器将成为该域的权威服务器。它可能不会自己给出最终答案（这不是必须的），因此它将表现为通常的 DNS 服务器层次结构。此权威服务器的选择主要受客户端 IP 的地理位置影响。
DNS查询的最终答案将是一个为查询域提供服务（属于查询域）的公司网络服务器，该服务器被判断为“最近”。
为了避免问题和拥塞，DNS 响应将具有较短的生存时间 (TTL)，因此该过程可能会不时重复，并且下次可能返回另一个服务器。