DNS_Security.mw

{{Header}}
{{#seo:
|description=Authenticated/Encrypted DNS, DNSSEC (over clearnet or Tor)
|image=Connect-20333640.jpg
}}
[[File:Connect-20333640.jpg|thumb]]
{{intro|
Authenticated/Encrypted DNS, DNSSEC (over clearnet or Tor)
}}
{{stub}}
{{Testers-only}}

= Introduction =
TODO: brief introduction what DNS is, current status of widespread insecure DNS

= DNS Resolver Features =
* Recursive: <blockquote>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.</blockquote> <ref>
https://wiki.archlinux.org/title/unbound
</ref>
** Opposite of recursive, is iterative: <blockquote>an iterative DNS query, where the client communicates directly with each DNS server involved in the lookup.</blockquote> <ref>
https://www.cloudflare.com/learning/dns/what-is-recursive-dns/
</ref>
* Authentication:
** DNSSEC: <blockquote>The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.</blockquote>
** Validating: perform DNSSEC authentication, end-to-end verification of DNSSEC.
*** Opposite of validating is non-validating.
* encryption:
** <u>D</u>NS <u>o</u>ver <u>T</u>LS (DoT): Encrypted DNS. (Port <code>853</code>).
** <u>D</u>NS <u>o</u>ver <u>H</u>TTPS (DoH): Encrypted DNS, similar to above but provides better censorship circumvention in theory as it uses the commonly used web https port <code>443</code>.
** Opposite of encryption is unencrypted.
* caching: <blockquote>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.</blockquote> <ref>
https://www.digitalocean.com/community/tutorials/a-comparison-of-dns-server-types-how-to-choose-the-right-dns-configuration
</ref>
** Opposite of caching is non-caching.

= DNS Encryption =
DNS encryption does not imply DNS authentication.

