On Thu, 22 Jul 2004, Paul Vixie wrote:
the primary beneficiaries of this new functionality are spammers and other malfeasants
It appears your glass is half empty rather than half full. The primary beneficiaries are all current and future .com/.net domain holders: timely and predictable zone updates from one's parent are a good and useful feature. Mistakes can be fixed more rapidly and zone administrators who know what they are doing can effect changes quickly. On Fri, 23 Jul 2004, Paul Vixie wrote:
but when someone says, later, that the .COM zone generator ought to use a ttl template of 300 rather than 86400 in order that changes and deletions can get the same speedy service as additions, i hope that icann will say "no."
Paul, as you know, the TTL of parent-side NS RRsets when the data sought is in the immediate child zone is largely irrelevant because of credibility, which I described in http://www.merit.edu/mail.archives/nanog/2004-07/msg00255.html. I also stated in that message that VeriSign has no intention of changing the current 48-hour TTL on delegation NS RRsets in .com/.net. On Thu, 22 Jul 2004, Daniel Karrenberg wrote:
I am not worried so much about the root servers here because of the reasons you cite. The root server system is engineered to cope with hugely excessive loads already. I am worried about all the other DNS servers that have to deal with much lesser query loads and might feel the impact of lowered TTLs much more.
If a zone owner lowers a TTL and causes an increase in load, most of the foot being shot off is his or her own: the zone's own name servers will bear the brunt of the increased query load. I agree with Daniel's earlier statement that this is an education issue. Does anyone want to co-author an Internet-Draft on the topic of choosing appropriate TTLs? Matt -- Matt Larson <mlarson@verisign.com> VeriSign Naming and Directory Services