Relay - Setup and Configure

Relay - Setup and Configure

ScoutDNS supports a Relay configuration which allows operators to install a lightweight service inside their network. The relay is a local forwarding resolver service that processes queries inside the operator network while relaying public queries to the ScoutDNS cloud resolver. Queries meant for internal services remain inside the network. The purpose of this is to enable the following ScoutDNS resolver functionality:

  1. Set Policy by subnet
  2. Log LAN IP for queries
  3. Encrypt DNS traffic
  4. Configure local network aliases
  5. Configure local DNS forwarding
  6. Automatic updating of the relay software

The relay is a local forwarding resolver service that handles queries inside the operator network while forwarding external queries to the ScoutDNS cloud based resolver service. Queries meant for internal services remain inside the network


Showing DNS query flow with Relay

Cloud Configured

The ScoutDNS relay is designed as a fully cloud configured service to simplify install and management. Setting up and configuring the relay involves two steps

1) Install the Relay inside a local host
2) Configure the Relay through the ScoutDNS UI

Installing the Relay involves simply downloading the files and executing the install command. 
Currently we only support Debian based Linux distros for running the relay service. This includes Ubuntu and Kubuntu. 

Preparing the Host

The ScoutDNS relay can run on any hardware that has at least 1 CPU, 1GB of free ram, and 10GB of storage. 
As this host will act as the local DNS for all subnets, be sure all networks are routable to it. 
For the Relay host itself, DNS should be set to our ScoutDNS anycast IPs for best practice.


Ready to Install

Download the install file from the Help icon at top right of UI.



Once copied to your Relay host, you will need to unpack and then execute the install command.

For AMD:
sudo  ./scoutdns-linux-adm64 - install-dns
For Intel:
sudo ./scoutdns-linux-i386 - install-dns

The service will start automatically once installed and update itself to the latest version of available. 
You can start/stop the Relay service with these commands:
sudo systemctl start scoutdns
sudo systemctl stop scoutdns

You can uninstall the relay service with these commands:
For AMD:
sudo  ./scoutdns-linux-adm64 - uninstall-dns
For Intel:
sudo ./scoutdns-linux-i386 - uninstall-dns

The ScoutDNS service will auto configure the relay host DNS settings and change them back en the service is stopped or uninstalled. 
The ScoutDNS relay will send DNS queries using DoH over port 443.  

Configure the Relay through ScoutDNS UI


In order for us to detect your relay, you must first configure the WAN the relay is using. Please see the Quick Start Setup Guide for instructions on this step. Once the relay is installed on a previously configured  WAN, it will begin calling our relay service to register. The detected relay will appear under the site tab within the selected site, in the Relays subtab.




You will see the relay ID with status "Not Adopted". Click the "Adopt" button to register this relay with on this site. You can install multiple relays within the same site, and all relays share the same configuration as set in the UI. This is recommend for high availability.

Once adopted, the relay will connect to our relay configuration service through secure HTTPS and periodically poll for new configurations as set here in the UI. Updates to configurations should be realized within 1-2 minutes at most. 


You can install multiple relays within the same site, and all relays share the same configuration as set in the UI. This is recommend for high availability.

Local Forwarders

With the relay acting as the primary DNS service within your local network, we need to tell the relay about any other DNS service such as Windows domain controllers, that your client devices will need access to. In the Local Forwarders subtab, you can configure the ScoutDNS relay to forward requests as needed to any valid local domain or DNS service. 

Click "+ New Domain". Then enter your desired local domain name. You will need to input the IP addresses the forwarding service can be found at. Up to 4 IP addresses for each entry. Finally choose which already configured LAN the rule applies to or leave "All LANs" as defaulted. Select "Save" and your configuration will be updated on the Relay shortly.  




Forward Lookup Zones

It is important to add ALL domains with a forward lookup zone from your domain controllers.  From the Windows DNS Manager tool, identify all domains listed in the forward lookup zone section.

It is important to add ALL domains with a forward lookup zone from your domain controllers

Redirects

You can create redirects to resolve specified internal IPs to other devices such as printers, video players, or other services.  You can also use redirects to alter any internal or external domain to your specified IP.  Think of this as a way to manually configure DNS records for Relay connected devices. Within the Redirects subtab select "New Redirect". Now enter the domain name and the IP address you want the name to resolve to. Click save and your relay will update.
‚Äč

