Waarmee kunnen we je helpen?
Sorry, je hebt geen toestemming om deze actie uit te voeren. U zal zich eerst moeten registreren (of aanmelden) op Helpburo.eu.
Laatste updates
RCE-kwetsbaarheid in Roundcube: meer dan 80.000 servers in gevaar
Geplaatst door Michel [Support] aan 13-06-2025 07:17

Vooropgesteld: wij verzoeken u vriendelijk dit bericht eerst aandachtig door te lezen (eventueel tweemaal), vóórdat u hierover een supportticket aanmaakt. Indien u toch een ticket instuurt zonder dit artikel gelezen te hebben, behouden wij ons het recht voor om direct technische ondersteuning in rekening te brengen. Alle relevante informatie en uitleg vindt u hieronder. Alvast dank voor uw begrip.

Een gevaarlijk lek, tien jaar onopgemerkt

Op 1 juni 2025 werd een ernstige kwetsbaarheid bekendgemaakt in Roundcube Webmail, een populair webgebaseerd mailplatform dat wereldwijd door zowel hostingbedrijven als eindgebruikers wordt ingezet. De kwetsbaarheid, geregistreerd als CVE-2025-49113, is uitzonderlijk ernstig en scoort een CVSS-classificatie van 9.9. Het gaat om een zogeheten Remote Code Execution (RCE)-fout, waarbij een aanvaller in staat is om op afstand willekeurige code uit te voeren op de server — mits deze over geldige inloggegevens beschikt.

Wat deze kwetsbaarheid extra zorgwekkend maakt, is het feit dat deze al meer dan tien jaar in de broncode van Roundcube aanwezig blijkt te zijn. Alle versies vanaf 1.1.0 (uit 2014) tot en met 1.6.10 zijn vatbaar. In totaal zouden volgens Shadowserver-scans wereldwijd meer dan 80.000 Roundcube-servers direct aan het internet blootstaan, waarvan een groot deel nog niet is bijgewerkt.

Hoe werkt de exploit?

De kwetsbaarheid bevindt zich in de manier waarop Roundcube omgaat met bestandsuploads via de instellingenpagina. Door misbruik te maken van de $_GET['_from'] parameter en een speciaal gemanipuleerde bestandsnaam te uploaden — bijvoorbeeld met een uitroepteken aan het begin — kan een aanvaller sessievariabelen manipuleren. Dit maakt het mogelijk om PHP-objecten te deserialiseren en zodoende willekeurige PHP-code uit te voeren.

Dit type aanval vereist weliswaar een geldige login, maar in de praktijk zijn veel mailbox-accounts zwak beveiligd of reeds gelekt via eerdere datalekken. Bovendien wordt dit lek inmiddels actief misbruikt, en zijn meerdere versies van werkende exploits opgedoken op darknet-forums en exploitmarktplaatsen.

Onze directe reactie op 12 juni 2025

Onze technische teams hebben op donderdag 12 juni direct actie ondernomen nadat duidelijk werd dat de exploit actief misbruikt werd. Vanaf de vroege ochtend tot diep in de avond is er non-stop gewerkt om alle beheerde servers te controleren, bij te werken of waar nodig te deactiveren.

Voor Plesk-servers met recente besturingssystemen zoals CentOS 7.x en AlmaLinux 8.x, is de situatie relatief goed onder controle. In de meeste gevallen werd de beveiligingsupdate automatisch doorgevoerd via Plesk's eigen updatekanaal. Voor servers waarbij deze automatische update nog niet was uitgevoerd, hebben wij direct handmatig ingegrepen en de juiste patch toegepast.

Anders lag het bij oudere Plesk-omgevingen op basis van CentOS 6.x. Dit besturingssysteem is sinds november 2020 officieel end-of-life en ontvangt geen enkele ondersteuning meer van de community, Red Hat, of Plesk zelf. Toch draaien er helaas nog enkele Plesk-servers op dit platform. In deze gevallen hebben onze technici het benodigde kwetsbare Roundcube-bestand handmatig gepatcht. Wij willen hier nadrukkelijk bij vermelden dat het draaien op een dergelijk verouderd OS onverantwoord en risicovol is. Een migratie naar een ondersteund platform is absoluut noodzakelijk.

Ook voor DirectAdmin-servers met een modern besturingssysteem zijn wij direct aan de slag gegaan. Alle Roundcube-installaties die op CentOS 7.x of AlmaLinux 8.x draaiden, zijn gecontroleerd en — waar nodig — handmatig bijgewerkt naar de meest recente, veilige versies 1.5.10 of 1.6.11. Hierin is de kwetsbaarheid definitief opgelost.

De situatie bij DirectAdmin-servers met CentOS 6.x is vergelijkbaar met die van Plesk. Indien een upgrade naar een veilige Roundcube-versie mogelijk was, is dit uitgevoerd. In alle overige gevallen is Roundcube gedeactiveerd en worden gebruikers automatisch doorgestuurd naar een alternatief webmailprogramma zoals Squirrelmail. Wij bieden in deze context dan ook geen enkele verdere ondersteuning op Roundcube onder CentOS 6.x meer aan.

Bijzondere aandacht verdient het scenario waarin Roundcube buiten DirectAdmin of Plesk om is geïnstalleerd — bijvoorbeeld handmatig binnen een LAMP-stack, of in een submap of gebruikersdirectory. Dergelijke installaties vallen buiten ons beheer en onze ondersteuning. Klanten die hiervan gebruik maken zijn zelf verantwoordelijk voor het onderhouden en beveiligen van deze software. Supportaanvragen in deze categorie vallen onder technisch support op basis van uurtarief.

Tot slot: indien u constateert dat Roundcube op uw serveromgeving plotseling is gedeactiveerd of verwijderd, dan is dit vrijwel zeker gedaan door onze technici, omdat de gebruikte versie niet meer te patchen viel. Dit kan te maken hebben met een te oud OS, een te oude Roundcube-release of het uitblijven van updates. Dit gebeurt uitsluitend ter bescherming van uw omgeving, uw e-mailverkeer en uw gebruikers.

Ons dringende advies

