NL: Webhosting APK

Aanspreekbaarheid van de registrar

De registrar mag bij registratie en beheer uitgaan van de door de aanvrager verstrekte gegevens, tenzij hij weet of redelijkerwijs behoort te vermoeden dat deze onjuist of misleidend zijn. De juistheid en volledigheid van deze gegevens blijven de verantwoordelijkheid van de aanvrager respectievelijk de houder.

Een afgeschermde houdernaam in het .nl-register duidt op het houdertype particulier. Wanneer een houdernaam feitelijk niet bestaat, is in beginsel sprake van een out-of-control-situatie, in die zin dat de registratie niet (meer) aan een verifieerbare houder kan worden toegeschreven. Dit geldt niet indien de onjuistheid onverwijld door middel van een mutatie wordt gecorrigeerd.

Uit hoofde van zijn rol als registrar heeft de registrar slechts beperkte bevoegdheid om zelfstandig wijzigingen in registratiegegevens aan te brengen. Voor zover wijzigingen plaatsvinden op instructie van de registry, geldt bovendien een duidelijke functiescheiding tussen registry en registrar.

De registrar kan, op verzoek van de aanvrager, de houder of een derde, technische of procedurele toelichting of expertise verstrekken, bijvoorbeeld per e-mail. Deze correspondentie heeft uitsluitend een informatief karakter; zij strekt niet tot verificatie of bevestiging van registratiegegevens en daaraan kunnen geen rechten worden ontleend.

Domeinnamen en hosting bij bedrijfsoverdracht

In de praktijk komt het met regelmaat voor dat domeinnamen, waaronder namen die in nameserverinstellingen worden gebruikt en vaak uit de begintijd van de onderneming dateren, op naam van de ondernemer in privé zijn geregistreerd en nadien niet zijn geactualiseerd naar de ondernemingsstructuur. Het betreft hierbij veelal ‘vergeten infrastructuur’ die buiten beeld blijft bij herstructureringen en overdrachten en doorgaans niet als zodanig uit de administratie blijkt.

Bij een bedrijfsoverdracht verdient het daarom aanbeveling deze digitale infrastructuur expliciet te inventariseren en te specificeren in de activa-lijst, alsmede hierover duidelijke afspraken vast te leggen in de koopovereenkomst. In de praktijk blijkt dat dergelijke inventarisaties binnen reguliere administratieve en auditprocessen, waaronder die van accountantskantoren, veelal achterwege blijven wegens de tijdsintensieve aard daarvan. Daarbij dient onderscheid te worden gemaakt tussen enerzijds de rechten voortvloeiend uit de domeinnaamregistratie en anderzijds de contractuele rechtsverhouding met de hostingprovider, inclusief de daarbij behorende beheergegevens, teneinde onduidelijkheid over gerechtigdheid en beschikkingsbevoegdheid te voorkomen. Aansluitend op het passeren van de akte dient de feitelijke en administratieve overdracht onverwijld te worden geëffectueerd, waarbij partijen gehouden zijn hun medewerking te verlenen aan eventuele vereiste handelingen van registrars en hostingproviders.

Indien domeinnamen en hosting op naam van de ondernemer in privé staan, vallen deze niet zonder meer binnen de onderneming en kunnen zij buiten de overdracht blijven. Dit vormt een relevant aandachtspunt in het kader van audit en due diligence, nu dergelijke digitale voorzieningen van wezenlijk belang kunnen zijn voor de continuïteit van de onderneming. Bij overlijden van de ondernemer kan bovendien een situatie ontstaan waarin de toegang tot deze voorzieningen niet of slechts moeizaam kan worden verkregen, bijvoorbeeld doordat een hostingprovider geen toegang tot e-mailaccounts kan verstrekken op grond van contractuele of privacyrechtelijke beperkingen; in voorkomende gevallen kan een rechterlijke uitspraak vereist zijn om toegang te verkrijgen.

Controle op organisatieniveau boven registrarniveau

Voor organisaties is het in de praktijk vaak lastig om een volledig en actueel overzicht te behouden van domeinnamen, hosting en bijbehorende registraties. Met name wanneer meerdere registrars, hostingproviders en administratieve omgevingen betrokken zijn, ontbreekt veelal centrale regie en samenhang.

