Content Filtering + (DoH) for OpenVPN Clients via BIND-DNSCrypt

We would like to express our deep sadness and sincere condolences to the families who lost their loved ones in the terrible 7.9 earthquake that struck Türkiye

1. BIND as a authoritative primary DNS server
2. DNSCrypt (dnscrypt-proxy) as a DNS proxy, traffic encryption protocol
3. CloudFlare (DoH) as a content filtered + DNS over HTTPS upstream DNS
4. OpenVPN as a secure connection protocol

In this tutorial, we won’t go over how to set up BIND, OpenVPN or DNSCrypt start from scratch, we assume that if you are reading here (expert subject DoH + content filtering) you have already technical knowledge to install these packages via package manager.

Here, BIND used as authoritative primary DNS server that listens to public IP for the zones it is responsible for.

Making our DNS traffic encrypted and content filtered we will use cloudflare-familyCloudflare DNS (anycast) with malware protection and parental control – aka 1.1.1.3  (DoH)DNS over HTTPS (DoH) is a relatively new protocol that encrypts domain name system traffic by passing DNS queries through a Hypertext Transfer Protocol Secure encrypted session. DoH seeks to improve online privacy by hiding DNS queries from view. via dnscrypt-proxy. So first we will integrate dnscrypt-proxyis a protocol that authenticates communications between a DNS client and a DNS resolver. It works by encrypting all DNS traffic between the user and resolver, preventing any spying, spoofing or man-in-the-middle attacks. It uses cryptographic signatures to verify that responses originate from the chosen DNS resolver and haven’t been tampered with and is DNSSEC compatible. It is an open specification, with free and open source reference implementations, and it is not affiliated with any company nor organization. Free DNSCrypt-enabled resolvers are available all over the world. with BIND.

Then we will look overall DNS system architecture, we have to deal with a few things such as systemd-resolved. It will make things complicated but don’t worry we will handle it.

Finally we will push our content filtered, (DoH) secured DNS to OpenVPN clients, will be testing the configuration and make sure it works.

Keep in mind that end of this tutorial we will able to watch our OpenVPN clients http traffic. So do you want to spy them? Let’s check the bash script at the end of the tutorial.

The project provides the DNSCrypt proxy as source code and pre-built binaries for most operating systems and architectures.

In default DNSCrypt listens on 127.0.0.1, here the issue that our authoritative DNS server already sits on 127.0.0.1. As mentioned before our BIND setup acts a recursive DNS server for our local. If you use default Unbound probably you need to make these changes anyway.

1. As you guess we will assign an other IP for DNSCrypt to listen.
2. DNSCrypt can cache DNS queries, depending your overall system setup you can enable or disable DNSCrypt caching. We prefer caching at proxy layer so we enabled it.
3. We will use cloudflare (DoH) specially here for testing our completed setup via cloudflare’s great service https://1.1.1.1/help
4. Enable logging so we can test our setup is working.

Open the configuration file and set the proxy to listen on 127.0.2.1:53 and modify other options as I recommend.

We speacially use cloudflare-family 1.1.1.3 here for DNS content filtering for OpenVPN clients. If you don’t want content filtering you can simple use cloudflare 1.1.1.1. After our test phase completed you can use any (DoH) public DNS server listed here to get better latency.

Here the DNSCrypt config file.

server_names = ['cloudflare-family', 'cloudflare-family-ipv6']
listen_addresses = ['127.0.2.1:53']
cache = true
[query_log]
file = '/var/log/dnscrypt-proxy/query.log'
ignored_qtypes = ['DNSKEY', 'NS']
format = 'tsv'

Depending on your configuration restart the service to take effect.

Here we have two task to complete for BIND/OpenVPN integration. But first we need to decide which traffic we will forward to DNSCrypt. Our whole DNS traffic or OpenVPN client DNS traffic?

If you forward all DNS traffic to DNSCrypt, the truth is DNSCrypt proxy will add a latency, not too bad but It can effect your local resolve operations. For better understand, think you have a very busy mail server on this setup and It queries many DNSBL’s, all these traffic will be forwarded to proxy. An other example can be nginx. If you use your primary DNS as a resolver for nginx all these traffic also will forwarded to proxy.

