ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


<<< Chronological Index >>>    <<< Thread Index >>>

[gnso-ff-pdp-may08] DRAFT text for Section 5.8

  • To: "Fast Flux Workgroup" <gnso-ff-pdp-May08@xxxxxxxxx>
  • Subject: [gnso-ff-pdp-may08] DRAFT text for Section 5.8
  • From: "Diaz, Paul" <pdiaz@xxxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 29 May 2009 14:05:21 -0400

Based on the comments already posted to this list, here is proposed text
for Section 5.8 (which also would appear in the Executive Summary re:
Charter Question #8.  Please share edits/comments to the list for
further discussion/approval at the next FF WG call on June 3.


Issue 
What would be the impact (positive or negative) of establishing
limitations, guidelines, or restrictions on registrants, registrars
and/or registries with respect to practices that enable or facilitate
fast flux hosting?


Response
The Working Group considered several possible options, including
governing Time-To-Live (TTL) values, charging registrants and/or
registrars for nameserver changes, and requiring multiple contacts to
confirm DNS updates before having them take effect.  The Working Group
did not reach consensus on or endorse any of them.  

The Working Group concluded from its study that setting minimum bounds
on TTL values is neither appropriate nor technically viable.  There are
a range of legitimate applications that make use of short TTLs, and it
would be impractical to try to sort them out for some special treatment.
Furthermore, registrars often don't provide DNS service for their
customers' names and thus won't have control over, or even necessarily
knowledge of, these domains' TTL values.  

Charging for nameserver changes is not recommended as a gTLD industry
best practice.  Most often a stolen credit card was used to register the
domain, so additional charges would be ineffectual.  Such fees would
only impose unfair costs on legitimate users whose account(s) were
hijacked.

Mandating that multiple contacts must confirm DNS updates before they go
into effect would be problematic.  Such a validation process almost
certainly would include the criminals abusing the domains, making it a
useless deterrent.  Also, solving for hijacked domains is a separate
problem outside the scope of this Working Group.




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy