Skip to content

SecureDNS Quickstart Guide

About this Document

This document describes how AXS Guard's SecureDNS should be deployed to guarantee optimal results for networks where clients do not rely on AXS Guard for DHCP and DNS, e.g. Microsoft environments using Active Directory Domain Services.


In order to use the SecureDNS feature, a Premium Threat Protection Pack and license are required. Contact if you wish to learn more about this feature or to upgrade your existing license.


Licensing & Feature Activation

  1. Log in to AXS Guard and start the license wizard to import your Premium Threat Protection license, then activate the SecureDNS feature.


  2. After activating the feature, navigate to Network > General and enable the SecureDNS option.


  3. Verify if the dns-internal and dnscache services are both running by navigating to System > Status > Services (look for dns).



To have full visibility of malicious DNS requests originating from devices in your network, the secure LAN IP address of AXS Guard should be configured as their preferred DNS Server. You can manually set a preferred DNS server for devices in your network or automatically via DHCP (a.k.a. DHCP option 6).

Note that only AXS Guard is able to handle DNS requests via Secutec's internet-facing SecureDNS servers; they cannot be accessed directly, unlike open DNS resolvers.

It is therefore crucial to configure your own DNS servers so they always use AXS Guard to resolve hosts and IP addresses on the Internet.


Equally important is that reverse DNS resolution is also correctly configured. Especially for Active Directory environments which rely heavily on forward and reverse DNS resolution to correctly locate and use resources on a network, e.g. when using Kerberos authentication.

Steps to take:

  • Make a list of all your internal domains, especially those configured for Active Directory.
  • Make a list of all internal reverse lookup zones, e.g. matches the following reverse DNS lookup zone:
  • Make a list of all your internal DNS servers. More often than not, these are the same as your Microsoft Domain Controllers (DC).
  • Configure DNS forwarding on AXS Guard:
    • Internal zones -> use your internal DNS server.
    • Internal reverse zones -> use your internal DNS server.
  • Once DNS forwarding is set up correctly, update the configuration of your internal DNS server(s) so they use AXS guard as their primary DNS server to resolve hosts on the Internet.
  • Add the sec-dns-tcp firewall rule to the AXS Guard stat-sec firewall policy to allow retransmission, i.e. DNS queries which exceed the UDP size limit of 512 bytes.
  • Change the configuration of your DHCP server, so clients automatically use AXS Guard as their preferred DNS server (option 6).


In small networks, AXS Guard itself often functions as the internal DHCP and DNS server. In this case, there is nothing to prepare.

Just configure your devices and computers to use AXS Guard as their preferred DNS server. This can be achieved manually by configuring the advanced TCP/IP Settings for each device or automatically through DHCP.

Once resolving via AXS Guard runs smoothly, make sure that no devices in your network can bypass AXS Guard to resolve hosts on the Internet. One way to achieve this, is by redirecting rogue DNS traffic (UDP port 53) going through AXS Guard.

DNS is a critical component for network security and stability. It can be made more robust through the installation of an AXS Guard High Availibility cluster, where devices and computers must be configured to use the virtual IP address of the AXS Guard HA cluster as their preferred DNS server.

Configuring your Clients and Servers

AXS Guard DHCP Server

Configure DHCP option 6 on AXS Guard, so it can pass the correct DNS server IP address to all the hosts in your network. Note that this is only required if you are using AXS Guard as your DHCP server.


Third-party DHCP Server

If you are not using AXS Guard for DHCP services, configure DHCP option 6 on your DHCP server, so it passes the LAN IP address of AXS Guard to all the hosts in your network, e.g.


Manual IP Address Configuration

For optimal results and protection, you want your internal DNS server(s) to forward all DNS lookups for external domains and IP addresses to AXS Guard.

To forward these lookups, add the LAN IP address of AXS Guard as a DNS forwarder in the Windows DNS management console.

For security and privacy reasons, we advise you not to add any open DNS resolvers to your server configuration.


Authenticated Users

The AXS Guard Single Sign-On (SSO) tool is designed to securely and transparently authenticate users against AXS Guard. After successful authentication, users are granted firewall and web access privileges based on their credentials.