Wij roepen iedereen met klem op om nooit te blijven draaien op verouderde besturingssystemen zoals CentOS 6.x. Niet alleen loopt u daardoor grote veiligheidsrisico’s, maar u kunt op korte termijn ook geen support meer verwachten van hostingpanels zoals Plesk of DirectAdmin. Voor migraties naar een moderne omgeving verwijzen wij u naar onze kennisbankartikelen:

  • Voor Plesk servers zie: https://www.helpburo.eu/Knowledgebase/Article/View/plesk-server-vpsdps-migratie-naar-nieuwe-os-besturingssysteem

  • Voor DirectAdmin servers: https://www.helpburo.eu/Knowledgebase/Article/View/directadmin-server-vpsdps-migratie-naar-nieuwe-os-besturingssysteem

Houd er rekening mee dat het momenteel bijzonder druk is binnen onze organisatie. Gemiddeld bedraagt de wachttijd voor het inplannen van een migratie momenteel tussen de 4 en 8 weken, mede vanwege reeds geplande werkzaamheden en vakantieroosters van onze technici.

Ook CentOS 7.x is sinds juni 2024 officieel end-of-life verklaard, maar wordt nog ondersteund door Plesk via het Extended Lifecycle Support (ELS) programma. Bij DirectAdmin is deze ondersteuning momenteel nog aanwezig, al is het zeer de vraag hoe lang dat nog het geval zal blijven.

Tot slot

Cybersecurity is nooit “klaar”. Het is een proces van voortdurend monitoren, patchen en meebewegen met nieuwe dreigingen. Deze Roundcube-kwetsbaarheid toont pijnlijk aan hoe lang een lek onopgemerkt kan blijven, en hoe snel het daarna wereldwijd misbruikt wordt.

Wij doen er alles aan om onze infrastructuur veilig te houden en danken al onze klanten voor het vertrouwen en het geduld. Vragen over deze kwetsbaarheid of de uitgevoerde maatregelen? Neem gerust contact met ons op. Voor omgevingen die buiten ons beheer vallen, verwijzen wij u naar ons technisch supportbeleid.

Blijf altijd waakzaam. En blijf vooral up-to-date.


Meer lezen

[afgerond] Gepland onderhoud – Vervanging APC's/PDU's op vrijdag 13 juni
Geplaatst door Michel [Support] aan 10-06-2025 10:59

Op vrijdag 13 juni 2025 zullen onze datacentertechnici in de ochtenduren onderhoud uitvoeren aan een aantal servercabinetten. Tijdens dit onderhoud worden de laatste resterende verouderde APC-units (American Power Conversion) en PDU’s (Power Distribution Units) vervangen door moderne, op afstand beheersbare modellen.

Dit is een essentiële vervolgstap in het moderniseren van onze stroomverdeling en remote beheerfunctionaliteit binnen de serverinfrastructuur. De meeste cabinetten zijn reeds in een eerdere fase voorzien van nieuwe PDU’s; deze ronde betreft uitsluitend de afronding van deze migratie voor een klein aantal overgebleven racks.

Planning en impact op beschikbaarheid

  • Startijd: vrijdag 13 juni rond 08:00 uur
  • Verwachte eindtijd: rond 13:00 uur
  • Geplande downtime per server: slechts enkele minuten, alleen tijdens het fysiek overzetten naar de nieuwe PDU

Onze technici zorgen ervoor dat alle betrokken hardware nodes en onderliggende servers gecontroleerd worden afgesloten voordat de stroomvoorziening wordt losgekoppeld. Na aansluiting op de nieuwe PDU's worden de systemen weer zorgvuldig en gecontroleerd opgestart. De downtime wordt tot een absoluut minimum beperkt en treft uitsluitend een klein aantal servers waarvan de stroomvoorziening fysiek omgezet moet worden.

Waarom dit onderhoud nodig is

De huidige PDU's die nog in gebruik zijn, voldoen niet langer aan de vereisten voor modern remote beheer, energie-inzicht en operationele betrouwbaarheid. Door het vervangen van deze componenten kunnen we:

  • Stroomcircuits op afstand monitoren en beheren
  • Individuele poorten uitschakelen of herstarten bij incidenten
  • Overbelasting beter detecteren en voorkomen
  • Realtime inzicht krijgen in stroomverbruik per uitgang

Dit zorgt voor hogere beschikbaarheid, betere probleemoplossing op afstand en een verbeterde controle over de fysieke infrastructuur.

Wat is een APC of PDU precies?

Een APC (van fabrikant Schneider Electric) of PDU is een professionele stroomverdelingsunit die in een serverrack wordt gemonteerd. Deze unit voorziet alle aangesloten apparatuur – zoals hardware nodes, switches en storage-units – van een stabiele en betrouwbare stroomtoevoer.

Moderne, zogenoemde Switched PDU’s, beschikken over geavanceerde functies zoals:

  • Individuele poortbewaking en aansturing – elke stroomuitgang is afzonderlijk te schakelen
  • Energiemeting per uitgang – real-time stroomverbruik zichtbaar per aangesloten apparaat
  • Individuele poortbewaking en aansturing – elke stroomuitgang is afzonderlijk te schakelen
  • Beveiliging tegen overbelasting – automatische waarschuwing of uitschakeling bij te hoge belasting
  • Remote reboot-mogelijkheid – bij vastgelopen apparatuur kan op afstand worden herstart

Deze functionaliteit is cruciaal binnen professionele datacenteromgevingen, waarin snelheid, controle en betrouwbaarheid essentieel zijn.

Wanneer de werkzaamheden afgerond zijn, dan zal dit nieuwsbericht vanzelfsprekend aangepast worden. Excuses voor het mogelijk ongemak in deze.

Update (17:10); technici zijn niet overal aan toegekomen vandaag helaas. Dit mede door de exploit inzake Roundcube. Naar verwachting zal men de zaken afronden medio (midden) jullie. Hierover zullen wij nog een nieuw bericht uiteraard plaatsen.


Meer lezen

Netwerkonderhoud Eurofiber afgerond - korte onderbreking toegelicht
Geplaatst door Michel [Support] aan 06-06-2025 06:29

In aansluiting op de eerder aangekondigde werkzaamheden door Eurofiber willen wij u informeren over een tijdelijke netwerkonderbreking die heeft plaatsgevonden tijdens het geplande onderhoud in de nacht van donderdag 5 juni op vrijdag 6 juni 2025.

Zoals gecommuniceerd door Eurofiber vond er in dit tijdsbestek onderhoud plaats op de locatie Eurofiber Cloud Infra Steenbergen, met als doel de kwaliteit en betrouwbaarheid van het netwerk op lange termijn te waarborgen. Het officiële onderhoudsvenster liep van 23:00 tot 06:00 uur (lokale tijd).

