DNS4EU – a bit EU, a bit secure, a bit pointless

In June 2025, the news that 'Europe is building its own Internet' or 'the European Union is taking the Internet out of the control of the USA' spread through more and less technological portals. I am talking about the newly created DNS4EU for Public project, a DNS resolver dedicated to the citizens of the European Union, which is supposed to ensure speed, security and privacy. But is this really the case, and do these hurrah-optimistic headlines have anything to do with reality? At least when it comes to protection against malicious domains and how EU-like this project actually is, I can disagree.

Table of contents

• How fast is DNS4EU?
• How secure is it?
• Digression: RIPE Atlas - a Flightradar24, but for the web
• How much EU is DNS4EU?
• Is DNS4EU anonymous?
• Summary
• So which DNS should I choose?

How fast is DNS4EU?

I am rather sceptical about DNS speed tests if we are talking about the home use of such a service. Does the response time matter to the average Joe? I am pretty sure that the user will not notice any difference between 30 and 300 ms. Resolved IP addresses are cached by operating systems and browsers anyway, so the DNS server is queried once in a while (according to TTL) and not, for example, every time a website is visited.

However, in order to take a comprehensive approach to the topic, in addition to measuring the times of the DNS queries themselves, I also made ping and traceroute measurements. These gave some insight into the venture's infrastructure and checked its stability. Running such experiments from one location at a time, as some people do, makes absolutely no sense. A botnet is needed for this task, but one that is quite legitimate.

To help with this comes the RIPE Atlas, a global network of research probes for conducting various measurements on the internet, which can be used by anyone interested. Using the blaeu tool and the fact that you can ask the DNS to provide your ID (aka NSID, according to the proposed RFC 5001), it is very easy to target at least part of the DNS4EU infrastructure and "bypass" anycast. Below, using a thousand probes from around the world, I queried DNS4EU in IPv4 to resolve the domain name z3s.pl and to display the NSIDs of the corresponding nodes.

As you can see - anycast worked, as 14 differently located nodes responded from one IP. Their number and location is also confirmed by material found on the ENISA website. It looks like the 'coverage' of Europe is quite decent and there should be no problems accessing the service within its territory.

Let's further check the situation for the IPv6 resolver variant.

This time, 12 different nodes were found. Those in Stockholm and Sofia may either not be involved in IPv6 traffic, or the Atlas probes did not manage to reach them. Just a simple observation.

The test can be repeated, narrowing down the location of the probes to those in Poland. Will this make the probes talk only to the Warsaw node? Not exactly.

The node from Warsaw jumped to first place in terms of the number of responses, while the more distant nodes dropped out of the ranking altogether. Interestingly, Prague and Amsterdam also responded quite frequently. This might be due to the routing of internet providers, although probably DNS4EU load balancing mechanisms also come into play. As can be seen in the map above, even probes from Pomerania (northern part) were able to visit Prague. However, regardless of which node managed to respond, it happened very quickly almost every time - in the region of 30 milliseconds.

Same test can be made with the IPv6 variant, which will certainly replace IPv4 one day. Soon. Trust me.

It is true that Polish IPv6-capable probes are few in number, but they too often managed to encounter a Czech node. Despite this, response times also remain very reasonable.

From the experiments conducted, it appears that, being in Poland, we have a high chance of reaching a node in Warsaw with an average time of less than 20 ms. By hitting a foreign node, it is still possible to get reasonable times of around 25-50 ms, so where geographically our query hits does not cause a drop in performance. It is also worth recalling that DNS4EU's infrastructure is set exclusively in Europe. If you are travelling around the world with DNS set up in this way, and happen to experience some packet loss along the way, this configuration is bound to cause issues.

Moving on to the ping tests, in the long run the times remain very stable. During my tests over several days, I did not note dramatically slow responses or noticeable spikes in latency. This is also confirmed by DNSPerf.com based on data from DigiCert PerfOps.

It is also important to remember that the ping (ICMP echo) is one thing and the DNS query time going over UDP is another. The two values are not directly comparable, but mostly in line. In addition, there are cases when the resolver does not know the answer to the query and has to query the higher-level servers, or when the stored addresses are kept in different cache layers - then these operations will obviously take more time. You can tell how the resolver behaves by the differences in time, which can be measured, for example, by a dig tool asking the selected DNS to resolve the records. For further tests I have already used a single machine connected to Orange Fiber (Poland), from which the ping to DNS4EU was about 11 ms.