1. Decide you will forward all DNS traffic or just OpenVPN client traffic.
2. Forward primary DNS traffic to DNSCrypt forwarders { 127.0.2.1; };
3. Listen OpenVPN TUN/TAP interface IP listen-on { 127.0.0.1; x.x.x.x; 10.8.0.1; };
4. Enable BIND logging channels for testing purpose

First tell BIND to forward to DNSCrypt, edit the named.confConfig file location depends to your linux distro in general you can find BIND config file at /etc/bind/named.conf.options file and forward the traffic to 127.0.2.1 where our dnscrypt-proxy is listening: (we set it DNSCrypt Setup part if you missed)

If you decided to forward only OpenVPN client traffic to proxy we will use BIND view to seperate traffic. You can find details in config file comments.

Tell BIND to listen our OpenVPN TUN/TAP interface IP 10.8.0.1. This is the key/trickiest part of this tutorial that necessary for OpenVPN integration. You can find your TUN/TAP interface IP via ifconfig or directly from OpenVPN server.conf file. It depends how you configured your OpenVPN server.

Here is the necessary BIND config changes if you decide to forward all DNS traffic.

// We defined OpenVPN clients IP range here
acl "vpn" {
  10.8.0.0/24;
};

// TUN/TAP interface IP 10.8.0.0/24 is also 
// trusted via 'localnets'.
// If you remove 'localnets' you need to
// enable recursion for ACL 'vpn' in options.
acl "trusted" {
  localhost;
  localnets;
};

options {
  // Here we added our TUN/TAP OpenVPN interface IP '10.8.0.1'
  // So BIND will listen this address.
  // We will push '10.8.0.1' to OpenVPN clients via OpenVPN server
  // x.x.x.x is our Public IP
  listen-on { 127.0.0.1; x.x.x.x; 10.8.0.1; };

  // BIND acts as a authoritative name server
  // It will answer all queries for zones it is responsible for
  allow-query {
    any;
  };

  // BIND is recursive for only our local
  // If you set 'any' you will be open resolver!
  allow-recursion {
    trusted;
    // If you removed 'localnets' from ACL 'trusted'
    // uncomment 'vpn' here. Even we forward query still we need recursion.
    // vpn;
  };

  // Zone transfer is disabled
  allow-update {
    none;
  };

  // dynamic updates for master zones is disabled
  allow-update {
    none;
  };

  // Here we forward all DNS traffic to dnscrypt-proxy
  // That means /etc/resolv.conf file is useless now.
  // BIND will acts a forwarder only.
  // You need to set upstream DNS via dnscrypt-proxy.toml 
  forwarders {
    // dnscrypt-proxy listens on
    127.0.2.1;
  };
  forward only;
};

// Enable queries logging channel
logging {
  channel queries_log {
    file "/var/log/named/queries.log" versions 1 size 20m;
    print-time yes;
    print-category yes;
    print-severity yes;
    severity info;
  };
  category queries { queries_log; };
};

Here is the necessary BIND config changes if you decide to forward only OpenVPN traffic. Key points highlighted. Global options depends your own configuration.

// We defined OpenVPN clients IP range for dnscrypt view
acl "vpn" {
  10.8.0.0/24;
};

// TUN/TAP interface IP 10.8.0.0/24 is also
// trusted via 'localnets'. 
// If you remove 'localnets' you need to
// enable recursion for ACL 'vpn' in view 'dnscrypt'
acl "trusted" {
  localhost;
  localnets;
};

// The global options defined here is applied to 
// all views. (if you don't ovverride 
// them in view segment manually)
options {
  // Here we added our TUN/TAP OpenVPN interface IP '10.8.0.1'
  // So BIND will listen this address.
  // We will push '10.8.0.1' to OpenVPN clients via OpenVPN server
  // x.x.x.x is our Public IP
  listen-on { 127.0.0.1; x.x.x.x; 10.8.0.1; };

  // BIND acts as a authoritative name server
  // It will answer all queries for zones it is responsible for 
  allow-query {
    any;
  };

  // BIND is recursive for only our local
  // If you set 'any' you will be open resolver!
  allow-recursion {
    trusted;
  };

  // Zone transfer is disabled
  allow-transfer {
    none;
  };

  // dynamic updates for master zones is disabled
  allow-update {
    none;
  };
};

