Re: [gnso-pednr-dt] Revised Recommendations

["Michele Neylon :: Blacknight" <michele@xxxxxxxxxxxxx>]

And to backup Alan (don't get used to it!)

We discussed the technical limitations of what a registrar can or can't do with 
respect to DNS records (and paths) at length over the past year (or was that a 
century .. I'm losing track of time) and Olivier's point / query was dealt with 
then


On 16 Feb 2011, at 21:59, Alan Greenberg wrote:

> Olivier, to be clear, "14a (old #15a)" says that everything must stop working 
> as it did during the specified period, as a mechanism to alert the registered 
> name holder that they are about to loose their domain name. Currently, and 
> presumably into the future, most registrars do "intercept" most web access, 
> and "14b (old #15b)" addresses this situation.
> 
> As Rob points out, there are many ways to disable the domain completely, and 
> all would satisfy "14a (old #15a)". If a registrar chooses to intercept web 
> traffic, there are generally two ways that they can do this. If that 
> registrar already host the DNS entries for that domain, they could change the 
> A record and change it back if and when the domain is renewed. If the 
> registrar does not control the DNS that the domain points to, or even if they 
> do, they can change it to point to a different DNS that is under their 
> control, and change it back if the domain is ultimately renewed. 
> 
> These are the techniques that are generally used today - we are not inventing 
> anything here.
> 
> Alan
> 
> 
> 
> At 16/02/2011 11:09 AM, Olivier MJ Crepin-Leblond wrote:
>> +1
>> 
>> I've just written to Michael about this:
>> 
>> --- quote ---
>> "
>> may I ask how this would be effected?
>> 
>> Would other services for that domain name still work?
>> 
>> If that's the case, then the Registrar would need to make a full copy of
>> the RNHaE's domain file, and only change the records for the
>> www.example.com address, and of course define the nameservers for that
>> domain into its own nameservers.
>> If on the other hand, all other services also get stopped, then it's
>> just a case of defining the nameserver for that domain as the
>> Registrar's nameserver & pointing the www.example.com address to a
>> suitable page."
>> 
>> --- end quote ---
>> 
>> Kind regards,
>> 
>> Olivier
>> 
>> 
>> 
>> Le 16/02/2011 16:45, Rob Hall a écrit :
>> > I don't think that does work.  Neither does actually.
>> >
>> > We have to keep in mind that the only thing the Registrar actually can 
>> > change on the domain is the DNS servers.   While the Registrar may choose 
>> > to put their own DNS servers there, and then direct the website as they 
>> > see fit, they should not be required to.
>> >
>> > It should be perfectly acceptable for the Registrar to change the DNS 
>> > server to nothing.  Or to simply put the domain on hold, which has the 
>> > effect of removing the DNS servers from the zone.
>> >
>> > A Registrar should not have to change the DNS server to something that 
>> > actually resolves to a website.  This places a burden on the Registrar 
>> > that does not currently exist.  There is no requirement in any contract 
>> > for the Registrar to operate DNS servers, nor web servers, to point client 
>> > domains at.
>> >
>> > I understand the intent, but I don't believe you have captured anything 
>> > workable here.
>> >
>> > Might I suggest that it simply be
>> >
>> > "Registrar causes the DNS servers in the zone to be changed."
>> >
>> > This would capture both putting the domain on hold which would cause the 
>> > DNS servers to be removed, as well as a Registrar changing them to a new 
>> > set.  In either case, the original website would not resolve.
>> >
>> > Rob
>> >
>> >
>> > -----Original Message-----
>> > From: owner-gnso-pednr-dt@xxxxxxxxx [ 
>> > mailto:owner-gnso-pednr-dt@xxxxxxxxx] On Behalf Of Michael Young
>> > Sent: Wednesday, February 16, 2011 10:27 AM
>> > To: 'Alan Greenberg'; 'PEDNR'
>> > Subject: RE: [gnso-pednr-dt] Revised Recommendations
>> >
>> >
>> > Alan this should, I believe, suffice.
>> >
>> > Replace
>> >
>> > Registrar directs port 80 traffic (Web) to a web server other than the one
>> > used by the RNHaE prior to expiration, 
>> >
>> > with
>> >
>> > Registrar changes the DNS resolution path to effect a different landing
>> > website than the one used by the RNHaE prior to expiration,
>> >
>> >
>> > Michael Young
>> >
>> > M:+1-647-289-1220
>> >
>> >
>> > -----Original Message-----
>> > From: Alan Greenberg [ mailto:alan.greenberg@xxxxxxxxx] 
>> > Sent: February-16-11 2:30 AM
>> > To: PEDNR
>> > Subject: [gnso-pednr-dt] Revised Recommendations
>> >
>> > I listened to the MP3 and hope that I caught all of the suggested changes.
>> >
>> > The document here shows all of the change to the actual recommendations. 
>> > The
>> > comments and old Status column were removed and a Rationale column added. I
>> > also added a new column for a suggested ordering of the recommendations.
>> > Probably not perfect, but it at least groups the similar ones together and
>> > in a rational order within each grouping.
>> >
>> > A few things that I noted while making the changes.
>> >
>> > - I don't suggest doing anything about it on this iteration, but after the
>> > comment period, we probably should look at old Rec 7 and 9. 
>> > They seem to overlap and could use some cleanup.
>> >
>> > - I realized that in my eagerness to accept James' VERY simplified version
>> > of old Rec 6 (disclosure of renewal price), something important was lost
>> > from the older version. The new version only talks about registrars that
>> > have a web presence for registration/renewal. 
>> > Those registrars who work solely through resellers are thus exempted which
>> > was certainly not my intent, nor, I think, that of the group. I suggested a
>> > new sentence be added putting back in the requirement to disclose renewal
>> > price either in the registration agreement or pointed to it. I did not
>> > include the RGP price but that could easily be added as well (but did not
>> > want to go outside of the intent of the original Rec.). The wording could
>> > probably be enhanced, but this should work for now, if all agree.
>> >
>> > - On rewording old Rec 14a (very old 15a) to replace "immediately" 
>> > with "commercially reasonable delay" as per the suggestion (I think from
>> > James), I found the wording rather awkward. I included an alternative
>> > working with the sentence inverted. I think it reads a bit better.
>> >
>> > - Still to come is the revised wording from Michael on the port 80
>> > interception.
>> >
>> > Please review and let me know if I got anything wrong or otherwise messed 
>> > up
>> > (now 2:30 am and past the point where I can proof-read my own work).
>> >
>> > Alan
>> >
>> >
>> 
>> -- 
>> Olivier MJ Crépin-Leblond, PhD
>> http://www.gih.com/ocl.html

Mr Michele Neylon
Blacknight Solutions
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.mobi/
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
UK: 0844 484 9361
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Twitter: http://twitter.com/mneylon
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845