In the test of querying a non-existent .pl domain, I waited about 30 ms for a response the first time. It should be expected that the first query will be slower, as each resolver first has to query the DNS responsible for this TLD itself. Subsequent requests were already resolved faster, which indicates a well-functioning cache.

Querying a freshly created .xyz subdomain took around 90 ms the first time. Then the response was cached and the times dropped again to around 10 ms.

The querying of Google.com, on the other hand, usually closes within 10 ms. In this case, we are assured that Google addresses will always be cached due to their popularity.

I also cursorily tested the service with dnsperf, although I limited the testing to a maximum of 15 queries per second for 12 hours. I was only interested in whether a 'series' of queries would clog up the DNS, because after all, most websites pull additional content from many different domains all at once. I compiled a test list of domains to test based on the popularity rankings of sites in Poland according to Cloudflare Radar and Semrush. But don't worry, global websites like Facebook, Weather.com, etc. are included too.

From all the tests carried out, it is clear that DNS4EU does indeed resolve domain names very quickly, as long as the user is located in Europe. The service is also very stable, so the promise of speed can be considered fulfilled.

How secure is it?

DNS4EU's malicious site filtering variant promises 'advanced protection' and 'proactive regional threat protection'.

The project's website also features a blog note, which identifies the role of the Polish NASK (Research and Academic Computer Network) as one of the sources of threat information.

The same is also confirmed by CERT Polska's (Poland) entry on its website.

Unfortunately, as can be seen from the experiment conducted below, DNS4EU does not implement (correctly or at all) the CERT Polska Warning List - the time to block a malicious domain remains absurdly high, which basically renders the 'protection' variant of this DNS useless.

To test the speed of blocking malicious domains, I wrote an application that downloaded new domains from the CERT Polska Warning List for 24 hours, and then checked in a loop if (and when) they were blocked by the selected DNS (in this case the "Protective resolution" one). This is very important, as domains used for phishing or stealing money can live a very short life, so they should be blocked immediately. I repeated the test a couple of times on different days to be sure, but the results always remained similar.

A domain is considered blocked when DNS returns the blackhole IP address - 51.15.69.11 (belonging to Scaleway SAS, used for displaying the blocking alert). Domains whose A record has ceased to exist for some reason are counted in favour of DNS4EU for simplicity. It should also be noted that while the CERT list was contantly being refreshed for 24 hours, it took more time until all the malicious domains had been blocked.

As can be seen in the graph above, DNS4EU seems to block malicious domains from CERT's list in batches every few hours, which contradicts the promises made on the initiative's website. CERT Polska itself recommends those using their lists to update every 5 minutes. Minutes, not hours!

From the logs reviewed, it also appears that some domains were blocked after two hours and others only after nine. It seems to me that if the CERT Polska list had been imported directly, such a time divergence would not have been possible - this behaviour is very strange. In any case, it's sad to see, especially since looking at the domain names themselves, you can guess which kind of scam it is. Things like this need to be blocked right away.

To check that I hadn't messed something up in my benchmark, I also ran a test on Orange Poland's DNS, which implements Warning List by default. The time from listing the domain to blocking it averaged in 8 minutes 20 seconds. I suspect that if I had refreshed the data faster, the results would have been even better.

Theoretically I could test whether and how quickly DNS4EU in the "protective" version blocks malicious domains from other lists, what's up with blocking domains with malware, etc. The thing is that the delays of several hours in blocking scams are - at least in my opinion - disqualifying. The protective variant of this DNS will not protect you from regional threats, so I see no reason to bully test further.

RIPE Atlas - a Flightradar24, but for the web

This section is not strictly about DNS topics and probably deserves a separate post, however I am putting it here as a curiosity. The end of offtopic will be marked with a similar banner, but you can also move on by clicking here.

