To start there are a few measures that can be distinguished at this point:
1. DNSSEC
2. Encrypted DNS queries (DNS over TLS or HTTPS)
3. QNAME minimisation
4. TCP Fast Open (TFO)
5. DNS block lists (breaks DNSSEC?)
Both measures have different impacts and require different actions to configure (or reconfigure for that matter).
DNSSEC
This encompasses the validation of zone certificates against their respective parent zones. Cloudflare has quite an elaborate explanation on how it works. But in short it should prevent different DNS attack types like cache poisoning, they have another page explaining the threats.
By default DNSSEC is enabled in IPFire, however IPFire does not return validated responses itself.
Disabling DNSSEC
It's possible to tamper with the DNSSEC settings according to the thread "Is it possible to disable DNSSEC?".
Testing
How to test whether or not DNSSEC is actually working on a client:
https://dnssec.vs.uni-due.de or http://en.conn.internet.nl/connection/
On the IPFire appliance you can test this with dig:
Code: Select all
[xxx@ipfire ~]# dig pir.org +dnssec +multi
; <<>> DiG 9.11.5 <<>> pir.org +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33426
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;pir.org. IN A
;; ANSWER SECTION:
pir.org. 299 IN A 97.107.141.235
pir.org. 299 IN RRSIG A 5 2 300 (
20190121084003 20190107084003 38661 pir.org.
NXxtWGKf/O4wmRohqw1Qi3TIhaVG0CB3WZ0m43KLYe0h
/WfVuj23iK+e82So6+9XwaPmCL5U9oHH9Nub7yseNkk6
jhVXrgCwRSL6zXfCFyTImVHcCQ3pI3dxr1NXZzYj2vVX
foSDS15RRchNCDBbhfGfXyPZgXdRK4YBqL83vpM= )
;; Query time: 66 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 07 13:54:42 CET 2019
;; MSG SIZE rcvd: 219
Code: Select all
[xxx@ipfire ~]# dig +dnssec www.dnssec-failed.org
; <<>> DiG 9.11.5 <<>> +dnssec www.dnssec-failed.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2916
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.dnssec-failed.org. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 07 13:55:18 CET 2019
;; MSG SIZE rcvd: 50
Concerns addressed: security
Encrypted DNS (DNS over TLS = DoT or DNS over HTTPS = DoH)
This encompasses encrypting the queries, effectively hiding them (in the case of DoT) in plain sight. I was unable to find consensus on whether one or the other is better, they both encrypt the requests, which should mean a MITM (man-in-the-middle) attack is harder to execute, since there's end-to-end encryption. The DNS server can still log the requests, which means privacy is still not effectively safe guarded, but in the end we're all at the mercy of the DNS servers and their promises not to log our activity.

