If you have gone through the process of setting up DNS-based security for your home (Pi-Hole) or enterprise (Defender for DNS) network that’s awesome, you have increased the security of that network.

If done right this will give you the visibility to see what is happening and control what’s going on with your network with clients that use internal DNS. If you have not take the time to identify, update, and block clients from using external DNS servers, you have a gap in your DNS security.

nslookup cormier.co 8.8.8.8

This command will bypass your internal DNS server and query Google’s DNS server 8.8.8.8.

Server:         8.8.8.8
Address:        8.8.8.8#53

If the above command returns a response, it’s possible to bypass your internal DNS server and query external DNS servers.

You can identify clients by looking for DNS queries that are not destined to your internal DNS but to external DNS. These clients will require configuration changes to use internal DNS, before implementing any type of access control to block external DNS usage, otherwise these clients will experience DNS resolution issues.

Why is this important?

If you have a DNS-based security solution in place, you have the ability to see and control what is happening on your network. But, if you allow clients to use external DNS, malware and other threats, and legit clients can bypass your DNS-based security solution with direct DNS queries to external DNS.

Leaving you in the dark.

How to fix this?

Identify clients that are using external DNS and update them to use internal DNS. That’s obvious, but that can be a challenge especially in large enterprise networks.

Once you have identified and updated clients to use internal DNS, which would come by the absence of traffic to external DNS, you can implement access control to block external DNS usage.

If after you block external DNS usage, you notice control list counters incrementing, and indication that clients are trying to use external DNS, you will have to identify and update those clients.

Might clients that were missed, new clients with old configuration, or a static configuration that should be updated to use internal DNS.

Conclusion

DNS-based security is a great way to increase the security of your network, but it’s only as good as the weakest link. Leaving yourself open to malware and other threats that can bypass your DNS-based security and is one way.

Setting up BIND can be a challenge in of itself. Interfaces can be make things easier, but it isn’t always quiet obvious how-to go about achieving what you want, and still require some knowledge of BIND/named configuration.

As with OPNsense DNS plugin, can be quite tricky to get right. This post is how I got my internal domain, hq.cormier.co, setup in OPNsense, complete with reverse zones.

Plugin Install

You can install the os-bind plug from the System > Firmware > Plugins page. Once installed you can find the BIND menus under Services > BIND.

BIND Configuration

In my examples I have three (3) zones. One (1) forward zone, hq.cormier.co, and two (2) reverse zones, 10.0.10.in-addr.apra and 70.0.10.in-addr.apra, for the networks 10.0.10.0/24 and 10.0.70.0/24 respectively.

Example of how I created my forward lookup zone hq.cormier.co.

Our records for the forward zone hq.cormier.co. Add NS and corresponding A record for our name server. In my example, fw.

The records for reverse zones will have just the host end as the name and full FQDN for the value. As an example to reverse resolve for 10.0.70.1, I would create record with name 1 in zone 70.0.10.in-addr.arpa. This seems odd at first, but this is the notation.

The following records will need to be created in the reverse zones that you create. Notice, the periods on the end of the FQDN for the values of reverse zone records.

• Nameserver (NS) record
  • Name: <blank> or @ depends on interface
  • Value: fw.hq.cormier.co. (notice period)
• PTR for A record host (1 in my example)
  • Name: 1
  • Value: fw.hq.cormier.co. (notice period)

Important note, notice the value ends with a period (.), this is the FQDN notation, if the period is missing BIND will append the zone name, in this case it would fw.hq.cormier.co.70.0.10.in-addr.arpa, which would be an error.

Lookups

To verify our zone we will query using nslookup command line tool

$ nslookup
> fw.hq.cormier.co
Server:		10.0.70.1
Address:	10.0.70.1#53

Name:	fw.hq.cormier.co
Address: 10.0.70.1
> 10.0.70.1
Server:		10.0.70.1
Address:	10.0.70.1#53

1.70.0.10.in-addr.arpa	name = fw.hq.cormier.co.
>