Likes: 0
Misschien wel, misschien niet.. ik stoor mij niet echt aan de 5 werkdagen wachttijd bij sommige providers. Althans, ik heb mij er nooit echt aan geërgerd. Gewoon tijdig verhuizen, dat voorkomt een hoop trammelant. Denk dat dat vaker de issue is dan die 5 werkdagen![]()
Nouja goed, ik ga geen 3 pagina's lezen over wat iedereen allemaal wel en niet denkt erover. Laat ik reageren op de eerste hele pagina:
@domenico "En toch blijf ik er bij dat de houder eerst zijn openstaande facturen moet betalen voordat hij zijn domein(en) kan verhuizen..." -> Dat is nog steeds mogelijk en heeft niets met de duur van de verhuizing te maken. Daarvoor is de directe opzegmogelijkheid na het verstrekken van de token, iets wat door SIDN geaccepteerd wordt.
@vic: je kunt in deze situatie 2 keuzes maken. Keuze 1 is om je houders als debielen te behandelen en keuze 2 is om je houders normaal te behandelen. Je kunt een domeinnaam alleen verhuizen met een token. Een token kan alleen opgevraagd worden door de houder. Als de houder de token wilt opvragen en daar dan een jaar niets mee doet dan kun je het niet aan SIDN wijten dat er een probleem optreedt als zijn mailbox gehackt wordt. Wordt zijn mailbox gehackt vrijwel na het ontvangen van de token, dan kun je de token laten resetten bij de SIDN (via je registrar). Wordt er snel verhuisd dan kun je de verhuizing ongedaan laten maken bij de SIDN.
@all: Overigens is een houderwijziging zonder toestemming van de houder keihard strafbaar, dan mogen jullie eindelijk eens het woord "kaping" gebruiken![]()
Maar; gezeur met je hoster bijvoorbeeld, die ineens de hele boel platgooit of weigert je nog langer in zijn DNS te plaatsen. Dan ben je ineens heeeeeel blij dat je per direct naar een ander kunt en niet nog 5 dagen je e-commerce platform plat hoeft te hebben liggen. Tevens is het bij migraties vaak heel handig. Vooraf verhuizen is een oplossing, maar je kunt hierin helaas niet generaliseren: het is niet per definitie altijd mogelijk om eerst de domeinnaam te verhuizen. Ik maak het zelf vrij regelmatig mee...
Mits er praktische (lees: toegankelijk en binnen een uur verwerkt) methoden zijn om een ongewenste verhuizing terug te laten draaien is dat nog wel een werkbare situatie. Het moet in ieder geval niet zo zijn dat een houder hiervoor eerst naar een registrar moet, die eerst via een registrar omgeving een PDF moet downloaden om bezwaar aan te tekenen, dit dan weer op de fax gaat, dat weer met de hand door SIDN wordt afgehandeld... etc.
Als je een domeinnaam snel moet kunnen verhuizen, moet je 'm naar mijn mening ook snel terug kunnen draaien als het ongewenst was, vooral als houder zijnde. Vooral als er geen expliciete bevestiging wordt gevraagd in de vorm van een link. Ik betwijfel dat de .com community positief zou reageren als daar de bevestiging van admin-c komt te vervallen, de lock verdwijnt en er alleen een EPP-code is vereist.
Vic, allen,
Even reagerend ontopic: het verhuisproces informeert wel, maar vraagt geen bevestiging; de authcode is leidend.
Michiel
P.s. "Michiel Henneke, die destijds bij SIDN werkte". Ik werk er nog steeds hoor...
"Het is niet ons probleem" is een wel erg makkelijk antwoord, als je er bewust voor kiest een minder veilige procedure te gaan gebruiken.
Bij de meeste wat grotere providers zal het token in te zien zijn via het beheerscherm.
Dit is bij veel andere TLDs nu eenmaal verplicht, en het is niet handig om voor .nl een andere procedure te hanteren.
Ik heb het dan niet over extensies van exotische landen, maar GTLDs zoals .com en .net die iedereen wel registreert.
Daar staat in de regels dat het opvragen van de authorisatie code niet moeilijker mag zijn dan het doorgeven van een adreswijziging.
Als er in het beheerscherm van de provider een knop zit waarmee de klant zelf kan doorgeven dat deze verhuisd is, dan ben je dus ook verplicht om een knop in te bouwen waarmee de klant de authorisatie code zelf kan opvragen.
Het probleem hierbij is dat het niet vanzelfsprekend is, dat degene die een jaar geleden toegang had tot het beheerscherm (en dus de code in kon zien en noteren), daar vandaag de dag nog steeds bevoegd tot is.
Dat kan immers ook een webdesigner/systeembeheerder/andere ex-werknemer zijn, die inmiddels de laan uitgestuurd is.
Zolang er een tweede vorm van beveiliging is, zoals een e-mail verificatie, de mogelijkheid tot het plaatsen van een lock en/of een wachttijd waarbinnen ingegrepen kan worden, is dat niet zo'n punt.
Maar alleen een authorisatie code geeft wel erg weinig veiligheid.