NL: Hosting 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.

Control op organisatieniveau boven registrarniveau

Voor organisaties is het vaak lastig om volledig overzicht te houden over domeinnamen, hosting en bijbehorende registraties. Zeker wanneer verschillende registrars, hostingpartijen en administraties betrokken zijn, ontbreekt vaak centrale regie.

– Een initiatief zoals domaincontrolregister.org maakt het mogelijk om regie op organisatieniveau te voeren. Daarmee kan inzicht ontstaan in domeinnamen, registraties en verantwoordelijkheden, ook wanneer deze over meerdere registrars of leveranciers verdeeld zijn.
Zie politieke_partijen.pdf. Zie ook manageable action points: politieke_partijen_hosting.pdf.
– Effectieve aanspreekbaarheid van de registrar veronderstelt inhoudelijke, state-of-the-art communicatie.
– Bij gTLD’s verwijst ICANN voor registratiegegevens doorgaans naar de RDAP-service van de registrar. Op registrarniveau kan toegang tot registrantgegevens afhankelijk zijn van expliciete autorisatie.
– Een tekortkoming in de RDAP-implementatie veroorzaakt een dubbele hyperlink (related.href equals self.href, een verboden self-loop): https://github.com/rdap-org/validator.rdap.org/issues/13
– Nederland kan als early adopter toewerken naar normalisatie van de IANA-topdomeinendatabase.
– Nederland kan structureel eigenaarschap organiseren rond een robuust en functioneel ticketsysteem.
– Het bedieningspaneel DirectAdmin vertoont al geruime tijd een structurele tekortkoming in de standaardafhandeling van www-rewrite- en redirectlogica, waardoor ongeldige HTTP(S)-doorverwijzingen ontstaan.
– Nederland kan toewerken naar een nieuw bedieningspaneel als strategische infrastructuurstap.

Ontwikkeling van software

– Als onderdeel van rijksbrede regie kan Nederland sturen op de ontwikkeling van essentiële beheersoftware voor webhosting binnen een nationaal kader, met het expliciete doel deze kennis en tooling Europees te ontsluiten.
– Het gebruik van Django-applicatiesoftware bij internet.nl kan goed samengaan met algemeen benodigde nascholing.
– Voor internet.nl zou omgaan met ‘time-out’ wereldwijd ondergrond bieden tegen het maar wegwijzen naar een andere partij.
– Voor internet.nl zou overgang naar een interface-ready tabeldefinitie voortschrijdend inzicht zijn.

E-mailhistorie bij een eenmanszaak (met mandaat)

De e-mailhistorie behorend bij een eenmanszaak is juridisch ondeelbaar 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, of 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.

Impliciete, niet-afdoende data (casus SIDN)

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
Verder mist in de registry RDAP semantisch de registrar RDAP; een oplossingsdatum ontbreekt.
En bij nl.nl bestaan onnodige statussen. Die scenario’s vertragen in 2026 nieuwe software.
In het algemeen vind ik een duidelijk verantwoordelijke registrar wenselijk.

APK Webhosting

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? T.z.t. gaat dit wereldwijd verplicht worden.
  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. Is het bestand security.txt ingericht, en op de juiste plaats, voor de white hat hacker?
  2. Gaat e-mail naar de comptabele persoon zonder handmatig doorsturen? Verantwoording?
  3. Gaat e-mail naar de systeembeheerder zonder handmatig doorsturen? Snelle oplossingen?
  4. Is een misbruik / abuse contact ingericht door de Registrar? Optioneel gebruik zoals bij .nl?
  5. Is het menu van de domain provider(s) state-of-the-art? Standaard rapportage voor controle?
  6. Werkt de mijns inziens benodigde driemaandelijkse tuning m.b.v. diverse testtools?

Controles door site-ontwerper

  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 10 maart 2026.