我对此进行了研究，但似乎没有尽头，我找不到明确的答案。
我们在 GoDaddy 上有超过 500 个域名，我们将它们指向我们使用 Bind 来管理的内部 DNS 服务器。
奇怪的是，每当我们指向一个标准域名 IE .com .net、.org、.us等等.info等等，TTL 几乎一直都很快，只有少数异常值。然而，当我们执行一些新的 非标准urls TTL 不仅不可靠，而且在美国某些地区根本不存在。我知道 GoDaddy 指向正确，因为我可以dig从西雅图正确访问我的 DNS 服务器——然后同时dig从芝加哥访问，传播就不发生。我甚至尝试更新序列号以尝试重置缓存，但无济于事。
我们遇到的问题只是这些非标准 URL。这只是某种宇宙巧合，还是背后有原因？为了在此 OP 中澄清，我将发布无法“正确”或“完全”传播的域之一的配置。——请告诉我，我可以配置或更改 Bind 中的某些内容以使它们正确传播，而不仅仅是互联网尚未准备好接受非标准域！
命名的.conf.本地
zone "somesite.builders" {
type master;
file "/var/lib/bind/somesite.builders.hosts";
};
主机名
$ttl 38400
somesite.builders. IN SOA ns1.somedns.com. email.email.com. (
1502145907
10800
3600
604800
38400 )
somesite.builders. IN NS ns1.somedns.com.
somesite.builders. IN A xx.xx.xx.xx
www.somesite.builders. IN A 40.xx.xx.xx
mail.somesite.builders. IN A 173.xx.xx.xx
webmail.somesite.builders. IN A 173.xx.xx.xx
somesite.builders. IN MX 10 mx1.somemail.com.
somesite.builders. IN MX 20 mx2.somemail.com.
4 天（96 小时）后我的 DNS 结果是什么
答案1
你所说的顶级域名实际上并不是非标准，它们只是相对较新地建立起来的。
地理位置并不是一个真正重要的因素。使用的递归名称服务器（通常由 ISP 提供）及其连接性才是最重要的。
在描述缓存行为和 TTL 时使用“传播”这一术语具有误导性，它听起来好像某些数据正在被主动传播（甚至可能以某种线性方式传播，这与地理位置很重要的想法相联系），而实际上它是等待任何已缓存的旧数据过期（这在每个缓存服务器上独立发生）。
至于手头的问题，问题中确实没有足够的信息来明确说明问题是什么。
话虽如此，在我看来，如果你已经等了四天，缓存似乎不太可能是问题所在。更有可能的是存在某种形式的配置错误，导致不断产生新的错误答案。
我的建议是仔细查看那些未按预期回答的递归名称服务器的实际答案，以及所有 TLD 名称服务器的响应方式以及您自己的区域的所有名称服务器的响应方式。
这些递归服务器是否表示您的域名不存在？如果是，SOA至少是否与实际 TLD 区域匹配？如果不匹配，则可能表明递归服务器可能存在一些干扰的错误配置。
至于权威方面，出于此目的dig +trace +add example.com NS和dig +nssearch example.com样式命令可以作为起点，然后从那里开始。服务如DNSViz也可能有助于获得更好的概览。
如果存在任何不一致，那也能说明问题。
举个例子，虽然概念上没有区别，但 TLD 的选择最终会成为一个因素，如果 TLD 区域的 N 个名称服务器之一由于某种原因没有使用其区域的当前版本进行更新，并且仍然声称您的域名不存在（有效响应，不会触发任何重试），而他们的其他名称服务器正确地响应并引用您的名称服务器，则任何给定的递归名称服务器从可信来源确切地知道您的域名不存在并采取此类行动的概率为 1/N。
答案2
从技术上讲，这些 TLD 之间并没有什么不同；缓存和区域传输的工作方式都相同。顺便说一句，您似乎对这两者有些混淆：
- TTL 仅影响缓存，即缓存多长时间递归服务器保持记录（不是整个区域）。
- SOA 串行仅影响区域传输；主服务器是否具有比其他服务器更新的区域权威性服务器。此外，当区域发生变化时，主服务器可能会发送通知。
答案3
与@Esa Jokinen 的观点相反，我认为 TLD 之间存在差异：TLD 本身的名称服务器。如果 TLD 本身由于其名称服务器不稳定而无法解析，那么您的名称也将无法解析。
我认为可能还存在限制可接受 TLD 的 DNS 服务器和/或防火墙；这与规范相悖，但我并不感到惊讶。