SIDN Labs and the research platform behind a national domain registry

Executive Summary

• SIDN Labs was established in 2011 as the applied research laboratory of SIDN, the organisation behind the Netherlands’ .nl country-code domain. It is an operating unit within SIDN BV rather than a separately incorporated company, university department or autonomous operator of the .nl registry.
• The laboratory’s comparative advantage is access to operational evidence: passive queries reaching .nl authoritative name servers, registration and mutation records, active measurements across more than six million domain names, routing observations, time-service traffic and an experimental network at Nikhef. Systems including ENTRADA, DMAP, Autocast, RegCheck, TimeNL and Tapdance turn those inputs into research, tools and operational advice.
• SIDN Labs works mainly between Technology Readiness Levels 3 and 7. Its documented transfer paths include an abuse-classification dashboard used by SIDN Support, DNS TTL research that prompted changes at several country-code registries and a planned 2026 production rollout of Autocast; other projects, including RPP, NTS Pool, SCION-NL and post-quantum DNSSEC work, remained standards efforts, pilots or experiments at the research cutoff.
• Public evidence supports the laboratory’s technical portfolio and partner network but not a standalone budget, revenue figure, audited headcount, complete tool-maintenance map or verified adoption rate outside SIDN. The current manager position was vacant on 31 July 2026, making leadership continuity, funding transparency and the conversion of research outputs into maintained infrastructure the principal questions for assessing its next phase.

SIDN Labs and the research systems behind the .nl registry

SIDN Labs gives the operator of the Netherlands’ country-code domain a controlled place to investigate problems that cannot safely be tested on live infrastructure. Its work spans DNS measurement, anycast engineering, routing security, abuse detection, authenticated time, post-quantum cryptography and alternative internet architectures. Yet its significance lies less in the number of prototypes it produces than in whether its evidence changes operational decisions, survives implementation and remains clearly separated from the authority of the teams that control live systems.

A registry laboratory for questions production systems cannot safely test

A national domain registry cannot treat live infrastructure as an open-ended experiment. Authoritative DNS must remain available while engineers assess where anycast sites should be placed, how routing changes may redistribute traffic, whether new cryptographic mechanisms are practical and which abuse signals justify intervention. Production teams are responsible for continuity, while academic researchers can study the underlying mechanisms without usually having the same access to long-term operational data or the same responsibility for running a live country-code domain.

SIDN Labs was established in 2011 to bridge that divide. It gives SIDN a controlled environment in which questions arising from the operation of .nl can be measured, tested and challenged before they reach production. Prototypes can fail without becoming registry incidents, researchers can work with conditions drawn from live operations, and engineering teams can review the results before deciding whether a method belongs in the production system.

The laboratory’s importance therefore lies less in any single product than in the process it maintains. An operational problem can become a dataset, experiment, prototype, dashboard, paper or standards proposal, then return to the registry as evidence for a practical decision. That process helps SIDN avoid two recurring weaknesses in infrastructure organisations: urgent fixes that address only the visible symptom, and research that remains too detached from operational responsibility to be deployed.

SIDN Labs sits between those worlds without replacing either. Its value comes from keeping research close enough to production to remain useful while preserving enough separation for ideas to be tested, rejected or revised before they affect national domain infrastructure. The laboratory can make choices more visible and better informed, but the teams responsible for running .nl retain the authority and liability attached to live operation.

SIDN Labs is an operating unit, not a separate company

The public name can make SIDN Labs sound like an independent institute, but the legal and organisational evidence indicates otherwise. SIDN Labs is the applied-research team within SIDN’s operating structure. Since 1 January 2023, SIDN’s operational activities have been carried out by SIDN BV, Dutch Trade Register number 88772896, while the original Stichting Internet Domeinregistratie Nederland retained the .nl delegation and contingency reserve and remained the sole indirect shareholder through SIDN Groep BV.

SIDN Labs sits within that chain and has no separately disclosed incorporation, audited accounts, revenue or valuation. This distinction is not corporate trivia because responsibility follows the operating structure. SIDN’s production teams and legal operator remain accountable for day-to-day registry and authoritative-DNS services, while SIDN Labs can analyse data, operate research systems, recommend changes and collaborate on deployment without independently determining the operational future of .nl.

The distinction also prevents several common category errors. SIDN Labs is not SIDN Fund, which is a separate grant-making foundation, and it is not NLnet Labs, the independent nonprofit that maintains software including NSD, Unbound and Routinator. Nor is SIDN Labs a standards body with authority to approve a protocol or impose a technical rule on registries, networks or software developers.

The laboratory becomes influential when its evidence changes what operators, developers or standards participants decide to do. Its institutional label does not give it command over those organisations, and its proximity to .nl does not turn research recommendations into operating instructions. The difference between influence and control is central to understanding both the laboratory’s value and its limits.

The ownership structure separates public mission from operating liability

SIDN’s 2023 restructuring placed its public-interest mission and commercial operating activities in related but distinct legal layers. The original foundation retained the delegation for .nl and a contingency reserve, while SIDN Groep BV became the ownership link to SIDN BV, which conducts operations. SIDN said the structure was intended to protect the delegation and contingency buffer from operating liabilities.

SIDN Labs therefore works inside a company whose ultimate owner remains the mission foundation rather than inside a conventional venture-backed research business seeking a sale, standalone profit or investment exit. That arrangement gives the laboratory greater patience than a project funded only through short-term grants or product revenue. Research on post-quantum DNSSEC, SCION, authenticated time or new provisioning protocols may take years to produce an operational result, and some projects may correctly conclude that a technology is not ready.

A mission-funded laboratory can treat an unfavourable finding as useful infrastructure evidence rather than as a failed product launch. The structure does not, however, make priorities automatic or remove competition for resources. The foundation, group company, SIDN BV management, production teams and research leadership operate across different areas of responsibility, and the laboratory must still compete for staff, computing resources, managerial attention and access to sensitive operational data.

Its public-interest setting creates room for long-horizon work, but it does not eliminate internal allocation decisions or prevent immediate operational pressures from narrowing the research agenda. The ownership model supports strategic patience without guaranteeing that every worthwhile research question will receive equal attention. It also leaves management responsible for deciding how much of SIDN’s operating capacity should be devoted to research whose benefits may appear only years later.

Registry-derived funding provides stability and dependence

SIDN Labs has no published standalone income statement, so its complete financial position cannot be reconstructed from public accounts. Its financial base comes principally from SIDN, whose consolidated turnover in 2025 was €25,875,333. SIDN reported an operating result of €2,147,090 and a result after tax of €1,570,644.

SIDN’s impact-accounting table listed €700,000 for certain SIDN Labs activities in 2025, up from €600,000 in 2024. A separate account written by SIDN Labs researchers said SIDN structurally allocates 6% of annual revenue to the laboratory. Applying that percentage mechanically to 2025 turnover produces about €1.55 million, more than twice the amount shown in the annual-report line.

The discrepancy should not be resolved by inventing a single figure. The annual report says the community-investment heading covers certain Labs activities, while research directly supporting .nl may be recorded elsewhere in core operations. That is a plausible explanation, but it is not a verified standalone budget or a complete account of the laboratory’s costs.

The defensible conclusion is narrower: SIDN provides recurring institutional funding, but its published accounts do not disclose the laboratory’s full cost. Staff secondments, storage, exchange connectivity, security monitoring, production-team support and infrastructure at Nikhef may be spread across several budgets. A laboratory financed through registry economics has more stability than a grant-only project, but it also inherits exposure to changes in .nl registration volumes, fees, operating costs and the parent organisation’s investment priorities.