Binnen dit onderhoudsvenster, specifiek tussen 23:00 en circa 01:30 uur, is een gedeelte van het netwerk tijdelijk niet bereikbaar geweest. Deze verstoring viel formeel binnen de aangegeven tijdspanne en was dus voorzien als mogelijk gevolg van de werkzaamheden. Toch vinden wij het belangrijk u hierover naderhand expliciet te informeren, in het kader van transparantie en open communicatie. Na 1:30 waren alle (netwerk)diensten weer operationeel. Aangezien de werkzaamheden door Eurofiber worden uitgevoerd op de locatie Dataplace te Steenbergen, zijn ook onze diensten hiervan afhankelijk.

Daarnaast willen wij u attenderen op een tweede punt van aandacht: onze oorspronkelijke aankondigingsmail over dit onderhoud — verstuurd medio maart 2025 — blijkt achteraf gezien niet correct verzonden te zijn naar alle klanten. Hierdoor is deze aankondiging vanochtend alsnog abusievelijk verzonden en mogelijk bij sommige ontvangers dubbel binnengekomen. Wij bieden hiervoor onze oprechte excuses aan. Daarnaast overwegen wij de introductie van een aparte nieuwspagina, waarop aankondigingen van onderhoud, storingen en andere belangrijke meldingen worden gepubliceerd. Deze pagina zal losstaan van ons eigen netwerk en extern bereikbaar zijn, zodat communicatie ook bij netwerkverstoringen gewaarborgd blijft. Hiervoor zal ook een aparte mailing volgen.

Kanttekening; servers zijn niet offline geweest, maar alleen het netwerk bij Eurofiber. Dus servers zijn niet offline geweest en/of gereboot; het onderhoud betrof puur en alleen aan het netwerk bij Eurofiber zelf.

Onderstaand treft u het oorspronkelijke bericht van Eurofiber aan, inclusief de relevante technische details en referentie (MNO 20250515-1):

Eurofiber Cloud Infra would like to inform you that we will be having a scheduled maintenance on our network soon. This work is necessary to continue guaranteeing the high quality and reliability of our network.
We will make sure to minimize the duration of any impact on your connection(s). These activities have been registered as MNO 20250515-1

Time Window Reason of Planned Work Location
from 05-06-2025 23:00 local time till 06-06-2025 06:00 local time Equipment migration Eurofiber Cloud Infra Steenbergen

Our local time is CET in the winter and CEST during the summer.

Preventive maintenance work is carried out to maintain the quality of our network. We are unable to provide a specific timetable or order of works. Please consider that the interruption may last during the complete Service Window.
All devices have parted maintenance.

Port ID Port LABEL Port CID Port Location
2200 ise-nedzone Eurofiber Cloud Infra Steenbergen
2201 ise-nedzone protected prot Eurofiber Cloud Infra Steenbergen


We apologise for the inconvenience the organization of these works may cause and thank you for your understanding.


Meer lezen

Wederom: probleem met FTP-verbinding voor KPN-klanten na recente KPN update
Geplaatst door Michel [Support] aan 23-05-2025 08:36

We hebben hier al reeds eerder melding van gemaakt (zie nieuws van 19 november 2024 en 3 april 2025) en we hebben hier ook al een uitgebreid kennisbank artikel voor aangemaakt (zie hier), maar KPN klanten lezen dit blijkbaar niet. Dus bij deze nogmaals ook als nieuwsbericht, zodat er niet onnodige support tickets hiervoor aangemaakt worden. Bvd. Dit is momenteel nog steeds actueel. Dus als je problemen hebt met FTP en je beschikt over een KPN (internet) verbinding, dan ligt het probleem voor 99% bij de update van KPN! Wij blokkeren geen FTP!

Het originele bericht van 19 november 2024 was als volgt:

Wij ontvangen meldingen van KPN-klanten die geen verbinding kunnen maken via FTP met hun hostingaccount of server. Dit probleem houdt verband met een recente update die door KPN is doorgevoerd en staat los van onze dienstverlening.

KPN heeft naar eigen zeggen op 13 november een beveiligingsupdate uitgevoerd, die heeft geleid tot het blokkeren van uitgaande FTP-verbindingen via de KPN-router. Deze maatregel valt onder het mom van "extra beveiliging", maar kan voor veel gebruikers tot ongemakken leiden, aangezien FTP wereldwijd als standaard communicatiemiddel wordt gebruikt voor het beheren van websites en servers.

Helaas kunnen wij vanuit onze kant weinig doen om dit probleem op te lossen, omdat wij geen toegang hebben tot uw KPN-routerinstellingen. Het probleem ligt dus niet bij onze servers, maar bij de instellingen van uw KPN-router. Om het probleem te verhelpen, dient u zelf in te loggen op uw KPN-router en de regel die uitgaande FTP-verbindingen blokkeert, te verwijderen. Meer informatie over deze situatie vindt u op het KPN-forum via de volgende link: https://community.kpn.com/modems-123/ftp-werkt-niet-meer-op-experia-box-v10-sinds-update-625186

Als u hulp nodig heeft bij het aanpassen van de instellingen, raden wij u aan om contact op te nemen met KPN. Zij kunnen u ondersteunen bij het ongedaan maken van deze wijziging, aangezien deze direct verband houdt met de door KPN doorgevoerde update. Dit staat geheel los van de bereikbaarheid van onze servers.

Dit heeft niks met onze servers en/of dienstverlening te maken, maar puur en alleen met uw KPN verbinding! Dit probleem is anno 2025 nog steeds actueel! Dus maak aub geen onnodige support tickets aan en volg de informatie hierboven op of bekijk het bijbehorende kennisbank artikel hierover: https://www.helpburo.eu/Knowledgebase/Article/View/met-een-kpn-verbinding-problemen-met-verbinden-naar-ftp.


Meer lezen

De verbindingsproblemen die op maandag 12 mei zijn waargenomen bij een deel van onze klanten, zijn inmiddels volledig verholpen. Na grondige analyse door onze technische afdeling, in samenwerking met externe netwerkexperts en uiteindelijk met directe betrokkenheid van een senior engineer van Eurofiber en een engineer van Microsoft, is de bron van het probleem herleid tot een onvolledig doorgevoerde wijziging binnen het netwerk van Eurofiber.

