Re: [gnso-ff-pdp-may08] Section 5.8

[Dave Piscitello <dave.piscitello@xxxxxxxxx>]

To be clear, the only recommendation I composed was the one Greg mentions.

Everything else in my message was a comment in response to Rod's post.


On 5/20/09 2:17 PM  May 20, 2009, "Greg Aaron" <gaaron@xxxxxxxxxxxx> wrote:

> I think that Dave's note here capture the general sentiment:
> "Recommendation: The WG concludes from its study that setting minimum bounds
> on TTL values is neither technically viable nor appropriate, given the range
> of applications that make use of short TTLs."
> 
> I do not think the WG should recommend these ideas:
> 1.  charging registrants and/or registrars for nameserver changes.  It does
> not appear to be an industry best practice.  And since double-flux is such a
> miniscule percentage of all the nameserver changes that happen in the
> gTLds/sTLDs each day, an ICANN consensus policy on this would be overkill.
> 2.  requiring multiple contacts to confirm DNS updates before having them
> take effect.  Solving for hijacked domains is a separate problem outside the
> scope of this WG.  And fast-flux domains are registered by the bad guys, so
> they could easily validate their own change requests, rendering the
> deterrent useless.
> 
> All best,
> --Greg
> 
> 
> 
> -----Original Message-----
> From: Dave Piscitello [mailto:dave.piscitello@xxxxxxxxx]
> Sent: Wednesday, May 20, 2009 12:06 PM
> To: Rod Rasmussen; Greg Aaron
> Cc: James M. Bladel; Joe St Sauver; gnso-ff-pdp-may08@xxxxxxxxx
> Subject: Re: [gnso-ff-pdp-may08] Section 5.8
> 
> I'm very sorry to have missed the call. SSAC has an executive team call at
> 10:00 and it ran very long.
> 
> I also apologize to have reopened a discussion when I intended to put it to
> bed. I was reaching out to find what the WG wants to specifically recommend
> in the report. From the list posts I think the recommendation is:
> 
> Recommendation: The WG concludes from its study that setting minimum bounds
> on TTL values is neither technically viable nor appropriate, given the range
> of applications that make use of short TTLs.
> 
> Does this capture the general sentiment?
> 
> Regarding charging for name server changes. Aren't there cases where charges
> would be imposed on the legitimate account holder for TTL changes to a name
> server he added in stealth to the NS list of a domain in a hijacked account?
> Or charges against stolen credit cards for TTL changes for name servers
> created in a fraudulently created account? I think DE's criteria for domain
> registration are more stringent than GTLDs and perhaps this accounts for
> their success?
> 
> I wonder if stronger confirmation measures when NS changes are requested, or
> requiring multiple contacts to confirm any DNS configuration change are not
> a better way to deter attackers.
> 
> 
> On 5/20/09 10:21 AM  May 20, 2009, "Rod Rasmussen"
> <rod.rasmussen@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
>> I agree on the TTL value change roadblock as well - just not
>> controllable enough.  However the changing nameservers charges or
>> "slowdown" is actually a decent deterrent, and .DK has been
>> successfully charging for NS changes for years.  Changing NS is
>> actually a control point at the registrar level, and thus something
>> that can be imposed upon a miscreant without alternative (other than a
>> different TLD of course).  That being said, it would only affect
>> double-flux domains today, of which we just don't see that much.  And
>> just to flip the argument one more time, we've been having good
>> success with killing nameserver domains that are supporting FFLUX
>> networks (and only those networks) so putting a "braking" factor on
>> nameserver changes would have a material impact on some abuse
>> activities, if supported by complementary efforts.  The thread is
>> getting a ways away from the original point, but just wanted to throw
>> this in for the record.
>> 
>> Thanks!
>> 
>> Rod
>> 
>> 
>> On May 19, 2009, at 9:02 AM, Greg Aaron wrote:
>> 
>>> 
>>> I agree.  Governing TTL values is not technically viable or justified
>>> solution.  And mandating charges for TTL changes or nameserver
>>> changes is
>>> neither justified nor practical.
>>> All best,
>>> --Greg
>>> 
>>> 
>>> -----Original Message-----
>>> From: James M. Bladel [mailto:jbladel@xxxxxxxxxxx]
>>> Sent: Tuesday, May 19, 2009 11:49 AM
>>> To: joe@xxxxxxxxxxxxxxxxxx
>>> Cc: gnso-ff-pdp-may08@xxxxxxxxx; dave.piscitello@xxxxxxxxx
>>> Subject: RE: [gnso-ff-pdp-may08] Section 5.8
>>> 
>>> 
>>> Joe and Group:
>>> 
>>> I agree with Joe's first point (below), that governing TTL values is
>>> probably a dead end.
>>> 
>>> Like many registrars, we offer basic DNS services with default values
>>> for TTL.  This is sufficient for the majority of customers.
>>> Registrants
>>> can override these defaults (within reason) by accessing an "advanced
>>> DNS" control panel.  But it is fair to assume that anyone bent on
>>> mischief would see this tool as a hindrance / exposure vulnerability,
>>> and simply set up their own nameserver.
>>> 
>>> J.
>>> 
>>> 
>>> -------- Original Message --------
>>> Subject: Re: [gnso-ff-pdp-may08] Section 5.8
>>> From: Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>
>>> Date: Thu, May 14, 2009 10:47 am
>>> To: dave.piscitello@xxxxxxxxx
>>> Cc: gnso-ff-pdp-May08@xxxxxxxxx
>>> 
>>> 
>>> Dave mentioned:
>>> 
>>> #Do we want to tackle the question of whether registrars should limit
>>> how
>>> #frequently registrants may change TTLs?
>>> 
>>> Would registrars have the ability to control TTL changes? While many
>>> registrars offer an integrated package that includes name registration
>>> and
>>> DNS service, in other cases the two activities are completely
>>> decoupled.
>>> 
>>> If the registrar doesn't provide DNS service for their customer's
>>> name,
>>> 
>>> they wouldn't have control over, or even necessarily knowledge of,
>>> their
>>> customer's TTL values.
>>> 
>>> I don't think this would be a productive line of action to pursue.
>>> 
>>> #What about fees for TTL changes? Looking at old threads, I see we
>>> talked
>>> #about the fact that fees would not generally deter criminal activity
>>> #(they are using someone else's money).
>>> 
>>> You're thinking about cases where someone is engaged in credit card
>>> fraud,
>>> etc., right? While that is certinly common for some registrations,
>>> effort
>>> such as the "Day Old Bread" list reduce miscreants' ability to nail up
>>> a
>>> domain, use it immediately until it is discovered that it was
>>> fraudulently
>>> ordered, iterating after that domain is disabled.
>>> 
>>> If you can induce what amounts to a community-imposed month long
>>> waiting
>>> period before a domain is trusted, the ability of a miscreant to make
>>> fraudulent orders is undercut, and then fees once again become a
>>> viable
>>> 
>>> tool for shaping behaviors (albeit *not* fees for "TTL changes")
>>> 
>>> Regards,
>>> 
>>> Joe
>>> 
>>> 
>>> 
>> 
>