The laboratory’s advantage begins with privileged observation

SIDN’s position as a major country-code registry creates a data surface unavailable to most university groups and commercial security vendors. Queries reach .nl authoritative name servers from resolver populations around the world, registrars submit creations and changes, and domain names move through renewal and expiration. Active measurement systems can inspect name-server configurations, DNSSEC, IPv6, mail security, TLS, DANE and web content across more than six million names, while routing feeds and time services provide additional views of network behaviour.

SIDN Labs can combine those perspectives because it works close to the systems that generate them. A university research group may have better access to a particular analytical method, while a security vendor may have wider commercial telemetry, but few organisations possess the same mixture of registry records, authoritative-DNS observations, active domain measurements and operational context. That combination gives the laboratory an unusually rich starting point for questions about infrastructure behaviour.

Observation is not the same as omniscience. A registry sees the domain lifecycle and traffic addressed to its infrastructure, not every application transaction or user intention. A DNS query may come from a recursive resolver serving many people, a scanner enumerating names or an automated security system, while a registry mutation may be routine administration rather than preparation for abuse.

A website snapshot may also become stale within minutes, and a resolver address may represent a large population rather than one person or device. The laboratory’s advantage is therefore not that its data automatically reveals the truth. It is that several incomplete classes of evidence can be examined together, over time, with enough operational context to test competing explanations.

ENTRADA turns transient DNS traffic into longitudinal evidence

DNS packets disappear quickly unless an operator deliberately preserves and organises them. ENTRADA became SIDN Labs’ foundational system for storing and analysing large volumes of queries received by .nl infrastructure. Instead of relying only on aggregate production counters, researchers can examine historical changes in query types, resolver populations, anomalous bursts, protocol adoption and the behaviour of particular infrastructure segments.

The system creates a memory layer around a service whose normal purpose is to answer a query and move on. That historical record allows an event observed today to be compared with earlier states rather than treated as an isolated incident. It also makes it possible to examine whether a change represents a persistent trend, a recurring pattern or a one-off anomaly.

The scale of the former platform illustrates both the value and burden of that memory. By 2022, SIDN Labs described a Hadoop-based research environment containing more than 2.3 trillion rows in a database of about 320 terabytes. It ran across 14 servers with approximately 600 terabytes of storage, 624 CPU cores and 1.6 terabytes of memory.

Those figures describe the earlier environment rather than the newer architecture at Nikhef, but they show that observational advantage depends on physical systems, software maintenance, access controls and researchers capable of interpreting data whose scale can make weak assumptions appear statistically persuasive. ENTRADA makes DNS behaviour queryable, but it does not determine what a pattern means. The analytical value comes from combining the data with sound classification, contextual knowledge and explicit limits.

Query volume is not the same as user demand

Passive DNS data invites a tempting error: treating frequent queries as evidence of human popularity or ordinary resolution demand. SIDN Labs’ 2026 work on zone scanning estimated that roughly one-third of traffic in the observed .nl datasets could be associated with scanning. On one studied day, a scan generated about 2.6 billion queries and accounted for 54% of the traffic received at three sites.

The authoritative infrastructure showed no measurable increase in processing time during that event, indicating substantial spare capacity in the system observed. That finding did not prove that scanning is harmless or that a smaller operator could absorb the same load. It showed that the studied infrastructure had enough capacity to process a particularly large event without a measurable increase in response-processing time.

The deeper finding concerns measurement design. If automated enumeration is not separated from normal resolver behaviour, an operator may optimise capacity, geography or security around the wrong population. A burst may look like sudden user interest when it is a scanner walking through the namespace, while a resolver cluster may appear anomalous because an upstream tool changed its technique.

Access to raw traffic is therefore only the beginning of the analysis. Classification assumptions, observation windows and uncertainty about client identity must remain visible, and the study’s limits matter. Measurements from a small number of days in a technically mature country-code domain cannot be converted into a universal scanner proportion for every registry or authoritative service.

DMAP adds evidence that passive logs cannot provide

Passive traffic shows what resolvers ask, but it does not reveal every technical property of the names being queried. DMAP supplies a complementary view by repeatedly measuring domains and the services associated with them. Across more than six million .nl names, active collection can examine DNSSEC deployment, IPv6 reachability, mail-security configuration, TLS and DANE, name-server behaviour, website content and indicators such as logo use.

The result is a continuously sampled technical population rather than a static list of registrations. Researchers can compare technical configurations over time, identify adoption patterns and connect infrastructure characteristics with other evidence. This makes it possible to investigate questions that authoritative query logs alone cannot answer.

Active measurement has different weaknesses from passive observation. A probe may encounter a temporary outage, trigger rate limiting, be treated differently from an ordinary browser or receive a location-dependent response. Website content may change soon after collection, and a securely configured domain may still serve a malicious purpose while a poorly configured site may be entirely legitimate.

DMAP increases the number of questions researchers can ask, but it cannot determine motive by itself. Its strongest use comes when configuration evidence is combined with registration history, query behaviour and external reports. The resulting picture is more useful precisely because no single source is allowed to carry more certainty than it can support.

Combining registry, DNS and website data improves detection and raises the stakes

SIDN Labs’ anti-abuse work benefits from a position that commercial web crawlers and pure DNS researchers do not share. Registry records reveal creation dates, renewal activity, registrar relationships and later mutations. Passive traffic can show when a name begins attracting queries or automated attention, while active scans can expose hosting, certificate, mail and page characteristics.

Abuse reports add allegations from users, organisations or security providers, allowing machine-learning models to search for relationships among several layers rather than judge a domain from its name alone. That can improve prioritisation and reveal patterns that would remain invisible in a single dataset. It can also help distinguish behaviour associated with malicious registration from behaviour caused by later compromise.

More evidence, however, expands the laboratory’s responsibility. A model that influences operational review may affect registrants who cannot see its training data, thresholds or error rates. Historical abuse feeds may overrepresent easily reported categories and underrepresent less visible harms, while a legitimate business may resemble a known campaign because it uses the same registrar, hosting platform or website template.

A compromised long-standing domain also differs from a domain registered for malicious use, even when both eventually host the same harmful content. SIDN Labs’ research distinguishes those cases, which is an important strength, but any production handoff still requires human review, monitoring for concept drift and a clear separation between suspicion and proof. People affected by false positives also need a practical route through which evidence can be corrected or reconsidered.

Privacy controls are part of the research infrastructure

DNS, registration and time-service data may be technically observable without being ethically equivalent to public statistics. Aggregation can reveal relationships among networks, organisations and user populations that no single packet exposes. A registry laboratory therefore needs controls at collection, storage, analysis, publication and partner access.

The 2022 NTP study provides one documented example. Observed IP addresses were anonymised using Crypto-PAn, and the collection proceeded with approval from SIDN’s Privacy Board. The method preserved structural properties required for analysis while reducing direct exposure of addresses in the research dataset.

One example does not establish a complete governance map for every project. Public evidence does not provide a single project-by-project inventory covering retention periods, access roles, linkage controls, deletion procedures and conditions for university sharing across all SIDN Labs datasets. The absence of such a public inventory does not prove weak governance, but it limits what an external observer can verify.

The laboratory’s open-research model consequently has several layers. Papers, code, interfaces and aggregated findings may be public, while raw operational records may remain controlled because disclosure would create privacy, security or contractual risks. The ability to share enough for scrutiny without turning operational telemetry into an uncontrolled asset is itself an infrastructure capability.

