[gnso-ff-pdp-may08] Towards a recommendation

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

The downward pressure on TTLs, begun by UltraDNS in 2004, and followed 
by Verisign the same year was the occasion of two policy errors by ICANN.

While widespread use of dynamic, low-TTL A-record bindings generally do 
not greatly increase DNS related wide-area network traffic, dynamic, 
low-TTL NS-record bindings, and dynamic, low-TTL A record bindings for 
nameservers will increase the load on the root and gTLD servers by about 
a factor of five and significantly harm DNS scalability.
Independent of the business model cited in support of dynamic, low-TTL 
A-record bindings for nameservers, or dynamic, low-TTL NS-record 
bindings, ICANN's policy, consistent with its fundamental mission "the 
Internet secure, stable and interoperable", should have been, and should 
now be, prescriptive of dynamic, low-TTL A-record bindings for 
nameservers, or dynamic, low-TTL NS-record bindings.

While additions, changes, and deletions to zone files are all 
technically equivalent deltas to zone files, and commonly published as 
updates without distinction, the use case for "speedy additions" to a 
zone is significantly different from the use cases for "speedy changes 
and deletions" to a zone.
Independent of the business model cited in support for failing to 
distinguish between the use cases for "adds" relative to "changes and 
deletes" to zone files, ICANN's policy, consistent with its fundamental 
mission "the Internet secure, stable and interoperable", should have 
been, and should now be, prescriptive of an increase of dynamicism of 
delegation change and domain deletion.

-----------------

I've reviewed the RC list traffic on this subject since the date of Mike 
R's request for a second (February 27th, 2008), and I think the above, 
which for those this is simply too geek, can be read as "turn the clock 
hands back four years", places the burden where it belongs, which is the 
point of origin of the feature-or-bug, and is consistent with the 
interests of the RC.
Additionally, as a registry back-end operator, I don't reach this 
recommendation unconcerned by its effect on the operators of the 
largest, and most affected by "fast flux" registries. I am sympathetic 
to the delayed discovery of error, and the cost of unrolling a 
competitive advantage that time and circumstance prevented its authors 
from fully appreciating when the error was made. Never the less, our 
industry has matured, and I'm optimistic this will be received in the 
spirit it is offered.
Cheers,
Eric