HushDNS, can I please get me some DNS privacy

02 Apr 2020 in Anonymity / Privacy / Security on Unbound, Pi-hole, Dnscrypt, Dns, Privacy, Anonymity

Motivation & background

I continuously try to improve my digital privacy. Which in todays world also means my general privacy.

So DNS.

Hmmm I don’t really need to say much more. But, I should. To properly set the scene and give an overview of the current state of domain name to IP issues.

The DNS queries your system/browser and whatever software you use execute, leave you exposed to tracking by prying outsiders. Leaving you with little privacy in regards to e.g. which websites you visit. This is so. Because the data (requests and responses) involved when using DNS, is in the clear. Meaning –> everybody can determine the websites and other Internet related services you use. Furthermore, a DNS query you execute can be mingled with. So you could end up on a website controlled be ill intended people. Rather on the one you intended.

Luckily, it’s possible to seriously combat the issues that DNS have. The rest of this post will be about how-to do exactly that.

Let’s do this!

Motivation & background

Action points

Make DNS queries anonymous
- Avoid being logged in as many locations en route to a DNS authoritative server answering ‘x’ DNS query
Encrypt DNS communication. From today until Halloween … so always ultra
Use some form of response validation control. So that the response can be controlled for integrity and forging (e.g. DNS cache poisoning)
The origin of ‘x’ DNS query should be as hard to track back to as possible
Give this project a name. Rememberable and catchy. All IT projects need such a name. Do they not?

Determining resolutions to the action points

Charged with motivation I then started investigating, analyzing and trawling through information on how-to make DNS private and secure. After scouring the corners of the Internet and reading plenty of blogposts and whatnot. I felt ready to get into the heat of the action.

A boring life is a life without action

Anonymity and logging

To avoid being logged and be in greater control of potentially what my DNS queries leak. I came to the conclusion that I needed to run my own DNS recursive name-server.

I ended up choosing Unbound. It is OSS. I can run it on my own hardware. And it can be containerized. The documentation on it is solid and it is build be a highly skilled group of people at NLNETLABS.

Because Unbound have support for DNS Query Name Minimisation. Your privacy is improved by only sending the parts of a domain name, that the different actors involved in a DNS query, really needs to process a request. That alleviates the pain of leaking DNS query data. Good stuff .

N.B. specifically I’ll be running Unbound as part of the dnscrypt-server in a container “package”.

Encrypt all the things

But with what? I’ll tell you my DNS security compadre.

With….

dnscrypt-server

In the words of the dnscrypt-server project, it is:

- A minimal Ubuntu Linux as a base image.
- Caching resolver: Unbound, with DNSSEC, prefetching, and no logs. The number of threads and memory usage are automatically adjusted. Latest stable version, compiled from source. qname minimisation is enabled.
- encrypted-dns-server. Compiled from source.

Keys and certificates are automatically rotated every 8 hour.

This is great. Some really cool people made this project. Ripe and ready for me to piggy back on. I was quite ecstatic when I found it.

It fits right into the needs of the HushDNS project. Because:

DNS queries will be encrypted
It can easily be run on an external server. Making it harder to traceback the origin of the DNS query
especially combined with the Anonymized DNS feature of dnscrypt-server.

dnscrypt-proxy

It wraps a DNS recursive name-server that natively does not support encrypting DNS queries. Enabling communication from the DNS recursive name-server to the externally running dnscrypt-server. To be wrapped in this case is le Pi-hole. Oui oui. More on Pi-hole in a few.

Both of the above systems is developed by the DNSCrypt project. Thank you for that! Great stuff .

They are OSS and have solid documentation. It’s all good in the hood-ie.

Integrity and anti-forging

The answer is DNSSEC (Domain Name System Security Extensions) provides anti-forging and validation.

Limit tracking

I’ve already been onto this subject. As I mentioned in the Anonymity and logging section. Unbound gives me control over DNS query logging as well as the DNS Query Name Minimisation feature. But there is more to combatting being tracked.

When you visit e.g. a website a request for a name to IP translation takes place. As DNS is designed, this request will be in the clear. If we encrypt it, use DNS Query Name Minimisation, avoid it being logged in as many places as possible and use DNSSEC to get integrity and prevent forging. We traverse into greener fields.

But <- there it was - Hi!