// Enable queries logging channel
logging {
  channel queries_log {
    file "/var/log/named/queries.log" versions 1 size 20m;
    print-time yes;
    print-category yes;
    print-severity yes;
    severity info;
  };
  category queries { queries_log; };
};

// We are seperating OpenVPN client's queries
// and forwarding them to dnscrypt-proxy here
// This must be our first view !
view dnscrypt {
  match-clients { vpn; };
  // If you removed 'localnets' from ACL 'trusted'
  // uncomment 'allow-recursion' here.
  // Even we forward query still we need recursion.
  // allow-recursion { vpn; };
  forwarders {
    // dnscrypt-proxy listens on
    127.0.2.1;
   };
   forward only;
};

// All queries exluded OpenVPN clients
// will resolve by our primary DNS server recursively
// Move all your zones under to this view !
// This must be our second view !
view all {
  match-clients { any; };

  // example zones
  zone "." {
    type hint;
    file "/var/bind/named.cache";
  };

  zone "127.in-addr.arpa" {
    type master;
    file "/var/bind/db.127";
  };

  zone "255.in-addr.arpa" {
    type master;
    file "/var/bind/db.255";
  };
};

rndc reload

Now take a deep breath here! We need to check our in use DNS architecture. Till many linux distrubitions have been started to use systemd-resolved.service I assume your system is working behind systemd-resolved currently. In short this is an fronted resolver that take over and handle all resolve operations and forward it to upstream DNS. It has many capabilities like caching, DNSSEC validation, (DoT)DNS over TLS, or DoT, is a standard for encrypting DNS queries to keep them secure and private. DoT uses the same security protocol, TLS, that HTTPS websites use to encrypt and authenticate communications. (TLS is also known as “SSL.”) DoT adds TLS encryption on top of the user datagram protocol (UDP), which is used for DNS queries. Additionally, it ensures that DNS requests and responses are not tampered with or forged via on-path attacks. etc. Not deep diving here and let’s focusing the our setup.

nameserver 127.0.0.1
nameserver 1.1.1.1
nameserver 8.8.8.8

127.0.0.1 is the loopback IP address, meaning it always represents the local machine. So by changing your machine’s /etc/resolv.conf to only have that address, it tells processes/services (e.g. postfix,nginx etc.) on that machine to use the primary DNS server. In our setup this is BIND. This can be Unbound or dnsmasq too.

Long story short;

Follow the symlink for /etc/resolv.conf to understand your current DNS architecture first.

mail ~ # ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 32 Dec 9 2018 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf

If symlinked to resolv.conf applications will directly make DNS requests to the “real” (aka. upstream) DNS resolvers configured (/etc/systemd/resolved.confConfig file of systemd-resolved.service ) in systemd-resolved. In this case, systemd-resolved only acts as a “resolv.conf manager”, not as a DNS resolver itself that what we prefer in our setup !

mail ~ # ls -al /etc/resolv.conf
lrwxrwxrwx 1 root root 32 Dec 9 2018 /etc/resolv.conf -> /run/systemd/resolve/stub-resolv.conf

If symlinked to stub-resolv.conf, applications will make DNS requests to the DNS stub resolver provided by systemd on address 127.0.0.53. This stub resolver will proxy the DNS requests to the upstream DNS resolvers configured (/etc/systemd/resolved.confConfig file of systemd-resolved.service ) in systemd-resolved, applying whatever logic it wants to those requests and answers, like caching them that we don’t prefer in our setup.

Because that is crayz, proxying over and over. We have a DNSCrypt protocol as a DNS proxy already. There is no no need to add an extra layer/proxy/config here. systemd-resolvedsystemd-resolved is a systemd service that provides network name resolution to local applications via a D-Bus interface, the resolve NSS service, and a local DNS stub listener on 127.0.0.53
already needs really extra work to work well with DNSSEC configured BIND. For that setup you can consider the stop using systemd-resolved via disabling it.

