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

["Greg Aaron" <gaaron@xxxxxxxxxxxx>]

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
>> 
>> 
>> 
>