NL: Nationale Digitale Kaders

De huidige inrichting van de digitale regie binnen het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties bereikt haar structurele grenzen door versnipperde coördinatie, tijdelijke structuren en een onvoldoende scherp onderscheid tussen normstelling en uitvoering. Digitale infrastructuur vormt een randvoorwaarde voor de uitvoering van wettelijke taken en vereist duurzame kennisborging, expliciete normatieve kaders en transparante risico-escalatie, met respect voor de ministeriële verantwoordelijkheid. Tijdelijke taskforces of programmatische expertisecentra bieden daarvoor onvoldoende continuïteit en systematische analyse op systeemniveau.

Een zorgvuldige inrichting van rijksbrede digitale governance vergt dat naamgeving en positionering van organisatieonderdelen nauw aansluiten bij hun feitelijke rol. Wanneer beleidsmatige functies als expertisecentra worden aangeduid, kan het onderscheid tussen kaderstelling, coördinatie en uitvoering vervagen. Juist op het terrein van cloud- en data-infrastructuur — waar het technische werk omvangrijk, continu en hooggespecialiseerd is — verdient terminologie bestuurlijke precisie. Heldere naamgeving versterkt transparantie, aanspreekbaarheid en een evenwichtige toedeling van verantwoordelijkheden.

Institutionele ordening

Nationale Raad voor Digitale Kaders (strategisch – Ministerie van Algemene Zaken)
De Nationale Raad voor Digitale Kaders bereidt rijksbreed normatieve kaders voor digitale infrastructuur voor en agendeert structurele systeemvraagstukken voor bestuurlijke afweging. De Raad verricht geen uitvoering of toezicht, maar waarborgt de samenhang tussen digitale randvoorwaarden en ministeriële verantwoordelijkheid. Structurele digitale knelpunten vormen een vast agendapunt en worden, waar strategische afwegingen noodzakelijk zijn, voorbereid voor besluitvorming op kabinetsniveau.

Nationale Digitale Kaders (normatief)
Nationale Digitale Kaders vormen de normatieve ondergrond voor de digitale infrastructuur van het nationale stelsel. Zij definiëren de randvoorwaarden waaronder digitale systemen, registers en ketens functioneren binnen overheid, bedrijfsleven en samenleving, met als doel rechtszekerheid, continuïteit, controleerbaarheid en bestuurlijke verantwoordelijkheid duurzaam te borgen.

Orgaan Digitale Expertise (tactisch – Ministerie van Binnenlandse Zaken en Koninkrijksrelaties)
Het Orgaan Digitale Expertise functioneert als tactisch voorbereidend orgaan ter ondersteuning van het rijksbrede management van digitale randvoorwaarden. Het verricht systeemanalyses, ontwikkelt normatieve duiding en ondersteunt de borging van digitale kaders binnen departementale en uitvoerende organisaties, zonder beschikkende of toezichthoudende bevoegdheden. Door monitoring juridisch en beleidsmatig te beleggen en expertisemanagement structureel te organiseren, wordt voorkomen dat centrale CIO- en CTO-functies permanent operationeel moeten interveniëren.

Digitale Kenniswisseling (operationeel verbindend – Ministerie van Binnenlandse Zaken en Koninkrijksrelaties)
Digitale Kenniswisseling faciliteert structurele uitwisseling tussen overheid en marktpartijen en vertaalt praktijkervaring naar toepasbare inzichten voor beleid en uitvoering, met behoud van de rijksbreed vastgestelde normatieve kaders.

Rijksinspectie Digitale Infrastructuur (toezicht – Ministerie van Economische Zaken en Klimaat)
De normopbouw binnen Nationale Digitale Kaders geschiedt in een gelaagd proces van analyse, normatieve duiding en bestuurlijke vaststelling, waarbij inzichten uit toezicht, uitvoering en praktijk systematisch worden betrokken zonder dat toezicht en kaderstelling institutioneel vermengen. Toezicht en handhaving leveren feitelijke bevindingen en risico-indicatoren aan ter onderbouwing van aanscherping, verduidelijking of herijking van bestaande kaders.

Strategische context

