Onderwerp: Verhuisprocedure

In reactie op: http://www.webhostingtalk.nl/1134667-post12.html

Oorspronkelijk geplaatst door Paul Jansen

maar als jij als latende registrar de token al hebt afgegeven waarom zou je als je notificatie ontvangt dat de overnemende registrar de verhuizing heeft opgestart dan geen akkoord geven zodat de domeinnaam in feite realtime wordt verhuisd?
De controle is al gebeurd (neem ik aan) toen jij de token hebt afgegeven.

Het token kan bij ons online door klanten worden opgevraagd.
Dit is bij de meeste internationale extensies nu eenmaal verplicht, en heb weinig zin om voor .nl een aparte procedure te hanteren.

Een klant kan dus ook zonder dat deze direct verhuisplannen heeft, het token opvragen en noteren.

Op het moment dat het token ingezien wordt vindt er gebruikersnaam/wachtwoord controle plaats.

Maar dat wil niet zeggen dat als er een jaar later een verhuizing voor het domein wordt aangevraagd, de persoon die destijds de code heeft ingezien, daartoe nog steeds bevoegd is.

Dit kan immers ook een ex-werknemer zijn geweest, die inmiddels de laan uit gestuurd is, of een webdesigner die destijds de inloggegevens van de klant heeft gehad.
Een klant kan zijn wachtwoord bij ons veranderen om deze buiten te sluiten, maar er is geen optie om het token van SIDN te veranderen.

De 5 dagen wachttijd bij SIDN is gewoon een fout in het proces.

Indien dat zo is, dan zou dat proces door SIDN aangepast moeten worden.
Maar niet door een e-mail naar de klant te sturen, dat die de latende registrar moet gaan bellen.


Of het echter een proces fout is, weet ik niet.
Bij de meeste extensies hebben ze naast de code zelf, nog een tweede beveiliging, om fraude tegen te gaan.

Door naast de authenticatie code, een e-mail bevestiging van de domeinnaamhouder te verlangen.
Of de code een beperkte houdbaarheidsduur te geven. (.eu extranet codes die 30 dagen geldig zijn).
...of een wachttermijn, waarbinnen de domeinnaamhouder stennis kan schoppen, als er iets niet in orde is.

@Paul: een stille tip: ga hier niet verder op in.

@maxnet: het is geen procesfout, je staat volledig in je gelijk. Zo denkt de taskforce er ook over. Alleen SIDN houdt dit tegen (of hoe ze het ook anders netjes willen verwoorden). Ik wil je vragen je mening erover te uiten bij SIDN.

Ik moest zojuist een .gr domein verhuizen, ik klop de naam in, klop de token in en was 10 minuten later verbaasd:

Code:

Log entry:  	
2010-03-30 15:01:01 [INITIATED] transfer of domain xxx.gr
to xxxx requested by xxxxx
2010-03-30 15:10:16 [SUCCESSFUL] transfer of domain
xxx.gr from UNKNOWN (UNKNOWN) to () SUCCEEDED

@ SIDN: zo moet het dus.

Oorspronkelijk geplaatst door WH-Tim

@Paul: een stille tip: ga hier niet verder op in.

@maxnet: het is geen procesfout, je staat volledig in je gelijk. Zo denkt de taskforce er ook over. Alleen SIDN houdt dit tegen (of hoe ze het ook anders netjes willen verwoorden). Ik wil je vragen je mening erover te uiten bij SIDN.

Tim, we gaan toch niet proberen dit issue wederom in een doofpot te stoppen?
Het is gewoon onjuist dat auth codes niet gewijzigd kunnen worden. Hierdoor ontstaan situaties zoals maxnet aangeeft.

Daarnaast ben ik een groot voorstander van levensduur beperking op tokens.
Het realtime inzien van tokens is dan ook geen slecht iets maar zou juist aangemoedigd moeten worden.

Ik weet dat over het tokenverhaal veel wroeging is ontstaan bij EPP taskforce leden...

Oorspronkelijk geplaatst door groenleer

Het is gewoon onjuist dat auth codes niet gewijzigd kunnen worden.

Probeer eens een houderwijziging, krijg je er gratis een nieuwe token bij

Leuke workaround, ware het niet dat de oude houder bij mijn weten en bericht krijgt dat het eigendom is gewijzigd van de domeinnaam.

Daarnaast is dit geen reële optie als je netjes van de expliciete handle's gebruik maakt. (Ofwel een genormaliseerde database na streeft).


De zelfde handle gebruiken bij meerdere domeinen voorkomt ook een stapel post bij de klanten in een onverhoopt faillissement. Immers voor elke houderhandle hoeft maar een brief verzonden te worden met alle daaraan gekoppelde domeinnamen.
In het verleden zagen we nog wel eens dat bepaalde partijen een complete postzak konden verwachten omdat een budget reseller geroyeerd was bij het SIDN.

@groenleer: volgensmij heb je niet goed gelezen. Lees die laatste zin van mij nog eens. Dat ik paul een tip geef is omdat hij dingen zegt die onwaar zijn, en als hij daarop verder borduurt is dan niet bepaald handig.