Initiatieven die regie op organisatieniveau faciliteren, maken het mogelijk om inzicht te verkrijgen in domeinnamen, registraties en verantwoordelijkheden, ook indien deze over meerdere registrars of leveranciers zijn verdeeld. Dergelijke benaderingen kunnen bijdragen aan het versterken van governance, auditability en beheersbaarheid van digitale infrastructuur binnen organisaties, zoals nader geïllustreerd in de bijgevoegde documentatie.

Zie politieke_partijen.pdf en politieke_partijen_hosting.pdf.

Observaties rond registrars en registratiedata

– Effectieve aanspreekbaarheid van de registrar vereist inhoudelijk en technisch adequate communicatie.
– Bij gTLD’s kan de RDAP-service van de registrar meer informatie bieden; op registrarniveau is de zichtbaarheid van registrantgegevens afhankelijk van expliciete autorisatie.
– De rdap.org-validator detecteert niet related.href equals self.href, wat een verboden self-loop vormt: https://github.com/rdap-org/validator.rdap.org/issues/13
– Nederland kan als early adopter bijdragen aan een effectievere IANA-topdomeinendatabase, waardoor RDAP-processen efficiënter kunnen verlopen.

Operationele tekortkomingen in hostingsoftware

– Het bedieningspaneel DirectAdmin kent een structurele tekortkoming in de standaardafhandeling van www-rewrite- en redirectlogica. Hierdoor ontstaan onjuiste of ongeldige HTTP(S)-doorverwijzingen, wat de betrouwbaarheid en consistentie van webdiensten aantast.
– Het beheer van DNSSEC-configuraties en het actueel houden van DANE-DNS-records wordt beperkt door fundamentele ontwerpkeuzes in bestaande hostingsoftware. Aanpassing van deze systemen brengt risico’s op verstoringen met zich mee voor grote aantallen bestaande omgevingen.
– DNS-updates worden in de praktijk uitgevoerd door registrars en hostingpartijen. Hierdoor wordt voortgebouwd op bestaande systemen en neemt de complexiteit toe. Dit onderstreept de noodzaak van een fundamentele herinrichting van de onderliggende structuur.

Ontwikkeling van software

Strategische infrastructuur

– Nederland kan sturen op de ontwikkeling van beheersoftware voor webhosting, met het expliciete doel deze kennis en tooling Europees te ontsluiten.
– Nederland kan toewerken naar een nieuw bedieningspaneel als strategische infrastructuurstap.
– Nederland kan inzetten op eigendom van een robuust en functioneel multi-tenant ticketsysteem.

Doorontwikkeling van bestaande tools

– Het gebruik van Django-applicatiesoftware bij internet.nl kan goed samengaan met algemeen benodigde nascholing.
– Voor internet.nl zou een robuustere omgang met ‘time-outs’ wereldwijd een alternatief bieden voor het doorverwijzen naar andere partijen.
– Voor internet.nl zou een overgang naar een interface-ready tabeldefinitie een logische volgende stap zijn.

E-mailhistorie bij een eenmanszaak (met mandaat)

De e-mailhistorie behorend bij een eenmanszaak is juridisch nauw verbonden met de natuurlijke persoon van de houder en ontbeert zelfstandige overdraagbaarheid. Toegang tot of gebruik van deze e-mailhistorie door derden is uitsluitend mogelijk op basis van een uitdrukkelijk en herroepbaar mandaat of volmacht van de houder, dan wel op grond van wettelijke uitzonderingen, zoals strafvorderlijke bevoegdheden of een expliciet rechterlijk bevel. Indien de houdernaam overeenkomt met de inschrijving in het Handelsregister, is deactivering op grond van een vermeend niet-bestaande houder niet aan de orde. In het verlengde hiervan kan bij overdracht van de onderneming of bij overlijden van de houder een situatie ontstaan waarin feitelijke toegang tot de e-mailhistorie ontbreekt, behoudens tijdig en rechtsgeldig verleende volmacht of tussenkomst van de rechter.

Impliciete, niet-afdoende data (casus SIDN)