De ontwikkeling richting een Nederlandse Digitale Dienst verlegt het accent naar uitvoering zonder expliciete normatieve ondergrond, terwijl internationale positionering — onder meer richting ICANN — een duidelijke nationale kaderstelling vereist. De inzet van hyperscale cloudinfrastructuur bij organisaties met een wettelijke registertaak, waaronder diensten van marktpartijen zoals Microsoft (Azure), dient te worden beoordeeld binnen rijksbrede digitale kaders die continuïteit, controleerbaarheid, afhankelijkheidsbeheer en uitvoerbare exit-strategieën expliciet waarborgen.

Tekst – formulering voor experts

In contact met de Rijksoverheid is textforexperts.hostingtool.org voorgesteld als alternatief voor losse mediaoptredens van individuele deskundigen. Het uitgangspunt daarbij is dat complexe digitale infrastructuurvraagstukken — met name op het snijvlak van hosting, DNS en governance — beter geborgd zijn in een gestructureerde kennisomgeving dan in incidentele publieke interventies.

Ervaringen uit recente crisisperioden hebben laten zien dat inhoudelijke deskundigheid gebaat is bij ingebouwde tegenspraak, expliciete normatieve kaders en transparante documentatie. Een thematisch gestructureerd expertplatform kan bijdragen aan consistente kennisdeling en onderlinge toetsing.

Voor Nederlandse datacentra ontbreekt het primair niet aan inhoudelijke expertise, maar aan schaalgrootte en bundeling om deze kennis integraal te overzien en strategisch inzetbaar te maken..

Cloudoperating ligt ver boven het initiële opleidingsniveau van veel IT-opleidingen.

Cloudoperatie bevindt zich op een niveau dat het initiële opleidingsprofiel van veel IT-opleidingen overstijgt en vereist voortdurende praktijkervaring in grootschalige omgevingen. In complexe cloudplatforms zoals Amazon Web Services is zelfstandige nascholing voor developers en cloudoperators onvoldoende om de benodigde diepgang en continuïteit te waarborgen. Structurele borging van praktijkkennis in handboeken, standaarden en gedeelde referentiearchitecturen is daarom noodzakelijk.

Dit vraagt van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties dat uiteenlopende expertisegebieden expliciet worden onderscheiden. Zonder duidelijke functiescheiding vervagen grenzen tussen beleidsduiding, architectuur, operatie en toezicht, wat effectieve samenwerking en wederzijds professioneel respect belemmert. Het herkennen en erkennen van specialistische deskundigheid gaat daarmee verder dan louter het beheersen van technische bediening.

Aanspreekbaarheid van de registrar

De registrar mag bij registratie en beheer uitgaan van door de aanvrager verstrekte gegevens, tenzij hij weet of redelijkerwijs moet vermoeden dat deze onjuist zijn. Een afgeschermde houdernaam in het .nl-register betekent houdertype particulier, bijvoorbeeld ja21.nl. Zie ook krimpenerwaard.nl.

Regie boven registrarniveau

– Een initiatief zoals domaincontrolregister.org maakt regie mogelijk op organisatieniveau. Zie politieke_partijen.pdf. Zie ook manageable action points: politieke_partijen_hosting.pdf.
– Zonder inhoudelijke, state-of-the-art communicatie blijft de registrar beperkt tot een uitvoerende schakel zonder effectieve aanspreekbaarheid.
– ICANN dient, denk ik, bij gTLD-registraties te voorzien in publicatie van gegevens waarvoor op registrar-niveau expliciet autorisatie bestaat. Ik wacht inhoudelijk op de meest gespecialiseerde in de V.S..
– Mijn melding ‘Not yet an error or warning: related.href equals self.href, creating a prohibited self-loop’ komt moeilijk verder: https://github.com/rdap-org/validator.rdap.org/issues/13
– Nederland kan als early adopter, naar mijn normalisatie inzake de IANA-topdomeinendatabase, toewerken.
– Het bedieningspaneel DirectAdmin kent al geruime tijd een tekortkoming in de standaardafhandeling van www-rewrite en redirect-logica, waardoor ongeldige HTTP(S)-doorverwijzingen ontstaan.
– Nederland kan werken naar een nieuw bedieningspaneel — een strategische stap.

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.

Aanleiding: 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 25 februari 2026.