CoreDNS Settings

To configure CoreDNS:

The CoreDNS page contains three areas: CoreDNS settings, Blocklists, and Groups. This document covers the top section, CoreDNS Settings.

../../_images/nexus-coredns-settings.png

CoreDNS Settings

See also

See the recipe for a walkthrough of a basic CoreDNS configuration: Configuring the CoreDNS Service

Easy Setup

If CoreDNS is not yet configured, the GUI presents an Easy Setup option which will disable the DNS Resolver and DNS Forwarder in pfSense software and then enable CoreDNS.

../../_images/nexus-coredns-easysetup.png

CoreDNS Easy Setup Dialog

To use this option:

  • Navigate to Services > CoreDNS

  • Find the Easy Setup Available dialog at the top of the page

  • Click the Easy Setup button

  • Click OK to confirm the action

Tip

CoreDNS and Unbound can work together! To keep using Unbound, configure it to use an alternate port such as 5353, then configure Unbound as a DNS server for use in a CoreDNS group, e.g. 127.0.0.1:5353. This ordering is important so that queries filtered by CoreDNS never reach Unbound, which is faster and more efficient.

Enable CoreDNS

This option enables the CoreDNS functionality in Netgate Nexus. When active, CoreDNS will listen for, and respond to, DNS queries from clients on the configured Listen Port.

CoreDNS is not a separate daemon, it is part of the Netgate Nexus controller. As such, it does not show up in the system process list. There is a virtual service entry for CoreDNS under Status > Services when configuring an instance within the Netgate Nexus GUI, so it can be restarted, stopped, or started manually if necessary.

Zero Trust Egress

When the Zero Trust Egress option is active, CoreDNS will tag connections as allowed or denied in the firewall rules based on client DNS queries. CoreDNS will only tag connections as allowed after a client resolves a hostname through DNS, and it only allows connections to the hosts in the DNS query result. In other words, clients can only connect to resolved addresses, and they cannot connect to IP addresses which CoreDNS did not first resolve.

See also

For a complete walkthrough of Zero Trust Egress Mode configuration, see Configuring CoreDNS Zero Trust Egress Mode

By default, there are no firewall rules that pass or block these tagged connections, the tags allow administrators to create their own rules however they prefer. See Firewall Rules for Zero Trust Egress Mode for details.

This functionality, combined with other DNS and traffic control techniques, makes it possible to more tightly control sites visited by clients.

Tip

No such control system will ever be perfect, but this technique can help with many common users and scenarios. Keep in mind that if a client can resolve a host and connect to that host, they could tunnel or proxy around these protections. That’s why the best practice is to combine this with other forms of traffic control and identification, such as an IDS/IPS and other block lists.

See also

Firewall Rules for Zero Trust Egress Mode

CoreDNS only tags the connections, it does not pass or block anything on its own. Manual firewall rules are necessary to enact CoreDNS Zero Trust Egress mode protections.

For an interface with clients, such as LAN, the minimum rules are:

  • Pass DNS (TCP/UDP port 53) to the interface address, so clients can reach CoreDNS

  • Pass connections Tagged with coredns_allow

  • Reject or block connections Tagged with coredns_deny

    Setting this rule to log connections can help with tracking down potential client issues as well as clients attempting to bypass CoreDNS.

Tip

Other rules can be added above and below those to manage connections as needed. For example, to always pass connections to internal or VPN resources on other interfaces, or resources that work by direct IP address access (e.g. PBX). Place pass rules for those resources before the rules that match connections tagged by CoreDNS.

See also

Listen Port

This setting defines the TCP and UDP port that CoreDNS will bind to when listening for DNS queries. It must not conflict with any other active service on the device. For example, other DNS services such as the DNS Resolver (unbound), DNS Forwarder (dnsmasq), or add-on packages such as BIND must either be disabled or configured to run on alternate ports.

Interface

This option controls the interfaces upon which CoreDNS will respond to queries from clients. By default, CoreDNS will respond to queries on all interfaces, leaving access control up to firewall rules.

The best practice is to select all local interfaces containing clients which will query CoreDNS, such as LAN.

Note

CoreDNS always responds on localhost (127.0.0.1, ::1).