Stoiko Ivanov: /* Installing and using unbound */

2023-01-05T09:25:50Z

Installing and using unbound

← Older revision		Revision as of 09:25, 5 January 2023
Line 41:		Line 41:
	search yourdomain.example		search yourdomain.example

			in <code>/etc/resolv.conf</code>. You can use the GUI for setting the dns-resolver as well under Configuration -> Network/Time -> DNS - Just add <code>127.0.0.1</code> as <code>DNS Server 1</code>.
	in <code>/etc/resolv.conf</code>.

	When Proxmox Mail Gateway is running as a Container on Proxmox VE, then you need to edit the container's DNS Settings to use <code>127.0.0.1</code> as DNS Server (and adapt your search domain to <code>yourdomain.example</code>)		When Proxmox Mail Gateway is running as a Container on Proxmox VE, then you need to edit the container's DNS Settings to use <code>127.0.0.1</code> as DNS Server (and adapt your search domain to <code>yourdomain.example</code>)

Stoiko Ivanov: /* Optional: Using the local unbound only for DNS Blocklist requests */

2020-08-26T16:20:00Z

Optional: Using the local unbound only for DNS Blocklist requests

← Older revision		Revision as of 16:20, 26 August 2020
Line 84:		Line 84:
	Should your environment require you to use an internal DNS server for all requests, because you have a very modified setup or are employing some other blocking for regulatory reasons you can also try to forward all other requests to your internal DNS Server and only ask the DNS Blocklist zones recursively.		Should your environment require you to use an internal DNS server for all requests, because you have a very modified setup or are employing some other blocking for regulatory reasons you can also try to forward all other requests to your internal DNS Server and only ask the DNS Blocklist zones recursively.

	This setup is '''not recommended for general use''', since it increases the complexity ~~and~~ makes debugging harder.		This setup is '''not recommended for general use''', since it increases the complexity which makes debugging harder.

	In the example we will use recursive queries for the following domains and forward all other requests to 192.0.2.53:		In the example we will use recursive queries for the following domains and forward all other requests to 192.0.2.53:

Martin: page created

2020-01-14T15:07:50Z

page created

New page

== Introduction ==