Keep in mind that redirecting a domain with an existing certificate may cause a certificate error. 

LAN

The LAN subtab allows operators to assigned policy based on local subnets. This way, users on one network will experience a different policy from users on another network. To configure this first select "+ New LAN".  We need to designate what WAN this LAN rule will apply on. By default ALL WANS is selected, but you have the option to specify a different combination of WANs should your network require. Give your LAN a name (used in reporting and other configuration tabs) and set the IP range this rule will apply to. Here are some valid examples:

192.168.3.0/24
10.10.0.1 /22
10.10.0.1 /20
172.16.0.0 /21



Yes, you can even specify specific IPs, giving a single IP address it's own policy. Be sure in this case to set a static IP or DHCP reservation for said host.

Finally, assign any of your already created policies to the LAN and click save. Now LAN clients will use the policy designated by their LAN IP. 

Setting local client devices to Relay

Testing the Relays


Before setting local client devices to the relays, you should first test the ability for the relays to be accessed from each network you are configuring. You will also want to their ability to resolve both public and local private DNS queries. You can do with with simple nslookup commands.

For public DNS try

nslookup test.verify.scoutdns.com (IP address of your relay host)
This is a test domain that only resolves from our service with a configured network. This verifies that the relay is retuning queries from our service to the requesting device. 



 For local DNS try:

nslookup example.yourlocaldomain.corp (IP address of your relay host)
This verifies that the relay is properly handling local queries withyour non-ScoutDNS local DNS service. 



If both domains resolve correctly from all subnets, you are ready for the next step. Otherwise, you will need to ensure the Relay is online and that you can access/ping the relay host from all subnets. 

If you have more than one Relay host, you should conduct tests with all relay host IPs to verify proper network access and resolution. 


Pointing Local Clients to the Relay

You will configure your DHCP server/service to hand out the earlier tested IP(s) of your Relay Hosts. You can use more an IP from more than one ScoutDNS relay service that you have installed. Be sure to test all Relay hosts the same before deployment.  You should not mix DNS server types for client devices meaning, you should not set one IP as relay, and another as domain controller, ScoutDNS anycast, or other DNS service. This will cause inconsistent policy enforcement and some queries will not be logged or protected.  As mentioned it is critical to test relay resolving capabilities for both external and internal domains before deployment. We highly recommend to manually set the relay as the DNS for a few local client devices in order to continue testing on all subnets. 


You should not mix DNS server types for client devices

Existing IP Leases 

There is no way to force change the DNS IP for existing client devices without restarting them or without using a group policy object. For machines subject to group policy you can execute a batch file with "ipconfig /renew". This will cause any client devices subject to group policy to renew a new DNS IP from your relay host. 

Out of Scope elements: We cannot provide support on local network configurations or host OS/network related issues. We cannot offer support on Windows domain controllers or DCHP configurations in windows or other customer equipment. Please see related  vendor documentation for such setup and support.
In Scope elements: ScoutDNS offers support for the install and configuration of the Relay service on qualified hosts as well as support for the cloud based GUI configuration. 





  


 






    • Related Articles

    • Quick Start Setup Guide

      This guide will walk you through the steps needed to configure ScoutDNS to your network. Step 1: Register Network IP ScoutDNS operates as a closed/private DNS resolver. This helps to improve security and prevent system abuse by third parties. As a ...
    • Dynamic IP Setup

        ScoutDNS supports dynamic DNS IP address integration with almost any dynamic DNS provider. Popular Dynamic DNS solutions include:   No-IP ChangeIP DynDNS FreeDNS Once you have an account with any of these or similar solutions, you can configure ...
    • Configuring Notifications

      ScoutDNS allows administrators to designate who can receive notifications and select what type of notifications are sent to where. This is done through the use of Notification Profiles. A notification profile contains both the email address to send ...
    • Prevent DNS Work-Around for Users

      Some users on your network may try to bypass ScoutDNS resolvers by changing the DNS servers in their device network settings when allowed. This can result in undesired content access on network assets along with increased security risk. The good news ...
    • Install ScoutDNS Certificate for Browser HTTPS Errors

      When a site or domain is blocked by ScoutDNS, a block page is served to the end user in place of the requested domain. If the requested domain was encrypted with HTTPS, then a security error will occur. In order to resolve this and receive a valid ...