Installation of this tool is recommended, as it provides critical host information in the SecureDNS dashboard, which can be used to get insights into malicious DNS activity and easily isolate devices from your network for further investigation and troubleshooting.


Hostnames of computers that have been registered on AXS Guard and that are generating potentially malicious DNS requests, will also appear on the SecureDNS dashboard.

Note that assigning AXS Guard security policies at the computer level is only appropriate for servers with a static IP address. In all other instances, Able recommends assigning security policies at the user or group level and to enforce user authentication.

Blocking Rogue DNS Requests

It is important to note that SecureDNS by itself doesn't prevent users from manually changing DNS server settings on their device and using an open resolver.

Therefore, it is recommended to prohibit user access to properties of LAN connections, client proxy settings and to redirect all rogue DNS traffic, so no queries can slip through the cracks.

Prohibiting Access to Properties of a LAN Connection

The following configuration determines whether the Windows Network Properties menu item is enabled, and thus, whether the Local Area Connection Properties dialog box is available to regular users.

Disable this setting and enable Network Connections settings for Administrators in order to disable the Network Properties menu items for all users, which will also prevent them from changing their DNS settings:

Registry PathSoftware\Policies\Microsoft\Windows\Network Connections
Value NameNC_LanProperties
Enabled Value0
Disabled Value1

Redirecting all DNS Traffic to AXS Guard

You can intercept all DNS traffic towards the Internet and redirect it via port forwarding to the LAN IP address of AXS Guard:

  1. Go to Network > NAT > Port Forwarding.
  2. Add a rule as shown in the example below and save your configuration.
  3. Repeat the same steps for TCP port 53.



In some cases, applications may try to use TCP instead of UDP for DNS requests. For example, if the DNS response is too large to fit in a single UDP packet (which has a maximum size of 512 bytes).

Following are 2 examples of apps that may use TCP for DNS requests:

  • Google Chrome: In some cases, Chrome may use TCP instead of UDP for DNS lookups. This behavior can be controlled with the dns_over_https flag in Chrome.

  • Mozilla Firefox: Like Chrome, Firefox may use TCP for DNS requests if UDP is blocked or if the response is too large for a single UDP packet. Firefox also supports DNS over HTTPS (DoH), which encrypts DNS requests and responses using HTTPS.

Overall, while it is not common for apps to use TCP for DNS requests, it is possible under certain circumstances.

Handling DNS over HTTPS

DNS over HTTPS or DoH is problematic for the analysis and monitoring of DNS traffic for cyber security purposes. DoH uses encryption and can be used to bypass SecureDNS or other DNS controls in your network.

There are several methods to prevent the use of DNS over HTTPS: blacklisting the IP addresses of public DoH servers in the AXS Guard firewall, disabling DoH options in web browsers or disabling DNS encryption in Windows.


By blacklisting the IP addresses, traffic to and from these servers will be blocked. Disabling the DoH options in web browsers and in Windows will ensure that traditional DNS is used instead of DoH.

Handling DNS over TLS

DNS over TLS, or DoT, is a standard for encrypting DNS queries to keep them secure and private.

DoT uses TLS to encrypt and authenticate communications. This ensures that DNS queries are not visible to third parties, protecting user privacy and security. Like DNS over HTTPS, this also means DoT can be used to bypass SecureDNS or other DNS controls in your network.

DoT uses TCP port 853 by default, although it is also possible to use UDP port 853. Some popular DoT servers include Cloudflare, Google and Quad9.

System administrators can easily block the specific ports and protocols used by DoT in the AXS Guard firewall with a static policy.


Preventing Users from Changing Proxy Settings

The AXS Guard proxy server adds an additional layer of security between your internal network and the Internet. It can securely relay requests from computers and devices in your network, acting as a buffer against cybersecurity threats.

When using the AXS Guard proxy, users should not be allowed to change their system's proxy settings, as the proxy itself also relies on SecureDNS. This can be achieved with a Windows group policy or by editing the Windows registry.

Creating DNS Sinkholes

