Dnscrypt-proxy: [ANNOUNCE] Anonymized DNS is here!

[jedisct1]

Anonymized DNS is here!

DNS encryption was a huge step towards making DNS more secure, preventing intermediaries from recording and tampering with DNS traffic.

However, one still has to trust non-logging DNS servers for actually doing what they pretend to do. They obviously see the decrypted traffic, but also client IP addresses.

In order to prevent this, using DNS over Tor or over proxies (HTTP, SOCKS) has become quite common. However, this is slow and unreliable as these mechanisms were not designed to relay DNS traffic.

A new step towards making DNS more secure has been made. Today, I am thrilled to announce the general availability of Anonymized DNSCrypt, a protocol that prevents servers from learning anything about client IP addresses.

How does it work?

Instead of directly reaching a server, an Anonymized DNS client encrypts the query for the final server, but sends it to a relay.

The relay doesn't know the secret key, and cannot learn anything about the content of the query. It can only blindly forward the query to the actual DNS server, the only server that can decrypt it.

The DNS server itself receives a connection from the relay, not from the actual client. So the only IP address is knows about is the one of the relay, making it impossible to map queries to clients

Anonymized DNSCrypt

Anonymized DNS can be implemented on top of all existing encrypted protocols, but DNSCrypt is by far the simplest and most efficient instantiation.

It only adds a header with a constant sequence followed by routing information (server IP+port) to unmodified DNSCrypt queries. Implementing it on top of an existing DNSCrypt implementation is trivial.

The overhead is minimal. Unlike DoH where headers may still reveal a lot of information about the client's identity, Anonymized DNSCrypt, by design, doesn't allow passing any information at all besides the strict minimum required for routing.

For relay operators, Anonymized DNSCrypt is less of a commitment than running a Tor node. Queries can only be relayed over UDP, they need to match a very strict format, amplification is impossible, and loops are prevented. Relays can essentially be only used for encrypted DNS traffic.

Available in dnscrypt-proxy now!

A first beta version of dnscrypt-proxy 2.0.29 is available now, and adds support for anonymized DNSCrypt.

The way it can currently be configured is through a new [anonymized_dns] section in the configuration file.

For each resolver, one or more relays can be defined. These relays can be provided as stamps, IP:port pairs, hostname:port pairs, or server name.

You can check that Anonymized DNS is being used by looking at the log messages when proxy starts.

Available in encrypted-dns-server now!

Server-side, Anonymized DNS can now be enabled in Encrypted DNS Server.

This is as simple as changing enabled = false to enabled = true in the dedicated section. It is also possible to restrict the range of upstream ports allowed to connect to, and blacklist IP addresses.

New Prometheus metrics related to relayed queries have been added.

A DoH server, a DNSCrypt server, and a DNSCrypt relay can all run simultaneously on the same IP and port.

Available in the server docker image now!

The DNSCrypt server Docker image has been updated, and supports Anonymized DNSCrypt relaying.

This is disabled by default. In order to enable it, add -A to the init command when creating a container.

Test server available now!

Hopefully more Anonymized DNS servers will be available over time, but for now, you can use the one with stamp sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM for testing.

New DNS Stamp type introduced

A new DNS stamp type has been introduced: DNSCryptRelay (identifier 0x81). It only encodes IPs and ports of relays.

The online DNS Stamp calculator has been updated to support the new stamp, as well as the Go and Rust libraries.

[uBlock-user]

Is this specific to DNSCrypt or available to DoH too ? Nvm, this seems to be a category of its own.

[jedisct1]

@uBlock-user This can only be used with DNSCrypt.

But it can be done with DoH. There is a work in progress to design such a protocol here. It's far more complicated to implement and deploy, but it will probably be implemented as well.

[jedisct1]

@uBlock-user Not a category of its own. It can work with any existing DNSCrypt server. DNS servers don't need any modification to be compatible.

[uBlock-user]

Not a category of its own. It can work with any existing DNSCrypt server

I meant for DoH, I use DoH servers instead of DNSCrypt.

[AlphaTangoCharly]

Works nicely here on Windows 7:

