Skip to content

Setting up dnsmasq with secureoperator

Jump to bottom
Nathan Wittstock edited this page Jan 6, 2018 · 4 revisions

Since secureoperator does no caching of its own, it's recommended that you set up a caching DNS server like dnsmasq on your local network, which responds from its own cache and forwards uncached requests to secureoperator for lookup.

This document assumes that you:

  • are setting up dnsmasq and secureoperator on the same machine
  • have already installed the dnsmasq package as apropriate for your operating system
  • are installing on a Linux system
  • are using systemd

This isn't the only way to do this (you could use Docker, for example) however these instructions should easily adapt to other environments.

Running secureoperator

  1. Download the latest release of secureoperator for your environment, and place it at /usr/local/bin/secure-operator. Ensure it is executable (chmod +x secure-operator)
  2. Create a systemd unit file to run secureoperator on startup. Save this file as /etc/systemd/system/secure-operator.service and ensure it is executable (chmod +x secure-operator.service)
[Unit]
Description=Secure Operator
After=network.target

[Service]
Type=simple
# start secureoperator on port 54, rather than the standard DNS port. dnsmasq will run on 53 and
# forward to this server.
ExecStart=/usr/local/bin/secure-operator -level warn -listen 0.0.0.0:54 -dns-servers "8.8.8.8,8.8.4.4"

[Install]
WantedBy=multi-user.target
  1. Run systemctl daemon-reload to reload the unit files
  2. Run systemctl start secure-operator.service
  3. If secureoperator starts successfully, enable the service with systemctl enable secure-operator.service; it will now run at startup.

Testing secureoperator's operation

Make a DNS request directly at secureoperator to ensure it's working; with the dig command:

dig @localhost -p 54 google.com

You should see a response which includes the A records for google.com.

Configuring dnsmasq

dnsmasq has a lot of configuration options; you should refer to its man page for information on each; however, you a minimal configuration should only require a few tweaks.

  1. Edit /etc/dnsmasq.conf, ensure the following lines are set as follows:
# stops dnsmasq from reading resolv.conf
no-resolv

# add your secureoperator server as the upstream dns server
server=127.0.0.1#54

# set how many entries you wish to have cached; you can tweak
# this setting depending on how much memory your sytem has
# available
cache-size=500
  1. Alter the dnsmasq unit file to depend on secureoperator; /etc/systemd/system/dnsmasq.service; add the following to the [Unit] section. Ensure these are new additions; don't replace any of the existing After or Requires directives:
After=secure-operator.service
Requires=secure-operator.service
  1. Reload the unit file with systemctl daemon-reload
  2. Start dnsmasq with systemctl start dnsmasq.service
  3. If it starts correctly, enable it at startup with systemctl enable dnsmasq.service

Testing dnsmasq's operation

Make a DNS request against dnsmasq to ensure it's working; with the dig command:

dig @localhost google.com

You should see a response which includes the A records for google.com.

Ensuring requests are going through secureoperator, and caching correctly:

Above, we opted to run secureoperator's logs at the warn level; this is because you probably don't want securoperator writing every DNS lookup you make to logs, which is what it does at the default info level. However, if you want to ensure things are working as appropriate, you'll need to see those logs:

  1. Alter the ExecStart line in /etc/systemd/system/secure-operator.service to log at the info level:
ExecStart=/usr/local/bin/secure-operator -level info -listen 0.0.0.0:54 -dns-servers "8.8.8.8,8.8.4.4"
  1. Reload unit files systemctl daemon-reload
  2. Restart secureoperator with systemctl restart secure-operator.service
  3. Follow the secure operator logs with journalctl -f "_SYSTEMD_UNIT=secure-operator.service"
  4. Now make some requests against DNS to see if behavior is as expected

What are you looking for?

  • You should see secureoperator being hit for each fresh lookup of a domain
  • You should not see any subsequent hits against secureoperator for any domain whose cache has not expired yet

You can tell how long a record should be cached for in the ANSWER section of dig's output:

;; ANSWER SECTION:
google.com.		299	IN	A	74.125.28.100
google.com.		299	IN	A	74.125.28.139
google.com.		299	IN	A	74.125.28.102
google.com.		299	IN	A	74.125.28.113
google.com.		299	IN	A	74.125.28.101
google.com.		299	IN	A	74.125.28.138

In the above example, 299 is the cache timeout value, in seconds.

Note: be sure to lower the log level of secureoperator back to warn when you are done testing.

Clone this wiki locally