The old Hadoop platform became both an asset and technical debt

A research environment can remain productive long after its architecture stops being desirable. SIDN Labs’ earlier Hadoop-centred platform accumulated years of data, scripts, queries and operational knowledge. That continuity enabled longitudinal studies and made ENTRADA more valuable over time.

The same continuity tied the laboratory to servers installed between roughly 2017 and 2020, a software ecosystem shaped by earlier assumptions about large-scale data processing and management components whose licensing and support conditions could change independently of SIDN. The platform therefore became both an important scientific asset and a growing source of technical debt. Its value increased with the accumulated historical record even as its hardware and software became harder to sustain.

This is a familiar infrastructure paradox. Replacing the platform threatens reproducibility, consumes staff time and requires data migration, while keeping it increases security, reliability, cost and skills risks. The move to rebuild at Nikhef in 2025 should therefore not be described simply as expansion.

It was also a technical reset prompted by ageing hardware and an architecture that no longer matched the laboratory’s intended workloads. The old environment had become evidence of success and a constraint on future research at the same time. That dual status shows why research systems need lifecycle planning even when they are not held to the availability standards of a production registry.

HPM removed one licensing dependency, not the maintenance burden

A change in Cloudera’s licensing made the economics of managing the earlier Hadoop environment less attractive. SIDN Labs responded by developing and publishing HPM, an open-source management tool that replaced part of the commercial layer. The decision demonstrated a useful form of operator agency because a laboratory with sufficient engineering capacity could reject a vendor transition and preserve control over a critical workflow.

Publishing the replacement also allowed other organisations to inspect or reuse the adaptation rather than leaving it as a private fix. That decision fitted the laboratory’s wider commitment to open research and technical portability. It showed that an infrastructure operator did not have to accept a licensing change simply because a commercial management layer had become embedded in an important system.

Open source did not make the dependency disappear. The burden moved from licence fees and vendor conditions to internal development, security updates, compatibility work and long-term stewardship. A tool built to solve one organisation’s immediate problem may also outlive the architecture that justified it or lose its maintainer when staff move.

HPM therefore illustrates both the value and cost of technical exit. SIDN Labs avoided one imposed commercial path, but it still had to modernise the wider platform later. Portability matters when an organisation can leave a component without losing its research state, not when every self-maintained replacement is assumed to remain optimal indefinitely.

The Nikhef rebuild separates experimental failure from .nl production

The new research environment at the Nikhef data centre in Amsterdam was designed around needs that differ from those of the production registry. Research workloads require flexible computing capacity, large data volumes, rapid creation of isolated environments and permission to fail. The .nl service requires tightly controlled change, high availability and much less tolerance for unexpected interaction.

Moving the laboratory’s infrastructure away from the production network created a clearer failure boundary. It also placed the platform close to a dense Dutch research and interconnection ecosystem. The design allowed the laboratory to support more varied workloads without forcing every experiment into the assumptions of the older Hadoop model.

The reported base included Kubernetes, Proxmox, S3-compatible object storage, Apache Spark and Jupyter notebooks, integrated with organisation-wide security monitoring and controls aligned with ISO 27001. The combination supports virtual machines, containers, object storage and interactive analysis. It also gives researchers more flexibility to isolate workloads and adapt the platform as analytical methods change.

Physical relocation and installation of the base platform were reported in 2025, while more detailed material indicated that application and data migration would continue into early 2026. The safe description at the research cutoff is therefore that the platform was rebuilt and relocated, not that every historical workload had been conclusively migrated. Separation improves resilience only when the remaining data paths, identities and operational dependencies are also understood.

Direct exchange visibility expands the routing questions that can be tested

SIDN Labs intended its experimental network to connect directly with AMS-IX and NLix and receive an independent, real-time BGP feed. This matters because route collectors and third-party measurements reveal only the perspectives available to them. A laboratory connected to internet exchanges can observe changes with less delay, establish controlled announcements and correlate path behaviour with its own DNS and anycast experiments.

That visibility is especially useful for studying route hijacks, routing-security mechanisms and the distribution effects of policy changes. It gives researchers another vantage point from which to compare control-plane announcements with the traffic and services they operate. It may also improve the reproducibility of experiments that would otherwise depend entirely on external collectors.

Direct connectivity does not create a complete view of global routing. BGP is a collection of local decisions made by autonomous networks, and paths visible at one exchange or collector are not identical to those selected elsewhere. Some commercial agreements and routing policies remain private, while traffic does not always follow the path that control-plane data appears to imply.

The advantage lies in adding a well-instrumented vantage point and the ability to run reproducible experiments. It does not give SIDN Labs central authority over routes or a complete reconstruction of the internet. The laboratory can make hidden dependencies more observable while the networks carrying traffic retain control of their own policies.

Technology Readiness Levels preserve the right to fail

SIDN Labs describes most of its work as falling between Technology Readiness Levels 3 and 7. The range begins after basic principles have been identified and extends through prototypes and demonstrations towards systems tested in relevant environments. It stops short of implying that every output has reached routine production operation.

This self-positioning is an important safeguard for interpreting the portfolio. A paper, open-source repository, pilot with registrars, public experimental service and operational dashboard represent different levels of maturity. Treating them as equivalent would exaggerate the readiness of some projects and obscure the operational significance of others.

Intermediate readiness gives the laboratory permission to produce negative results. A routing-security implementation may be too immature, a cryptographic format may sign a large zone successfully but remain unsuitable for resolver validation, and a machine-learning model may identify useful candidates while producing too many false positives. Such findings can still reduce future risk by exposing constraints before a production team commits.

The danger comes when enthusiasm compresses the maturity ladder and presents a promising prototype as a completed infrastructure transition. SIDN Labs’ credibility depends on preserving the distinctions between demonstration, adoption and sustained operation. Its strongest work is often that which clarifies why a technology should not yet be deployed.

Autocast makes anycast placement a measurable decision

Authoritative DNS anycast uses multiple sites announcing the same service prefix, allowing BGP policy to direct resolvers towards reachable instances. Choosing sites is difficult because geographic distance, network topology and routing policy do not align neatly. A new location can improve latency for some resolver populations while attracting traffic in unexpected ways or delivering little benefit relative to cost.

Traditional planning may require repeated deployments and live announcements before an operator understands the effect. Autocast uses unicast measurements to estimate the median response time of candidate combinations of anycast sites without first announcing the service from every proposed location. The method seeks to reduce the amount of trial and error required before a new site or combination of sites is introduced.

SIDN Labs reported that Autocast could estimate the measured metric with approximately one-millisecond accuracy under the studied conditions. That qualification matters because the result is not a promise that every end user’s experience can be predicted to within one millisecond. Resolver placement, transient routing and measurement coverage remain constraints.

The stronger claim is operational: Autocast turns part of a manual and expensive search into a repeatable recommendation process. Its announced production rollout with SIDN’s DNS team in 2026 would test whether that analytical advantage survives the demands of live planning and maintenance. The operational value will ultimately depend on whether predictions remain useful after routing conditions, traffic distributions and cost assumptions change.

BGP Tuner and Autocast address different parts of the anycast problem

Autocast asks which combination of sites is likely to produce favourable response times, while BGP Tuner asks how a change in routing policy may redistribute traffic across sites already participating in an anycast service. The tools operate in the same architectural domain but address different control points. Site selection is a capacity and topology decision, while policy tuning is an announcement and traffic-engineering decision.

