Digital Sovereignty

This page documents the external dependencies of this website and its underlying infrastructure, including vendors, jurisdictions, and legal frameworks.

The goal is not to claim independence from regulation or from the internet as a whole, but to be transparent about where control resides, how dependencies are distributed, and what the practical consequences would be if any single party were to become unavailable or intervene.

Modern internet services inevitably depend on third parties. The question is not whether dependencies exist, but where, how concentrated, and under which jurisdictions.

This page outlines how DNS, hosting, routing, e-mail, and domain registrations are structured, which legal frameworks apply, and how resilient the overall system is against vendor failure, legal pressure, or unilateral takedown.

The personal goal behind this design is to minimise single points of failure — technical, legal, or organisational.

In this context, sovereignty refers to the distribution of control rather than absolute independence. It describes how legal jurisdiction, operational responsibility, and technical authority are deliberately separated so that no single provider, registry, registrar, or legal framework can unilaterally disable or fundamentally control essential services.

This approach focuses on practical resilience and transparency: understanding where dependencies exist, which parties have influence over which components, and what the consequences are if any single dependency fails or intervenes.

Many internet services depend on third parties for critical functions such as DNS resolution, certificate issuance, and hosting. By documenting where control lies and how dependencies are structured, this page provides an engineering view of resilience and risk, not a claim of absolute independence.

DNS hosting and authority

Authoritative DNS for this site is intentionally split across multiple name servers, top-level domains, registries, registrars, hosting providers, and legal jurisdictions. The goal is to minimise single points of failure at both the technical and jurisdictional level.

Design goals

• Avoid reliance on a single registry, registrar, or jurisdiction
• Separate DNS authority (control plane) from DNS hosting (data plane)
• Ensure that loss or intervention by any single party does not fully disable DNS resolution

Name server structure

Two groups of authoritative name servers are used:

• US-registry–dependent name servers, using .com, .net, and .org domains registered with US-based registrars
• EU-registry–dependent name servers, using .de and .eu domains registered with a European registrar operating under Swiss and EU legal frameworks

Both groups serve equivalent DNS data but are subject to different legal and organisational constraints.

Current authoritative name servers

Glue records

Glue records are a critical factor in DNS resilience. Where present, glue records allow resolvers to reach authoritative name servers without relying on additional DNS lookups, reducing circular dependencies and control-plane coupling.

Glue record availability varies by registry and registrar tooling.

DNSSEC

All authoritative zones are signed with DNSSEC and have DNSSEC correctly configured end-to-end.

• Each zone uses a Key Signing Key (KSK) generated and stored in a Hardware Security Module (HSM).
• The KSK is published and registered at the respective registries.
• Zones are signed using a software-based Zone Signing Key (ZSK).
• ZSKs are rotated on a regular schedule (currently quarterly).

This approach separates long-term trust anchors from operational signing keys while limiting the impact of key compromise.

Notes and limitations

• The absence of glue records for some US-registered domains is a registrar limitation rather than a design choice.
• Name servers without glue remain authoritative but introduce additional resolution dependencies.
• Hosting locations and DNS software are independent of registry and registrar jurisdiction.
• Registrar concentration for US-based TLDs is a known limitation and may be addressed in the future.

Future direction

The authoritative name server set may be further mixed across US and EU-managed domains to reduce reliance on any single registry or legal framework during delegation and resolution.

Web hosting and traffic flow

The primary public entry point for all websites is www.mostertman.com. An alternative access path is available via www.mostertman.eu.

Both entry points ultimately serve the same content but are reachable through different DNS and jurisdictional paths.

Public entry points

• Primary: www.mostertman.com Uses authoritative name servers under .com, .net, and .org
• Alternative: www.mostertman.eu Uses authoritative name servers under .de, and .eu

This provides redundancy at the DNS and registry level, while keeping the application stack unified.

Global ingress and reverse proxy

All public web traffic is terminated on a VPS, hosted at Hetzner in Germany.

This system acts as a global ingress node and performs:

• TLS termination
• Virtual host routing
• Forwarding of traffic to the appropriate backend

Traffic is forwarded over an encrypted WireGuard tunnel to the actual backend systems.

Backend hosting and data location

All websites and their data are hosted on a server located at home in the Netherlands.

• Location: Netherlands
• Connectivity: 1000/1000 Mbit fibre
• Provider: KPN
• Connectivity model: Direct internet uplink

This backend is currently a single point of failure. That said, however:

• Server has an Uninterruptable Power Supply
• Data is on storage with multiple redundancies
• Data is backed up
• Services are designed to be easily deployable to a new environment if necessary

A secondary internet connection (for example via satellite) is being evaluated as a future fallback.

TLS certificates

All public-facing services use certificates issued by Let’s Encrypt.

• Certificates are automatically issued and renewed
• Let’s Encrypt operates under US jurisdiction

This represents a known jurisdictional dependency. An alternative European CA (Buypass, Norway) was previously used but is no longer available for this purpose.

At present, no affordable and operationally viable alternative CA is in use. This risk is accepted while alternatives are being evaluated.

E-mail infrastructure

• E-mail for @mostertman.com, @mostertman.eu (and all other domains) is currently hosted on the same EU VPS that serves as the global ingress node.
• E-mail for @mostertman.org is still being hosted at Google (US) but is slowly being phased out.

Mail routing

• Mail domain: mostertman.email
• MX records: mostertman.email & mx.mostertman.eu
• The mail domain itself uses authoritative name servers under .com, .net, and .org

An EU-based alternative MX hostname (mx.mostertman.eu) was introduced to provide jurisdictional redundancy at the DNS level. It points to the same server.

Mail service characteristics

• The mail server software does not support clustering or high availability
• The VPS hosting the mail service is therefore a single point of failure
• TLS for mail services also relies on Let’s Encrypt
• @mostertman.org still has some legacy and Android vendor lock-in things, but is being phased out

These limitations are known and accepted at this time.

Summary of current single points of failure

The following single points of failure are currently acknowledged:

• Home backend server (hardware and connectivity)
• Home internet uplink (single fibre connection)
• Global ingress VPS (web and mail)
• TLS certificate authority (Let’s Encrypt)
• Non-clustered mail server software

All of the above are explicitly documented, monitored, and considered acceptable risks given current cost and complexity constraints.