比方说，我为我的DNS服务器创build一个192.0.2.0/24networking的反向区域文件，我的DNS服务器将是反向区域2.0.192.in-addr.arpa的权威。 在这个反向区域文件中，我使用以下参数创build“权限的开始”logging：
$ dig @localhost -t SOA 2.0.192.in-addr.arpa. +noall +answer 2.0.192.in-addr.arpa. 604800 IN SOA primary-DNS-server secondary-DNS-server 2015010600 28800 7200 1209600 86400 $ 我是否正确，该反向区域的DNS TTL是86400秒？ 这意味着如果recursion（caching）名称服务器从该区域请求一个PTRlogging，那么这个recursion名称服务器将caching结果86400秒？
早在1997年，这将是一个正确的SOAlogging解释。 :)当时事情有点模棱两可。
RFC 2308将SOAlogging的最后一个字段重新分类为负caching间隔，否则称为NCACHE字段。 RFC2308§4是这里最适用的。 它不仅将其重新定义为NCACHE字段，而且还解释了为什么将缺省TTL编码到SOAlogging中会被误导开始。 （后者的重点是粗体）
4 – SOA最小字段
过去，SOA最小字段有三种不同的含义，一个区域中所有RR的最小TTL值，不包含TTL值的RR的默认TTL和负面响应的TTL。
尽pipe是最初定义的含义，其中第一个是所有区域内RR的最小TTL值，实际上从未被使用过，因此不推荐使用。
第二，在主区域文件中不包含显式TTL的RR的默认TTL仅与主服务器相关。 区域传输之后，所有RR都有明确的TTL，并且不可能确定logging的TTL是否明确设置，或者在区域传输之后是否从缺省导出。 在服务器不要求RR明确包含TTL值的情况下，它应该提供一种机制，而不是SOAlogging的MINIMUM字段的值，从中可以获得缺less的TTL值。 这是如何完成的，取决于实现。
主文件格式[RFC 1035 Section 5]扩展到包括以下指令：
$TTL <TTL> [comment]所有出现在指令之后的资源logging都没有显式地包含一个TTL值，它们的TTL被设置为在$ TTL指令中给出的TTL。 没有显式TTL的SIGlogging从SIGlogging的“原始TTL”[RFC 2065 Section 4.5]中获得它们的TTL。
其余的当前意义，作为负面反应使用的TTL，是SOA最小字段的新定义的含义。
打破这个：
NCACHE ）指定如果查询导致NXDOMAIN，则远程名称服务器应该caching否定响应的时间。 $TTL指令相同。 $TTL和家庭不是logging，因此你不能查询他们，他们将无法生存的区域转移。 （相反，在区域传输时，所有丢失的TTL将被replace为该值） 正如Andy所说，如果单个logging指定了自己的TTL，那么默认的TTL是没有意义的。
几乎。 soalogging本身的TTL为86400秒，取决于服务器端软件，它将是该区域的默认ttl。
该区域内的单个logging（例如PTR或NS）可以覆盖TTL。 我相信任何单个DNSlogging的recursion查询将返回自己的TTL，虽然我说的基于观察而不是引用的文档。