Op vrijdag 9 mei heeft Eurofiber een wijziging doorgevoerd in het routeringsbeleid van een aantal IPv4-adressen. Deze wijziging betrof het verwijderen van een aantal oudere IP-ranges die inmiddels buiten gebruik waren. In dit proces is echter abusievelijk een essentiële filterregel niet opnieuw toegepast op enkele resterende, nog actief gebruikte IP-ranges. Deze filters zijn noodzakelijk om correcte routering richting Microsoft-diensten mogelijk te maken en bestaan onder andere uit toegangsregels die ICMP-communicatie en DNS-resolutie tussen het Eurofiber-netwerk en Microsoft-infrastructuur faciliteren.

Gedurende het weekend zijn hierop slechts sporadisch klachten binnengekomen, wat aanvankelijk geen directe aanleiding gaf om een grotere netwerkfout te vermoeden. Daarbij kwam ook nog eens dat op de website van allestoringen.nl een groot aantal meldingen waren inzake het niet functioneren van Microsoft diensten in zijn algemeenheid. Echter, en pas op maandagochtend, nam het aantal meldingen merkbaar toe, specifiek van klanten die gebruikmaken van Microsoft 365 en Exchange Online. Overige diensten, zoals standaard e-mailverkeer en HTTP/HTTPS-verbindingen, bleven wél volledig operationeel, waardoor de storing zich erg gefragmenteerd manifesteerde en de oorzaak moeilijker te traceren was. En laat netwerk c.q. routerings problemen nu één van de meest lastigste en meest tijdrovende zaken zijn om te troubleshooten.

Een diepgaande analyse bracht uiteindelijk aan het licht dat verbindingen naar Microsoft vanuit enkele IP-blokken abrupt eindigden bij een tussenstation in het Eurofiber-netwerk, dat normaal gesproken als laatste hop fungeert richting Microsoft’s infrastructuur. De traceroutes bevestigden dat pakketten daar niet verder kwamen en ook ICMP-verkeer en DNS-query’s richting Microsoft werden vanuit deze IP-ranges geblokkeerd, terwijl andere IP-ranges – waaronder oudere blokken die al langer actief zijn – geen enkel probleem ondervonden en volledige connectiviteit richting Microsoft 365-servers hadden. Deze stopte overduidelijke bij de volgende hop van Eurofiber: 89-20-160-93.static.ef-service.nl (89.20.160.93) 4.674 ms 4.662 ms 4.626 ms (89.20.160.64/27 range behoort toe aan Eurofiber Nederland).

