| Key | Value |
|---|
DNS4all is our experimental public DNS resolver. You can read more about it on our main page. The page you are looking at right now is intended to provide debugging information.
Frontend
Our service consists of a global network of frontends, distributed over the
globe by means of BGP anycast. This page will show you the identifier of the
(anycast) frontend where your DNS queries enter the DNS4all network
[1],
when you use it. It depends on where you are on the globe where your DNS
query comes in (although quirks in the BGP routing can sometimes produce
unexpected, illogical results).
Protocol
The resolver service supports DNS-over-HTTP(3), DNS-over-TLS, DNS-over-QUIC and plain
old DNS over UDP and TCP. The page shows what protocol you use for your DNS queries,
based on a couple of test queries.
Backend and Source
Your queries are processed by so called backends. DNS4all has a number of them,
distributed globally. This page shows the identifier of the backend
where your query was processed. I.e. where your query left the DNS4all network towards
authoritative servers.
It also shows it's (unicast) source IP address, or if DNS4all is not
used, the source IP address of the resolver that was used instead.
DNS or DNS64
Finally, DNS4all supports DNS64 and this page shows if you make use of
that, or not (assuming you use the DNS4all service).
Most fields are associated with DNS4all and will show 'n/a' if you don't make use of DNS4all, but are using another resolver service instead.
Prefer a command line option?
It is also possible to use this test on the command line, for instance
with this command: dig +short TXT
debug.information.dns4all.eu
The command line version shows some additional information, when
applicable, such as UDP buffer size, ECS information and TLS
information.
Q: How do I configure DNS4all so I can use it?
A: This is explained on our main
page.
Q: I'm in Amsterdam, using DNS4all, and my frontend is:
BOM1-1 and the backend is: SIN1, which suggest
faraway locations, whereas I would have expected to end up on nodes
nearby - what's wrong?
A: One reason could be that the nearby nodes are down (for maintenance),
but it is also possible that the so called 'BGP catchment' is
suboptimal. There are many reasons why this could happen and improving
the routing can be tricky sometimes. This is precisely why we deploy
this experimental environment; to learn and to better understand how BGP
anycast works and how it can be improved. And yes, you are part of that
experiment ;-) .
Q: I do not trust the outcome of this test page - what should
I do?
A: There's a number of things that can go wrong, resulting in
incorrect results. It's best to reload the page a couple of times to see if
things improve. Check the included timestamp to verify if the page was indeed refreshed.