Using both could help an operator reason from the proposed footprint to the expected distribution of traffic. One model cannot replace the other because a well-chosen set of sites can still be poorly balanced by routing policy, while careful policy changes cannot compensate for a footprint that lacks useful locations. The two approaches are complementary rather than interchangeable.

BGP Tuner emerged from the SAND collaboration with the University of Twente and NLnet Labs. It demonstrates how SIDN Labs can take an operational question, combine it with external expertise and produce a reusable prototype. The collaboration also subjects the method to perspectives outside SIDN’s own production environment.

Its predictions remain conditional because networks may alter policy, routes may change after measurement and traffic may not follow the control-plane path an observer expects. The useful discipline is to compare predicted and observed outcomes rather than treat the model as an oracle. Anycast management remains a feedback loop of measurement, modelling, change, observation and revision.

The DNS TTL study shows how evidence can influence without control

Time-to-live values determine how long recursive resolvers may cache DNS data. Very low values increase query volume and may add latency when caches expire frequently, while very high values slow the propagation of legitimate changes. Registry operators must balance responsiveness against caching efficiency rather than assume that one setting is optimal for every environment.

SIDN Labs studied practices among country-code registries and contacted eight operators whose configurations appeared suboptimal. Three reportedly changed their settings. In the clearest published case, median latency for .uy fell from 28 milliseconds to 8 milliseconds, while the 75th percentile fell from 183 milliseconds to 21 milliseconds.

The result is notable because SIDN Labs did not command those registries. It produced measurements, communicated the findings and allowed independent operators to decide whether to act. This is a stronger example of infrastructure influence than a broad claim about thought leadership because the chain from observation to configuration change and measured result is visible.

The outcome should still be kept in proportion. One country-code domain’s improvement does not guarantee the same result elsewhere because traffic patterns, resolver behaviour and starting configurations differ. The important mechanism is that evidence crossed organisational boundaries through voluntary adoption while the external operator retained responsibility for the change.

Anteater and Tapdance make DNS behaviour easier to inspect

ENTRADA provides the historical data substrate, while tools built above it translate that data into forms better suited to operational questions. Anteater monitors authoritative name servers using passive DNS observations. Tapdance, announced in May 2026, provides near-real-time DNS statistics through an open-source application.

These tools reduce the distance between a research database and the people who need to understand current behaviour. They can expose anomalies, compare traffic categories and support investigation without requiring each user to rebuild the full analytical pipeline. In practical terms, they turn a large research dataset into interfaces that operational staff and external researchers may be able to use more directly.

Interfaces can also hide assumptions. A graph may appear authoritative even when its categories depend on uncertain classifier labels, incomplete vantage points or choices about aggregation. Near-real-time statistics improve responsiveness but may encourage premature interpretation when the baseline is noisy.

Public release does not establish broad external adoption, and the available material does not provide a uniform support commitment for every tool. Operational value therefore depends on documentation, update cadence, reproducible queries and the ability to move from a dashboard indicator back to the underlying evidence. Observability is strongest when abstraction helps users ask better questions rather than replacing investigation with a single score.

Abuse research improves when malicious registration is separated from compromise

A newly registered domain created for phishing presents a different intervention problem from a legitimate long-standing domain whose website has been compromised. Registration data may be particularly useful in the first case, while the second may require evidence from hosting, content and incident-response systems. Treating both as one category can direct action towards the wrong party and distort model training.

The COMAR collaboration among SIDN Labs, Afnic Labs and Université Grenoble Alpes focused on classifying abuse reports along this distinction. SIDN later said the work contributed to a dashboard used by SIDN Support. The transfer into a support workflow demonstrates a practical research path in which academic methods were applied to reports connected to registry operations and then translated into a system used by operational staff.

The dashboard did not make the underlying judgement infallible. Reports may be incomplete, duplicated or maliciously submitted, while a compromised site may change before review. Classification can structure evidence without turning uncertain information into proof.

The value lies in separating operational categories and helping staff decide which evidence and response path are appropriate. Where research affects registrants, the responsibility boundary must remain visible. The model assists, but accountable operational processes make the decision.

Machine-learning outputs should support review, not become verdicts

SIDN Labs uses machine learning in several contexts, including the detection of potentially malicious registrations, classification of abuse reports, identification of website types, analysis of renewal behaviour and discovery of unusual registry mutations. These applications differ in labels, time horizons and consequences. A system that prioritises possible phishing domains should not be evaluated or governed in the same way as a system studying renewal patterns.

A supervised model trained on known abuse inherits the quality and bias of those labels. An unsupervised anomaly system can identify unusual relationships without previously labelled malicious examples, but unusual behaviour is not necessarily harmful. Both approaches require continuing evaluation as attackers and legitimate users change their behaviour.

A production-quality pipeline needs more than an accuracy figure. Training and test periods must avoid leaking future information, while features tied to a registrar, hosting provider or language may become proxies for characteristics that are not causal. Concept drift must be monitored because the behaviour being modelled will change.

High-risk outputs require human review, and the process should distinguish a prioritisation signal from evidence sufficient for intervention. No reviewed material showed SIDN Labs automatically suspending domains solely because an experimental model produced a score. That absence should be preserved rather than replaced with assumptions about enforcement.

Registry-mutation analysis moves detection upstream without proving intent

The most recent verified SIDN Labs publication at the 31 July 2026 cutoff was a thesis published on 10 July on monitoring suspicious DNS registry mutations through an ensemble anomaly-detection framework. The work examined behavioural and relational changes in registry data rather than relying entirely on previously labelled malicious cases. Such an approach may reveal patterns that a name-based filter misses.

An account changing many domains in an unusual sequence, relationships among objects that rarely change together or transitions that diverge from earlier behaviour may all deserve review. Moving detection upstream is attractive because intervention may become possible before harmful content reaches many victims. It also offers a way to detect unfamiliar behaviour that has not yet appeared in historical abuse labels.

The cost of false positives is correspondingly high. Mergers, portfolio migrations, registrar operations, bulk DNS changes and legitimate security responses can all create unusual patterns. An anomaly model identifies where expectations fail, but it does not explain why.

The thesis confirms that SIDN Labs continued to explore this layer in 2026. It does not establish operational integration, automated action against domains or a measured reduction in abuse. Those outcomes would require a separate production design, error analysis and governance record.

ForSale shows how registry coordination can create a market signal

The ForSale pilot used a DNS label to indicate that a domain name was available for sale. By December 2025, participating registrars had reportedly added the signal to more than 250,000 .nl names. The project is distinct from abuse detection and performance engineering because it explores whether a registry ecosystem can publish a machine-readable market status through infrastructure already associated with the name.

Such a signal could reduce the need for buyers to infer availability from landing pages or fragmented marketplace listings. It could also give registrants a standard mechanism for publishing their intention without relying on one commercial marketplace. The registry would provide the coordination layer rather than become a party to the sale.

The scale demonstrates registrar participation, not a transformation of the secondary domain market. The label must be accurate, removable and resistant to misuse, while registrants need to understand what is being published. Marketplaces and search tools must decide whether to use it, and other top-level domains would need compatible practices for the signal to spread widely.

The registry did not create the commercial relationship. It supplied a coordination mechanism that other actors could choose to adopt. Its value depends on whether the record continues to reflect the holder’s intention and whether external systems find the signal useful.

RPP treats a registry protocol constraint as a cloud-architecture problem

The Extensible Provisioning Protocol used between registrars and registries is stateful. A client opens a session, authenticates and maintains a connection whose context remains associated with a server. The design is mature and widely implemented, but it complicates horizontal scaling in containerised environments.