Whichever you choose is up to you, DoH hides your DNS queries between other HTTPS traffic, whereas DoT is still recognizable as DNS traffic.
This topic has been discussed several times this year, the following threads were easily identifiable for covering this:
- 09-11-2018 Verständnisfrage zu DNS/Unbound
- 03-10-2018 petition: support for dns-over-tls
- 23-07-2018 config unbound forward.conf
- 06-04-2018 dns servers: local recursor update
- 03-04-2018 Secure DNS-over-TLS alongside unbound?
- 03-04-2018 DNS Cloudflare : 1.1.1.1
Plus there is a mail conversation.
Again Cloudflare has taken care of an explanation, this saves me a lot of time/typing.
Configuration
This is not automatically configured and requires some know-how to setup, there is a wiki page to support users, but option 1, the most preferable does not work anymore. Plus you still would need to configure unbound to act as such.
So - correct me if I'm wrong - you need to configure following, assuming you want IPFire to act as the DNS server:
- Configure unbound to not use forwarders and save this setting in the (probably) non-exitent file /etc/sysconfig/unbound.
Code: Select all
echo "USE_FORWARDERS=0" > /etc/sysconfig/unbound
- Combine the certificates for unbound The cert-bundle is already available in /etc/ssl/certs/ca-bundle.crt [update]
Code: Select all
cat /etc/ssl/certs/* > /{DIRECTORY CONTAINING CERT BUNDLE}/{BUNDLE FILE}
- Configure unbound to connect to a DoT/DoH forward DNS server (configure tls as enabled and list the servers you want) for the root zone (dot) = every request. You can configure any number of servers. The setting forward-tls-upstream en- or disables whether queries to the forward servers use TLS or not, this is not a setting to control TLS queries from the client to IPFire, plus you need to configure the tls-cert-bundle:
tls-upstream: <yes or no>
Enabled or disable whether the queries to this forwarder use TLS for transport. Default is no. If you enable this, also configure a tls-cert-bundle or use tls-win-cert to load CA certs, otherwise the connections cannot be authenticated.
unbound documentationtls-cert-bundle: <file>
If null or "", no file is used. Set it to the certificate bundle file, for example "/etc/pki/tls/certs/ca-bundle.crt". These certificates are used for authenticating connections made to outside peers. For example auth-zone urls, and also DNS over TLS connections.
Exempli gratia:Note: the syntax is forward-addr: <IP-address>[@port][#tls-authentication-name]Code: Select all
server: tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt forward-zone: name: "." forward-addr: 1.1.1.1@853 # Cloudflare forward-addr: 9.9.9.9@853 # Quad9 forward-tls-upstream: yes
You can find some sever info here. - Use a patched init script (see attachment) and overwrite /etc/init.d/unbound
Note: use this script at your own risk, it's advised to use it only in development/acceptance environments.[update] - Restart unbound
Code: Select all
/etc/init.d/unbound restart
- Configure the clients to actually use the IPFire appliance as their DNS server. You can do this by setting the DNS server to the IPFire instance in the green network section of the DHCP page on the WUI.
If you are running a domain, you probably have set the DNS/DC as first DNS server... I'm not sure what you should do then. Maybe configure the DNS/DC to query IPFire instead of the ISP? See question "d". - Block all other DNS traffic, as outlined on the wiki page.
This is a little bit more difficult to check, as you need to investigate the traffic, you can use the following packages (available in Pakfire):
- tcpick - discontinued for ARM, I couldn't find it
Code: Select all
tcpick -i red0 -C "port 853"
- tcpdump
Code: Select all
tcpdump -vvv -i red0 dst port 853
- unbound-control; you can check whether or not the forward servers are loaded
Or dump the cache
Code: Select all
unbound-control list_forwards
Code: Select all
unbound-control dump_cache
- The WUI shows local recursor and I'm unable to browse the internet. Try updating the forwarders, it might be that the responses are dropped:
Code: Select all
/etc/init.d/unbound update-forwarders
You can also check whether or not the root key matches the one shared by ICANN (root-anchors.xml) by calling
Code: Select all
unbound-anchor -l
Code: Select all
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
. IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D
Concerns addressed: privacy, security
QNAME minimisation
In other words, minimise the information sent upstream to the bear minimum, this will not yield better result in the form of quicker responses per se, but it will avoid sharing unnecessary information to third parties.The idea is to minimise the amount of data sent from the DNS resolver to the authoritative name server. In the example in the previous section, sending "What are the NS records for .com?" would have been sufficient (since it will be the answer from the root anyway). The rest of this section describes the recommended way to do QNAME minimisation -- the way that maximises privacy benefits (other alternatives are discussed in the appendices).
Instead of sending the full QNAME and the original QTYPE upstream, a resolver that implements QNAME minimisation and does not already have the answer in its cache sends a request to the name server authoritative for the closest known ancestor of the original QNAME. The request is done with:
o the QTYPE NS
o the QNAME that is the original QNAME, stripped to just one label
more than the zone for which the server is authoritative
For example, a resolver receives a request to resolve foo.bar.baz.example. Let's assume that it already knows that ns1.nic.example is authoritative for .example and the resolver does not know a more specific authoritative name server. It will send the query QTYPE=NS,QNAME=baz.example to ns1.nic.example.
A slide show which further explains can be found here.
Configuration
This should be fairly easy, there are a few options to control the behaviour, as described on the unbound settings page. This requires unbound version 1.5.7 or higher.
You obviously need to restart and stop/start unbound afterwards to load the new settings.qname-minimisation: <yes or no>
Send minimum amount of information to upstream servers to
enhance privacy. Only sent minimum required labels of the QNAME
and set QTYPE to A when possible. Best effort approach; full
QNAME and original QTYPE will be sent when upstream replies with
a RCODE other than NOERROR, except when receiving NXDOMAIN from
a DNSSEC signed zone. Default is yes.
qname-minimisation-strict: <yes or no>
QNAME minimisation in strict mode. Do not fall-back to sending
full QNAME to potentially broken nameservers. A lot of domains
will not be resolvable when this option in enabled. Only use if
you know what you are doing. This option only has effect when
qname-minimisation is enabled. Default is off.
Note: the below setting is optional!
harden-below-nxdomain: <yes or no>
From RFC 8020 (with title "NXDOMAIN: There Really Is Nothing
Underneath"), returns nxdomain to queries for a name below
another name that is already known to be nxdomain. DNSSEC man-
dates noerror for empty nonterminals, hence this is possible.
Very old software might return nxdomain for empty nonterminals
(that usually happen for reverse IP address lookups), and thus
may be incompatible with this. To try to avoid this only
DNSSEC-secure nxdomains are used, because the old software does
not have DNSSEC. Default is on. The nxdomain must be secure,
this means nsec3 with optout is insufficient.
Code: Select all
/etc/init.d/unbound restart
unbound-control stop
unbound-control start
QNAME minimisation is easily tested using dig, querying the txt section of the qnamemintest.internet.nl domain on the IPFire appliance itself.
When it's not enabled it will return:
Code: Select all
[xxx@ipfire ~]# dig txt qnamemintest.internet.nl +short
a.b.qnamemin-test.internet.nl.
"NO - QNAME minimisation is NOT enabled on your resolver :("
Code: Select all
[xxx@ipfire ~]# dig txt qnamemintest.internet.nl +short
a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
TCP Fast Open (TFO)
See RFC here: https://tools.ietf.org/html/rfc7413TCP Fast Open (TFO) is an experimental update to TCP that enables data to be exchanged safely during TCP's connection handshake. This document describes a design that enables applications to save a round trip while avoiding severe security ramifications. At the core of TFO is a security cookie used by the server side to authenticate a client initiating a TFO connection. This document covers the details of exchanging data during TCP's initial handshake, the protocol for TFO cookies, potential new security vulnerabilities and their mitigation, and the new socket API.
Configuration
This can't be configured on-the-fly at this point, it needs to be configured when the package is built using the following configuration parameters:
Code: Select all
--enable-tfo-client
--enable-tfo-server
DNS block lists
Whether it's ads or malicious sites you want to block, unbound provides for black- and whitelists to fully control your (DNS) traffic.
Configuration
Setup a block list, for example by using the script from sfeakes: https://github.com/sfeakes/ipfire-scripts
PS: I still need to test this and make sure I can actually document something...

Update: I've been informed that this will break DNSSEC functionality, so use at your own risk.
Concerns addressed: security, no ads
Questions
- Aimed at encrypted DNS point 1, is it correct to assume this file is used when unbound starts and is not there on vanilla installations?
Yes, this file does not exist on vanilla installation and can be used to override settings. - Also aimed at encrypted DNS point 1, why would you need to disable forwarders, that is exactly what the conf-file contains?
It will disable any setup/WUI configured forwarders, which will enable the ones in the settings file(s). - Aimed at encrypted DNS point 2, what good does it do to configure a whole lot of servers? I presume mostly just the top one (assuming they are recursive and will retrieve the entry when it's not there) will be used? Unless that one is not available, but that shouldn't happen too often, so more than two servers is possible, but will almost never be used.
Unbound will randomly select from those servers, meaning it will divide the queries amongst those servers, further improving privacy. - Aimed at encrypted DNS; when running a domain I just need to point my domain controller to the IPFire appliance, as opposed to my IPS's, right?
- Is this the correct command to create the tls-cert-bundle? -> cat /etc/ssl/certs/* > /etc/unbound/ca-bundle.pem
See inline updates, the cert bundle was already there. - What do the DNS settings in "setup\Network configuration\DNS and Gateway settings" mean? Will they be overwritten by the unbound config? Or are those for the IPFire instance itself, even though it might as well use the unbound server too?
Thanks for all the responses (from which I will learn) in advance!