As I was researching how to approach DNS resolver benchmarking in general, I came across an interesting service called RIPE Atlas. It is similar to Flightradar24 in its operating model, however, instead of collecting aircraft information from volunteers, it allows researchers to monitor and measure various hosts from across the network. This does not necessarily have to be a DNS test - ping, traceroute, TLS and NTP are also supported. In order to take measurements ourselves, we need to have Credits in the Atlas service, which can be obtained under certain conditions.

In Flightradar, the Free plan only includes access to basic data, and you must pay extra for more filters and information, or just provide aircraft data by yourself instead. All you need for this is an SDR radio and a computer. The cost of a receiver (RTL SDR v3 or v4 - just right for an amateur!) complete with antennae is approximately $40, plus a minicomputer (perhaps a Raspberry Pi) to pass on the collected ADS-B data. As a reward for sharing the data, everyone gets a Business plan for free, so it could be a treat for aviation fans. Who knows - perhaps the required hardware is already in your cluttered drawer?

As an offtopic to offtopic, I might add that detecting just a few aircraft unlocks the prize. You really don't need any specialised equipment or secret knowledge. So you might consider buying an SDR instead of a Pro plan - it will pay for itself in the long run.

In the case of RIPE Atlas, anyone with credits can ask the volunteer probes to make various measurements. This makes it easy to query, for example, a ping to a particular server from all the probes from Poland; to perform DNS queries from the resolvers of different ISPs or to examine network routes from Australia to Austria - the possibilities are probably endless. Measurements can also be run periodically, which is useful, for example, when investigating anomalies.

How many credits for this simple test did we need to spend? Before creating a measurement we are informed of the cost and in this case our order was priced at 200 credits.

How then do you get the credits? As with Flightradar24, we also need to install special software, however, all you need is any computer or Raspberry Pi and a stable internet connection. I used the most powerful (albeit the only one I have) hardware in my homelab and created a performance monster like the one pictured below.

Such a router will work very well as a probe for Atlas. It is important to connect the device wired to avoid instability and redundant latency. Once the probe is set up, we will automatically start collecting credits for uptime alone. However, they will not come immediately - they are awarded collectively once a day, at 17:00 UTC. Currently, the rate is 15 credits per minute the probe is running, a gain of 21 600 per day. In addition to this, you get a bonus for the results delivered to other users - the number, however, depends on how many measurements your probe takes part in.

The publicly available probes can be viewed via a map. In Poland we currently have around 230 such probes, which is, however, a rather mediocre result compared to the rest of Europe.

Those wishing to set up own probe are invited to read this guide, and more interested ones can also apply for a physical probe using the dedicated form.

Interestingly, NASK (Polish Research and Academic Computer Network) has two probes (searching at least by ASN names) - one hardware and one Anchor type (in short, a more professional one, adapted to the data centres and requiring the additional blessing of RIPE).

Now you can safely move on to the rest of the post.

How much EU is DNS4EU?

After all, since it has "EU" in its name, it is surely EU, right?

In fact, if we were to be completely pedantic and start checking every detail, it's not. However, there is one catch.

Looking at the list of available DNS4EU variants, we see that all IP addresses belong to a single prefix 86.54.11.0/24. We can therefore move on to an analysis of the BGP protocol - something like a roadmap of the internet, where instead of place names, we will only see the autonomous systems (AS) responsible for the different IP address pools. So using the RIPE database, we know that this range belongs to AS198121, which is an autonomous system from Whalebone, s.r.o registered in the Czechia. Sounds OK, but out of curiosity let's check how this AS is connected to the rest of the world. The BGPlay tool is sufficient for this. The situation presents itself as in the image below. On the left - in pink - is the autonomous system on which DNS4EU is running. As you can see, from there all roads lead to AS60068.

This is also confirmed by bgp.tools. AS60068, owned by DataCamp Limited, is currently the only directly connected autonomous system to DNS4EU. This means that all network traffic to these DNSs is the responsibility of DataCamp. The problem is that this is a company from the United Kingdom, which has not been a member of the European Union for more than 5 years. That's a bit of a bummer, but does it mean that our DNS queries will always run outside the EU? Not necessarily.

DataCamp provides various services mainly as two entities: CDN as CDN77, and as dedicated server hosting, anti-DDoS and a network transit as Datapacket. Their client list includes organisations such as Discord, Udemy, Bunny CDN or AdGuard. In the case of DNS4EU, Datapacket is responsible for the infrastructure for the operation of the resolvers themselves.