Load balancers cannot always send any request to any available instance because session state and ordering matter. Large volumes of information queries may also compete with more consequential create or update transactions within the same service architecture. These constraints become more visible as registries adopt distributed deployment models and seek to separate workloads.

SIDN Labs’ RESTful EPP proposal, later developed as the Registry Provisioning Protocol, seeks to preserve registry semantics while making requests self-contained and compatible with HTTP-oriented infrastructure. Stateless handling could allow instances to scale independently and permit separate capacity pools for different transaction classes. The attraction is operational rather than cosmetic because modern deployment tooling becomes easier to use when protocol assumptions do not bind a client to a single process.

The risk is that a new interface must reproduce years of security, error handling, transaction integrity and registrar practice. Removing state from one layer may move complexity into tokens, idempotency, audit and distributed consistency elsewhere. A more cloud-compatible interface is not automatically a simpler registry system.

Standards adoption is a chain of decisions, not a publication event

RPP moved from an internal proposal towards IETF working-group activity with participation from registries including DENIC and Internetstiftelsen. That route gives the design wider scrutiny and reduces the risk that it becomes a SIDN-specific interface presented as a general protocol. It also exposes the proposal to implementers and operators whose requirements may differ from those of .nl.

The process does not make RPP a completed standard. At the research cutoff, drafts, requirements and prototype plans remained part of an ongoing process expected to continue through 2027 before production use could reasonably follow. Publication of a draft marks the beginning of a broader coordination problem rather than its resolution.

A protocol becomes infrastructure only through several linked decisions. Standards participants must agree on semantics and security, independent developers must produce interoperable implementations, and registries must conclude that the benefits of migration exceed integration costs. Registrars must update software and procedures, while monitoring, incident response and compatibility with existing EPP deployments must be proven.

Procurement and change windows may lag technical agreement by years. SIDN Labs can contribute code, measurements and implementation experience, but it cannot declare the ecosystem ready. Running systems, rather than document status, reveal whether the coordination problem has been solved.

The BGPsec testbed was useful because it produced an unfavourable answer

BGPsec aims to provide cryptographic validation of the autonomous-system path contained in routing announcements. A protocol definition does not establish that operators can deploy it safely. Implementation maturity, performance, interoperability and operational tooling determine whether a security mechanism can be trusted in a live network.

SIDN Labs tested five software implementations: QuaggaSRx, ExaBGP-SRx, GoBGP-SRx, FRR and BIRD. The work took place in a small experimental environment, and the team concluded that none of the evaluated software-router options provided sufficiently mature support for production use under the versions and conditions tested.

That result is strategically useful because it blocks a common infrastructure shortcut: treating an RFC or feature checkbox as proof of operability. Path validation introduces signature processing, certificate and key dependencies, configuration complexity, interoperability requirements and new failure modes. A small testbed cannot predict internet-wide behaviour, but it can expose implementation gaps before an operator attaches a critical service to them.

The qualification must remain visible. The conclusion applies to particular software versions examined in the 2025 evaluation and is not a permanent judgement on BGPsec. Its value lies in providing a dated readiness assessment that implementers and operators can challenge with improved code and stronger evidence.

Small RPKI deployments reveal the cost hidden behind a security recommendation

Resource Public Key Infrastructure is often discussed in terms of the benefits of Route Origin Validation. Practical adoption also requires validators, repositories, certificate management, monitoring and staff who understand how failures should be handled. The operational burden can be easy to overlook when discussion focuses on the desired security outcome.

SIDN Labs’ 2026 internship work on small RPKI servers examined part of that operational surface. Small networks and experimental environments may not have the people or platform capacity assumed by designs tested at large operators. The same protocol can therefore impose very different costs depending on the organisation attempting to deploy it.

A security mechanism can be globally desirable while remaining locally difficult to operate. If adoption requires specialist knowledge, continuous maintenance and careful interpretation of invalid routes, organisations with fewer resources may depend on hosted services or avoid the mechanism entirely. That creates questions about concentration, dependency and access in addition to the technical design.

Research into small-server behaviour can help separate minimum technical requirements from institutional aspiration. It also fits the laboratory’s role: establish what running implementations require before turning adoption into a moral judgement about operators. The evidence available at the cutoff shows continuing research rather than a universal reference design for every small network.

MANRS+ asks whether routing expectations can become auditable practice

Mutually Agreed Norms for Routing Security provides a voluntary framework around filtering, coordination, global validation and related practices. The MANRS+ prototype developed with the Global Cyber Alliance explored tools for scanning or evaluating compliance. Turning a norm into evidence requires more than checking whether a network appears in a database.

Assessors must decide which routes, contact records, RPKI objects or policy statements are examined, how exceptions are handled and whether an observed failure represents a temporary operational event or persistent neglect. A repeatable technical test can narrow disagreement, but it cannot determine every legitimate exception or explain every inconsistency.

Automation can make assessments more systematic, but it cannot settle the governance of the label. Questions remain about who qualifies an auditor, how disputed findings are corrected and whether a network can explain a legitimate exception. Those questions require an institutional process rather than a scanner alone.

SIDN Labs can build measurement and prototype mechanisms, while the community operating MANRS determines the consequences of an assessment. This division again separates responsibility from control. Technical evidence should support accountability without quietly becoming a power to punish organisations that were never given a meaningful review process.

TimeNL treats clock synchronisation as shared infrastructure

Accurate time supports certificate validation, DNSSEC operations, authentication, event logs, distributed databases and incident reconstruction. Many systems rely on it quietly until a clock source drifts, disappears or is manipulated. TimeNL makes the dependency explicit by providing a Dutch public time service through the Network Time Protocol and, by arrangement, the Precision Time Protocol.

The programme also gives SIDN Labs an operational platform for studying source quality, anycast distribution, client behaviour and authenticated time. That combination of service delivery and experimentation distinguishes TimeNL from projects that remain confined to a testbed. The laboratory can observe how a public infrastructure service behaves while developing ways to improve its resilience and security.

Operating a public time service differs from publishing a measurement paper. Reference clocks, network paths, server software, hardware timestamping, monitoring and incident response must continue after the experiment. The service therefore carries ongoing operational obligations even when it also supports research.

SIDN Labs’ role is unusually direct here, but the scope should remain precise. TimeNL is not the national clock for every Dutch system, and its availability does not remove dependence on external networks, hardware or other infrastructure. It is one additional, inspectable source whose design can be improved through measurement.

The 2022 NTP dataset shows scale without turning addresses into people

During a 24-hour period on 22 and 23 June 2022, SIDN Labs collected roughly 4.7 terabytes of NTP data from an anycast service deployed across 30 sites. The dataset contained about 13.67 billion NTP messages and 7.28 billion client queries associated with approximately 158.7 million observed client addresses before interpretation and anonymisation caveats.

The volume shows how a service often treated as invisible can reach a vast and heterogeneous population of machines. It also provides evidence about load distribution, client behaviour and the operational characteristics of a global anycast time service. The scale is meaningful because timing traffic is usually discussed as a background dependency rather than a major public service.

An IP address is not a reliable count of devices or people. Carrier-grade network address translation can place many clients behind one address, dynamic allocation can make one device appear under several addresses, and scanners or misconfigured systems can generate disproportionate traffic. Treating addresses as users would therefore exaggerate or distort the population being observed.

The study’s value lies in characterising behaviour and infrastructure load rather than converting observed addresses into a census. The use of Crypto-PAn and approval from SIDN’s Privacy Board show that the method had to account for the sensitivity of large-scale network observations. The one-day collection window also limits claims about seasonal or long-term behaviour.