[NOTICE] dnscrypt-proxy 2.0.29-beta.1
[NOTICE] Source [public-resolvers.md] loaded
[NOTICE] Anonymized DNS: routing [suami] via [sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM]
[NOTICE] Anonymized DNS: routing [developerli-fr] via [sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM]
[NOTICE] Anonymized DNS: routing [scaleway-fr] via [sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM]

This is a major update IMO.

Hopefully more Anonymized DNS servers will be available over time, but for now, you can use the one with stamp sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM for testing.

The testing one provided which works perfectly is located in France, as my device so it's just fine for me, but I'm wondering if a device located i.e. Far-East wouldn't encounter lags when the Anonymized DNS server is located far away.

[jedisct1]

@AlphaTangoCharly Thanks for your report!

Yes, we need more anonymizers.

[tigernero79]

@jedisct1
excuse my request but I would like to understand how to configure my dnscrypt-proxy with the new "anonimized dns" function introduced in "2.0.29-beta.1". In practice I'm running my pi-hole so that it redirects the dns calls on port 54 where my dnscrypt-proxy is listening and I only use cloudflare with active dnssec as a server.
my setting:

server_names = ['cloudflare']

## List of local addresses and ports to listen to. Can be IPv4 and/or IPv6.

listen_addresses = ['127.0.0.1:54', '[::1]:54']

# Server must support DNS security extensions (DNSSEC)
require_dnssec = true

how should the new function be configured?
please tell me-.

[anonymized_dns]

## Define one or more routes, i.e. indirect ways to reach servers.
## A set of possible relay servers is assigned to each DNS resolver.
## A relay can be specified as a DNS Stamp (either a relay stamp, or a
## DNSCrypt stamp), an IP:port, a hostname:port, or a server name, if
## the server is in the servers_list.

# routes = [
#   { server_name='cloudflare', via=['sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM'] },
#    { server_name='quad9-dnscrypt-ip4-nofilter-pri', via=['sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM'] }
# ]


## Optional, local, static list of additional servers
## Mostly useful for testing your own servers.

[static]

#   [static.'myserver']
#   stamp = 'sdns:AQcAAAAAAAAAAAAQMi5kbnNjcnlwdC1jZXJ0Lg'

which entries need to be commented out because it does, knowing that I only have cloudflare namer server on 127.0.0.1#54 and active dnssec?

please tell me

[jedisct1]

This will not work with Cloudflare, because they don't support DNSCrypt (yet). With Cloudflare, your only option is to use Tor.

[tigernero79]

@jedisct1

then keeping the main settings, these:

server_names = ['cloudflare']

## List of local addresses and ports to listen to. Can be IPv4 and/or IPv6.

listen_addresses = ['127.0.0.1:54', '[::1]:54']

# Server must support DNS security extensions (DNSSEC)
require_dnssec = true

the anonimized dns section how should it be configured to work?
what values ​​to uncomment and which entries to modify for the new function to work?

[anonymized_dns]

## Define one or more routes, i.e. indirect ways to reach servers.
## A set of possible relay servers is assigned to each DNS resolver.
## A relay can be specified as a DNS Stamp (either a relay stamp, or a
## DNSCrypt stamp), an IP:port, a hostname:port, or a server name, if
## the server is in the servers_list.

# routes = [
#    { server_name='comodo-02', via=['sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM'] },
#    { server_name='quad9-dnscrypt-ip4-nofilter-pri', via=['sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM'] }
# ]


## Optional, local, static list of additional servers
## Mostly useful for testing your own servers.

[static]

  # [static.'myserver']
  # stamp = 'sdns:AQcAAAAAAAAAAAAQMi5kbnNjcnlwdC1jZXJ0Lg'

should I leave the" routes" entries as they are and the static section should be uncommented or not?

or should I also change the main settings I have set?

[vivekrp]

This will not work with Cloudflare, because they don't support DNSCrypt (yet). With Cloudflare, your only option is to use Tor.

So this means it will not work with setup? dnsmasq with dnscrypt-proxy and Cloudflare DNS on macOS: https://gist.github.com/irazasyed/88894e75034af9f8c167f0cbeede9159