When a domain name has been properly translated to an IP address that IP address will be accessed. Of course. It’s your ticket to the destination website. If this is done over a tunneled connection (HTTPS) the SNI HTTP header will be sent along with the request. So that the receiving end (the web-server) can serve the correct certificate (public key cryptography my friend). This header reveals what you are visiting. If HTTPS is not involved, the web-server will look at the hostname part of the URI. However, everything is in the clear anyway. So tracking in that scenario is easy peasy.

Hey! Mr. Lars Bengtsson. Haven’t you heard. ESNI (Encrypted Server Name Indication) is a thing now! Yes I have. But it is not supported by all web-browsers. And if you rely on e.g. the Firefox <-> Cloudflare DoH ESNI solution. You basically trust them not to forge and log your DNS requests. This is an issue. By some, considered to be of major proportions. See:

DNS Privacy at IETF 104

More DOH

Both articles are by Geoff Huston. The chief scientist at APNIC (the Asia Pacific Network Information Centre)

However, I’ll try to see if I can configure Firefox to use my DoH DNS setup. Then again, I control logging or no logging. Encryption and on we go. Follow along to see if I succeed. If (when) I do, ESNI can be used and we are a tad more safe. However, there is still the caveat that the web-server hosting the destination website have to support ESNI. So we are not home-free. And even with ESNI there is PLF (Page Load Fingerprints), which is a way to determine the website you are accessing by analyzing the meta-data “surrounding” that visit. In other words. Even though your DNS query was secure, unforgeable and so forth. Accessing the IP address that was returned as a response to the DNS query and the other resources involved in loading a website, can reveal the identity of the website you are visiting. Because most websites have a unique set of resources they need. Integration with facebook (need, yeah right), ad networks, CDN’s and on we go. So basically. Identify this set and you know the website being visited.

It is possible to combat PLF. By using an ad-blocker that works on the application layer. By blocking DNS requests to the resources that ‘x’ website thinks it needs, but doesn’t really, for the website to be useful to you. This is where Pi-hole comes in.

E.g. you can often block ads or metrics software on a website and the website continues to work. In this way, prying eyes, trying to identify the website you are visiting, would not be able to utilize PLF. As the resources actually being requested when accessing a website do not match the PLF set determined by analyzing the website.

But the issue around SNI and ESNI still persists. Nothing else to do there than push for companies to host their website on platforms supporting AND using ESNI. Unless you go the VPN or Tor route. However, using Tor comes with its own caveats. See this.

Executing on the findings

A jaw dropping project name

HushDNS it is. Because those DNS queries should “shut up and be quiet”. I’ll let it be up to you to grade the name.

I like IT - and I like it a looooot . HushDNS, who can’t remember that?

N.B. the rest of the practical part of this blog post, will be going through the components one by one. In order to detail how each component work. However, if you quickly want to reap the benefits of using HushDNS follow the installation guidelines on the HushDNS repository

Resolving the anonymity and logging issue

Blocking DNS requests at the Application layer

Pi-hole is a blackhole for Internet advertisements. Technically you configure it to be your DNS server on your LAN and then, when ‘x’ software on your computer needs to resolve a domain name to an IP address. Pi-hole is requested to do that. If it finds that the requested domain name is on a blacklist it responds with its own IP, and the software making the request gets an empty payload back when requesting data from the returned Pi-hole IP. This results in an empty space on the website you are accessing. E.g. where an ad should have been shown.

This is a great way to combat the effectiveness of page load fingerprinting. Simultaneously you limit the amount of 3rd parties that know of your IP and website surfing habits.

Configuring Pi-hole

I’ll be running Pi-hole in a container. Using this docker-compose.yml file.

Kick of the Pi-hole container

Download the above mentioned file
Execute: docker-compose -f PATH_TO/docker-compose.yml -p "PiHole" up -d
1. This will install Pi-hole. Name the compose “project” and container PiHole and detach from the container

Settings for the Pi-hole container

The Pi-hole docker-compose file is specified to setup Pi-hole in the following way.

