Politiek en providers zijn het eens over oplossing overstapproblemen

Nu nog een oplossing voor de problemen welke soms ontstaan bij het overstappen van de ene naar de andere hoster :-).

Het overstappen van de ene naar de andere hoster is toch niet zo'n probleem, in iedergeval is het sowieso zonder enige downtime mogelijk en dat maakt het toch wezenlijk anders dan internet toegang.

Uch... Arnout, ik had van jou toch verwacht dat de problemen welke soms ontstaan bekend waren... Enkele voorbeelden: Domeinhouders welke hun AUTH-Code met geen mogelijkheid los krijgen, ISP's welke opzeggingen niet verwerken cq geen reactie hierop geven, domeinen opheffen omdat klant aangeeft de overeenkomst te willen stoppen en haar domein wenst te verhuizen (slechts het woord opheffen en domein wordt gelezen).... Moet ik nog even doorgaan? :p

Arjan, de punten die je noemt zijn pure onwil, met kwade honden is het slecht hazen vangen, zegt het spreekwoord. De de onwil van sommige hosters is het probleem, niet het overstappen zelf.

Arnout, de overstapproblemen waar dit artikel eigenlijk op doelt betreffen ook niet meer dan pure onwil. Zowel technisch als theoretisch is een naadloze overstap, met slechts enkele seconden downtime, al jaren lang te realiseren. Pas nu de consumentenbond en de politiek aan de bel trekken komt er een oplossing.

Arjan, natuurlijk niet, het vereist redelijk wat inspanning en samenwerking van alle partijen om een overstap naadloos te laten verlopen, zowel organisatorisch als technisch. Bij een overstap naar een andere hoster, heeft de klant in de meeste situaties enkel zijn data en domeinnaam nodig, in tegen stelling tot het aansluiten van een nieuwe leverancier op een specifieke fysieke telefoonlijn.

Als de oude provider de auth-code van de domeinnaam niet wilt geven (waarbij de mogelijkheid van een fax-tranfer open staat) of zelfs de domeinnaam opheft dan hebben we het niet over een probleem bij het overstappen, maar juist het actief tegenwerken dat de klant uberhaubt weggaat. Het niet verwerken van opzeggingen heeft ook niks met het verhuizen te maken, dat zie je in veel meer branches, zoals bijvoorbeeld bij uitgevers van tijdschriften.

Arnout, valt reuze mee... KPN heeft alleen jaren lang een sloopbeleid gevoerd waarbij de lijn eerst vrij gemaakt moest worden van een ADSL signaal alvoor er een nieuw signaal op geplaats kon worden. Tussen slopen en opnieuw opbouwen zat een (zogenaamde) administratieve periode van een week of 6.

BBNet was een van de eerste partijen binnen Nederland welke in wist te spelen op dit sloopbeleid. Hierdoor konden ADSL verbindingen welke aangesloten waren op het KPN netwerk al redelijk naadloos overgezet worden naar het BBNet Netwerk. KPN heeft door tegenwerken een poging gedaan om bij klanten op deze manier een overstapangst te vormen. Dit laatste is dan ook aardig gelukt... Vandaar dat andere providers met websites kwamen in de vorm van overstappenisnieteng.nl.

Heb zelf 2 jaar lang als monteur rond gezworven in wat KPN centrales....

Dan nog blijft overstappen lastig (probeer maar eens een naadloze overstap te realiseren als het gaat om een belangrijke website met een database). De overstap problemen maken het voor webshops zeer lastig om over te stappen van de ene naar de andere provider.

@ Mark, als je webshop zoo belangrijk is, dat je die 15 minuten midden in de nacht niet kan missen, dan draai je denk ik wel op eigen servers.

Anders is het met wat technische kennis prima te doen.

@Wido:
Er zijn nog steeds access providers die zich niet aan de TTL houden en alle DNS zaken minimaal 12 uur cachen (bijv. @home cached alles 24 uur als ik me niet vergis). Met enige kennis en wat redirects zou het dan nog steeds te doen zijn, echter zien nieuwe klanten daar wel tegen op. De downtime kan tot 5 minuten beperkt worden als je tijdelijk de shop op 2 subdomeinen draait en alles op het oude subdomein forward (bijv. met een 301) naar de tijdelijke url. In tussen kan de DNS zich aanpassen en daarna kunnen alle klanten van de oude url weer gebruik maken.

Klopt, maar dat is niet iets waar hosters iets aan kunnen doen?

Je website verhuizen gaat prima, maar het komt door een andere factor dat het soms wat lastiger gaat.

Dat klopt, maar de klanten ervaren het wel als een belemmering. Daarnaast zit je altijd nog met AUTH codes/locks bij bepaalde extencies. Websites met een .NL-domeinnaam kunnen zonder dat de eindgebruiker er last van heeft van de ene provider naar de andere verplaatst worden.

@Mark: Vergeet vooral KPN Niet... DNS Cache van minstens 48 uur voor iedere partij welke gebruik maakt van Planet DNS Servers. Ernstig voor een partij welke zo groot maar helaas waar.

De Planet DNS Resolving servers cachen zeker geen records 48 uur. Minimale caching tijd staat geloof ik wel op 3600. Dus lager dan dat kun je niet gaan.

Er is ooit wel bij mijn weten een probleem geweest met negative caching die erg lang bewaard bleef als de DNS servers voor dat domein niet conform RFC waren opgezet. Maar dit was een bug in de software.

@Pascal: Verklaar nader aub: DNS verwijzing van bepaalde nameservers worden op DNS servers van Planet opgenomen naar een set foutieve IP-Adressen welke niet in gebruik zijn. Pas na 48 uur wordt bij een nieuwe update de IP-Adressen weer juist verwezen.

Conclusie: Planet Cached de DNS weldegelijk 48 uur.