[tigernero79]

@jedisct1
then the static I understood that it is a voice that must be decommenata if I have some private server my dns, while it should simply be uncommented the voice or the two routers voices that in practice are relays that hide to the principal dns server the ip of the right client right?
at the moment we only have 02 and quad9 right? how to understand when others will have the same function?

[uBlock-user]

So this means it will not work with setup? dnsmasq with dnscrypt-proxy and Cloudflare DNS on macOS: https://gist.github.com/irazasyed/88894e75034af9f8c167f0cbeede9159

Yes, CF only supports DoH and DoT, just like Google.

[jedisct1]

at the moment we only have 02 and quad9 right?

No, you can use any DNSCrypt server. You can set doh_servers = false, leave server_names empty and type dnscrypt-proxy -list to see the list.

[unixfox]

Do you plan to introduce a list of anonymized DNS servers just like for the DNSCrypt servers with the dnscrypt-resolvers github repository?

[jedisct1]

@unixfox Yes!

So that the list can be automatically updated. Entries will be exactly like the current resolvers, just with a different stamp.

[dmin7b5]

Beta working great for me so far on Catalina @jedisct1 , thanks for all your hard work.

[h-town]

can we spin up a discussion about why DoH support/advocacy should be dropped? serious question.

[Samillion]

That is awesome news, great work!

Do I need to use -list, then add each server based on my options to routes with the test stamp, or is there like a wildcard or a global option to enable it?

[jedisct1]

h-town

DoH is supported, will remain supported and improved, and encrypted-dns-server will soon be able to enable it without configuration (but you still need a domain name).

@Samillion

sever_name='*' can be added, but for anonymized DNS to make sense, the relay and the server have to be operated by different entities.

If both a relay and what it relays to are operated the same company, there is no anonymization at all.

Some heuristics can be added based on IP addresses, but these wouldn't be very reliable. Some people and organizations operate multiple servers on different networks.

[Samillion]

@jedisct1 That makes perfect sense, thank you, I misunderstood how it works at first.

[curiosity-seeker]

Please excuse this probably stupid question from a layman - but even after reading the issues here concerning SNI I'm not really sure if the DNSCrypt protocol encrypts SNI, and if it hasn't so far, if the new anonymized DNS will deal with it.

[jedisct1]

@curiosity-seeker Any encrypted DNS protocol supports ESNI. The decision to enable it or not solely depends on the web browser. https://github.com/DNSCrypt/dnscrypt-proxy/issues/941#issuecomment-536599318

[methmouth]

DoH is supported, will remain supported and improved, and encrypted-dns-server will soon be able to enable it without configuration (but you still need a domain name).

DoH is a scourge to privacy, all told, and a dream come true for bad-actors.

[jedisct1]

There is nothing wrong with the DoH protocol itself. And an anonymized version of also being designed.
Bad actors have tons of creative ways to control botnets. DoH doesn't change anything, except for websites about security looking for headlines that make people click.

But we are digressing a little bit :) Please keep that thread to discuss issues and possible improvements regarding the beta, the server, and anonymized DNS.

[mattriots]

Hello all - And thank you for all your hardwork on dnscrypt! I'm very excited to get this Anonymized DNS up and running but I'm having a bit of trouble. Please excuse me for some layman questions here:
First - is there a more efficient way to update to a new release? I went the long hard way and uninstalled the previous release then installed the new. There has to be a better way right?
Second - This is how i have my "anonymized dns" section set up in the dnscrypt-proxy.toml but im not getting a read out on my log:

 routes = [
    { server_name='scaleway.fr', via=['sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM'] },
    { server_name='quad9-dnscrypt-ip4-nofilter-pri', via=['sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM'] }
 ]


## Optional, local, static list of additional servers
## Mostly useful for testing your own servers.

[static]

  # [static.'myserver']
  # stamp = 'sdns:AQcAAAAAAAAAAAAQMi5kbnNjcnlwdC1jZXJ0Lg'