CONDITIONAL_FORWARDING: "true": Used in the case that Pi-hole is not the DHCP server on the network
CONDITIONAL_FORWARDING_IP: "IP_ADDRESS": The IP address of the DHCP server on the network
CONDITIONAL_FORWARDING_DOMAIN: "DOMAIN_NAME": A DNS suffix name. It has to match the DNS suffix name used in the DHCP server
DNS_BOGUS_PRIV: "true": Specifies that reverse IP lookups for LAN IP addresses should never be forwarded to upstream DNS servers
DNSMASQ_LISTENING: "local": Controls which network interface dnsmasq will listen on. Specifying “local” results in > Allows only queries from devices that are at most one hop away (local devices).
DNS1 and DNS2. As Pi-hole complains if you don’t specify two addresses I had to trick it to query on the localhost IP and the regular IP of the same network interface. The port part, #5354 is important. This is the port that dnscrypt-proxy listens to. And that is where queries from Pi-hole is being sent. More on that dnscrypt-proxy later on
ServerIP: "IP_ADDRESS": Needed when running the container in host network mode
TZ: 'Europe/Copenhagen': The timezone that Pi-hole runs in
WEB_PORT: "808": Need when Pi-hole runs in host network mode. Can break that you see a “beautiful”, blocked by Pi-hole block where an ad would’ve been displayed. I can live with that
dns: - 127.0.0.1. Used to specify the DNS server used inside the container. Should end up in the container /etc/resolv.conf file. However, not always do. There is an issue on this on GitHub. Still have the setting here, to remember the issue and that this is the intended configuration
volumes: - "./etc-pihole/:/etc/pihole/" && - "./etc-dnsmasq.d/:/etc/dnsmasq.d/": To store Pihole data between upgrades
volumes: - "./resolv.conf:/etc/resolv.conf:ro": A trick I needed to do. More on this in the QNAP specifics section below.

N.B. I haven’t configured Pi-hole to use DNSSEC as the dnscrypt-server is per default configured to do this. And validating DNS answers via dnssec in several locations will not do us any good. Just slow things down and potentially causes failed DNS queries. However, if you are not going to use the dnscrypt-server make sure to enable it via the DNSSEC environment variable in the docker-compose file

QNAP specifics

If you’ve been following my blog here, you will know that I run much of workloads on a QNAP NAS. Because of that, I often times need to go through loopholes to get “things” to run like I want it. Which in turn is also why I’m often considering abandoning my QNAP.

So here is another one of those sections . How-to get ‘x’ to run properly on a QNAP.

Fixing resolve.conf
1. Create a resolve.conf file with the following content. The file needs to be located relative to the resolve.conf container volume mapping mentioned in The settings above

nameserver 127.0.0.1
options ndots:0

this content will overwrite whatever is in the etc/resolv.conf inside the Pi-hole container. Making dns work as intended inside the container.

This setting also relates to the dns: - 127.0.0.1 setting. As it didn’t always work without overwriting the resolve.conf file.

Disable dnsmasq. To do that execute the below

cp /etc/dnsmasq.conf /etc/dnsmasq.conf.orig
sed 's/port=53/port=0/g' < /etc/dnsmasq.conf.orig >/etc/dnsmasq.conf
/usr/bin/killall dnsmasq

Alternatively follow Running your own application at startup (on QNAP), to avoid doing that on every QNAP boot

Useful docs

Tumbling DNS queries

By using dnscrypt-proxy we gain access to the DNSCrypt projects Anonymized-DNS feature. This feature makes it harder to origin trace our DNS queries. It does its magic by … aaah no, allow me to use a word by word copy of this description. So:

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

Considering Anonymized-DNS when you run your own `dnscrypt-server`

The question is, however, if it’s necessary and/or beneficial to use Anonymized-DNS if you run your own dnscrypt-server. In comparison, you really should if you use an external provider like CloudFlare.

After having used Anonymized-DNS for several days, with my own isolated dnscrypt-server I weighted the pros and the cons. Then re-considered. The feature is simply not stable enough. Then, when it also entails added latency, it is currently not worth it. But, I will revisit this in the feature as it does add an extra layer of anonymization.

For good measure. Here is my list of pros and cons:

Pros

Extra anonymity, yes even if you run your own dnscrypt-server, specifically if someone tries to sniff on you. By analyzing traffic between the dnscrypt-server and the dnscrypt-proxy they could be able to see that its DNS traffic going out of the dnscrypt-server endpoint and then on the other side, what IP that’s connecting to it. And if its very few IP’s, it should be possible to analyze the source of the DNS traffic and thereby de-anonymize your .

Cons

Extra latency
Depending on the external Anonymized-DNS relay servers being up and working
The implementation of Anonymized-DNS in dnscrypt-proxy, at least up until v2.0.42, selects one relay server and then stays on that until reboot. So if that relay goes down you’ll have to reboot. Instead the Anonymized-DNS feature should be able to switch over to another configured relay server if there is problems with the currently selected one
Added complexity when troubleshooting