Uit verder onderzoek bleek dat deze situatie is ontstaan doordat bij het verwijderen van oude IP-ranges de bijbehorende routeringsfilters (ACL's of prefix lists) niet opnieuw of onvolledig zijn toegepast op de resterende actieve IP-ranges. Hierdoor ontbrak een essentieel deel van de toegangsregels voor verkeer richting Microsoft, met als gevolg dat clients vanuit deze IP-ranges geen verbinding konden maken met Microsoft 365-servers, terwijl andere providers en IP-blokken wel gewoon toegang hadden.

Het herstellen van deze fout bleek complexer dan aanvankelijk gedacht. Eurofiber heeft het incident uiteindelijk geëscaleerd naar hun hoogste technische niveau. In de loop van de avond heeft een van hun senior netwerkengineers in samenwerking met een Microsoft-specialist een correctievoorstel opgesteld en dit eerst getest op één getroffen range. Nadat deze test succesvol bleek, is het fix-beleid uitgerold naar de overige getroffen IP-blokken. Rond 01:00 ’s nachts waren alle aanpassingen doorgevoerd en functioneerde de communicatie richting Microsoft 365 en Exchange Online weer zoals verwacht.

Deze storing was volledig het gevolg van een fout in de infrastructuur van Eurofiber, die als netwerkleverancier verantwoordelijk is voor de core routing in het datacenter waarin onze hardware is gehuisvest. Onze eigen routers, switches en servers functioneerden tijdens het gehele incident correct en zonder enige verstoring. Wij hebben dit probleem dan ook niet zelf kunnen verhelpen, daar de toegang tot de relevante routeringsinfrastructuur uitsluitend bij Eurofiber ligt.

Het feit dat dit pas na meer dan twaalf uur is opgelost, komt voort uit de complexiteit van het routeringsbeleid, de betrokkenheid van meerdere partijen (waaronder Microsoft) en het ontbreken van zichtbare netwerkproblemen buiten de Microsoft-diensten. Wij hebben dit incident intern geëvalueerd en zullen in overleg met Eurofiber nagaan hoe in de toekomst beter toezicht kan worden gehouden op kritieke routeringswijzigingen, en hoe communicatie en escalatie sneller kunnen verlopen bij soortgelijke situaties.

We beseffen dat dit voor de betrokken klanten zeer vervelend is geweest en danken iedereen voor het geduld en begrip. Deze situatie onderstreept het belang van zorgvuldig change management op netwerkniveau en het tijdig escaleren van netwerkfouten naar de juiste partijen. Hoewel wij als ISP afhankelijk zijn van de fysieke infrastructuur van derden, nemen wij onze coördinatierol hierin serieus en zullen wij blijven toezien op de kwaliteit en betrouwbaarheid van onze dienstverlening.

Het moge duidelijk zijn dat wij de impact van deze storing, die het gevolg was van handelen binnen het netwerk van Eurofiber, zeer serieus nemen. Dit is inmiddels het tweede incident binnen een relatief korte periode dat direct te herleiden is tot wijzigingen of werkzaamheden aan hun zijde, waarbij het vorige voorval in november 2024 werd veroorzaakt door onvolledig gecommuniceerde netwerkwerkzaamheden binnen hun infrastructuur. Wij begrijpen dat onvoorziene technische problemen kunnen optreden — ook bij gerenommeerde partijen — maar we vinden dat er sneller en adequater gereageerd mag worden op concrete bevindingen van onze technici, zeker wanneer die tijdig en onderbouwd worden aangedragen. In dit kader zullen wij in gesprek gaan met Eurofiber om te pleiten voor een directere en efficiëntere communicatielijn met hun technische support, zodat in soortgelijke situaties sneller kan worden gehandeld en de duur van een eventuele verstoring substantieel kan worden teruggebracht.

Hoewel netwerkstoringen zoals deze zeldzaam zijn, kunnen de gevolgen ervan aanzienlijk zijn. Het blijft een technisch complex en tijdrovend proces om de oorzaak van dergelijke verstoringen te identificeren, op te lossen en die oplossing vervolgens zorgvuldig in te voeren binnen een actief productienetwerk zonder nieuwe risico’s te introduceren. Wij doen er alles aan om onze infrastructuur in topconditie te houden: van tijdige vernieuwing van servers, opslag, geheugen en netwerkapparatuur tot het preventief vervangen van switches, routers en PDU’s bij de geringste signalen van slijtage of instabiliteit. Maar zoals geldt voor elke partij die actief is in een digitaal ecosysteem: volledige garantie op het uitblijven van storingen bestaat niet. De afhankelijkheid van talloze externe factoren, onderliggende systemen en leveranciers maakt dat zelfs een kleine verstoring op één schakel invloed kan hebben op kritieke diensten. Dit zien we niet alleen bij onszelf, maar ook terug bij andere grote partijen — van Cloudflare tot KPN, van banken tot overheden.

Wat wij wél kunnen garanderen, is dat we blijven investeren in preventie, responsiviteit en samenwerking met externe partijen, om de betrouwbaarheid van onze diensten op het hoogst mogelijke niveau te houden.

Nog een kleine toevoeging inzake "Microsoft 365 (zakelijk)"-gebruikers die problemen ervaren met het inloggen. Dit is geen probleem wat naar aan ons te herleiden valt, maar een probleem vanuit Microsoft. Zie ook Tweakers nieuwsbericht hierover: https://tweakers.net/nieuws/234860/ontwikkelaar-deelt-fix-voor-inlogproblemen-outlook-in-microsoft-365.html. Aldaar wordt het probleem ook bevestigd door diverse gebruikers en verder verwezen naar een Youtube filmpje welke de oplossing zou moeten bieden. Voor zover wij kunnen constateren betreft dit alleen zakelijke gebruikers van Microsoft 365 die gebruik maken van zogenamen tenants.


Laatste update inzake storing: 3:50. Laatste aanpassing uitleg 7:35.


Meer lezen

Naar aanleiding van onze eerdere communicatie zijn wij inmiddels gestart met het doorvoeren van de prijsverhogingen binnen het Plesk ELS-programma voor oudere Plesk-servers die nog draaien op basis van CentOS 7.x.

De eerdere nieuwsberichten hierover kunt u via onderstaande links terugvinden:

Voor een volledig overzicht en nadere toelichting over het ELS-programma voor Plesk op CentOS 7.x verwijzen wij u naar het volgende kennisbankartikel: https://www.helpburo.eu/Knowledgebase/Article/View/plesk-prijsverhogingen-en-els-extended-lifecycle-support.
In dit artikel vindt u alle relevante informatie omtrent het ELS-programma en de bijbehorende prijsaanpassingen.

Dit bericht geldt als onze laatste reminder betreffende de prijswijzigingen vanuit Plesk met betrekking tot het ELS-programma.


Meer lezen


Helpburo [Online Support Systeem] - Copyright © 1999-https://www.helpburo.eu Helpburo
Waarmee kunnen we je helpen?
knowledgebase : Domeinnamen
   

Duur van een verhuizing van een domeinnaam in het algemeen

Vaak denken klanten dat een verhuizing van een domeinnaam direct geregeld is. Bij bepaalde TLD's (dus domeinnaam extensies) is dit ook wel zo, maar in de praktijk kan dit soms wel eens anders zijn. Een verhuizing van een domeinnaam hangt van vele factoren af; ten eerste de TLD oftewel extensie van een domeinnaam; zo gaat de verhuizing van een .nl-domeinnaam vaak vrij snel en probleemloos.

Echter bij bijvoorbeeld een .com-domeinnaam kun je weer afhankelijk zijn van de oude c.q. vorige provider (of registrar), daar deze nog akkoord moet geven voor een verhuizing. Dit ondanks het feit dat je een verhuistoken (EPP code) hebt. Ook kan het zijn dat je bij bepaalde TLD's eerst een bevestigingsmail krijg op het "admin"-contact van de domeinnaam; deze moet je bevestigen c.q. accorderen, alvorens de verhuizing überhaupt gestart wordt. Ook kan er bij bepaalde TLD's een "lock" (verhuis blokkade) op de domeinnaam staan; hierdoor is het niet mogelijk om een domeinnaam zomaar te verhuizen en zal eerst deze "lock" verwijderd dienen te worden bij de huidige provider/registrar; dit kunnen wij niet doen, daar de domeinnaam natuurlijk (nog) niet bij ons staat. En zo heeft iedere TLD wel iets wat een daadwerkelijke verhuizing van een domeinnaam kan vertragen.

Over het algemeen is een verhuizing van een domeinnaam binnen 1 (werk)dag geregeld en soms sneller, maar een verhuizing (wederom afhankelijk van de TLD en provider of registrar) kan ook maximaal 5 werkdagen duren. Helaas kunnen wij hierop geen invloed uitoefenen; het is gewoon een kwestie van wachten. Een email sturen of een support ticket inschieten wat de status is van de verhuizing en/of dat uw domeinnaam nog altijd niet verhuisd is, is dan ook niet noodzakelijk. Wij vragen iedere domeinnaam gewoon direct aan voor verhuizing en bij eventuele problemen nemen wij gewoon contact met de klant op. Zo ook met incorrecte verhuistokens (EPP codes) en een eventuele "lock" op een domeinnaam.

Je kan vaak bij een WHOIS zien of een domeinnaam daadwerkelijk aangevraagd is voor verhuizing; zo zien je bijvoorbeeld bij een .com domeinnaam vaak de tekst "Pending" of "Pending transfer" staan. Dat wil dus zeggen dat de verhuizing is aangevraagd en de verhuisprocedure loopt. In dat geval is het dus afwachten totdat de domeinnaam daadwerkelijk over is. En nogmaals; dit kunnen wij niet beïnvloeden.

Domeinnaam na verhuizing niet oproepbaar / zichtbaar op het internet

U heeft een domeinnaam aangevraagd voor verhuizing en deze is volledig afgerond, maar toch is deze nog altijd niet oproepbaar of zichtbaar op het internet. Dat wil niet zeggen dat de verhuizing niet goed is gegaan of dat dit aan onze servers ligt. Dit kan echter verschillende oorzaken hebben; hieronder leggen wij een aantal oorzaken uit die wij het vaakst tegen komen.

Domeinnaam staat niet (correct) aangemaakt op de nieuwe server

Hoe vreemd dit ook mag klinken, toch krijgen wij hier regelmatig mee te maken. Wij krijgen na de verhuizing een email of een support ticket waarbij de klant aangeeft dat de domeinnaam is verhuisd, maar deze nog altijd niet werkt. Vaak gaat dit gepaard met een opmerking of onze servers wel correct werken of dat er iets mis is met de server. Bij controle blijkt dan dat de domeinnaam in kwestie niet eens op de server aangemaakt staat... Tsja, in dat geval is het vrij logisch dat een domeinnaam niet zichtbaar wordt; met een auto kun je ook niet gaan rijden als deze geen wielen heeft, toch?

Daarnaast maken wij ook mee dat men, op de server, de DNS-records (incorrect) heeft aangepast/gewijzigd en dat de domeinnaam hierdoor niet zichtbaar wordt op het internet. Of wat te denken van verkeerde nameservers (ns1/ns2) opgegeven te hebben of ingevoerd te hebben. Dit alles komt vaker voor dan je zou denken. Dus controleer altijd, bij problemen, of de domeinnaam in kwestie aangemaakt staat op de server, of de (originele) DNS records goed staan en of de juiste nameservers gebruikt zijn (een typfout is zo gemaakt). Daarmee voorkom je al een ellende, downtime en onnodige support tickets en/of emails.

Hoge TTL (Time To Live) ingesteld op een domeinnaam (SOA records)

Bij een groot aantal domeinnamen zien wij dat de TTL (Time To Live) ingesteld staat op één dag oftewel 24 uur. Dat wil zeggen dat iedere aanpassing die je doet inzake je domeinnaam (m.b.t. DNS-records) dit 24 uur zal duren alvorens dit zichtbaar zal zijn op het internet. De TTL heeft alleen betrekking op bestaande records; maak je een nieuw DNS-record aan, dan zal deze aanpassing direct zichtbaar zijn, echter pas je deze vervolgens aan, dan zal het dus 24 uur duren. Wel zien wij (gelukkig) een steeds lager ingestelde TTL; doorgaans zien wij 1 uur tegenwoordig. Wijzelf werken doorgaans met een TTL van 5 minuten. Dus iedere DNS aanpassing zal zichtbaar zijn na 5 minuten; denk bijvoorbeeld aan een aanpassing van een A-record of MX-record. Pas je dit bij ons aan, dan zal deze normaliter na 5 minuten zichtbaar/actief worden.

Maar wat heeft dit dan te maken met een verhuizing van een domeinnaam? Nou de TTL wordt opgeslagen door DNS providers en ondanks dat een domeinnaam naar een andere provider en/of server gaat, dan wordt nog altijd door het meerendeel de actuele TTL gehanteerd (uitzonderingen daar gelaten). Dus als deze op 24 uur stond, dan zal de domeinnaam die eerste 24 uur (vaak) nog blijven verwijzen naar de oude locatie, dus server. Hou hier dus rekening mee.

Wanneer de TTL van een domeinnaam op 24 uur (oftewel 1 dag staat) is het verstandig om dit al op voorhand, dus voordat men een domeinnaam gaat verhuizen, aan te passen. En dan pas de domeinnaam daadwerkelijk te verhuizen na die 24 uur. Op die manier weet je zeker dat het één en ander snel opgepakt wordt op de nieuwe server, waar de domeinnaam op aangemaakt staat. Dit is ook aan te bevelen bij een domeinnaam met DNSSEC (zie verderop voor uitleg hierover). Er zijn diverse websites waar je de TTL kunt zien van je huidige domeinnaam, bijvoorbeeld bij MxToolbox hier.

En dan meteen een kanttekening; wij krijgen vaak support tickets van klanten die aangeven dat de TTL op 5 minuten staat. Dat kan best zijn, maar als deze voordien op 24 uur stond en deze is vervolgens aangepast naar 5 minuten, dan duurt het dus eerst 24 uur alvorens de instelling van 5 minuten actief wordt. De oude c.q. vorige TTL instelling blijft gehanteerd worden, totdat deze verlopen is. Dus nogmaals; je huidige TTL staat bijvoorbeeld op 4 uur en deze pas je aan naar 10 minuten, dan duurt het 4 uur alvorens de nieuwe instelling van 10 minuten actief wordt. Hou hier ook rekening mee.

DNSSEC stond actief op de domeinnaam bij de oude registrar/provider

DNSSEC bestaat al sinds 2012, echter wordt dit steeds vaker gebruikt. Maar wat is het precies? DNSSEC voorziet de DNS records van een digitale handtekening, zodat de aanvrager kan controleren of de record die terug komt, authentiek is. Het “spoofen” van DNS, of zogeheten cache-poisoning, is hierdoor niet langer meer mogelijk. Dus het is in feite een extra beschermingslaag t.b.v. je domeinnaam. Dit is natuurlijk een mooi iets, echter levert dit ook (heel) vaak problemen op. Niet alleen bij aanpassingen van bepaalde DNS-records (dan moet DNSSEC opnieuw ingesteld worden), maar dus ook bij verhuizingen. En, zoals wij al eerder aangaven, is DNSSEC een zeer mooie beschermingslaag bij goed gebruik, maar het kan ook voor zeer vervelende problemen zorgen (zeker met een verkeerd of hoog ingestelde TTL; zie hierboven).

Wanneer bij de oude registrar/provider DNSSEC actief stond op de domeinnaam, dan wordt deze dus ook meegenomen met de verhuizing. Dan zal de domeinnaam, ook nadat de verhuizing volledig is afgerond, niet gaan resolven. Immers ontbreekt op de (nieuwe) server de DNSSEC van de vorige server oftewel de digitale handtekening. Aangezien de domeinnaam naar een nieuwe server is verhuisd, dan zal deze digitale handtekening nooit corresponderen. Met als gevolg dat de domeinnaam nooit zichtbaar zal worden op het internet (oftewel resolven). Dit zien wij steeds vaker gebeuren helaas. Dan krijgen wij vaak support tickets of de DNS van de server wel klopt en/of er andere problemen met de server zijn; dit is dus niet het geval. Wij hebben inmiddels meer dan 23 jaar ervaring, dus wij hebben inmiddels meer dan voldoende ervaring inzake het opzetten van servers en DNS configuraties.

Om eventuele problemen inzake het resolven van je domeinnaam te voorkomen met DNSSEC, is het altijd verstandig om DNSSEC compleet te laten verwijderen op voorhand van de verhuizing. En hou ook rekening met de TTL (zie hierboven) en pas eerst de TTL aan, dan DNSSEC verwijderen (op de server en op de domeinnaam zelf) alvorens de domeinnaam aangevraagd wordt voor verhuizing. Een verhuizing van een domeinnaam met actieve DNSSEC én een TTL van 24 uur kan ervoor zorgen dat uw website 1 dag lang offline is. Pas dus hiermee op.

Browser cache en DNS providers

Ook hier krijgen wij veel mee te maken. Domeinnaam is verhuisd naar een andere server en alles staat goed. Op bijvoorbeeld de telefoon wordt de website op de nieuwe server aangegeven, maar op de laptop weer niet. Is er dan iets fout op de server? Of is er iets niet goed met de DNS? Kort door de bocht... Neen. Alles is goed gegaan inzake de verhuizing, echter heb je nog met andere factoren te maken (naast de hierboven genoemde TTL uiteraard), namelijk "browser caching" en DNS providers.

Inzake browser caching; als je een website opent (in welke browser dan ook), dan slaat deze informatie op van een website. Waarom? Om zo sneller te kunnen laden wanneer je deze opnieuw opent; dit maakt een website niet alleen sneller, maar scheelt ook datatraffic. Dit doet iedere webbrowser of je nu Safari, Chrome, Firefox, Edge of welke browser dan ook gebruikt. Uiteraard zijn er uitzonderingen en kan caching ook uitgeschakeld worden, maar dat is zeer uitzonderlijk en dan zou je dit artikel ook hoogstwaarschijnlijk niet lezen. ;-)