systemctl stop systemd-resolved.service
systemctl disable systemd-resolved.service
systemctl mask systemd-resolved.service

If you choose staying behind the systemd-resolved at least be sure it is not in stub mode.

We are ready to push secured DNS to OpenVPN clients. push "dhcp-option DNS 10.8.0.1"

As mentioned before we won’t go over how to set up OpenVPN server start from scratch. Instead of that we are highlighting the key integration steps. If you want to spy your OpenVPN client’s http traffic we have an extra step. You need to assign static IP to them. That means you must create a new certificate for each client and set the ccd path in server.conf. You can find many tutorial how to assign static IP to OpenVPN clients.

client-config-dir /etc/openvpn/server/ccd/

Here is the full OpenVPN server config file. Key points highlighted. You don’t need to edit any OpenVPN client.ovpn files. We are pushing DNS to all clients via OpenVPN server.

port 1194
push "explicit-exit-notify 1"
proto udp4
dev tun0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-crypt tls-crypt.key
client-config-dir /etc/openvpn/server/ccd/
auth SHA256
auth-nocache
tls-ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
tls-cipher TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-RSA-WITH-CHAC HA20-POLY1305-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256:TLS-ECDHE-RSA-WITH- AES-128-GCM-SHA256
cipher AES-256-GCM
tls-version-min 1.2
remote-cert-tls client
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.8.0.1"
persist-key
persist-tun
keepalive 10 120
fast-io
reneg-sec 0
client-to-client
resolv-retry infinite
user nobody
group nobody
status /var/log/openvpn-status.log
log /var/log/openvpn.log
verb 4
explicit-exit-notify 1

Depending on your configuration restart the service to take effect.

If all went well we are ready to test our setup. Our testing methodology depends on log analysis and cloudflare service check.

1. Cloudflare service check https://1.1.1.1/help
2. DNSCrypt log analysis /var/log/dnscrypt-proxy/query.log
3. BIND log analysis /var/log/named/queries.log
4. tcpdump traffic analysis (deep dive)  tcpdump

Before starting the test, connect to OpenVPN server via your client.ovpn file.

Navigate the browser https://1.1.1.1/help and check the results. If you see “Using DNS over HTTPS (DoH)” “YES” then congrats. your setup is working. Also don’t forget to check adult content filtering is working.

Navigate the browser https://www.wikipedia.org/ and watch /var/log/dnscrypt-proxy/query.log. If you see cloudflare-family that means BIND succesfuly forwarded OpenVPN client’s DNS queries to upstream DNS (cloudflare) via DNSCrypt proxy. If you repeat this action you cannot see it in logs because DNSCrypto caches this query already and next time It is answering via cache.

tail -f /var/log/dnscrypt-proxy/query.log

[2023-02-17 01:01:06] 127.0.0.1 www.wikipedia.org A PASS 56ms cloudflare-family
[2023-02-17 01:01:06] 127.0.0.1 wikipedia.org DS PASS 18ms cloudflare-family
[2023-02-17 01:01:06] 127.0.0.1 dyna.wikimedia.org A PASS 19ms cloudflare-family
[2023-02-17 01:01:06] 127.0.0.1 wikimedia.org DS PASS 16ms cloudflare-family
[2023-02-17 01:01:06] 127.0.0.1 upload.wikimedia.org A PASS 37ms cloudflare-family
[2023-02-17 01:01:06] 127.0.0.1 tr.wikipedia.org A PASS 55ms cloudflare-family

As explained in BIND Setup phase If you decided to forward only OpenVPN traffic and configured BIND this way test your local DNS resolution via dig. You will able to see these queries in BIND queries.log but not in dnscrypt-proxy query.log.

Now navigate the browser https://en.wikipedia.org/wiki/2023_Turkey-Syria_earthquakeOn 6 February 2023, a Mw 7.8 earthquake struck southern and central Turkey, as well as northern and western Syria. It occurred 32.4 km (20.1 mi) west–northwest of Gaziantep at 04:17 am TRT (01:17 UTC), with a maximum Mercalli intensity of XI (Extreme). A Mw7.7 earthquake occurred nine hours later, centered 95 km (59 mi) to the north–northeast in Kahramanmaraş Province. There was widespread damage and tens of thousands of fatalities. and watch /var/log/named/queries.log.