A terrestrial timing source improves resilience without creating sovereignty

In May 2026, TimeNL added a terrestrial Dutch timing source delivered over local fibre. The change reduced exclusive reliance on satellite-derived signals for one part of the service. GPS and Galileo provide valuable global reference time, but their signals may be disrupted, jammed or spoofed.

DCF77 and other terrestrial or radio-derived sources have different propagation and control characteristics. A diversified clock chain gives operators additional evidence when sources disagree and reduces the chance that one failure mode affects every path at once. The value comes from diversity rather than from assuming one source is universally superior.

The change was described partly through the language of sovereignty, which requires restraint. A domestic timing path can improve national resilience and reduce a specific external dependency. It does not make the service independent of foreign hardware, software, network components, semiconductor supply chains, standards or upstream connectivity.

Digital autonomy is not a binary property acquired by replacing one signal. The defensible result is narrower and still significant: TimeNL gained a satellite-independent source with failure characteristics different from those of GNSS-based references. That improves resilience by adding an alternative rather than by creating complete national self-sufficiency.

The NTS Pool moves authenticated time from protocol support towards an operating system

Network Time Security adds cryptographic authentication to NTP. It helps clients establish that time responses come from the expected server and have not been altered in transit. Protocol support alone is insufficient for widespread use because a secure standard still requires a functioning service ecosystem.

Clients need discoverable servers, operators need deployable software, and a pool requires governance, monitoring, capacity planning and methods for dealing with abuse or failing nodes. SIDN Labs’ NTS Pool work, supported by the ICANN Grant Program and developed with the Trifecta Tech Foundation, addresses that service layer. It therefore moves beyond asking whether the protocol works and towards asking whether an operating system around the protocol can be sustained.

At the research cutoff, the project remained a pilot rather than a mature replacement for the conventional NTP Pool. Its importance lies in making the non-protocol dependencies visible. Authentication changes key management, connection setup and resource use, while anycast may improve distribution but complicate server identity and troubleshooting.

Operators must decide who can participate, how service quality will be measured and what happens when a server misbehaves or disappears. A secure specification becomes useful only when these relationships work together. SIDN Labs can build and test the mechanism, but a sustainable global service would require a wider community of implementers, server operators and clients.

DNS4ALL turned public resolution into an experimental platform

DNS4ALL began in August 2022 as an experimental distributed public resolver. In May 2024, SIDN Labs described it as a blueprint with roughly 30 nodes. Unlike research based only on authoritative .nl traffic, a resolver platform allows the laboratory to study recursive behaviour, encrypted transport, distribution and client-facing service design.

It also provided a place to test hybrid post-quantum mechanisms in 2023 without attaching them directly to the .nl production path. That made DNS4ALL useful as an intermediate environment between a local testbed and a critical national-domain service. Researchers could observe consequences across a distributed system without claiming the service carried the same operational commitment as a major commercial resolver.

The word “experimental” is essential. A public resolver enters users’ dependency chains, so availability, privacy, caching behaviour and policy choices may affect every name they attempt to resolve. Even a research service acquires operational responsibilities once external users rely on it.

Documentation from 2024 establishes the architecture and approximate footprint, but the reviewed evidence did not provide a detailed 2026 status, current node map or support commitment. DNS4ALL should therefore be treated as a documented research service rather than equated with a long-term production resolver operating at the scale or service level of major commercial providers.

Post-quantum DNSSEC forces cryptography through packet and zone reality

A future cryptographically relevant quantum computer could undermine signature algorithms used in DNSSEC and other infrastructure systems. Selecting a post-quantum replacement cannot be reduced to comparing abstract security levels. Signature and key sizes affect DNS packet fragmentation, transport fallback, resolver behaviour, zone-file volume, signing time, validation cost and hardware requirements.

A top-level domain with millions of names imposes constraints that a small laboratory zone may not reveal. A theoretically secure algorithm may create packets that are too large, signing operations that are too slow or rollover procedures that are too difficult to operate safely. Infrastructure suitability therefore depends on the behaviour of the complete system rather than the cryptographic primitive alone.

SIDN Labs tested Falcon-512 and MAYO-2 for signing zones at roughly million-name scale. It reported that both were suitable candidates for the signing task under the conditions examined, while further work in 2026 continued to analyse Falcon formats using .nl data. The studies bring registry-scale evidence into a debate that can otherwise remain abstract.

Those findings do not establish that .nl is quantum-safe or that either algorithm will be deployed. Resolver validation, key rollover, interoperability, standards status, packet loss and a transition period combining classical and post-quantum signatures remain unresolved. The contribution is more modest and more useful: operational evidence that narrows the candidate set before the ecosystem must make a difficult and potentially irreversible migration.

SCION and 2STiC widen the horizon without escaping adoption economics

SIDN Labs became the Netherlands’ first SCIONlab affiliate in 2019 and established a direct SCION connection in 2020. Through 2STiC, it participates in a Dutch collaboration focused on security, stability and transparency in communication between networks. SCION offers path awareness and architectural mechanisms that differ from today’s BGP-centred internet.

That makes it attractive for high-security or resilience-sensitive uses, particularly where operators want more explicit control over paths or trust domains. A proposed SCION-NL pilot and possible naming or certificate-authority roles for SIDN were part of the 2026 agenda. These activities show that the laboratory is willing to test architectures beyond incremental improvements to current routing.

They do not amount to a replacement internet under SIDN’s control. Alternative architectures depend on connected domains, applications, trust roots, operational tools, business incentives and governance agreements. A technically sound island may deliver little value if counterparties do not join or if existing applications cannot use it without major adaptation.

SIDN’s possible naming or certificate-authority role remained exploratory, and no production authority had been granted at the cutoff. The laboratory’s role is strongest when it makes adoption requirements, interoperability boundaries and failure modes visible. Architecture becomes infrastructure only when participants choose to run it and can do so without sacrificing the continuity they already have.

Academic secondments turn institutional boundaries into shared capacity

SIDN Labs’ team page listed ten research engineers or data specialists and one management assistant, with the manager role vacant. The effective research organisation is larger than that public roster because the laboratory also uses university secondments, students, data-sharing agreements and funded collaborations. These relationships expand the laboratory’s capacity without turning every participant into a SIDN employee.

In 2025, four researchers each spent one day per week in academic environments: two at the University of Twente, one at Delft University of Technology and one at the University of Amsterdam. SIDN also reported supervising three master’s students and four doctoral students and contributing to eight academic papers that year. The pattern suggests recurring institutional exchange rather than occasional sponsorship.

Secondment changes the relationship because researchers carry operational questions into universities and bring methods, peer criticism and students back towards the registry environment. The model allows a relatively small internal team to produce more than it could alone. It can also expose SIDN’s assumptions to researchers who are less embedded in the organisation’s operational culture.

The arrangement creates dependencies on individuals, university incentives and the ability to share data under acceptable controls. If key researchers leave, a collaboration may lose both subject expertise and the informal bridge that made it productive. Secondment is therefore a force multiplier rather than a substitute for stable internal capability.

Open research has several layers

SIDN Labs publishes papers, technical reports, open-source software, internet drafts, measurement interfaces and educational material. It also shares data with universities under controlled arrangements and produces internal findings that cannot be released in full. These modes serve different purposes and involve different levels of access.