Configuring dnscrypt-proxy

Another workload I’ll be running in a container. This time by using this docker-compose.yml file.

Kick of the dnscrypt-proxy container

Download the above mentioned file
Execute: docker-compose -f PATH_TO/docker-compose.yml -p "dnscrypt-proxy" up -d
1. This will install dnscrypt-proxy. Name the compose “project” and container dnscrypt-proxy and detach from the container

Settings for the dnscrypt-proxy container

DNSCRYPT_LISTEN_PORT: “5354”: Self-explanatory
DNSCRYPT_SERVER_NAMES: “[‘MY_SECRET_DNSCRYPT-SERVER’]”: The dnscrypt-server or DoH server that dnscrypt-proxy should connect to
network_mode: “host”: The port was not reachable for Pi-hole if this network mode was not used

In order to setup Anonymized-DNS we need to complete the following steps (if you still want to set it up, considering the pros and cons of Anonymized-DNS):

Ensure that there is a sub-folder named conf in the folder of the dnscrypt-proxy docker-compose.yml file 1. In this folder create a file named dnscrypt-proxy.toml
Use this dnscrypt-proxy.toml file as a template
1. Change the value of server_names in the Global settings section to the name you will give your dnscrypt-server
2. Potentially change the listen_addresses to the port you want (in the Global section)
3. Under the Anonymized DNS section change the routes array to contain one or more Anonymized DNS relay servers of your choice. Find available relay servers here. Make sure to change the server_name in the routes definition, to reflect the value of the server_names property in the Global section

N.B. if you look at the dnscrypt-proxy docker-compose.yml file you’ll notice that there is a volumes mapping. This volume mapping is what the above steps relate to

I said: “don’t log me”

And “they” listened. Good for them. So what “they” did was to ensure that neither Pi-hole, dnscrypt-proxy or dnscrypt-server was in any form of logging mode.

Disabling logging in Pi-hole

When you feel certain that your Pi-Hole installation is working, it’s a good time to disable its logging behavior. By:

Going to Settings in the Pi-Hole web-interface
Clicking on the Privacy tab
Then activating the radio button: Anonymous mode: This disables basically everything except the live anonymous statistics…... This setting is very privacy minded but still makes it possible to verify that Pi-Hole is actually blocking certain queries. You’ll also still have the main stats available, now just politely anonymized

There is currently no way to do the above in an automated fashion. As the Pi-hole in a docker container project does not support configuration on this on container initialization. However, you could overwrite the PRIVACYLEVEL=0|1|2|3|4 (optionally read this) setting, by using a Docker volume mapping to /etc/pihole/ in order to overwrite the pihole-FTL.conf file with your own customized one. I chose not to, as this is the only setting I would need to overwrite. Making the extra work required too much in my opinion

Disabling logging in dnscrypt-proxy

Not much to do here. The dnscrypt-proxy is already non-logging in its default setup.

Disabling logging in dnscrypt-server

Not much to do here. The dnscrypt-server is already non-logging in its default setup.

Encrypting all the things

This is achieved by using dnscrypt-proxy and dnscrypt-server.

As I have already explained how-to setup dnscrypt-proxy and there is no more to it. This part focuses on the dnscrypt-server.

Configuring dnscrypt-server

As dnscrypt-server needs an init container, and that is not supported by the Docker engine, you’ll have to do with a shell script.

Download this bash script and ensure to update the placeholders (capital words, separated by an underscore) with actual useful values
1. Change the port of the dnscrypt-server if you need to (already have ‘x’ service running on port 443). Change from port 443 to “your” port, in all the locations where it is specified
2. Make the file executable by executing: sudo chmod +x ./THE_NAME_YOU_GAVE_THE_FILE
Execute the file on the system that is to host the dnscrypt-server
Note down the output of the init -N NAME_TO_GIVE_YOUR_DNSCRYPT_SERVER... command as you need the info when configuring dnscrypt-proxy
1. you can also get the output after the fact by executing docker logs dnscrypt-server
2. The output to copy is the generated stamp. You need this in order to connect to the dnscrypt-server via the dnscrypt-proxy

Using it together with `dnscrypt-proxy`