tail -f /var/log/named/queries.log

17-Feb-2023 02:16:54.456 queries: info: client @0x7f93547f65e0 10.8.0.25#58096 (en.wikipedia.org): view dnscrypt: query: en.wikipedia.org IN A + (10.8.0.1)

Here 10.8.0.25 is our OpenVPN client static IP. BIND filtered source IP of queryacl “vpn” configured in named.conf via viewsview dnscrypt configured in named.conf and flagged it dnscrypt. 10.8.0.1 is our primary DNS IP that BIND listens for OpenVPN clients, also our OpenVPN TUN/TAP interface IP. A + means that is a recursive query. After that BIND will forward this query to 127.0.2.1 dnscrypt. Finally query will reach to our upstream DNS cloudflare 1.1.1.3 that we configured via dnscrypt-proxy.toml

As explained in BIND Setup phase If you decided to forward only OpenVPN traffic and configured BIND this way test your local DNS resolution via dig. You will able to see these queries in BIND queries.log but not in dnscrypt-proxy query.log. These queries flagged as view all instead of view dnscrypt. This means that all queries except OpenVPN clients are resolving recursively by the primary DNS server BIND.

Analyze BIND & DNSCrypt traffic bidirectionaly via tcpdump

First lets check the route of our local DNS queries. I forwarded all DNS traffic to DNSCrypt via BIND to make things clear crystal. As you can see the postfix mail server local DNSBL queries also forwarded to 127.0.2.1 DNSCrypt. This queries will follow the next route and reach to upstream DNS server cloudflare as we set before. As mentioned before, this setup cause of performance degratation so I did recommended forwarding only OpenVPN client DNS traffic.

tcpdump -nli lo host 127.0.2.1

05:41:58.506543 IP 127.0.0.1.38222 > 127.0.2.1.53: 9675+% [1au] A? 71.244.107.40.zen.spamhaus.org. (71)
05:41:58.506585 IP 127.0.0.1.2375 > 127.0.2.1.53: 28636+% [1au] A? 71.244.107.40.dnsbl-2.uceprotect.net. (77)
05:41:58.506588 IP 127.0.0.1.11970 > 127.0.2.1.53: 36958+% [1au] A? 71.244.107.40.all.spamrats.com. (71)
05:41:58.506618 IP 127.0.0.1.23052 > 127.0.2.1.53: 47304+% [1au] A? 71.244.107.40.bl.spameatingmonkey.net. (78)
05:41:58.506789 IP 127.0.0.1.39946 > 127.0.2.1.53: 9585+% [1au] A? 71.244.107.40.hostkarma.junkemailfilter.com. (84)
05:41:58.507411 IP 127.0.0.1.53923 > 127.0.2.1.53: 46127+% [1au] A? 71.244.107.40.dnsbl-1.uceprotect.net. (77)
05:41:58.507449 IP 127.0.0.1.39014 > 127.0.2.1.53: 30388+% [1au] A? 71.244.107.40.bl.mailspike.net. (71)
05:41:58.507460 IP 127.0.0.1.40200 > 127.0.2.1.53: 61618+% [1au] A? 71.244.107.40.iadb.isipp.com. (69)
05:41:58.507494 IP 127.0.0.1.12608 > 127.0.2.1.53: 15406+% [1au] A? 71.244.107.40.list.dnswl.org. (69)

Now check the OpenVPN client DNS resolution. Be sure you connected OpenVPN server via your client.ovpn and navigate the browser https://en.wikipedia.org/wiki/Mustafa_Kemal_Atatürk and analyze the traffic.

tcpdump -nli lo host 127.0.2.1