Do i need to comment out the server name sections? Do I have something incorrectly implemented? any help would be amazing! And thank you again for dealing with my first post - will improve i promise

[ghost]

@jedisct1 This is amazing!

If I may make a suggestion for another useful feature: QNAME minimization / RFC 7816

[curiosity-seeker]

@curiosity-seeker Any encrypted DNS protocol supports ESNI. The decision to enable it or not solely depends on the web browser. #941 (comment)

Thanks, Frank! I had read that before, but I was wondering if the anonymization of your new approach would somehow deal with the SNI aspect regardless which browser is used. But it seems that it doesn't.

[D1n0Bot]

Do we have an ipv6 relay test server?

[jedisct1]

@D1n0Bot We don't! Can you run one?

[adgelbfish]

What's to prevent cloudflare from flooding the internet with relays it controls?

Also, if the operator of the server has access to the encrypted relay traffic (let's say the isp of the relay) they potentially could deannonymize based on timing.

[jedisct1]

@adgelbfish Who chooses the relays? The user does. You choose both the relays and the servers you want to use.

[ghost]

@adgelbfish The problem can be solved with a mix network at the cost of extra time:

1. https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf
2. https://github.com/Katzenpost/docs/blob/master/specs/mixnet.rst#network-topology
3. https://youtu.be/j3AUC0x_ju8?t=1813

QNAME minimization would still help the most?

Neither of these requests needs to include the full name of the website you are looking for
Thus stripping making each request harder to link.

Anyway I see myself out and go back to silent lurking.

[pengelana]

Relays:

IPv4:

Stamp: sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz

IPv6:

Stamp: sdns://gSBbMjQwMDo2MTgwOjA6ZDA6OjVmNzM6NDAwMV06MTQ0Mw

~~~

routes = [
{ server_name='jp.tiar.app', via=['sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz'] },
{ server_name='id-gmail', via=['sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz'] },
{ server_name='scaleway-fr', via=['sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz'] },
{ server_name='id-gmail-ipv6', via=['sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz'] },
{ server_name='jp.tiar.app-ipv6', via=['sdns://gSBbMjQwMDo2MTgwOjA6ZDA6OjVmNzM6NDAwMV06MTQ0Mw'] },
]
~~~

~~~
./dnscrypt-proxy
[2019-10-18 22:16:12] [NOTICE] dnscrypt-proxy 2.0.29-beta.1
[2019-10-18 22:16:12] [NOTICE] Network connectivity detected
[2019-10-18 22:16:12] [NOTICE] Source [public-resolvers.md] loaded
[2019-10-18 22:16:12] [NOTICE] Anonymized DNS: routing [developerli-de-ipv6] via [sdns://gSBbMjQwMDo2MTgwOjA6ZDA6OjVmNzM6NDAwMV06MTQ0Mw]
[2019-10-18 22:16:12] [NOTICE] Anonymized DNS: routing [id-gmail-ipv6] via [sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz]
[2019-10-18 22:16:12] [NOTICE] Anonymized DNS: routing [scaleway-fr] via [sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz]
[2019-10-18 22:16:12] [NOTICE] Anonymized DNS: routing [jp.tiar.app] via [sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz]
[2019-10-18 22:16:12] [NOTICE] Anonymized DNS: routing [id-gmail] via [sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz]
[2019-10-18 22:16:12] [NOTICE] Anonymized DNS: routing [jp.tiar.app-ipv6] via [sdns://gSBbMjQwMDo2MTgwOjA6ZDA6OjVmNzM6NDAwMV06MTQ0Mw]
[2019-10-18 22:16:12] [NOTICE] Firefox workaround initialized
[2019-10-18 22:16:12] [NOTICE] Now listening to 127.0.0.1:5003 [UDP]
[2019-10-18 22:16:12] [NOTICE] Now listening to 127.0.0.1:5003 [TCP]
[2019-10-18 22:16:12] [NOTICE] [developerli-de-ipv6] OK (DNSCrypt) - rtt: 174ms
[2019-10-18 22:16:12] [NOTICE] [id-gmail-ipv6] OK (DNSCrypt) - rtt: 5ms
[2019-10-18 22:16:12] [NOTICE] [scaleway-fr] OK (DNSCrypt) - rtt: 160ms
[2019-10-18 22:16:12] [NOTICE] [jp.tiar.app] OK (DNSCrypt) - rtt: 71ms
[2019-10-18 22:16:12] [NOTICE] [id-gmail] OK (DNSCrypt) - rtt: 4ms
[2019-10-18 22:16:12] [NOTICE] [jp.tiar.app-ipv6] OK (DNSCrypt) - rtt: 71ms
[2019-10-18 22:16:12] [NOTICE] Sorted latencies:
[2019-10-18 22:16:12] [NOTICE] - 4ms id-gmail
[2019-10-18 22:16:12] [NOTICE] - 5ms id-gmail-ipv6
[2019-10-18 22:16:12] [NOTICE] - 71ms jp.tiar.app
[2019-10-18 22:16:12] [NOTICE] - 71ms jp.tiar.app-ipv6
[2019-10-18 22:16:12] [NOTICE] - 160ms scaleway-fr
[2019-10-18 22:16:12] [NOTICE] - 174ms developerli-de-ipv6
[2019-10-18 22:16:12] [NOTICE] Server with the lowest initial latency: id-gmail (rtt: 4ms)
[2019-10-18 22:16:12] [NOTICE] dnscrypt-proxy is ready - live servers: 6

~~~

[jedisct1]

Awesome!

A new list was created for relays (buy @pengelana already noticed it!) :

https://github.com/DNSCrypt/dnscrypt-resolvers/blob/master/v2/relays.md

[vbauerster]

@jedisct1
I suppose client should not connect to server directly if that server is routed via relay. So if this is true, then in my case I should be able to use banned servers by my ISP via accessible relay. But this is not the case, for example I cannot use jp.tiar.app directly, and was hoping to use it via sdns://gRExODguNjAuMjUyLjE2OjQ0Mw relay, but with no success:

I had to mention that I'm able to use not banned server via that relay, for example there was no problem with comodo-02.
PS: dnscrypt-server compiled against 18ba5fe.

[EsmailELBoBDev2]

I know this kinda weird but can i do mix between relays ? something like

routes = [
   { server_name='a-and-a', via=['sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM', 'sdns://gRExODguNjAuMjUyLjE2OjQ0Mw', 'sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz'] },
   { server_name='doh-ibksturm', via=['sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM', 'sdns://gRExODguNjAuMjUyLjE2OjQ0Mw', 'sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz'] },
   { server_name='publicarray-au-doh', via=['sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM', 'sdns://gRExODguNjAuMjUyLjE2OjQ0Mw', 'sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz'] },
   { server_name='publicarray-au2-doh', via=['sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM', 'sdns://gRExODguNjAuMjUyLjE2OjQ0Mw', 'sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz'] },
   { server_name='developerli-fr-doh', via=['sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM', 'sdns://gRExODguNjAuMjUyLjE2OjQ0Mw', 'sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz'] },
   { server_name='developerli-de-doh', via=['sdns://gRIxMzcuNzQuMjIzLjIzNDo0NDM', 'sdns://gRExODguNjAuMjUyLjE2OjQ0Mw', 'sdns://gRMxNzQuMTM4LjI5LjE3NToxNDQz'] }
]

it will work ? or i must add one relay ?

[jedisct1]

@vbauerster A direct connection is still required to retrieve the current certificate. This step will eventually also be routed through relays.

[jedisct1]

@EsmailELBoBDev2 Yes, for each server, you can have as many relays as you like.

Currently, a random relay of each list will be chosen for each resolver, and that relay will be used until the end of the session. But the plan is to be able to either use a random relay for every query, or automatically use the fastest ones.

[EsmailELBoBDev2]

@jedisct1 sound great! i mean one each query it will be good for privacy (we will see some lag but yeah) i hope you can do this future ASAP

[h-town]

There is nothing wrong with the DoH protocol itself. And an anonymized version of also being designed.
Bad actors have tons of creative ways to control botnets. DoH doesn't change anything, except for websites about security looking for headlines that make people click.

But we are digressing a little bit :) Please keep that thread to discuss issues and possible improvements regarding the beta, the server, and anonymized DNS.

i'm kind of questioning my use of dnscrypt[-proxy] at this juncture. have you done your research? do you understand the implications of allowing/enabling encrypted dns to follow the same outbound port as your web traffic? you could legit use this project as a somewhat public statement against a really, really bad mechanism for dns resolution if you chose to eliminate it.

yes, i still use several deployments of dnscrypt-proxy. yes, doh is disabled. this isn't about me being able to configure my client to do what i want, rather a campaign against this BS before it's too late. !remindme 2022

edit: btw, the anonymized dns feature looks promising. excellent work. this is the right direction for all things dns...only without https, naturally.

[vbauerster]

@jedisct1 Thank you I got it.
Another question, how is load-balancing strategy handled with anonymized dns?
For example suppose that fastest server is routed via slowest relay by coincidence and if load-balancer still pick ups by server latency there could be quite opposite effect.

[jedisct1]

@vbauerster The fastest server will be chosen at the beginning, but if it turns out to be slower due to relaying, other servers will gradually be preferred.

[D1n0Bot]

Question on dnssec
Does relay server also need to have dnssec on for it to work?

Coz I tried both anon-tiarap & anon-tiarap-ipv6
The ipv4 dnssec but ipv6 seems to fail? Both end dns server are dnssec ready. Using Quad9 for both ipv4 and ipv6.

Or does Quad9 ipv6 dnscrypt have dnssec in the first place? Anyone can confirm?

[pengelana]

@D1n0Bot Relay doesn't need to have dnssec.
The problem with IPv6 already fixed .

[glitsj16]

Anonymized DNS works very well here when using the stamps format in the routes entree. Documentation mentions that a server name can also be used:

## A relay can be specified as a DNS Stamp (either a relay stamp, or a
## DNSCrypt stamp), an IP:port, a hostname:port, or a server name, if
## the server is in the servers_list.

Is servers_list in this context referring to relays.md or to public-resolvers.md, or both? Either way, I always get Invalid relay [foo] for server [dnscrypt.nl-ns0] with latest from git:

 routes = [
    { server_name='dnscrypt.nl-ns0', via=['anon-charis'] }
 ]

dnscrypt-proxy[**]: Invalid relay [anon-charis] for server [dnscrypt.nl-ns0]

routes = [ { server_name='dnscrypt.nl-ns0', via=['ibksturm'] } ]
dnscrypt-proxy[**]: Invalid relay [ibksturm] for server [dnscrypt.nl-ns0]

This might not be implemented yet, in which case this is more of a FYI.

Regards

[Safari77]

Why is it sometimes sending 2048 or 4096 byte UDP packets? Nothing in log file with log_level = 0.

Linux x86_64 4.19.78 , dnscrypt-proxy 2.0.29-beta1 configured with anonymized_dns and
dnscrypt_servers = true doh_servers = false.

2019-10-20T10:19:18.379778724Z IP (tos 0x0, ttl 64, id 21917, offset 0, flags [+], proto UDP (17), length 1500)
    192.168.178.44.22862 > 77.66.84.233.443: UDP, bad length 2048 > 1472
2019-10-20T10:19:18.379790873Z IP (tos 0x0, ttl 64, id 21917, offset 1480, flags [none], proto UDP (17), length 596)
    192.168.178.44 > 77.66.84.233: ip-proto-17
2019-10-20T10:19:18.424370760Z IP (tos 0x0, ttl 56, id 59967, offset 0, flags [none], proto UDP (17), length 1420)
    77.66.84.233.443 > 192.168.178.44.22862: UDP, length 1392

[jedisct1]

@Safari77 Because you're probably using dnsmasq with DNSSEC enabled, sending queries that will require large responses. UDP fragmentation is fine with authenticated messages. But this is unrelated to anonymized DNS.

[jedisct1]

Closing, since beta 2 is out and has quite a bit of changes, so it probably needs a new thread in order to avoid mixing issues from beta 1 and beta 2.