As we can see in the Settings for the dnscrypt-proxy container section. Configuring the dnscrypt-proxy involves its dnscrypt-proxy.toml file. So, in order to use the dnscrypt-server you just spun up together with your dnscrypt-proxy server, you need to update the dnscrypt-proxy.toml file.

Find the [static] section in the file
Change the server name part of [static.'hush.dns'] to the server name you’ve used throughout the dnscrypt-proxy.toml file
Finally set the value of the stamp property to the DNSCrypt stamp that the dnscrypt-server spit out when it was initialized

Verifying that the dnscrypt-server works

N.B. if you are on Docker Desktop for Mac you cannot ping or use dig/drill directly to the container. Even though it is in host network mode. This is because Docker Desktop for Mac cannot route traffic to containers. That's the reason for the below way to test whether the dnscrypt-server` is working

With a DNS query

On Mac

Execute: docker exec -it DNSCRYPT_PROXY_CONTAINER_NAME /bin/sh
Then: drill -p THE_PORT_YOU_CHOSE @127.0.0.1 SOME_DOMAIN

On Linux

I haven’t tested this but it should be possible to execute: drill -p THE_PORT_YOU_CHOSE @127.0.0.1 SOME_DOMAIN directly to the dnscrypt-proxy container. In other words you don’t have to exec into the container.

For both of the above examples. If you get back a valid answer you know that the dnscrypt-server works. To get even more reassurance, stop the dnscrypt-server container and try again. Now you should get no answer back. Rather a timeout/network error.

Verifying the use of Anonymized-DNS

It makes the most sense to verify Anonymized-DNS from the point of the dnscrypt-server. As this is the server that will get the dnscrypt-proxy forwarded DNS query. And therefore is the server that should NOT see your WAN IP (from where the dnscrypt-proxy is running). Rather the WAN IP it sees making a DNS query is an Anonymized-DNS relay server.

On the server where the dnscrypt-server is running execute: tcpdump -nnSX port 443 this will sniff on HTTPS (port 443).

An example output could look like:

20:35:10.770590 IP SOME_WAN_IP.443 > ANONYMIZED_DNS_RELAY_SERVER_WAN_IP.38756: UDP, length 240
        0x0000:  4500 010c 2a4a 4000 4011 6c80 82e2 d9de  E...*J@.@.l.....
        0x0010:  5410 f245 01bb 9764 00f8 a420 7236 666e  T..E...d....r6fn
        0x0020:  7657 6a38 f984 9650 3145 710b a9ff c436  vWj8...P1Eq....6
        0x0030:  f999 4174 d7ae a874 b313 08f7 aa9b 7c9c  ..At...t......|.
        0x0040:  5dc6 0da6 3c19 1adc d272 30ee 0927 472a  ]...<....r0..'G*
        0x0050:  83e5 6fa9 8ac8 7a9f a8c7 6201 1dbf ff06  ..o...z...b.....
        0x0060:  7703 e04c 0023 c681 6e47 7b37 1b2b cb35  w..L.#..nG{7.+.5
        0x0070:  a740 edbc c232 0fb5 15d5 8036 fe57 6525  .@...2.....6.We%
        0x0080:  5925 e324 d25b 376d 5d0a 4e4d 320d c6d8  Y%.$.[7m].NM2...
        0x0090:  58d2 7697 1aff d2f0 37a7 cc19 48be d066  X.v.....7...H..f
        0x00a0:  1e68 ff34 fb35 d231 651f 8b33 0033 93e1  .h.4.5.1e..3.3..
        0x00b0:  6ceb f9e1 1676 a592 f69e fe62 a3f5 688f  l....v.....b..h.
        0x00c0:  2db6 ea30 0e6b ff56 fa8a 4223 4520 767c  -..0.k.V..B#E.v|
        0x00d0:  79d1 dcb9 cf66 6aba a748 2de8 223f d2dd  y....fj..H-."?..
        0x00e0:  d2af 3179 47ac 85a6 b7cd a8ab ef7a cfa9  ..1yG........z..
        0x00f0:  ee99 9df9 70ce 2049 c657 f686 906c 0c41  ....p..I.W...l.A
        0x0100:  1f13 1f07 dd0c 0154 0871 4a46            .......T.qJF