Code allows others to inspect or reuse an implementation, while a paper exposes methods and results. An aggregate dashboard can provide public visibility without releasing raw records, and a data-sharing agreement may permit independent academic work while preserving obligations to registrants, users and network operators. Openness therefore operates through several channels rather than through one universal release policy.

Calling the model open is reasonable only if the limits remain explicit. Raw DNS-query and registry datasets can contain sensitive relationships and operational detail, while some findings may expose weaknesses before affected organisations can address them. Reproducibility may require access that cannot safely be offered anonymously to the public.

The laboratory’s responsibility is to disclose enough method, code, aggregation and review for claims to be tested without treating unrestricted release as the sole measure of integrity. Openness is an architecture of access levels, audit and accountability rather than the absence of boundaries. The quality of the model depends on whether those boundaries are clear and consistently applied.

The partner network distributes expertise but also divides responsibility

SIDN Labs works with universities, peer registries, open-source organisations, exchanges, research-infrastructure providers and standards communities. The University of Twente, Delft University of Technology and the University of Amsterdam provide continuing academic links, while NLnet Labs has been a formal technical partner since 2012. Afnic Labs and Université Grenoble Alpes collaborated on COMAR, and DENIC and Internetstiftelsen broadened the RPP effort.

SURF, Nikhef, AMS-IX and NLix provide different combinations of storage, computing, interconnection and research context. IETF, ICANN, CENTR and RIPE channels expose the work to communities outside SIDN. The network gives the laboratory access to expertise and infrastructure that would be difficult for a small internal team to reproduce alone.

Each relationship has a different status. A named partner may contribute to one completed project, host infrastructure, finance a pilot or employ a former director. A listing does not prove a current contract, equal control or continuing financial commitment.

The strategic benefit is distributed expertise and external challenge. The corresponding risk is that no single organisation owns the entire maintenance or adoption chain, and a standard, service or experiment may stall when another participant’s priorities change. SIDN Labs can convene and contribute, but it cannot guarantee that every partner will continue carrying its part of the system.

Research reaches production through a handoff

The laboratory’s Technology Readiness Level model implies a staged transfer. An operational team may identify a problem, or researchers may detect one through measurement, after which SIDN Labs develops a method, dataset or prototype. Academic and peer review test the assumptions, and researchers and production engineers assess feasibility.

Privacy and security controls must then be examined before the production owner decides whether to deploy. Monitoring after deployment determines whether the expected effect appears and whether new problems emerge. Any stage can stop the project without making the earlier research worthless.

Autocast is the clearest current example because SIDN publicly described a planned production rollout in 2026. The abuse-classification dashboard is a documented completed integration into SIDN Support, while other outputs remain public tools, pilots, testbeds or drafts. These different statuses should not be collapsed into one measure of success.

The handoff boundary assigns responsibility correctly. Researchers should not be able to push a prototype into a critical path simply because they built it, while production teams should not dismiss evidence merely because it challenges established practice. Adoption is a decision made under operational liability, using evidence that the laboratory helps create.

Impact is clearest where behaviour changed

Research organisations often report papers, presentations and partnerships because those outputs are easy to count. Infrastructure impact requires a harder test: whether an operator, protocol implementation or decision process changed, and whether that change can be connected to the evidence. Attention and output are not the same as operational effect.

SIDN Labs has several examples at different levels of maturity. Its TTL work prompted three country-code registries to change configurations, abuse-classification research entered a support dashboard, and ForSale reached more than 250,000 labelled names through participating registrars. Autocast was prepared for production transfer, while RPP attracted other registries into standards work.

Those examples should not be compressed into one success metric. A configuration change with a measured latency improvement differs from a participation count in a pilot, and both differ from progress inside an IETF working group. Each represents a different form of influence and a different distance from routine operation.

The laboratory’s influence is most defensible when the starting condition, intervention and observed result can be separated. A publication citation or stakeholder score may indicate attention, but it does not establish an operational benefit. The value of the model lies in making effects traceable enough to be judged rather than celebrated by association.

The laboratory’s footprint is a network of relationships, not a set of offices

SIDN’s main organisational location is in Arnhem, while the new research platform and experimental network are at Nikhef in Amsterdam. Data storage and projects involve SURF, and seconded researchers spend recurring time at Dutch universities. Anycast NTP sites and the roughly 30-node DNS4ALL deployment extend the technical surface internationally.

None of this means SIDN Labs owns facilities or employs staff in every location where its software or services appear. A node may be hosted by a partner, connected through an exchange and maintained under a limited project agreement. A university presence may consist of one researcher working there one day a week rather than a branch laboratory.

This distinction matters because infrastructure reach is often exaggerated through maps and location counts. A distributed footprint can depend on contracts, access rights and partner support rather than direct organisational control. The number of locations alone says little about who maintains them or how durable the arrangement is.

The footprint is still consequential because distributed services, measurement vantage points and partner organisations allow a small team to observe and test systems far beyond Arnhem. Its resilience depends on the contracts, access arrangements, people and upstream services that connect those locations, not merely on the number of dots. The topology is institutional as well as technical.

The leadership vacancy tests whether the model is institutionalised

Cristian Hesselman was identified as Director of SIDN Labs in the December 2025 results review. By 2026, SURF listed him as Director of Trusted Digital Infrastructures, while the current SIDN Labs team page showed the manager position as vacant. Publications continued through July, so the vacancy was not evidence that the team had stopped working.

It was nevertheless a material governance condition at the research cutoff. The manager of this laboratory must arbitrate among immediate SIDN needs, long-horizon infrastructure research, university relationships, public communication and maintenance of existing systems. The role also represents the research agenda within the parent organisation.

Resource allocation is particularly important because projects cannot be compared through one commercial return. A tool supporting current .nl operations may produce immediate value, while work on post-quantum cryptography or alternative routing may take years to mature. Leadership must decide how much capacity to reserve for each category.

A durable institution should continue producing during a leadership transition, but prolonged uncertainty can delay recruitment, partnership commitments and difficult portfolio decisions. The next appointment will help show whether the model depended heavily on one visible strategist or has become a repeatable organisational capability shared across SIDN. Continuity of output is encouraging, but it does not eliminate the importance of formal direction.

Dependence on .nl economics links research capacity to the system being studied

SIDN’s annual report identified reliance on .nl earnings as a strategic risk. It also recorded contraction in the zone during 2024 and 2025, alongside an increase in registry fees in 2025. SIDN Labs benefits from recurring funding that reduces the need for constant grant applications, but the source is not independent of market conditions.

If registration volumes decline for an extended period or operating costs increase, research spending may come under pressure even as the need for resilience and modernisation grows. This creates a tension between the long-term value of research and the short-term economics of the system funding it. The laboratory’s stability is real, but it is not absolute.

The funding structure may also shape the portfolio. Projects with a direct and easily explained benefit to .nl operations, such as abuse detection, anycast optimisation, registry protocols or DNSSEC migration, may be easier to defend than wider work on future architectures or public time. That does not mean cuts were announced or that narrower projects are inherently better.

It means the laboratory’s public-interest range depends on management continuing to value benefits that may not accrue directly to the parent organisation’s immediate revenue line. Grants and collaborations can add capacity, but no complete annual grant ledger was available to show how much financial diversification they provide. The funding model offers patience and creates dependence at the same time.

An open-source portfolio can become a cemetery when maintenance is unclear

SIDN Labs’ public tools page spans ENTRADA, Tapdance, Autocast, Cloudburst, LogoMotive, RegCheck, PathVis, Anteater, TimeNL, Rollover Monitor, SPIN, DNS Workbench and the DANE Validator, among others. The breadth demonstrates experimentation and a willingness to publish. It also creates a long-term obligation that is easy to underestimate.

