您的问题实际上与编程无关，而更多地与操作有关，并且也有点过于模糊（“还有其他优化名称服务器的方法吗？”）。
但是让我们试着给你指点。
用户X想访问www.example.com，获取IP地址的步骤如下：
那么您的以下描述大部分是正确的。请注意，在每个步骤中，默认情况下直到最近，递归名称服务器都会将查询的整个名称发送到每个名称服务器。最近，QNAME 最小化作为一种标准出现，现在递归名称服务器可以只向每个权威名称服务器发送它需要回复的标签。这在不更改协议的情况下增强了隐私性，但今天并不普遍，因为一些权威名称服务器在以这种方式查询时无法正常工作。
作为域名所有者，您确实只能在最后一步产生影响。但请记住，递归名称服务器具有缓存，因此根名称服务器列表以及 .COM 名称服务器列表非常“热”（经常需要），它们肯定总是位于解析器的缓存中，所以基本上是第 1 步并且 2 不会经常发生（通常在缓存为空时开始）。
我遇到了 IP Anycast 名称服务器（也用于 13root 名称服务器）并且完全理解分布式机器的概念。但我不明白的是决策逻辑，根据他的“位置”，用户将被发送到哪个分布式机器？
首先，IP 任播并非特定于 DNS，它在这里非常受欢迎，因为
- 它解决了所有大型 TLD 都存在的负载平衡/故障转移问题
- 它特别适用于基于 UDP 的 DNS，这是一种简单的一查询一回复协议。
所以理论上任何服务都可以被任播。这意味着给定的 IP 地址只出现在世界上的不同位置。
概括地说，提供商之间的 Internet 流量（AS 编号）在对等点交换，它们相互连接，每个提供商说“我知道 IP 块 192.0.2.0/24，请向我发送它的所有流量”，等每个块
（这又是一个总结。块是由 RIR 分配的，是的，默认情况下，这并没有经过太多身份验证，因此当另一个提供商也说“给我这个流量”而不应该说“给我这个流量”时，就会发生 BGP 劫持——这是因为恶意目标或只是简单的人为错误）。
对于一个普通的（技术术语：“单播”）IP 地址，只有一个提供商 (AS) 会在某处宣布它（技术上：宣布它的块，而不仅仅是一个 IP），并且一切都将以这样的方式进行配置：无论交换的起点在哪里，对于这个作为目的地的单一 IP，它都会到达完全相同的盒子。
相反，对于任播 IP 地址，单个提供商或多个提供商（即多个自治系统）将在全球不同位置（对等点）公布此 IP。在每个对等点上，该 IP 的流量将被提供商在那里宣布，然后它将该流量路由到“附近”的特定服务器。在对等点 A 和对等点 B 宣布相同 IP 将在数据中心 X 的一侧和数据中心 Y 的另一侧驱动相应的流量。
对于客户端，当一切正常时，它不会改变任何东西，只要所有回复服务器对相同查询的反应方式相同。客户端甚至不知道（有时甚至不知道）该 IP 是任播的，或者它想要定位 X，而另一个客户端做同样的事情却会点击位置 Y。
因此，简而言之，名称服务器在这方面没有“决定”。在 DNS 解析的每一点，当他们需要联系名称服务器 NS1 时，他们知道其 IP 地址是 IP1，并且他们只是打开一个到该 IP 的 UDP（或有时是 TCP）连接，绝对正常。底层 IP 和 BGP 协议，如果任播在起作用，则使响应来自适当的“关闭”服务器。
请注意，对于 DNS，以这种方式进行任播可以同时实现：
fail-over ：如果一台服务器死机，在适当的监控下，它的提供商会撤回其 IP 公告，即这种本地副本消失，流量将自动（按顺序秒）转移到宣布相同 IP 的任何其他实例
负载平衡：粗略地说，如果您在 2 个位置上任播一个 IP，则每个位置应接收 50% 的流量。在实践中并非如此，而且预测甚至监控都非常复杂（阅读：不可能），因为这完全取决于对等点、提供商之间的协议和各种其他策略（简单示例：如果您在两个点上对等）首先，只有一个提供商向您发送流量，而在另一点，您有 100 个提供商与您交换流量，那么您可能会获得更多连接到第二个实例......当然，如果第一个对等点的单一提供商除外是一家拥有数百万客户的 ISP，而其他 100 家提供商都是单个小型组织...）
因此，一些域名服务器是任播的。现在所有的根域名都是（但在 16 个月前情况并非如此，请参阅 https://b.root-servers.org/news/2017/04/17/anycast.html，因为 b.root-servers.org 是最后一个登上任播车的）以及所有大型 TLD，有时甚至有多个“任播 DNS”提供者”。
对于任何域名，您都可以获得一些提供商，这些提供商会为您提供基于任播域名服务器“云”的 DNS 服务。
参见示例：
现在关注一个完全不同的主题：
除此之外，我发现另一种为用户提高速度的小方法是只使用 A 记录而不再使用 CName 记录。
这并不是你真正获得的东西，CNAME 记录在许多其他情况下很有用。
同样，您需要记住存在缓存。
所以即使你的配置是：
www.mywebsite.example CNAME www.mywebsite.example.somegreatCDN.example
www.mywebsite.example.somegreatCDN.example A 192.0.2.128
这确实意味着理论上两个 DNS 请求最终能够进行 HTTP 查询，但实际上会缓存一些东西（今天更是如此，使用大型公共开放解析器，例如 1.1.1.1 或 8.8.8.8或9.9.9.9，实际上也是任播的），因此差异可以忽略不计（并且只会影响第一次，直到它在缓存中才会再次影响）......尤其是在HTTP的情况下以及后来发生的所有事情经常打开几十个连接来下载可能托管在其他地方的 javscript 源代码、CSS 文件、字体等。
许多网站使用CNAME 记录而没有负面影响。例如，请参阅www.amazon.com，现在：
;; ANSWER SECTION:
www.amazon.com. 730 IN CNAME www.cdn.amazon.com.
www.cdn.amazon.com. 11 IN CNAME d3ag4hukkh62yn.cloudfront.net.
d3ag4hukkh62yn.cloudfront.net. 11 IN A 54.239.172.122
但是，您可能会争辩说，某些名称会比其他名称更受欢迎，因此在缓存中的保留时间更长，这是肯定的。
最后：
还有其他优化域名服务器的方法吗？
基于什么？上面我们触及了各种主题，都是妥协，你牺牲一些东西（可能只是“钱”）来获得别的东西（冗余等）。没有通用规则可以声明这种妥协何时有意义，这在很大程度上取决于您的情况以及您正在尝试做什么。
您是对的，应该祝贺您，出于安全和性能原因，您应该在 DNS 设置方面投入一些时间。虽然很多钱经常投资于庞大的 HTTP 设置以维持各种问题或活动高峰（但即使是最好的有时也会失败，请参阅最近的 Amazon Prime Day 开幕，这是一个巨大的失败），但人们常常忘记 DNS，因为它处于基础架构级别，因此不为人所知，也不为人所知（使用 UDP 使其在所有其他已知协议中脱颖而出，因为这种情况很少见）。
例如，还有另一个完全不同的东西（它与任播正交，因此它可以使用或不使用它，目标不同）是相关的：“geo-DNS”表示名称服务器何时会根据不同的方式回复客户问的地方。例如，这意味着为网络服务器提供一个不同的 IP，一个更接近客户端的 IP（因此在这种情况下，网络服务器本身可能不是任播的）。这是通过仅查看 DNS 数据包中的源 IP 来完成的，但这通常还不够好，因为权威名称服务器仅将来自递归名称服务器的源 IP 视为源 IP，而不是真正的最终客户端 IP，而且现在有大量的开放公共递归名称服务器的位置应该很远，因此您还有一个称为 EDNS 客户端子网的特定 DNS 选项，可以在递归和权威名称服务器之间传递，以便它们获得最终客户端的真实 IP 地址（实际上是一个块而不是单个 IP隐私原因）并可以采取行动。