One of the most effective means to detecting spam currently is the use of [https://cwiki.apache.org/confluence/display/SPAMASSASSIN/DnsBlocklists DnsBlocklists].
These lists are used to query the IP of the connecting SMTP server, or IPs and hostnames occurring in the mail body.

Some of the DNS Blocklists used by SpamAssassin (and thus also Proxmox Mail Gateway) allow only a certain number of requests per DNS server and don't respond once your DNS server has reached it's quota.
This is reflected in the mail logs and SpamAssassin hits of a mail. If you see 'URIBL_BLOCKED', 'RCVD_IN_DNSWL_BLOCKED' or 'SURBL_BLOCKED' in your mail logs or the mail headers, this is an indication that your system has reached the quota.

If you're using a shared DNS server (e.g. your ISPs, or a publicly available one like 9.9.9.9, 1.1.1.1, 8.8.8.8) it is quite likely that the Mail Gateway's requests will be blocked.

Installing a dedicated DNS server on the Proxmox Mail Gateway can help in such situations.

Keep in mind that the DNS Blocklists can only count the requests per public IP, i.e. if you have both your internal DNS and Proxmox Mail Gateway natted to the same public IP setting up a recursive DNS server will not help.

If you keep reaching the limit despite having a dedicated recursive server for your Proxmox Mail Gateway you should consider getting a dedicated feed, which is provided by most DNS Blocklist providers for a fee. This also helps keeping this important infrastructure up and running.

We will use the [https://nlnetlabs.nl/projects/unbound/about/ Unbound] recursive DNS server.

== Installing and using unbound ==

Simply run
apt install unbound dnsutils

to install the <code>unbound</code> server - the <code>dnsutils</code> package contains <code>dig</code>, which can be used for testing.

Check that unbound is indeed listening on port 53:
# ss -tulnp | grep :53
udp UNCONN 0 0 127.0.0.1:53 0.0.0.0:* users:(("unbound",pid=137,fd=5))
udp UNCONN 0 0 [::1]:53 [::]:* users:(("unbound",pid=137,fd=3))
tcp LISTEN 0 128 127.0.0.1:53 0.0.0.0:* users:(("unbound",pid=137,fd=6))
tcp LISTEN 0 128 [::1]:53 [::]:* users:(("unbound",pid=137,fd=4))

You can verify that DNS resolution works by using the <code>dig</code> utility
# dig a proxmox.com @127.0.0.1 +short
79.133.36.244

Afterwards you need to configure your Proxmox Mail Gateway installation to use the local dns-server listening on <code>127.0.0.1</code> (or optionally <code>::1</code>) as resolver.
In the following article we assume that your domain is <code>yourdomain.example</code> - you need to adapt the posted configuration.
On a standard installation this is done by simply placing:
nameserver 127.0.0.1
search yourdomain.example

in <code>/etc/resolv.conf</code>.

When Proxmox Mail Gateway is running as a Container on Proxmox VE, then you need to edit the container's DNS Settings to use <code>127.0.0.1</code> as DNS Server (and adapt your search domain to <code>yourdomain.example</code>)

If you have installed the resolvconf package you should not need to change everything, since the unbound package in Debian brings integration with <code>resolvconf</code>

Should your system use <code>systemd-resolved</code> make sure that
resolvectl status

indicates that <code>127.0.0.1</code> is listed as <code>Current DNS Server</code>

Alternatively you can simply disable and stop the service
systemctl disable systemd-resolved
systemctl stop systemd-resolved

After installing you can either reboot you Proxmox Mail Gateway, or restart the services relevant for mail-processing:
systemctl restart pmg-smtp-filter pmgpolicy postfix

== Forwarding requests for your internal zone to your internal DNS ==

In some environments the internally used DNS has all knowledge about your domain, and should be consulted for it, instead of unbound getting the publicly available data via DNS delegation from the root-servers.

You can configure unbound to ask your internal DNS-server (for this example the internal DNS-server has the IP 192.0.2.53) for your internal domains (yourdomain.example and yourseconddomain.example).
Create a dedicated config-snippet <code>/etc/unbound/unbound.conf.d/local-stub.conf</code>:

stub-zone:
name: "yourdomain.example"
stub-addr: 192.0.2.53

stub-zone:
name: "yourseconddomain.example"
stub-addr: 192.0.2.53

Afterwards restart unbound and verify that DNS-requests for yourdomain.example are delegated to 192.0.2.53 (by checking the DNS logs there):
systemctl restart unbound
dig test.yourdomain.example @127.0.0.1

== Optional: Using the local unbound only for DNS Blocklist requests ==

Should your environment require you to use an internal DNS server for all requests, because you have a very modified setup or are employing some other blocking for regulatory reasons you can also try to forward all other requests to your internal DNS Server and only ask the DNS Blocklist zones recursively.

This setup is '''not recommended for general use''', since it increases the complexity and makes debugging harder.

In the example we will use recursive queries for the following domains and forward all other requests to 192.0.2.53:
* mailspike.net
* dnsbl.sorbs.net
* rhsbl.sorbs.net
* bl.spamcop.net
* spamhaus.org
* surbl.org
* uribl.com
* dnswl.org

The list is taken from the [https://cwiki.apache.org/confluence/display/SPAMASSASSIN/DnsBlocklists Spam Assassin Entry on DNS Blocklists].
You should enhance the list by all domains you are using in your setup (especially the one's configured for <code>postscreen</code>)

Since unbound cannot do recursive lookups for specific zones if it is forwarding all other requests we will configure 2 unbound instances:
* one listening on port <code>5003</code> for recursive lookups - the DNSBL instance
* one forwarding requests for the DNSBL domains to port 5003, and all other requests to your internal DNS Server.

For the DNSBL instance - create a config-file which does only include the necessary config-options <code>/etc/unbound/unbound-dnsbl.conf</code>:
#unbound instance listening on port 5003 for DNSBL lookups
include: "/etc/unbound/unbound.conf.d/qname-minimisation.conf"
include: "/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf"

port: 5003
remote-control:
control-port: 8954

Additionally you need to create a systemd-unit (<code>/etc/systemd/system/unbound-rbl.service</code>

[Unit]
Description=Unbound DNS server for DNSBL lookups
Documentation=man:unbound(8)
After=network.target
Before=nss-lookup.target
Wants=nss-lookup.target

[Service]
Type=simple
Restart=on-failure
EnvironmentFile=-/etc/default/unbound
EnvironmentFile=-/etc/default/unbound-rbl
ExecStartPre=-/usr/lib/unbound/package-helper chroot_setup
ExecStartPre=-/usr/lib/unbound/package-helper root_trust_anchor_update
ExecStart=/usr/sbin/unbound -c /etc/unbound/unbound-rbl.conf -d $DAEMON_OPTS
ExecReload=/usr/sbin/unbound-control -c /etc/unbound/unbound-rbl.conf reload

[Install]
WantedBy=multi-user.target

and enable it with
systemctl enable unbound-rbl
systemctl start unbound-rbl

For the instance listening on port 53 you need to create a config-snippet in <code>/etc/unbound/unbound.conf.d/pmg-dnsbl.conf</code>:
server:
do-not-query-localhost: no
# depending on your internal DNS-servers capabilities these options might be necessary
# harden-dnssec-stripped: no
# module-config: "iterator"

forward-zone:
name: "uceprotect.net"
forward-addr: 127.0.0.1@5003

forward-zone:
name: "mailspike.net"
forward-addr: 127.0.0.1@5003

forward-zone:
name: "sorbs.net"
forward-addr: 127.0.0.1@5003

forward-zone:
name: "bl.spamcop.net"
forward-addr: 127.0.0.1@5003

forward-zone:
name: "spamhaus.org"
forward-addr: 127.0.0.1@5003

forward-zone:
name: "surbl.org"
forward-addr: 127.0.0.1@5003

forward-zone:
name: "uribl.com"
forward-addr: 127.0.0.1@5003

forward-zone:
name: "dnswl.org"
forward-addr: 127.0.0.1@5003

forward-zone:
name: "."
forward-addr: 192.0.2.53

Test the setup by doing lookups to:
* a testpoint of a DNSBL and verify that the query does not arrive at your internal server
* a testpoint of an arbitrary address (which should arrive at your internal server):

# dig any test.uribl.com.multi.uribl.com @127.0.0.1 +short # should not show up as query on 192.0.2.53
127.0.0.14
"permanent testpoint"
# dig a proxmox.com @127.0.0.1 +short #should show up as query on 192.0.2.53
79.133.36.244

DNS server on Proxmox Mail Gateway - Revision history

Stoiko Ivanov: /* Installing and using unbound */

Stoiko Ivanov: /* Optional: Using the local unbound only for DNS Blocklist requests */

Martin: page created