1. In de praktijk worden bij het domein amsterdam.amsterdam contact-e-mailadressen gepubliceerd die wel syntactisch valide zijn, maar geen functionerend contactmechanisme vormen. Dit creëert schijn-traceerbaarheid en ondermijnt de transparantie binnen WHOIS/RDAP. Zie: amsterdam.amsterdam
2. In registry RDAP mist semantisch de registrar RDAP hyperlink; een oplossingsdatum ontbreekt.
3. Zoals bij nl.nl bestaan onnodige statussen. Die scenario’s vertragen in 2026 nieuwe software.
4. In het algemeen is een zichtbare registrar wenselijk. Bij sommige langbestaande door SIDN beheerde domeinen lijkt SIDN echter een uitzondering te maken, waarbij de registrarrollen feitelijk ondoorzichtig blijven en binnen de betrokken groep van rechtspersonen geen eenduidig identificeerbare verantwoordelijke entiteit kan worden vastgesteld.
5. SIDN kan naar zakelijk houderschap toewerken voor bij haar bekende .nl-nameserver namen.

Bestandsbeheer van Whois (uitgesproken als “who is”); ook van leveranciers

1. Bestaat de handelsnaam van de registrar / reseller? De registry kan niet verantwoordelijk zijn.
2. Verzorgt de registrar de ‘abuse’ contact informatie? Bereikbaarheid is professioneel.
3. Staan de domeinen in servernamen en van de name servers goed op naam?
4. Staan de IPv4- en IPv6-adresblokken op de gewenste naam?
5. Is de afkorting ‘B.V.’, volgens wettelijk voorschrift, in hoofdletters en met puntjes?
6. Is mogelijke vermelding van domeinen bij de KVK juist?

Regelkringen

1. Staat de handelsnaam op de site in het Handelsregister, en dan niet als uitgeschreven?
2. Staat het KVK-nummer op de site, en is dit nummer juist?

Wet beveiliging netwerk- en informatiesystemen (Wbni)

1. Regelmatige beoordeling van het opsporen en dichten van beveiligingsgaten;
2. Wie komen er allemaal binnen en hebt u daar zicht op?
3. Een doeltreffende reactie op incidenten.

Privacy

1. Is een privénaam niet onnodig openbaar zichtbaar? Worden ook IP-blokken geaudit?
2. Staan privacygevoelige gegevens op een server met MySQL poort 3306 open?

Beveiliging

1. Is HTTPS op de website in orde, ook bij leveranciers?
2. Is DNSSEC op de name servers, in combinatie met de domain provider, in orde, ook bij leveranciers?
3. Is DMARC/DKIM/SPF/DANE (adkim=s; aspf=s;) voor e-mail up-to-date?
4. @www.: ‘v=DMARC1; p=reject;’ ‘v=DKIM1; p=’ ‘v=spf1 -all’ (DDoS aanval kan via wildcard DKIM)
   @www.: ‘v=DMARC1; p=reject;’ [identiek aan zonder www] ‘v=spf1 +a -all’ (www servernaam)
   @www.: ‘v=DMARC1; p=reject;’ ” ‘v=spf1 -all’ (geen DKIM, dan DMARC-reject en zo’n SPF)
5. Is er behoorlijke inrichting van security headers?
6. Is e-mail beveiliging getest met een valse afzender?

Instellingen

1. Werkt HTTP/2 t.b.v. de snelheid?
2. Zal een niet-ondersteunde PHP-versie snel worden uitgefaseerd?
3. Zijn er meerdere MX-servernamen/IP’s als uitwijk voor inkomende e-mail?
4. Is er in de applicatie uitwijk naar een andere uitgaande e-mail service?
5. Werkt u toe naar geen subdomein www in de URL?

Datacenter(s) etc.

1. Is het datacenter in drie ‘availability zones’ gebouwd t.b.v. redundantie?
2. Zijn datacenter/name servers/DNS/applicatie/plug-ins IPv6-klaar?
3. Is de locatie van het datacenter binnen Nederland?
4. Inkomende mailservers upgraden naar / vervangen door OpenSSL 1.1 / TLS 1.3.
5. Zijn applicaties met (Java-)plug-ins (bijv. voor een PDF) getest met OpenSSL 1.1?
6. Zijn snelle SSD-schijven van toepassing? En mogelijk dedicated processoren?

Laatst gewijzigd op 19 maart 2026.