Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Networking - DNS - Unbound - Configure Encrypted DNS with Caching ======

To prevent recording and tracking of your DNS requests.

Benefits of this setup are:

  * The connection is encrypted so responses cannot be observed or modified.
  * DNSSEC is used to assure that the responses are correct. 
  * Results are cached by Unbound to improve the responsiveness of your network activity.

----

===== Configure Unbound =====

<file bash /etc/unbound/unbound.conf>
server:
    # Provide unencrypted DNS services on port 53.
    interface: 127.0.0.1@53
    interface: ::1@53
    port: 53

    # Provide TLS protected dns services on port 853.
    # **NOTE:  This is generally not needed for local use.
    tls-service-key: "/etc/pki/tls/private/privkey.pem"
    tls-service-pem: "/etc/pki/tls/certs/fullchain.pem"
    interface: 127.0.0.1@853
    interface: ::1@853
    tls-port: 853

    # Support both IPv6 and TCP.
    do-ip4: yes
    do-ip6: yes
    do-udp: yes
    do-tcp: yes

    # Only allow access from localhost.
    access-control: 0.0.0.0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: ::0/0 refuse
    access-control: ::1 allow

    # Enable DNSSEC.
    auto-trust-anchor-file: "/var/lib/unbound/root.key"

    # Certificate authorities needed to authenticate upstream servers.
    tls-cert-bundle: "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem"

forward-zone:
    name: "."
    forward-tls-upstream: yes

    # Cloudflare DNS.
    forward-addr: 2606:4700:4700::1111@853#cloudflare-dns.com
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 2606:4700:4700::1001@853#cloudflare-dns.com
    forward-addr: 1.0.0.1@853#cloudflare-dns.com

    # NordVPN.
    forward-addr: 103.86.96.100@853#dns1.nordvpn.com
    forward-addr: 103.86.99.100@853#dns2.nordvpn.com

    # Quad9.
    forward-addr: 2620:fe::fe@853#dns.quad9.net
    forward-addr: 9.9.9.9@853#dns.quad9.net
    forward-addr: 2620:fe::9@853#dns.quad9.net
    forward-addr: 149.112.112.112@853#dns.quad9.net
</file>


<WRAP info>
**NOTE:**  To generate the trust-anchor file for DNSSEC you need to run unbound-anchor or you can get it from https://www.internic.net/domain/named.cache.

The **“.”** passed to name in forward-zone matches **all** names and so specifies that all requests should be sent to the configured resolvers.  You can have multiple forward-zone sections, but then each should have different names.

The companies that provide the configured servers (Cloudflare, NordVPN, and Cloud9) all claim to be privacy oriented and so do not normally log your IP address.

Unbound distributes its requests evenly to all configured servers, so the more servers that are configured the fewer of your requests any one actually sees, making it more difficult to for them to get a complete picture of your activities even if they tried.

----

The **forward-addr** have following syntax:

  * The first part, before the @, is the IP address.
  * The middle part, between @ and #, is the port.
  * The trailing part, after the #, is the hostname.  The host name should match the certificate being used by the server. This last part is optional, but not providing it allows you to connect to another DNS server as long as it has a valid certificate, which allows man-in-the-middle attacks.

</WRAP>

----

===== Handle Unresolved Responses =====

In the above configuration, Unbound would not resolve the name if none of the configured resolvers responded; and if the name was not in the cache.

To get Unbound to try to resolve the name itself in this case, you can add:

<file bash /etc/unbound/unbound.conf>
....
forward-zone:
    forward-first: yes
</file>

<WRAP important>
**WARNING:**  Be aware that in this case the servers you contact might not be as privacy oriented as the configured servers.
</WRAP>

----

===== Serve Names to Peers =====

This configuration is designed to only serve names locally.

If you want to want to serve names to peers, you would need to open the desired ports (53 and perhaps 853) in your firewall and change access-control as follows:

<file bash /etc/unbound/unbound.conf>
...
# Only allow access from localhost.
access-control: 0.0.0.0/0 allow
access-control: 127.0.0.0/8 allow
access-control: ::0/0 allow
access-control: ::1 allow
</file>

----

===== Test that TLS is Working =====

<code bash>
openssl s_client -connect localhost:853
</code>

You can find the name suitable for an upstream server using:

<code bash>
openssl s_client -connect 1.1.1.1:853
</code>

The host name you append to your **forward-addr** should match that given as the CN name reported by openssl.

----

===== Workaround Man-In-The-Middle =====

A corporate firewall that inserts itself as a man-in-the-middle in all connections may cause this setup to fail.

If your TLS CA bundle does not have the corporate certificates, Unbound refuses to connect to the external resolvers in this case.

This situation prevents you from resolving any names. In addition, in some extreme cases, corporate firewalls block access to the DNS ports completely.

==== Resolution ====

To work around this issue, access to a trusted resolver is provided using an SSH tunnel; assuming that SSH can be used, and the IP address of the secure server is known so that setting up the tunnel is not dependent on the resolver.

If TLS is not required:

<file bash /etc/unbound/unbound.conf>
...
server:
    tcp-upstream: yes
    do-not-query-localhost: no

forward-zone:
    forward-tls-upstream: no
    forward-addr: 127.0.0.1@11053
...
</file>

<WRAP info>
**NOTE:**  Here an SSH tunnel exists from localhost@11053 to the remote secure server’s port 53.
</WRAP>


If TLS will be used for all upstream resolvers:

<file bash /etc/unbound/unbound.conf>
server:
    do-not-query-localhost: no

forward-zone:
    forward-tls-upstream: yes
    forward-addr: 127.0.0.1@11853#server-name.tld
</file>

<WRAP info>
**NOTE:**  If TLS is required for any resolver in a **forward-zone**, it is required for all resolvers.

TLS must be properly configured for the secure remote resolver being accessed through the SSH tunnel and your local certificate authority bundle must include the certificate of the authority that issued your TLS certificate. 


This example uses:

  * server-name.tld is a name compatible with the certificate.  Use openssl to determine CN.
  * An SSH tunnel exists from localhost@11853 to the remote secure server’s port 853.
</WRAP>