DNS sinkholing is a mechanism aimed at protecting users by intercepting DNS requests initiated by clients that are attempting to connect to unwanted domains. If configured, AXS Guard will return a controlled IP address which points to a sinkhole server defined by an AXS Guard system administrator.

This technique can be used to prevent hosts from connecting to or communicating with unwanted destinations, e.g. legitimate domains and subdomains which aren't blocked by SecureDNS.

  1. Go to Network > DNS > Forwarding.
  2. Create a new entry as shown in the example below.
  3. Save your configuration.



DNS sinkholing can be a useful tool for preventing access to certain websites, but it should be implemented carefully and with consideration for the potential risks and limitations.

  • False positives: One of the main risks of DNS sinkholing is the possibility of false positives, where legitimate websites are incorrectly blocked. This can be particularly problematic in environments where access to certain sites is critical, such as in corporate or government settings.

  • Incomplete coverage: DNS sinkholing is not a foolproof solution and may not catch all instances of malicious activity. Various techniques exist to bypass DNS sinkholes, such as using IP addresses instead of domain names or using alternative DNS servers, e.g. open DNS resolvers.

  • Increased network latency: DNS sinkholing can add latency to DNS queries, especially if the sinkhole server is located far from the user. This can result in slower browsing and network performance.

  • Maintenance overhead: Maintaining a DNS sinkhole requires ongoing effort and resources to ensure that it remains up-to-date and effective. This can include updating blacklists, monitoring for new threats, and managing the sinkhole infrastructure.

  • Legal and ethical concerns: DNS sinkholing can raise legal and ethical concerns, particularly in terms of privacy and censorship. In some cases, blocking access to certain websites may be seen as a violation of free speech or civil liberties, and could result in legal challenges or public backlash.

Testing SecureDNS

Several organizations maintain and publish free blocklists of malicious URLs, systems and networks that can be used to test your SecureDNS configuration. Please note that some of these lists have usage restrictions. You can also use the following FQDNs provided by Secutec:

FQDN Category Blacklist Malware Spam

See the system administration guide on this site for additional information about the various SecureDNS categories.

You can quickly test SecureDNS on a Windows machine with nslookup or via the AXS Guard console with the dig command:

axsguard:~$ dig        

; <<>> DiG 9.16.24 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56956
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 2

; EDNS: version: 0, flags:; udp: 1232
; COOKIE: fc8af1a095b8b2b201000000639839e4592e46fed880b8d9 (good)
;      IN  A

;; ANSWER SECTION:   5   IN  CNAME 86400 IN CNAME 5 IN   CNAME 300   IN  A

;; ADDITIONAL SECTION:   1   IN  SOA 3 5 5 5 5

;; Query time: 260 msec
;; WHEN: Tue Dec 13 09:37:56 CET 2022
;; MSG SIZE  rcvd: 290

Logging & Reporting

SecureDNS events are logged throughout the AXS Guard configuration tool.


SecureDNS events related to clients which connect to the Internet via the AXS Guard proxy server are logged at the proxy level, not at the client level.

SecureDNS Logs

  1. Go to Network > DNS > SecureDNS Logs.
  2. Click on a date to view the logs.

SecureDNS Logs

Network Security Logs

  1. Go to System > Logs > Network Security.
  2. Click on the desired log file to open it.

Network Security Logs

Threat Reports

  1. Go to Reports > Threats > Malware Detection Report.
  2. Click on Show Statistics under "DNS queries to domains reported by SecureDNS grouped by category".


SecureDNS Dashboard

The AXS Guard Cloud provides multiple dashboards allowing authorized administrators and MSSPs to remotely and securely monitor AXS Guard deployments, push configuration settings to large-scale installations, view license and operational status information, register new appliances, manage customer contracts, troubleshoot systems and consult threat intelligence data, such as SecureDNS events.



While it is possible to keep your current DNS flow where clients solely use your internal (Windows) DNS server, which must be reconfigured to use AXS Guard SecureDNS for upstream resolving, it will limit AXS Guard's ability to link malicious DNS requests to individual hosts, which is required for effective troubleshooting and isolation of affected devices. It may also cripple host logs and reporting options.