[dns-operations] RFC2308, negative answer caching, and the largest gTLDs

[Alexander Dupuy]

Note that the SOA returned in a negative response and the SOA returned in a
direct query for the SOA could have entirely different TTLs.

It does appear that Verisign com/net/org name servers return TTL=900 in
both cases, but there may be other name servers with different behavior. In
particular I recall that a direct query to some name servers for SOA
returns an SOA TTL larger the SOA MIN value, while the SOA TTL in a
negative response is clamped to be no larger than the SOA MIN, so that even
clients that don't implement the correct behavior per RFC 2308 get the
right TTL value.

$ dig @a.gtld-servers.net com SOA +noall +ans | tail -1
com.            900    IN    SOA    a.gtld-servers.net.
nstld.verisign-grs.com. 1520482920 1800 900 604800 86400
$ dig @a.gtld-servers.net asldkjasldkjasd.com +noall +auth | tail -1
com.            900    IN    SOA    a.gtld-servers.net.
nstld.verisign-grs.com. 1520548542 1800 900 604800 86400

I suspect that only people at Verisign can tell you why they chose such
different values for the SOA TTL and SOA MIN.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180308/d157445e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180308/d157445e/attachment.bin>