You can be all up if the WAN IP making the DNS query is not your WAN IP but the WAN IP of a DNSCrypt Anonymized-DNS relay server. Getting the IP of a relay server is easy with the online DNSCrypt Stamp calculator. Just insert the stamp of the Anonymized-DNS server you use in the stamp field on the page and you should be able to see the WAN IP of the relay server in the IP Address field .

Optionally you can go-to the DNS leak test site to see whether it’s your private WAN IP or a WAN IP of an Anonymized-DNS relay server.

Don’t forge my integrity

As you may remember, the answer is DNSSEC. We got a little here. In that it is already enabled when we use the jedisct1/dnscrypt-server container image. The devil is the detail, or maybe in the detail. Whatsoever, DNSSEC is availble via the Unbound DNS recursive name-server that dnscrypt-server uses internally. Therefore gifting us with DNSSEC.

How DNSSEC works and some background

To my surprise the IETF (Internet Engineering Task Force) have been working on DNSSEC since 1993.

It is designed to protect against:

packet interception (in its various forms)
ID Guessing and Query Prediction
Name chaining (a subset of “cache poisoning” attacks)
Betrayal By Trusted Server. E.g. an ISP DNS server configured to forward statistics to a 3rd party unbeknownst to the end-user
Authenticated Denial of Domain Names
Data integrity and data origin authentication for “wildcard” DNS names

However, it does NOT protect against:

modification of the DNS message header. Meaning that the response is digitally signed. But the message packet header could still be mingled with. A properly configured DNS recursive name-server, however, combat that
unless configured to do so, DNSSEC does not cover glue records, which are records that combat circular lookup dependencies, e.g. when ‘x’ domains name-servers are on the same root domain as the general resource records
Denial of Service. Actually enabling DNSSEC might make the problem worse

It works by….nah, let’s just unscrupulously copy in the description on wikipedia

DNSSEC works by digitally signing records for DNS lookup using public-key cryptography. The correct DNSKEY record is authenticated via a chain of trust, starting with a set of verified public keys for the DNS root zone which is the trusted third party. Domain owners generate their own keys, and upload them using their DNS control panel at their domain-name registrar, which in turn pushes the keys via secDNS to the zone operator (e.g., Verisign for .com) who signs and publishes them in DNS.

N.B!

DNSSEC does NOT give us confidentiality. That is why we need a solution like the dnscrypt-server. That wraps the Unbound DNS recursive name-server in the encrypted-dns-server proxy. Only then, prying eyes will not be able to sniff (on) the data-stream between the dnscrypt-proxy and the dnscrypt-server.

Configuring DNSSEC

Both the dnscrypt-proxy container, if you use the example dnscrypt-proxy.toml file, and the dnscrypt-server is all ready and prepped for using DNSSEC. Nothing more to do. Perfect days

Verifying that DNSSEC works

Enter the dnscrypt-proxy container by executing: docker exec -it dnscrypt-proxy /bin/sh
Fire of: drill -p PORT_DNSCRYPT_PROXY_LISTENS_ON @127.0.0.1 dig sigfail.verteiltesysteme.net
1. Should return ->>HEADER<<- opcode: QUERY, rcode: SERVFAIL, id: 64618 if it doesn’t on your first try (you might see Error: error sending query: Could not send or receive, because of network error), try again.
Then fire of: drill -p 5354 @127.0.0.1 dig sigok.verteiltesysteme.net
1. Should return ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 36866 and the A record of the domain in the resulting payload

DNSSEC documentation

Limiting tracking

DNS Query Name Minimisation

Already enabled in the default dnscrypt-server settings (more specifically, its actually the Unbound configuration). So that can be

SNI & ESNI, Firefox

I decided that it is too early days for using ESNI. It is simply not supported broadly enough. Still very much an experimental feature and the performance cost is too steep to my liking. The dnscrypt-proxy project describes some facts on ESNI to consider here.

In all fairness I should mention that it would be possible to use ESNI by taking advantage of the dnscrypt-proxy and then configure Firefox to direct its ESNI DoH traffic through your dnscrypt-proxy. Therefore, if you still feel that ESNI is something you want to experiment with, then follow the dnscrypt-proxy ESNI guide

PLF AKA Page Load Fingerprints

I’ve already touched upon this issue in the Limit tracking section.

Here we are at the end of the rainbow … and what do we, you, somebody find?

Nothing more. Sorry for destroying your imagination .

What you did find via this post though, was a HushDNS setup to make your DNS life more private, anonymous and secure. What a tremendous .

Over and out