Let us get the obvious part out of the way first.
I run the company that has just launched a European dynamic DNS service. This article is therefore not an independent review of the market.
It is, however, an explanation of why we built one.
Dynamic DNS is old infrastructure. The protocol has been around for decades. Routers already support it. Home users rely on it to reach a NAS, a VPN, a camera gateway or a server. Businesses use it for branch offices, mobile connections and equipment installed at customer sites.
It is not fashionable technology.
It is also exactly the kind of technology Europe keeps discovering that it no longer controls.
A hostname should not depend on reading an email
The basic problem dynamic DNS solves is simple.
Most internet connections do not have a permanent public IP address. The provider may change it without warning. When that happens, the address you used to reach your home, cabin or branch router stops working.
Dynamic DNS replaces that changing address with a name that stays put.
Your router reports its current address. The DNS record is updated. You continue connecting to the same hostname.
That should be the whole arrangement.
But one of the best-known free dynamic DNS services requires users to confirm their hostname every 30 days. Miss the email, and the name can expire and be removed from DNS. After that, it may enter a recovery process or eventually become available to someone else.
The provider explains that this keeps unused hostnames off its network. That is a legitimate operational concern.
It is also a strange property for infrastructure.
A hostname used for a cabin, a VPN or an emergency connection is often most important precisely when nobody has thought about it for a while. The service can be working perfectly. The router can be reporting correctly. The hostname can be actively resolving.
Then it disappears because a person failed to click a link in an email.
Nothing technical failed.
The human failed the monthly attention test.
Infrastructure should not work like that.
Free should not mean temporary
There is a familiar pattern in internet services.
The free version is not made unusable. It is made slightly inconvenient, repeatedly, until the user either pays or leaves.
A banner is inconvenient.
A missing feature is inconvenient.
Allowing a working network endpoint to disappear because someone missed a confirmation message is different. The inconvenience has been placed inside the reliability of the service itself.
For dynamic DNS, the hostname is the product. If the name disappears, there is no reduced version of the service left. There is simply a connection that can no longer be found.
A better rule is much simpler:
A hostname remains yours until you delete it.
The provider can still prevent abuse. It can rate-limit updates, revoke credentials, detect abandoned accounts and remove names that violate its terms.
But a working hostname should not expire because its owner went on holiday, changed email address or stopped treating an automated reminder as urgent.
That is the principle behind Dynway’s free dynamic DNS service. A Dynway hostname remains active until its owner deletes it. There is no recurring email that must be opened to keep working infrastructure alive.
The small file that says more than it appears to
There is also a European question here.
A dynamic DNS provider receives the public address of a connection whenever it changes. Over time, that produces a history.
For a home connection, the history may show reconnects, outages and changes of provider.
For a laptop, mobile router or travelling connection, it may reveal movement between networks.
For a business, it may identify branch locations, edge equipment and the moments when individual sites went offline or came back.
This is not the contents of anyone’s files.
It is still revealing operational data.
The hostname may itself say something: cabin, warehouse, oslo-gw, camera or vpn. Add the address history and timestamps, and a supposedly modest DNS service begins to describe part of the network behind it.
That does not mean every non-European provider is doing something improper with the data.
It means jurisdiction, ownership and infrastructure location matter even for services that appear too small to deserve the discussion.
Europe tends to begin the sovereignty debate with clouds, artificial intelligence and large public-sector systems. Those are important.
But dependence is assembled from smaller pieces: identity, email, monitoring, DNS, certificates, source code, update services and the quiet protocols embedded in routers.
You do not become independent by replacing only the expensive parts.
This is why European operation is part of Dynway’s design, rather than a geographical label added after the service was built.
European is not a protocol
Building a European alternative should not mean inventing a European-only protocol.
That would replace one dependency with another.
DynDNS2 already exists. It is supported by routers that have been sitting in homes and offices for twenty years. FRITZ!Box, OpenWrt, MikroTik and many other systems can work with a custom provider.
The useful European approach is therefore not to build a new gate.
It is to operate an existing, open protocol under European ownership and law, then make the service around it more transparent:
- credentials limited to one router and one hostname;
- IPv4 and IPv6 handled independently;
- tokens that can be rotated or revoked;
- DNSSEC-signed records;
- documented APIs;
- clear event history;
- and no requirement to click an email every 30 days to prove continued interest in infrastructure that is visibly still being used.
The Dynway router configuration uses the same familiar fields already found in many routers: an update server, an update URL, a hostname and a separate credential.
European digital sovereignty becomes credible when leaving remains technically possible.
If the service uses a standard protocol, the router is not trapped. If the management interface has a documented API, the customer is not forced to operate through one dashboard. If credentials are scoped to individual devices, replacing one router does not require rebuilding everything around it.
That is more meaningful than putting an EU flag in the footer of a proprietary system.
Not every router will cooperate
There is one practical problem with relying on the router.
Not every router supports a custom dynamic DNS provider. Some only include a fixed list of vendors. Others are supplied and locked down by an internet provider. In apartments, offices, hotels and shared networks, the person who needs the hostname may not control the router at all.
The protocol may be open.
The box in the hallway may have other ideas.
A European alternative is not particularly useful if it only works for people who can replace their router or install custom firmware.
That is why we also built Dynway apps for Windows, macOS and Linux.
The application performs the update from the computer itself. You sign in, choose or create a dynway.eu name, and the app keeps it pointed at the current connection. It reacts to address changes, network changes and sleep or resume events without requiring access to the router configuration.
For laptops, there is an additional safeguard. Moving to a new network does not silently republish the hostname from that location. The update pauses until the user approves the network, allows one update or explicitly permits updates from any network.
The Windows application is signed by WAYSCloud AS. The macOS application is also notarised by Apple, while Dynway is also available as a Linux AppImage. Published checksums allow the downloaded files to be verified independently.
Dynamic DNS should work through the router when possible.
When it is not possible, the answer should not be “buy another router”.
The Dynway desktop application makes the same service available without requiring any change to the router.
The router is already telling us something useful
Traditional dynamic DNS services generally answer one question:
What address does this hostname point to?
For a household, that may be enough.
For a business operating many connections, the more useful question is often:
Which site has stopped reporting, and why?
A router updating its address already produces an operational signal. If the updates stop, the line may be down. If the router continues reporting but authentication fails, the connection is alive and the credential is wrong. If the reported address and the published DNS record differ, something else has failed.
Those are different problems with different fixes.
No additional network probing is required. The update protocol is already carrying the information.
This is where an old household utility becomes useful business infrastructure: not by replacing the protocol, but by treating what it already says as an operational event.
Dynway Business Fleet uses these existing updates to distinguish between a silent router, an authentication failure, a DNS record mismatch and missing IPv6 reporting.
Sites can be organised using names, locations and tags. Events can be sent to existing monitoring, automation or CMDB systems using signed webhooks. The dynamic DNS service updates the operational tools the business already uses instead of becoming another isolated dashboard someone must remember to check.
So we built one
This brings me back to the disclosure at the beginning.
WAYSCloud has launched Dynway, operated by a Norwegian company on European infrastructure.
For private accounts, one hostname is free. It remains active until the customer deletes it. There is no monthly confirmation email.
It works with the DynDNS2 protocol already present in many routers. If the router cannot be configured, the Dynway desktop application can perform the updates from Windows, macOS or Linux instead.
For businesses, Dynway Business Fleet adds APIs, event history, site monitoring and signed webhooks.
People who want the technical details can read the Dynway documentation or inspect the Dynway API. Those who already have a WAYSCloud account can open Dynway directly.
This is, clearly, the point where the argument becomes a product.
But the product came after the argument.
We did not need a new dynamic DNS protocol. We needed an alternative that treated a hostname as infrastructure rather than a monthly engagement exercise, that kept the operational data under European control, and that remained compatible with equipment people already own.
Dynamic DNS will not decide Europe’s digital future on its own.
That is almost the point.
Digital dependence rarely arrives as one enormous decision. It accumulates through hundreds of small services that nobody considered important enough to build here.
Eventually, the small dependencies become the infrastructure.
Europe needs alternatives before that happens—not only for the fashionable technologies, but for the quiet ones that have kept the internet working all along.