Authenticated/Encrypted DNS, DNSSEC (over clearnet or Tor)
TODO: brief introduction what DNS is, current status of widespread insecure DNS
DNS Resolver Features
A recursive DNS lookup is where one DNS server communicates with several other DNS servers to hunt down an IP address and return it to the client. Recursively querying a host that is not cached as an address, the resolver needs to start at the top of the server tree and query the root servers, to know where to go for the top level domain for the address being queried.
- Opposite of recursive, is iterative:
an iterative DNS query, where the client communicates directly with each DNS server involved in the lookup.
- Opposite of recursive, is iterative:
The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.
- Validating: perform DNSSEC authentication, end-to-end verification of DNSSEC.
- Opposite of validating is non-validating.
- DNS over TLS (DoT): Encrypted DNS. (Port
- DNS over HTTPS (DoH): Encrypted DNS, similar to above but provides better censorship circumvention in theory as it uses the commonly used web https port
- Opposite of encryption is unencrypted.
- DNS over TLS (DoT): Encrypted DNS. (Port
To avoid having to take the performance hit of issuing multiple iterative request to other DNS servers every time it receives a recursive request, the server caches its results.
- Opposite of caching is non-caching.
DNS encryption does not imply DNS authentication.
root name servers
DoT vs DoH
There are, however, DNS clients that do not support DoT but are able to use DNS-over-HTTPS (DoH) instead. Where DoT sends a DNS message directly over TLS, DoH has an HTTP layer in between. Where DoT uses its own TCP port (853), DoH uses the standard HTTPS port (443). Using the standard HTTPS port makes it harder to block DoH queries, as blocking TCP traffic on port 443 will also block a lot of web traffic. Some people think this is great as this ensures that the user’s DNS queries will always be encrypted; others have concerns about DoH as they might lose control over clients in their network. At NLnet Labs we are in favour of encrypting DNS traffic to limit the exposure of privacy-sensitive data. By adding downstream DoH support to Unbound we hope to increase the ratio of encrypted DNS traffic and increase the number of resolvers that offer encrypted services in home networks, enterprise networks, ISPs, and public resolvers.
There was some bad press about DoH.  There are some stakeholders who find DoH troublesome (oppressive governments, censors, corporate network administrators) however see this rebuttal by the DoHoT project. It would also be problematic if browser vendors such as Google Chromium of Mozilla Firefox enabled DoH by default. That is because it delegates the power which website remains reachable and which gets blocked in DNS from the internet service provider (ISP) to the browser vendor. Firefox enabled DoH by default in USA.  In conclusion, an end-user having awareness of their DNS setting that opt-in to reconfigure on their system level to use either an DoT or DoH server should have only advantages and no disadvantages.
Here is a big DNS over HTTPS (DoH) server list.
There is a difference between a local DNSSEC aware resolver and a local DNSSEC validating resolver.
At the time of writing, no major end-user operating system performs DNSSEC validating by default. 
When enabling DoH in some web browsers such as Mozilla Firefox, there is no authentication yet. In other words, Firefox does not perform local DNSSEC validation yet.
DNS Resolving Security Feature Wishlist
Ideally, all of the following security properties would be fulfilled by a local DNS resolver setup the same time:
- Recursive: One would want to get the information from the most authoritative source, starting from the root name servers instead of iterative "asking a third-party server".
- DNSSEC: authenticating DNSSEC signed DNS data.
- Validating: Locally verifying DNSSEC signatures instead non-validating, i.e. trusting a remote DNS server to do that.
- Encryption: To protect non-DNSSEC data from malicious manipulation through man-in-the-middle attacks (injection of advertisements, malicious redirects, malware), to protect network neutrality, privacy and for circumvent censorship.
DNS Security Optimization Problem
At the moment it is impossible to get all features from the DNS Resolving Security Feature Wishlist at the same time.
The author of this wiki page is unaware of any DNS resolver software with DNS encryption features which would also perform local DNSSEC validation on the user's computer.
dnscrypt-proxyis DNSSEC aware but dnscrypt-proxy at time of writing is DNSSEC non-validating. 
cloudflaredis DNSSEC non-validating? 
systemd-resolved: Has at time of writing an non-acknolwedged bug report resolved DNSSEC validation can be bypassed by MITM and a feature request local DNSSEC validation which asks to clarify if systemd-resolved is a DNSSEC aware or local DNSSEC validating DNS resolver.
When a user is using
cloudflared, the user must choose one or multiple specific DNS servers used for DNS resolution (iterative DNS resolver). I.e. the user can not these programs as recursive DNS resolver.
It is a difficult choice to make. Depends on the user's threat model.
- The user either trusts the root DNS servers or third-party servers.
- TODO: expand
There are various options.
- A) The start situation in which most users are in. Without any configuration, most users use their internet service provider's DNS server which often is DNSSEC unaware. Even if DNSSEC aware, the ISP would do validation for the user since as mentioned above, no (mainstream) operating systems at the time of writing perform local DNSSEC validation. Therefore the user is vulnerable to malicious DNS through a man-in-the-middle attack on DNS for both, DNSSEC secured and DNSSEC unsecured domains.
- B) Using encrypted DNS without local DNSSEC validation with a trusted DNS server should by definition prevent a man-in-the-middle attack on DNS for both, DNSSEC secured and DNSSEC unsecured domain names. But then which DNS servers are really considered trusted by user? Most users do not wish to trust any third-parties if not unavoidable.
- C) Using authenticated DNS (performing local DNSSEC validation) without encryption in iterative mode using any supported DNS servers. Which DNS servers support that? In iterative mode, can DNS servers just lie and pretend "no DNSSEC available that domain name?"
- D) Using authenticated DNS (performing local DNSSEC validation) without encryption in recursive mode without needing to trust any DNS server. In that case, the user has much higher certainty  that any DNSSEC secured domains will be properly resolved. Any malicious modifications by a man-in-the-middle attack on DNSSEC secured DNS replies would be detected. However, DNSSEC unsecured domains would still be vulnerable to man-in-the-middle attacks. Perhaps even more vulnerable since a recursive DNS resolver makes much more requests to much more targets on the internet. It depends on where the user would consider man-in-the-middle attack to be most likely. From their computer to their ISP or anyone in between or rather anyone outside their ISP network.
For all options equally applies that a man-in-the-middle attacker could attempt a denial of service of all of the user's DNS requests. This would likely lead to the user believing that their DNS configuration is broken and perhaps to downgrade to insecure options such as going back to their ISP's DNS server. It might be possible to reduce this risk by tunneling all DNS traffic over Tor.
This is a list of things the user should know before and after considering to modify the system default DNS resolution. Sorted in order of likelihood. Most likely obstacles are on top of the list.
- Websites based tests might be dysfunctional, show false-positives.
- A browser extension such as noscript breaking website based tests.
- Issues introduced though use of a tunnel-link such as a VPN.
- Some domains can be resolved while others fail.
- VirtualBox users:
VBoxManage modifyvm "$VMNAME" --natdnsproxy1 onbreaks DNS.
- The user's computer has a local IPv6 but no actual IPv6 connectivity which might confuse DNS resolvers such as
- The web browser might have a bug that disables DNSSEC.
Many applications do actually not use system DNS but their own internal DNS implementation.
- The web browser might not use system DNS but use its own DNS.
- Firefox in USA comes with its own DoH enabled by default. 
- Tor Browser does not use system DNS but uses Tor to resolve DNS.
- Other web browsers not listed here might use similar implementations.
- Check browser settings or use search engines on how to view/change these settings.
- Android has private DNS.
- Other applications (non-browser) might use similar implementations.
In other words, changing system DNS settings according to this wiki page might not result in changes how the web browser resolves DNS. For example, Firefox in USA would still use its internal DoT default setting, unless modified by the user to use system DNS.
To test if the browser (or any other application) uses system DNS or its own internal DNS implementation, the user could temporarily disable their system DNS resolution.
To disable system DNS resolution...
1. Edit the
/etc/resolv.conf system wide DNS configuration file
2. Disable all settings by adding a hash (
#) in front of it.
The process of disabling system DNS has been completed.
Unbound (unbound security audit) (in Debian) is a is a validating, recursive, and caching DNS resolver with DoT and DoH support. In context of censorship circumvention, routing DoT over Tor is possible and fast enough according to the DoHoT: making practical use of DNS over HTTPS over Tor.
1. Choose an option.
recursive, unencrypted, validating, caching
No extra steps required for this options.
iterative, encrypted (DoT), validating, caching
1. Create folder
sudo mkdir --parents /etc/unbound/unbound.conf.d
2. Open file
/etc/unbound/unbound.conf.d/50_user.conf in an editor with root rights.
Kicksecure™ for Qubes
NOTE: When using Kicksecure-Qubes, this needs to be done inside the Template.
Others and Alternatives
- This is just an example. Other tools could achieve the same goal.
- If this example does not work for you or if you are not using Kicksecure, please refer to this link.
3. Paste the following lines. 
Note: The user is free to add, remove, modify the servers at the bottom of the following configuration snippet.
server: #verbosity: 5 hide-identity: yes hide-version: yes interface: 127.0.0.1@53 interface: ::1@53 port: 53 do-ip4: yes do-ip6: no do-udp: no do-tcp: yes tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt" forward-zone: name: "." forward-tls-upstream: yes # Freifunk München forward-addr: 188.8.131.52@853#dot.ffmuc.net # Digitalcourage e.V. forward-addr: 184.108.40.206@853#dns2.digitalcourage.de # Digitale Gesellschaft (CH) DNS Server forward-addr: 220.127.116.11@853#dns.digitale-gesellschaft.ch forward-addr: 18.104.22.168@853#dns.digitale-gesellschaft.chforward-zone: # Cloudflare forward-addr: 22.214.171.124@853#cloudflare-dns.com forward-addr: 126.96.36.199@853#cloudflare-dns.com
dnssec-trigger. To accomplish that, the following steps A. to D. need to be done.
A. Update the package lists.
sudo apt update
B. Upgrade the system.
sudo apt full-upgrade
C. Install the
sudo apt install --no-install-recommends dnssec-trigger
The procedure of installing
dnssec-trigger is complete.
The process is complete.
1. Learn how to interpret the results.
See the following A) vs B).
A) Something similar to the following would be showed if the system resolver does not have DNSSEC support.
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> +multiline . DNSKEY ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 42982 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: EDNS query returned status NOTIMP - retry with '+noedns' ;; QUESTION SECTION: ;. IN DNSKEY ;; Query time: 0 msec ;; SERVER: 10.139.1.1#53(10.139.1.1) ;; WHEN: Wed Jul 17 17:41:33 UTC 2019 ;; MSG SIZE rcvd: 17
B) Something similar to the following would be showed if the system resolver has DNSSEC support.
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> +multiline . DNSKEY ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63055 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1252 ;; QUESTION SECTION: ;. IN DNSKEY ;; ANSWER SECTION: . 8461 IN DNSKEY 256 3 8 ( AwEAAcTQyaIe6nt3xSPOG2L/YfwBkOVTJN6mlnZ249O5 Rtt3ZSRQHxQSW61AODYw6bvgxrrGq8eeOuenFjcSYgNA McBYoEYYmKDW6e9EryW4ZaT/MCq+8Am06oR40xAA3fCl OM6QjRcT85tP41Go946AicBGP8XOP/Aj1aI/oPRGzRnb oUPUok/AzTNnW5npBU69+BuiIwYE7mQOiNBFePyvjQBd oiuYbmuD3Py0IyjlBxzZUXbqLsRL9gYFkCqeTY29Ik7u suzMTa+JRSLz6KGS5RSJ7CTSMjZg8aNaUbN2dvGhakJP h92HnLvMA3TefFgbKJphFNPA3BWSKLZ02cRWXqM= ) ; ZSK; alg = RSASHA256 ; key id = 59944 . 8461 IN DNSKEY 257 3 8 ( AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN 7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5 LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8 efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7 pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws 9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ) ; KSK; alg = RSASHA256 ; key id = 20326 ;; Query time: 0 msec ;; SERVER: 127.0.2.1#53(127.0.2.1) ;; WHEN: Wed Jul 17 17:43:09 UTC 2019 ;; MSG SIZE rcvd: 578
2. Run the following command.
dig +multiline . DNSKEY
3. Internet the result.
DNSSEC DNSKEY test has been completed.
dig +dnssec Test
Test with dig.
dig +dnssec nic.cz @localhost
Please refer to upstream documentation on how to interpret the DNSSEC test results.
- ZdNet: DNS-over-HTTPS causes more problems than it solves, experts say
- Ignoring potential exploitation of the DNS resolver software.)