== root name servers ==
[https://en.wikipedia.org/wiki/Root_name_server Root name servers] [https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf do not support encryption yet].

== DoT vs DoH ==
Quote https://blog.apnic.net/2020/12/14/dns-over-https-in-unbound/

<blockquote>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.</blockquote>

There was some bad press about DoH. <ref>
[https://www.zdnet.com/article/dns-over-https-causes-more-problems-than-it-solves-experts-say/ ZdNet: DNS-over-HTTPS causes more problems than it solves, experts say]
</ref> There are some stakeholders who find DoH troublesome (oppressive governments, censors, corporate network administrators) however see [https://github.com/alecmuffett/dohot#why-dohot this rebuttal] by the [https://github.com/alecmuffett/dohot 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. <ref>
https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_are-you-rolling-this-default-out-in-europe
</ref> 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 [https://github.com/curl/curl/wiki/DNS-over-HTTPS DNS over HTTPS (DoH) server list].

= DNS Authentication =
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. <ref>
* https://wiki.debian.org/DNSSEC
* https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj200221(v=ws.11)
* https://security.stackexchange.com/questions/93879/non-validating-dnssec-aware-client-security-implications
</ref>

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.

https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_do-you-validate-dnssec

= 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".
* Authentication:
** 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.

* TODO:
** anon-dns
** onion

= DNS Security Optimization Problem =
At the moment it is impossible to get all features from the [[#DNS Resolving Security Feature Wishlist|DNS Resolving Security Feature Wishlist]] at the same time.

Since [https://en.wikipedia.org/wiki/Root_name_server root name servers] are required for recursive DNS resolution but [https://root-servers.org/media/news/Statement_on_DNS_Encryption.pdf do not support encryption yet], it is at time of writing impossible to have both, recursive and encrypted DNS resolution.

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.

* [https://github.com/DNSCrypt/dnscrypt-proxy <code>dnscrypt-proxy</code>] is DNSSEC aware but [https://github.com/DNSCrypt/dnscrypt-proxy/discussions/1954 dnscrypt-proxy at time of writing is DNSSEC non-validating]. <ref>
https://github.com/DNSCrypt/dnscrypt-proxy/issues/167#issuecomment-367689381
</ref>
* [https://github.com/cloudflare/cloudflared <code>cloudflare<u>d</u></code>] is [https://github.com/cloudflare/cloudflared/issues/520 DNSSEC non-validating]? <ref>
https://community.cloudflare.com/t/does-the-cloudflared-dns-client-locally-verify-dnssec/335402
</ref>
* [https://github.com/systemd/systemd <code>systemd-resolved</code>]: Has at time of writing an non-acknolwedged bug report [https://github.com/systemd/systemd/issues/25676 resolved DNSSEC validation can be bypassed by MITM] and a feature request [https://github.com/systemd/systemd/issues/28086 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 <code>dnscrypt-proxy</code> or <code>cloudflare<u>d</u></code>, 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 <ref>
Ignoring potential exploitation of the DNS resolver software.)
</ref> 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.

= Potential Obstacles =
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: <code>VBoxManage modifyvm "$VMNAME" --natdnsproxy1 on</code> breaks DNS.
* The user's computer has a local IPv6 but no actual IPv6 connectivity which might confuse DNS resolvers such as <code>unbound</code>.
* 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. <ref>
https://www.zdnet.com/article/mozilla-enables-doh-by-default-for-all-firefox-users-in-the-us/
</ref>
** 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.

{{box|text=
To disable system DNS resolution...

'''1.''' Edit the <code>/etc/resolv.conf</code> system wide DNS configuration file

{{CodeSelect|code=
sudoedit /etc/resolv.conf
}}

'''2.''' Disable all settings by adding a hash (<code>#</code>) in front of it.

'''3.''' Done.

The process of disabling system DNS has been completed.
}}

= Unbound =
<code>Unbound</code> ([https://ostif.org/our-audit-of-unbound-dns-by-x41-d-sec-full-results/ unbound security audit]) ([https://packages.debian.org/unbound 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 [https://github.com/alecmuffett/dohot DoHoT: making practical use of DNS over HTTPS over Tor].

'''1.''' Choose an option.
{{Tab
|type=controller
|content=
{{Tab
|addToClass=info-box
|active=true
|title= == recursive, unencrypted, validating, caching ==
|content=
No extra steps required for this options.
}} <!-- close tab : recursive -->
{{Tab
|addToClass=info-box
|title= == iterative, encrypted (DoT), validating, caching ==
|content=
'''1.''' Create folder <code>/etc/unbound/unbound.conf.d</code>.

{{CodeSelect|code=
sudo mkdir --parents /etc/unbound/unbound.conf.d
}}

'''2.''' {{Open with root rights|filename=
/etc/unbound/unbound.conf.d/50_user.conf
}}

'''3.''' Paste the following lines. <ref>
https://www.privacy-handbuch.de/handbuch_93c.htm
</ref>

<u>Note:</u> The user is free to add, remove, modify the servers at the bottom of the following configuration snippet.

{{CodeSelect|code=
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: 195.30.94.28@853#dot.ffmuc.net

   # Digitalcourage e.V.
   forward-addr: 46.182.19.48@853#dns2.digitalcourage.de

   # Digitale Gesellschaft (CH) DNS Server
   forward-addr: 185.95.218.42@853#dns.digitale-gesellschaft.ch
   forward-addr: 185.95.218.43@853#dns.digitale-gesellschaft.chforward-zone:

   # Cloudflare
   forward-addr: 1.1.1.1@853#cloudflare-dns.com
   forward-addr: 1.0.0.1@853#cloudflare-dns.com
}}

'''4.''' Save.
}} <!-- close tab : iterative -->
}} <!-- End Tab Controller -->

'''2.''' Install <code>dnssec-trigger</code>. <ref>
https://nlnetlabs.nl/projects/unbound/about/
</ref>

{{Install Package|package=
dnssec-trigger
}}

'''3.''' Done.

The process is complete.

= Testing DNSSEC =
== Browser Tests ==
* https://wander.science/projects/dns/dnssec-resolver-test/
* https://www.cloudflare.com/ssl/encrypted-sni/

== DNSKEY Test ==
'''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 <u>not</u> have DNSSEC support.

<pre>
; <<>> 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
</pre>

'''B)''' Something similar to the following would be showed if the system resolver <u>has</u> DNSSEC support.

<pre>
; <<>> 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
</pre>

'''2.''' Run the following command.

{{CodeSelect|code=
dig +multiline . DNSKEY
}}

'''3.''' Internet the result.

'''4.''' Done.

DNSSEC DNSKEY test has been completed.

== dig +dnssec Test ==
Test with dig.

{{CodeSelect|code=
dig +dnssec nic.cz @localhost
}}

Please refer to upstream documentation on how to interpret the DNSSEC test results.

= DoHoT =

https://github.com/alecmuffett/dohot/issues/4

= References =
* TCP - https://ns1.com/blog/dns-over-tcp-as-seen-from-the-authoritative-server

= Footnotes =
{{reflist|close=1}}

{{Footer}}

[[Category:Documentation]]