Users need to know whether a repository is a maintained service, a reusable research prototype, an archived demonstration or a component supported only while a particular project remains active. Those distinctions affect whether an external operator can safely depend on the software. Downloadability alone does not establish operational readiness.

The public evidence does not provide a uniform lifecycle matrix listing maintainers, release cadence, security-support periods and deprecation plans for every item. That gap limits outside adoption because an operator cannot safely treat code as a production dependency merely because it is available. Uncertainty about maintenance may be more damaging than an explicit statement that a project has ended.

Maintenance may properly stop when the research moves on, and retirement is not itself a failure. The problem is ambiguity. A mature publication model should make status explicit so users can fork, replace or avoid a tool before it becomes embedded in their own infrastructure.

Visibility into .nl cannot stand in for the whole internet

The .nl zone is large, technically mature and unusually rich in DNSSEC, registrar and operational data. Findings drawn from it can expose behaviour that smaller datasets miss and support comparisons over long periods. The quality of the measurement environment makes .nl an unusually valuable case study.

The same characteristics limit generalisation. Language, law, registrar concentration, hosting markets, abuse incentives, resolver populations and security adoption differ among top-level domains. A scanner proportion measured over selected days at .nl is not automatically the proportion seen by a smaller country-code registry or a generic top-level domain.

Generalisability must be demonstrated through replication, cross-registry studies and clear descriptions of sampling. SIDN Labs’ work with Afnic, other country-code operators, universities and measurement platforms helps, but the evidence remains project-specific. Collaboration expands the number of contexts in which a mechanism can be tested without making any one dataset universally representative.

The laboratory’s strongest contribution is not a claim that .nl represents everyone. It is the ability to produce well-instrumented case studies and invite other operators to test whether the mechanism travels. A national registry becomes a useful research platform when its particular view is treated as a vantage point rather than the internet’s universal centre.

Resilience claims are stronger when sovereignty remains bounded

TimeNL’s terrestrial source, the Nikhef platform, SCION experimentation and direct routing visibility can reduce particular dependencies and improve Dutch capacity to diagnose infrastructure problems. These are meaningful contributions to resilience. They create additional options and improve the ability to observe failures.

They do not create a self-contained national internet. Hardware, software, transit, internet exchanges, cryptographic standards, cloud services, academic collaboration and supply chains remain international. Even a system located entirely in the Netherlands may depend on foreign components and globally coordinated protocols.

Precision matters because “digital sovereignty” can turn a technical improvement into an institutional claim larger than the evidence. SIDN Labs is most useful when it identifies which dependency was reduced, which failure path remains and who retains operational control. That makes the value of the intervention easier to assess.

A terrestrial clock source diversifies timing, an experimental network creates a safe place to test routes, and a path-aware architecture may give participating domains new choices. None gives SIDN authority over the networks or organisations adopting those mechanisms. Resilience grows through options, observability and replaceable dependencies rather than rhetorical ownership of infrastructure relationships.

Stakeholder praise is feedback, not an independent audit

In 2025, SIDN invited fifteen Dutch internet experts to review SIDN Labs. The reported average score exceeded eight out of ten, and the exercise produced seven recommendations, including calls to sharpen the technical vision and clarify target audiences. The result indicates that informed stakeholders valued the laboratory and saw room for improvement.

The exercise also gave management a structured external perspective that internal output counts cannot provide. Experts familiar with Dutch internet infrastructure may identify strategic weaknesses or communication gaps that are less visible within SIDN. Such feedback can therefore be useful even without the formality of an audit.

The workshop was organised and reported by SIDN, so it should not be described as an independent institutional audit. Public material did not provide a complete methodology, participant list, scoring rubric or external assurance process. The score should therefore be interpreted as stakeholder feedback rather than as verified evidence of institutional performance.

That distinction does not invalidate the exercise. It prevents the result from carrying more evidentiary weight than it deserves. A stronger evaluation system would combine stakeholder review with measurable production effects, publication quality, tool adoption, data-governance controls, staff development and transparent portfolio decisions.

A thin-coordination lens keeps research influence in proportion

The discipline running through SIDN Labs’ portfolio is the separation of records, recommendations and running systems. The registry position supplies data and an operational problem set, while the laboratory converts those inputs into measurements and possible mechanisms. Production teams, peer operators and standards communities decide whether to implement them.

A paper does not become a standard because it is published, and a registry dataset does not give a researcher authority over the organisations represented in it. A prototype may reveal that a change is possible without proving that it is safe, affordable or desirable in production. The distinction keeps research claims proportionate to the evidence.

This thin-coordination lens is particularly important where the work touches abuse, routing security, time and alternative architectures. Evidence may justify a warning, a test or a new interface, but it does not justify turning every technical preference into compulsory governance. Organisations controlling live systems remain accountable for the consequences of adoption.

Running-code primacy provides a practical test because the strongest claim is the one that survives implementation, observation and voluntary use. SIDN Labs’ clearest examples, including the TTL changes, the support dashboard and the production-oriented Autocast work, gain credibility because the path from research to adoption is visible. The model remains safe when influence follows evidence and responsibility stays with the actor controlling the live system.

SIDN Labs makes invisible infrastructure choices inspectable

Country-code registries are usually encountered through stable public interfaces. A domain can be registered, a name resolves and the system appears routine. Beneath that surface are decisions about caching, anycast, routing, abuse evidence, time, cryptography, provisioning and data retention.

SIDN Labs makes some of those decisions visible before they become crises. It can measure scanner traffic rather than assume all queries represent equal demand, test BGPsec software rather than equate standards status with readiness and examine post-quantum signatures against the constraints of a large zone. The laboratory turns infrastructure assumptions into questions that can be measured and challenged.

The work also shows the organisational cost of producing that visibility. Data platforms age, open-source tools need maintainers and university partnerships depend on people who can bridge institutions. A public-interest budget still depends on registry revenue, while a vacant manager role matters even when the remaining team continues to publish.

SIDN Labs is therefore a compact example of how infrastructure intelligence is produced: through access, measurement, partnerships and controlled experiments, bounded by the responsibilities and incentives of the organisation that hosts it. The laboratory does not eliminate uncertainty or centralise authority. It makes more of the decision process open to evidence.

The main uncertainties concern continuity, not whether research occurred

The evidence leaves little doubt that SIDN Labs is active and technically broad. The unresolved questions concern the durability and consequences of that activity. No reconciled standalone budget shows the full cost of staff, computing, grants and shared services.

No current announcement identified a permanent successor to Hesselman at the research cutoff, and complete migration of every workload to Nikhef was not separately verified. Autocast’s planned production rollout had no published before-and-after results, while RPP had not become an RFC. DNS4ALL’s 2026 support status remained unclear, and external usage figures for most open-source tools were unavailable.

Those gaps should guide future reporting rather than be filled with plausible narratives. The most useful next evidence would include the appointment of a manager and publication of a strategy, a reconciled budget and a clear tool-status matrix. Confirmation that the Nikhef migration is complete would clarify the state of the research platform.

Production results from Autocast, error rates from anti-abuse systems, RPP interoperability tests, operating results from the NTS Pool, governance documents for SCION-NL and independent case studies from peer registries would show whether research outputs are becoming maintained capabilities. The laboratory’s operating model is already visible. The next test is whether its work remains durable without allowing research visibility to be mistaken for control of the infrastructure it studies.