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

If done right this will give you the ability and 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.

Server:         8.8.8.8
Address:        8.8.8.8#53

You can identify clients by looking for DNS queries that are not from your internal DNS server and destined for external DNS servers (8.8.8.8:53/udp). These clients you will have to update to use the internal DNS before implementing any access control to block external DNS usage, otherwise these clients DNS will stop working.

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.

You are missing the ability to see and control what is happening on your network, if you allow for external DNS use, malware and other threats can bypass your DNS-based security solution.

Leaving you in the dark.

How to fix this?

Identify clients that are using external DNS servers and update them to use internal DNS servers. 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 servers, which would come by the absence of traffic from clients 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 too.

Could be clients that were missed or new clients that were added to the network. A configuration or policy will need to be updated.

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.

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.
>