05:55:40.907308 IP 127.0.0.1.52381 > 127.0.2.1.53: 1250+% [1au] A? tr.wikipedia.org. (57)
05:55:40.932234 IP 127.0.2.1.53 > 127.0.0.1.52381: 1250 2/0/1 CNAME dyna.wikimedia.org., A 91.198.174.192 (90)
05:55:40.932586 IP 127.0.0.1.32391 > 127.0.2.1.53: 31803+% [1au] DS? wikipedia.org. (54)
05:55:40.939988 IP 127.0.2.1.53 > 127.0.0.1.32391: 31803| 0/0/1 (42)
05:55:40.941353 IP 127.0.0.1.37448 > 127.0.2.1.53: 14139+% [1au] A? dyna.wikimedia.org. (59)
05:55:40.956795 IP 127.0.2.1.53 > 127.0.0.1.37448: 14139 1/0/1 A 91.198.174.192 (63)
05:55:41.288592 IP 127.0.0.1.62897 > 127.0.2.1.53: 18056+% [1au] A? upload.wikimedia.org. (61)
05:55:41.302635 IP 127.0.0.1.23328 > 127.0.2.1.53: 7545+% [1au] A? login.wikimedia.org. (60)
05:55:41.304040 IP 127.0.2.1.53 > 127.0.0.1.62897: 18056 1/0/1 A 91.198.174.208 (65)
05:55:41.304145 IP 127.0.0.1.51319 > 127.0.2.1.53: 37887+% [1au] A? meta.wikimedia.org. (59)
05:55:41.310428 IP 127.0.2.1.53 > 127.0.0.1.23328: 7545 2/0/1 CNAME dyna.wikimedia.org., A 91.198.174.192 (83)
05:55:41.319564 IP 127.0.2.1.53 > 127.0.0.1.51319: 37887 2/0/1 CNAME dyna.wikimedia.org., A 91.198.174.192 (82)

Analyze final DNS traffic bidirectional via tcpdump

Here we will watch the final source & destination of DNS query (second route). The final source address of query is our server public IP and the final destination address is cloudflare 1.0.0.1 port 443.

tcpdump -nli eth0 host 1.0.0.1 and host 159.69.xx.xx

06:18:20.046509 IP 159.69.xx.xx.62280 > 1.0.0.1.443: Flags [.], ack 147344, win 1055, length 0
06:18:22.020358 IP 159.69.xx.xx.62280 > 1.0.0.1.443: Flags [P.], seq 46176:46278, ack 147344, win 1055, length 102
06:18:22.020410 IP 159.69.xx.xx.62280 > 1.0.0.1.443: Flags [P.], seq 46278:46377, ack 147344, win 1055, length 99
06:18:22.025708 IP 1.0.0.1.443 > 159.69.xx.xx.62280: Flags [.], ack 46377, win 8, length 0
06:18:22.026154 IP 1.0.0.1.443 > 159.69.xx.xx.62280: Flags [P.], seq 147344:147379, ack 46377, win 8, length 35
06:18:22.069073 IP 159.69.xx.xx.62280 > 1.0.0.1.443: Flags [.], ack 147379, win 1055, length 0
06:18:22.135207 IP 1.0.0.1.443 > 159.69.xx.xx.62280: Flags [P.], seq 147379:147934, ack 46377, win 8, length 555
06:18:22.135234 IP 159.69.xx.xx.62280 > 1.0.0.1.443: Flags [.], ack 147934, win 1055, length 0
06:18:25.489007 IP 159.69.xx.xx.62280 > 1.0.0.1.443: Flags [P.], seq 46377:46480, ack 147934, win 1055, length 103
06:18:25.489088 IP 159.69.xx.xx.62280 > 1.0.0.1.443: Flags [P.], seq 46480:46579, ack 147934, win 1055, length 99
06:18:25.494713 IP 1.0.0.1.443 > 159.69.xx.xx.62280: Flags [P.], seq 147934:147969, ack 46579, win 8, length 35
06:18:25.494729 IP 159.69.xx.xx.62280 > 1.0.0.1.443: Flags [.], ack 147969, win 1055, length 0
06:18:25.534389 IP 1.0.0.1.443 > 159.69.xx.xx.62280: Flags [P.], seq 147969:148524, ack 46579, win 8, length 555
06:18:25.534409 IP 159.69.xx.xx.62280 > 1.0.0.1.443: Flags [.], ack 148524, win 1055, length 0

I wrote a simple bash script for spying your OpenVPN clients http traffic. Sure you can modify it for your needs.