我终于让我的 DYNDNS 运行起来了，但我正在寻找一些关于优化它的建议。
编辑：基本上，我在注册商处获得了一个域名，我将它指向我自己的名称服务器，并在其中保存我自己的记录。我用它nsupdate来更新记录。我希望用户能够注册，获得一个子域名，他们可以将其指向获得动态 IP 的设备，从而使其“静态”。
动态更新的示例http://ip.seveas.net/dnsgraph/png/client1.epnddns.com/?skip_.=on&show_A=Show
基本上，我希望实现最快的解析速度，如果我可以这么称呼的话。这意味着用户在更新子域名后，直到他们真正可以使用/解析它为止需要等待的最短时间。在不让服务器停止运行的情况下，想想 1000 多个用户。这说得通吗？
所以我想知道 SOA 的 TTL 值、我的名称服务器以及如何为用户可能频繁更新的动态创建的子域提供信息。
另一个问题是，在客户端 1 的示例中。它似乎在其他设备或其他用户上都能很好地解析，但从我家里的 IP（我也用这个 IP 来更新记录）来看，它是否连接似乎是随机的。这可能是我的设置有问题，还是与我从家里的 IP 更新记录有关？
我的第一个名称服务器值
$ORIGIN .
$TTL 38400 ; 10 hours 40 minutes
mydomain.com IN SOA ns3.mydomain.com. admin.mydomain.com. (
2880848856 ; serial
28800 ; refresh (8 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
38400 ; minimum (10 hours 40 minutes)
)
NS ns3.mydomain.com.
NS ns4.mydomain.com.
A 66.33.x.x
$ORIGIN mydomain.com.
$TTL 10 ; 10 seconds
client1 A 75.119.x.x
$TTL 38400 ; 10 hours 40 minutes
ns3 A 64.111.x.x
ns4 A 67.205.x.x
www A 66.33.x.x
我的第二个名称服务器值
$ORIGIN .
$TTL 38400 ; 10 hours 40 minutes
mydomain.com IN SOA ns4.mydomain.com. admin.mydomain.com. (
2006071806 ; serial
28800 ; refresh (8 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
38400 ; minimum (10 hours 40 minutes)
)
NS ns3.mydomain.com.
NS ns4.mydomain.com.
A 66.33.x.x
$ORIGIN mydomain.com.
$TTL 10 ; 10 seconds
client1 A 75.119.x.x
$TTL 38400 ; 10 hours 40 minutes
ns3 A 64.111.x.x
ns4 A 67.205.x.x
www A 66.33.x.x
除此之外还有其他方法可以优化吗？
提前感谢您提供的任何见解或建议！
答案1
你写了：
我想知道是否有人可以给我一些指点，如何对其进行优化，以便在不过度推动服务的情况下获得最快的解决方案。
您能否更清楚地说明一下通过调整 TTL 值想要实现什么目的？
我认为您知道，TTL 控制（或应该控制 - 并非每个名称服务器都真正正确遵守它）您的资源记录可以在非权威名称服务器的缓存中保留多长时间。
如果客户端能够从其本地递归解析器的缓存中获得答案，则尝试解析您的记录查询的客户端将（“可能”可能是更好的表达方式）获得更快的解析。因此，从这个意义上讲，较长的 TTL 允许其他名称服务器更长时间地缓存您的 RR 数据，从而提高客户端查询从缓存中得到满足的可能性。从这个意义上讲，较高的 TTL 往往会提高客户端查询解析速度。
但是，您需要平衡这一点与非权威服务器缓存不正确数据的问题。当您的数据发生变化时（例如，由于您已移动到其他 IP 地址，或更改了记录的目标），其他名称服务器可以缓存旧数据，最长可达 TTL 秒。因此，如果您经常更改数据（例如，经常移动到新 IP 地址，或更改区域的内容），则需要降低 TTL。
按照目前的规定，您的问题实际上并没有提供任何有关数据变化速度的指导，因此无法更具体地建议您哪些 TTL 值合适。它们将在很大程度上取决于您的使用模式。
答案2
我认为这适用于相对较少流量的情况。需要大量可靠 DNS 查询的服务器属于静态 IP 地址。如果是这样，调整 TTL 就没那么重要了。
仅凭部分信息很难给出好的建议。以下回答对我有用。由于我只有有限的信息，所以答案可能不适合您。
在为这种情况选择 TTL 时，我会查看 IP 地址源的 TTL。如果您使用的 DHCP 的租期超过一两分钟，则 10 秒的 TTL 可能过于极端。
如果您为 DHCP 客户端提供内部 DYNDNS 服务，则 TTL 应为租期的一半或四分之一。对于动态获取地址的面向外部的服务，您可能需要更短的 TTL。
需要考虑的因素包括数据缓存的位置、地址更改的频率以及服务不中断的重要性。您还应该考虑错误定向的连接可能落在哪里。与无法控制的 Internet 上的服务器相比，组织内部或无效地址可能不那么令人担忧。
编辑：无论您指定什么 TTL，某些 DNS 服务器都会忽略它，并缓存自己的 TTL。我相信这种情况更有可能发生在较短的 TTL 中。几年前，出现了大量使用快速通量 DNS 来避免检测的僵尸网络。我确实看到报告称，忽略短 TTL 并缓存更长时间是处理这些服务器的一种方法。
您还需要处理负缓存。Bind 9 使用最小 TTL 作为负缓存期。（在您的例子中，这似乎是 10h40，比您的正 TTL 长得多。）对于动态服务，您可能希望它们相同。
我希望你的客户分为三类（他们可能有不同的需求）：
- 具有较稳定IP地址的用户，并且在动态IP上运行公共服务，导致DNS查询相对频繁。
- 拥有相当稳定 IP 地址的用户，偶尔会远程访问服务器。
- 经常断线的旅途人员，但希望在连接网络时能够保持联系。
可以通过监控 DNS 查询和更新来确定您拥有哪些类型的用户。确定此类数据需要时间。确定 TTL 时，重要的是确定上次查询后多久发生更新。随着时间的推移检查此值可能有助于确定合理的 TTL。检查查询频率和源 IP 分布与更新频率也可能有帮助。您可以使用这些数据随时间调整 TTL 值。