All right, but is Datacamp a bad thing? On the contrary, their service is reportedly very good and recommended to the others. The trouble is that those who were hoping for a DNS independent from companies outside the European Union may have felt cheated. Sovereignty is somewhat suggested by the name itself, the marketing materials on the initiative's website and the multitude of different 'information' sites. The trouble is that mention of Datacamp as a non-EU partner is not clear - they are only mentioned as 'European', which is not the same thing.

But this does not at all mean that queries to DNS4EU via the are passing through via UK. The theoretical route shown in BGP browsers is not at all necessarily the actual route over which packets pass. This can be very easily verified with the traceroute tool, and even better when you have access to hundreds of devices connected by different operators. Again, you can use the RIPE Atlas here and just do the measurements.

In the case of Orange Polska, everything looks correct. The penultimate hop is the one from AS5511 (Orange's OpenTransit network), which is then directly connected to DNS4EU. In such an arrangement it is highly likely that the traffic will remain within the Union.

In the case of Play/UPC it's already more interesting. You can see that there is a hop in CDN77 (Datacamp), but that doesn't mean the traffic is jumping to the UK. A search for IP reversals points more towards Poland and Germany. For the routes where Arelion (twelve99) is at the end, the last hop occurs directly between Warsaw and DNS4EU. It is safe to assume that the traffic stayed in the EU.

By the way: checking the exact location of hosts using their IP addresses is pointless. Such an address can have different locations entered in databases. Just take a look at the IP Location.net service, for example, which searches over a dozen geolocation databases simultaneously.

There are many reasons for the discrepancy. Data from IP geolocation providers may be more or less up-to-date. They may also be copies of data from regional registries (RIRs), and these may have nothing to do with reality (after all, the owner of the address pool can enter anything). One IP address can also actually exist in multiple locations through the magic of anycast. Some geoIP data providers try to determine the location of addresses themselves, as IPInfo does with its own network of ping probes. This is why context is so important, i.e. where the previous and following hops are located (and can be more certain about). A route from Poland to France via Africa is far less likely than via Slovakia.

Let's check another ISP that just happens to still have a reasonable number of available probes in Atlas, namely T-Mobile.

In the case of the first two routes, you may be a little surprised, as the hops were in Germany and Hungary. The routes of the subsequent probes only led from Poland to Germany. The last probe, on the other hand, did not report any hops along the way other than the local network. The only explanation I can think of is black hole physics or witchcraft. Later tests from this particular probe showed more reasonable routes.

I also did some measurements in other countries, as I still couldn't reach the UK in traceroute logs. In Germany, Belgium or France I occasionally spotted some ridiculous routing, but none of them included the promised by BGP United Kingdom. As a last resort, I chose probes lying on the very edge of the English Channel for my final research.

In the end, after hundreds of IPs reviewed and hours of paging through logs, the UK showed up, albeit only under specific conditions. In the case of the Isle of Guernsey, which is physically connected by undersea cable to France and the UK, it just so happened that the first hop was the UK. In the second case, the probe was connected to Starlink, so the occurrence of London as the first hop is also logical. In both cases the traffic immediately hopped to the Union and finally to the node in the Netherlands.

Despite efforts and searching, I have not been able to find a reasonable scenario where traffic to DNS4EU, working with the UK' DataCamp, would 'escape' outside the EU. That the initiative's website does not explicitly state that it is working with a non-EU company, however, is surprising. From a project subsidised by the EU and advertising itself as 'sovereign', I would expect it to be within the union. Such a disclaimer would be welcome.

So if we are only interested in the mere "jurisdiction" of the traffic, then until a network operator or some intermediary decides to route traffic through Slough, it should not leave the EU borders. This does not change the fact that DNS4EU is not a fully independent EU initiative.

There have also been voices of disappointment on the internet about the fact that the official DNS4EU website uses Cloudflare service and that Google is responsible for email. It is true that these corporations are American, but in my opinion this is irrelevant. My interest here is strictly in the DNS service, not in the marketing environment or methods of contact. Nevertheless, I leave it here out of obligation and also as an interesting fact.

Is DNS4EU anonymous?

On the question of anonymity, you can only believe (or not) the assurances of the project coordinators.

Presentation from the conference, although the method of anonymisation now looks different (6:19)

IPs from DNS requests are anonymised according to the extensive procedure outlined above. In the worst case scenario, if by some miracle the HMAC keys and modulo value were leaked, an attacker could forcibly guess traffic from a subnet (not a specific address) and only on a given day. The keys and modulo value are rotated every 24 hours, and the anonymised logs are used in the fight against malicious domains and deleted after six months. However, if fewer than 100 queries are found for an anonymised, single IP, the data is deleted immediately.

Compared to the more popular DNS services, Cloudflare promises anonymisation through IP address pruning, where logs are stored for 25 hours. Google, on the other hand, claims that it deletes temporary logs for up to 48 hours, but reserves the right to keep them longer once a specific IP address is changed to a user's city or region.

Neither independent nor secure

Well, DNS4EU on the surface looked like a fully EU initiative that would allow independence from foreign corporations, and the additional 'protective' option was also supposed to give protection from cyber threats. In practice, what we got was a service run by a Czech company working with a UK operator to which the EU gave some money, and which the protective DNS does not protect. Well, the infrastructure provider can be changed and the protection against malicious domains can be improved. Still, the direction and future of the whole project is cause for concern.

As early as next year, the service is to be commercialised and stripped of its EU funding, remaining entirely in the hands of the Czech Whalebone. In my opinion, it is better that such important projects remain under greater control of the member states. Because in that case, what will DNS4EU be different from already existing services? Worse filtering of scams? Meanwhile, there are alternative services on the market that block threats better, are more European or take even better care of anonymity and privacy, and do not cost citizens 3 million EUR. I am wondering why DNS4EU even exists. And I don't know.

So which DNS should I choose?

There is not really a ready-made solution that suits every user. Some may prefer configurability, pay attention to the origin of the organisation behind the service, look for a security solution or prioritise speed and reliability. As each solution has its advantages and disadvantages, I have decided to list the example services in a random order and briefly introduce them. However, I have not researched them in as much as DNS4EU here, and some of them I have never heard of before. I also assume that some of you will have more-or-less positive opinions about these resolvers. In that case, the comments section stands open.

• DNS from Wikimedia, the organisation behind Wikipedia: https://meta.wikimedia.org/wiki/Wikimedia_DNS
• DNS.SB - a small project located in Germany, provides transparency reports, has easy-to-remember short IPv6 addresses: https://dns.sb
• DNS4all - Dutch experimental project of the national domain registry SIDN there: https://dns4all.eu
• DNS0 - European DNS that runs on an EU-tailored NextDNS infrastructure, various filtering options: https://www.dns0.eu
• NextDNS - American service, very extensive configuration options, firewall, servers worldwide, free and paid plans: https://nextdns.io
• Quad9 - Swiss DNS that cares about privacy and security: https://quad9.net
• Google DNS - a classic, although disturbing reports of anti-piracy censorship and Google's patronage itself may be discouraging: https://developers.google.com/speed/public-dns
• AdGuard DNS - for many a simple and effective method of blocking adverts on the internet, although some may be disturbed by the company's Russian origins. On the other hand, in May Roskomandzor itself ordered the removal of the AdGuard VPN app from Samsung and Xiaomi's Russian stores. https://adguard-dns.io/public-dns.html
• Cloudflare DNS - often used as a more private alternative to Google's service, they advertise, among other things, the fastest response times in the world: https://www.cloudflare.com/pl-pl/application-services/products/dns
• Mullvad DNS - a service from one of the more honest VPN providers, that does not bend reality in its advertising, few filtering options: https://mullvad.net/en/help/dns-over-https-and-dns-over-tls
• Why not leave the operator's default DNS? After all, the ISP has to comply with local laws, and there are times when it already implements blocklists against threats. On the other hand, operators can be forced to block selected sites (for good or bad reasons). Your mileage may vary.
• If you are curious, why not something selfhosted? Spinning up an instance of Unbound seems like an interesting solution: https://nlnetlabs.nl/projects/unbound/about

​