Hoe dan ook; doordat er website gegevens opgeslagen worden, kan het zijn dat ook na de verhuizing de website dus (al dan niet gedeeltelijk) uit de cache wordt geladen en hierdoor de oude website en/of locatie aangeeft. Dit heeft dus niks met onze servers te maken of met mogelijke DNS problemen, maar puur en alleen met uw computer, laptop, tablet, telefoon en dergelijke. Je zou dit kunnen omzeilen door het geheugen van de browser cache te legen, CTRL-F5 (werkt niet bij een forward), incognito modus van je browser opstarten, etc. Werkt dit laatste altijd? Nee, want je zit ook nog eens met bijvoorbeeld DNS providers. Maar als wij aangeven dat een domeinnaam actief en/of correct verwijst naar de juiste server, dan kan u met 100% zekerheid aannemen dat dit zo is. Uiteraard kun je dit zelf ook testen via deze handige DNS Propagation Checker. Wanneer deze aangeeft dat de domeinnaam verwijst naar het nieuwe IP-adres, dan kun je er 100% zeker vanuit gaan dat de verhuizing gewoon correct afgerond is en dat het niet aan de server of diens DNS configuratie ligt, maar aan uw browser, computer of DNS provider.

Dan DNS providers. Vooropgesteld; wijzelf (zowel bedrijfsmatig als prive) maken altijd gebruik van een combinatie van twee verschillende (open) DNS providers, namelijk Cloudflare DNS en Google DNS. Hierdoor weten wij zeker dat wij snelle DNS queries hebben en daarnaast ook het snelste DNS aanpassingen zien. Alsook dat deze zeer regelmatig vernieuwd worden. Bij klanten zien wij vaak dat zij nog altijd DNS providers gebruiken van hun internet leverancier (ISP), bijvoorbeeld: Ziggo, KPN, Delta, Caiway, etc. Uiteraard is hier niks mis mee, maar de DNS servers die hun gebruiken voor je internet, lopen regelmatig achter en worden slechts een paar keer per dag vernieuwd (soms slechts één keer per 24 uur). Dus ook dan kan het zijn dat je nog altijd verwezen wordt naar de oude server c.q. locatie na de verhuizing van je domeinnaam.

