News, events & blog

From Cloud Exit to DNS Resilience: Key Takeaways from CENTR’s Technical Working Group

Moving out of the cloud, but where to?

The Belgian registry (.be) is preparing to leave AWS. At the same time, it still expects the convenience of cloud services from the new solution: infrastructure management automated with Terraform, virtual machines, and support for Kubernetes. The procurement process attracted 15 bids, so there is no shortage of options, although no contract had been signed by the time of the meeting.

The Swedish registry (.se) has focused on reducing vendor lock-in. Instead of AWS’s own container management solution, it now uses a Kubernetes-based service. It is not leaving AWS or the cloud yet, but a more standardised setup should make that easier in the future if necessary.

The Dutch registry’s (.nl) migration to its new registry platform, Hello Registry, has been postponed until November. One important requirement is that DNSSEC signing must take place in an environment hosted in the Netherlands.

An interesting counterexample came from Israel, where AWS is being tested as a way to build distributed DNS infrastructure. Kubernetes and Global Accelerator make it possible to use servers in different regions through a single IP address without having to build and operate an entire anycast network independently. So far, the setup is being tested with the organisation’s own domain.

According to the experience of Austrian colleagues, this kind of setup became too expensive at top-level domain query volumes in the case of RCode Zero. Israel is still measuring the results. The cloud may work technically, but in the end the bill will provide the final answer.

After VMware comes Proxmox

Moving away from VMware has become a recurring topic. Slovenia and Luxembourg have already migrated to Proxmox, while the French registry Afnic plans to begin its migration in early 2027. In Luxembourg, it is enough to define a new virtual machine in NetBox and automation takes care of the rest.

The Latvian registry described several issues it had experienced with Proxmox. Most of them ultimately came down to networking or other problems not directly related to the virtualisation software itself. For us, it is important to look more closely at what exactly was done, how the problems appeared, and what checks could have detected them earlier. We are also expecting to move away from VMware, most likely in favour of Docker and Proxmox.

Open source does not necessarily make Mattermost predictable

Changes to Mattermost’s licensing and packages have forced several organisations to choose between paying, modifying the software themselves, or moving elsewhere. ISC has switched to Zulip and has been satisfied with the experience so far. The Austrian and Czech registries have decided to stay with Mattermost for now, but maintain their own versions.

The Austrian registry uses the Nix package manager and the patches already available there. This avoids the need to create its own build process, but creates dependency on the maintainers of the package and its patches.

The Czech registry used Claude to analyse the code and documentation and found that the single sign-on functionality through GitLab that they needed was still present in the code. With a few changes, they were able to re-enable it and increase the user limit. According to them, the code changes were minor, but the testing effort was significantly greater. And naturally, GIF sharing also had to be restored – user experience has its own priorities.

In the Czech registry’s view, the main benefit was buying time. They were able to move to a supported version, but research into alternatives, including Matrix, continues. The question of trademark use in modified software also remained unresolved. Changing a few lines of code may be simple, but having confidence that the same approach will still work with next year’s versions is a different matter altogether.

AI is finding vulnerabilities faster than they can be fixed

ISC and NLnet Labs described the flood of security vulnerability reports generated with the help of AI. This is already affecting development roadmaps: more time is being spent on fixes, leaving less time for new functionality. ISC has therefore postponed the next stable BIND release until early 2027.

ISC now also uses continuous language-model-based code analysis itself in an attempt to find issues before external researchers report them.

For registries, this means more frequent updates. Danish colleagues discussed whether their current process for patching production systems can keep up with the new pace. Finding a security flaw is good news, but someone still has to prepare the fix, test it, and deploy it into a live service. That last part tends to receive less attention in AI success stories.

At the same time, the Czech registry is experimenting with language models running in its own infrastructure. It has purchased six NVIDIA machines to test models including Qwen and MiniMax. The reason is practical: contracts, invoices, and other internal documents are not necessarily something they want to send to an external service provider.

Public AI services are also used, for example in open-source development. The choice depends on what kind of data is being processed.

DNS has to work

The Dutch registry SIDN presented Tapdance, which collects statistics from authoritative nameservers through the dnstap interface and displays them using InfluxDB and Grafana. With the previous DSC solution, they were frustrated by issues such as intermediate file management and a delay of around 15 minutes. With Tapdance, metrics reach the dashboard at one-minute intervals.

A more interesting addition is network latency measurement. The system sends ping requests to active clients in order to estimate how far they are from the nameserver in network terms. This helps determine where an anycast network should be expanded and whether changes actually improve the service. It is still an estimate of latency, rather than a measurement of the response time of every DNS query.

After encountering an NSD software bug, the Austrian registry added comprehensive DNSSEC checks for customer zones at all of its anycast locations. In addition to standard responses, the tests cover non-existent names and queries related to previous failures. It is a useful reminder that a running process and a green server-monitoring dashboard do not necessarily mean that the DNS service itself is working correctly.

DNSSEC: signing and testing. What comes next?

Support for OpenDNSSEC ends in October 2027, and NLnet Labs is developing Cascade as its successor. Luxembourg plans to run the new solution alongside the existing one so that results and performance can be compared before switching production over.

Afnic will first replace HSMs that are reaching end of life – the hardware used to store cryptographic keys – and will then move on to the signing software. They do not want to rebuild everything at the same time.

The New Zealand registry (.nz) is building a signing pipeline in which separate containers receive the unsigned zone, validate it, sign it using an HSM, validate the result, and pass the zone on for publication. Before signing, the intention is also to compare the zone against the registry database. This means it is not enough for the file to be technically valid: its contents must also match what the registry actually intends to publish.

The origin of the software is treated with the same level of care. Signed code changes are checked before being allowed into the signing environment, and the required components are brought into local infrastructure. The aim is to be able to rebuild the solution even without an external internet connection.

If the automated build and deployment environment fails, the same operations should still be executable manually through the same Makefile. At the time of the meeting, the solution was still being tested, with parallel operation and migration still ahead.

It is a useful principle: a backup plan should ideally be another way of running the same process, rather than a separate set of instructions that nobody has tested in years.

The Zonemaster presentation focused this time on user interface customisation. The newer solution makes it possible to carry custom branding into the next version, provided that the customisations were implemented in a supported way. It may seem like a small detail, but keeping your own logo and colours should not become a reason for delaying security or functionality updates.

The most everyday lesson in resilience, however, came from Latvia’s summer storm. A home generator and connections from three mobile operators were still not enough to maintain communication during a prolonged power outage. To let colleagues know that they were unreachable, someone had to drive around looking for mobile coverage.

Three connections may ultimately depend on the same electricity supply. That is worth remembering even when everything looks nicely duplicated on an infrastructure diagram.

Business data verification requires cooperation

I also gave an update on CENTR’s task force on business data verification. We have mapped options across 32 countries: where business data can be obtained, how company representatives can be verified, and what free or paid services are available.

The more difficult question is how to keep all of that information up to date. Ideally, each country would need someone who understands the local options and monitors changes over time.

Our longer-term plan is to start by integrating the markets that are most relevant to .ee and, where possible, offer the resulting solution as a service to registrars and other registries as well. Development is already under way and the first prototype is being tested.

As a more practical update, we were also able to share that integration with the Estonian Business Register is now live: when establishing a company, users can also reserve a .ee domain name. The first users discovered the option even before any separate communication campaign had started.

Sometimes it is enough for the right service to be available in the right place at the right time.

That is all for this time.