Wij adviseren altijd om eveneens gebruik te maken van open DNS providers; er zijn veel mogelijkheden, zo gebruiken wij dus een combinatie van Cloudflare en Google, maar als je Google niet vertrouwd zijn er ook voldoende alternatieven. Hoe dan ook; het is (bijna) altijd beter om een open DNS provider te gebruiken, dan die van je internet provider (ISP). Dit zorgt niet alleen voor snellere en actuele DNS queries, maar ook je privacy kan beter gewaarborgd worden alsook je veiligheid tegen malafide websites. Dit laatste twee is weer afhankelijk van het type open DNS provider. Maar hier is meer dan voldoende informatie over te vinden op het internet en hoe je dit gemakkelijk kunt instellen (het beste is natuurlijk via je router, dan wordt dit toegepast op alle internet verbonden apparatuur binnen je netwerk).

En nogmaals; als je zeker weet dat het aan onze servers / DNS ligt, controleer dit eerst dan eens via de DNS Propagation Checker. Als deze het juiste IP-adres doorgeeft van de nieuwe omgeving c.q. server, dan ligt het echt niet aan onze servers en/of DNS configuratie, maar toch echt aan uw eigen apparatuur.

Autorisatiecode / epp codes voor EU namen:
     Deze zijn niet verplicht maar optioneel en kunt u als eigenaar verkrijgen op www.eurid.eu

Autorisatiecode overige ( com, net,org, biz, info )
    Deze kunt u aanvragen bij accountbeheer@  de hostingprovider van u.

Autorisatiecode voor co.uk
     Deze heeft geen autorisatiecode maar een ander manier van kenbaar maken. Dit een zogenaamde pull en push systeem
     U moet aan uw huidige provider zijn co.uk tag vragen en doorgeven aan ons. Wij doen dan een zogenaamde retag en als
     deze naam dan zichtbaar is in de whois kan de andere provider de naam naar zich toe halen ( pull)

Let wel,
U moet altijd eerst opzeggen voordat u deze kunt aanvragen.
Als u opzegt verlengen wij de naam niet meer en moet u dus zorgen voor een tijdige verhuizing.
Een Epp ( autorisatiecode) is slechts 14 dagen geldig in de meeste gevallen. Wij verstrekken deze eenmalig.
Mocht u niet tijdig verhuizen en de naam nog niet verlopen zijn kunnen we kosten in rekening brengen voor het nogmaals versturen van deze code.

Niet tijdig verhuizen kan extra kosten met zich meebrengen. Omdat wij na opzegging niet meer verlengen en u te laat bent met verhuizen
komt de naam in redemption / quarantaine. De kosten om uit quarantaine of redemption halen verschillen per tld tussen de 65 en 380 euro per domeinnaam.

De procedure om een domeinnaam te verhuizen verschilt per domeinnaam extensie/TLD. Om die reden hebben we hieronder een overzicht gemaakt van de meest voorkomende domeinnamen met daarbij toelichting over de door te lopen verhuisprocedure, zo weet u precies wat u nodig heeft of moet regelen om dit soort domeinnaam te verhuizen. De verhuisprocedure kan in sommige gevallen per domeinnaam verschillen.

COM/NET/ORG: Zorg ervoor dat uw WHOIS gegevens actueel zijn, met name het e-mail adres is belangrijk in verband met de bevestigingmail. Vraag de verhuiscode bij uw huidige provider op.
   
NL: Vraag het benodigde verhuis token bij uw huidige provider op.
   
BE/EU: Vraag de verhuiscode bij uw huidige provider op.
   
NU: In sommige gevallen zijn verhuisformulier nodig om de verhuizing af te kunnen ronden, deze zullen wij u per e-mail toezenden.
   
DE: Deze verhuisprocedure kan verschillen, in sommige gevallen wordt gebruik gemaakt van e-mail validatie, in andere gevallen heeft u een verhuiscode nodig. Hiervoor kunt u terecht bij uw huidige provider.

CO.UK: Deze heeft geen autorisatiecode maar een andere wijze van verwerken. Dit is een zogenaamd pull en push systeem.
U moet aan uw huidige provider zijn co.uk tag vragen en doorgeven aan ons. Wij doen dan een zogenaamde retag en als deze naam dan zichtbaar is in de whois kan de andere provider de naam naar zich toe halen ( pull)
Dit verschilt per domeinnaam, om u inzage te geven in de verhuisduur van de meest populaire domeinnamen hebben we hieronder een overzicht voor u samengesteld. De meer exotische domeinnamen en domeinnamen welke niet vaak besteld worden zijn niet opgenomen in dit overzicht, voor informatie over de verhuisduur/verhuisprocedure van een andere domeinnaam kunt u contact opnemen met accountbeheer.

NL: Direct, de domeinnaam verwijst binnen 2 tot 4 uur na verhuizing naar de nieuwe nameservers/de nieuwe locatie.

COM/NET/ORG: Hierbij wordt een mail verzonden naar het admin-c, zodra de verhuizing per e-mail is bevestigd wordt deze in gang gezet. De doorlooptijd verschilt van 1 uur tot 5/10 werkdagen.
    
BE: Direct, de domeinnaam verwijst binnen 2 tot 4 uur na verhuizing naar de nieuwe nameserver/de nieuwe locatie.
   
EU: Er wordt een mail verzonden naar het admin-c, zodra de verhuizing per e-mail is bevestigd wordt deze in gang gezet. De doorlooptijd verschilt van 2 uur tot 5 werkdagen.

DE: Direct, de domeinnaam verwijst binnen 24 uur na verhuizing naar de nieuwe nameserver/de nieuwe locatie.

NU: Na ontvangst van de benodigde formulieren binnen 5 tot 10 werkdagen.
Uitleg over verhuizen .nl Domeinnaam (nieuwe procedure)

Er zijn een aantal stappen bij een .nl domeinnaam verhuizing:

Authorisatie
Zoek eerst uit wat de verhuis/ophefprocedure bij de vorige hostprovider is.
Geef daar tijdig aan dat u de domeinnaam zal gaan verhuizen. (ook om latere misstanden te voorkomen denk aan facturatie)
Vraag ook een bevestiging van de verhuizing bij de oude hostprovider. (voor uw eigen administratie)
Vraag de token op bij de oude provider!



Token (AUTH code)
Een .nl domeinnaam kan alleen verhuisd worden als u het token (AUTH code) ingeeft in het aanvraagformulier.
Het token is een unieke code voor iedere .nl domeinnaam.
Deze code is bedoeld om de domeinnaam tegen ongewenste aanpassingen (zoals een verhuizing) te beschermen.
Dan wel de domeinnaam houder zelf, dan wel de huidige/vorige provider heeft het token, of kan deze opvragen.
De nieuwe host kan dit niet voor u doen.

Een token ziet er ongeveer zo uit:      khylaw5pxero

Starten verhuizing & de verhuisprocedure
Nadat u via het bestelformulier de verhuizing van uw .nl domeinnaam heeft ingegeven + de bijbehorende token heeft ingegeven, wordt de verhuizing van de domeinnaam bij de SIDN aangemeld en staat deze per direct bij de nieuwe hostprovider, de dns zal enige uren later al zijn aangepast naar de nieuwe omgeving.



Geen token? Dan de verhuizing escaleren.
Indien uw oude hostprovider niet meewerkt en u dus geen token kan verkrijgen, dan kan de nieuwe hostprovider op uw verzoek de verhuizing escaleren.

Hiervoor dienen wij uw identiteit vast te stellen. (wettelijk geldig legitimatie bewijs die overeenkomt met de Whois)
Na het vaststellen van uw identiteit en het nieuwe ingediende verzoek bij de SIDN (met de melding dat de oude hostprovider de token niet wil verstrekken) tot het verstrekken van de token wordt het verzoek nogmaals door de SIDN beoordeeld.
Als de overlegde bescheiden in orde zijn zal de SIDN binnen 5 werkdagen de token aan de betreffende nieuwe hostprovider de token rechtstreeks verstrekken.

Hierna wordt bovenstaande procedure vervolgd en zal de verhuizing alsnog doen plaatsvinden!


Domeinnaam via reseller geregistreerd deze geeft geen autorisatie code.

Indien u een domeinnaam heeft geregistreerd via een van onze resellers en deze reseller wil u de autorisatie code niet verstrekken dan kunnen wij hier opvolging aan geven, u dient dan wel de bescheiden te overleggen (e-mails, brief, fax) waarin u de reseller heeft verzocht om de autorisatie code aan u (eigenaar/houder van de betreffende domeinnaam) te verstrekken en dat hij ingebreke blijft!!

Tevens dient u geldige legitimatie te overleggen waaruit blijkt dat u de daadwerkelijke eigenaar/houder van de domeinnaam bent, u kunt dus niet deze procedure door derden (uw nieuwe hostingprovider, webdesigner, etc.) laten uitvoeren! (uitsluitend de eigenaar/houder van de domeinnaam)

Nadat wij deze stukken van u als eigenaar/houder van de betreffende domeinnaam hebben ontvangen zullen wij binnen 5 werkdagen de autorisatie code aan de eigenaar/houder verstrekken.