Configuring DNS Server on pfSense 2.6.0

uquevedo

Hi Everyone,

I'm new to pfSense and like what I've configured so far, but coming from the world of Linux and how it configures bind, which apparently is a bit more lax right out of the box, is baffling to me with how pfSense handles bind.

For instance, I thought that I would just need to create zones, tell which vlans to advertise these zones on, and be done with it.

Apparently it's not that simple?

It would seem that I need to configure which hosts/IP addresses should be configured for each of the acl types [none, any, localhost, localnets which were all pre-configured blank] and also have a view created to match which acls are going to be used. On the Linux system [Ubuntu] that I've used before, the bind service was a bit more lax and didn't have acls or views configured by default. The bind used in pfSense is more robust by default.

I setup the acl localnet with a 10.0.0.0/8 entry in hopes that would pickup the five vlans I'm testing [10.32.1.0/10.32.10.0/10.32.20.0/10.32.30.0/10.32.40.0]. I tried doing each subnet with a 24 bit mask, but that didn't seem to work...nor can I quite tell if anything I'm doing is working.

I also can't seem to get the zone that I created to be accessible by the view that I created
There also doesn't seem to be anything in the zone to make it accessible by the view?

I'm terribly confused at what I should be doing to get this configured so that it will work. The netgate documentation is helpful for dns resolving and forwarding, but not for how to properly configured a true bind configuration [unless I'm missing something?].

Any advice or pointing in the right direction to look would be greatly appreciated!

Gertjan

@uquevedo said in Configuring DNS Server on pfSense 2.6.0:

I'm new to pfSense and like what I've configured so far, but coming from the world of Linux and how it configures bind, which apparently is a bit more lax right out of the box, is baffling to me with how pfSense handles bind.

pfSense is a firewall router.
Not a web server, file server, mail server or domain name server.
Way back, it had basic DNS capabilities, it was common to forward all DNS originating from LANs and the router itself to a upstream resolver, like the one your ISP offers you.
Or a public one. Or a upstream resolver that does some filtering for you.

The forwarder from back then, dnsmaq, is fashed out, but still present, and usuable. These these pfSense does the resolving itself using unbound, a DNSSEC capable resolver.

bind is another animal : it can do far more as just resolving.

I know, it is possible to de activate unbound, and install the pfSense package 'bind' and work with bind.
The thing is : bind uses several, or actually : many config files. bind is not a process that can be set up with a GUI.
Like postfix, nginx, apache2, radius etc : forget it. It's command line - and severe read-documentation-time.
This is IMHO of course.
I'm using bind myself on a Debian system for my 30+ domain names as a master domain name server, and several slave domain name servers. I even added DNNSEC for all of them, because : why not.

That said : it can be done, I presume.
Keep in mind that using bind on pfSense adds one more complexity : if the GUI edits / restarts / whatever a file in the wrong way, your in for a nice debug cycle.

uquevedo

@gertjan Thanks for the response, and this makes sense for how much frustration I've been running into with trying to get things configured through the frontend and the backed. The commandline doesn't phase me at all and I was baffled why it was that the zones that I configured weren't showing up in the chrooted environment that pfSense launches bind into.

Below is the compiled named.conf that gets generated from some of what I entered through the frontend [rndc secret purposefully obscured]:

#Bind pfsense configuration
#Do not edit this file!!!

 key "rndc-key" {
 	algorithm hmac-sha256;
 	secret "xXx#xXxXXXXXXXXx/xXx#xxx#XXxXX##xx#XxxxxXX=";
 };

 controls {
 	inet 127.0.0.1 port 8953
 		allow { 127.0.0.1; } keys { "rndc-key"; };
 };



options {
	directory "/etc/namedb";
	pid-file "/var/run/named/pid";
	statistics-file "/var/log/named.stats";
	max-cache-size 256M;
	dnssec-validation auto;

	listen-on-v6 port 53 { none; };
	listen-on port 53 { 10.32.20.1; 10.32.30.1;  };
	forwarders { 8.8.8.8;8.8.4.4; };
	
};


logging {
	channel custom {
		syslog daemon;
		print-time no;
		print-severity yes;
		print-category yes;
		severity info;
		};
	category default { custom; };
};

view "Testing" { 
	recursion yes;
	match-clients { any; };
	allow-recursion { any; };

	zone "." {
		type hint;
		file "/etc/namedb/named.root";
	};

};

The above makes perfect sense to me except that I don't see anyway to tie the zone information that I've created into the view I've created. As far as I can tell, the zone information isn't stored in a file that can be accessed by this process since every time the named service restarts, it blows away the chroot environment and recreates it.

I was really hoping that the pfSense box could be used like this so I could migrate the DNS service off of the one Linux box I'm running it on to this pfSense system.

I haven't had a chance to really just dive into the documentation as much as I'd like, so I'll try delving into that again but why have bind/named without letting it actually be a true DNS server?

johnpoz

@uquevedo said in Configuring DNS Server on pfSense 2.6.0:

get things configured through the frontend and the backed

Your trying to configure bind on pfsense via the direct edit of conf files? Yeah is going to be very problematic at best - pfsense is meant to be gui only..

What is your reason for wanting to use bind? Unless you have some specific reason, unbound is more than capable of providing dns for your network, and providing for local resolution of local resources.

Unless you have a specific need of a bind specific sort of feature, and all you want to do is provide your clients on your network a dns to use that resolves public resources and local resources - unbound is more likely a easier route to that than setting up bind.

I was a bind user myself back in the day, but since I didn't and don't have any specific need of bind features for my local network - unbound is for sure an easier route to a resolver that does dnssec, etc.

But I could run through a simple setup of local zone and having your clients on different local networks use bind to resolve those records while also having bind be a resolver for public records.

uquevedo

@johnpoz Thanks for the response, not necessarily trying to configure bind through the backend. I've used bind pretty extensively in the past and am very familiar with how it works, so I was baffled on how the backed processing of bind on pfSense worked when looking through the config files.

I want to be able to resolve my systems by name on my local network as well as provide general DNS resolution services, and in the past, I've used bind running on various Linux things to do that. I just thought that if bind was available through pfSense, I could re-use the pfSense box as a DNS server for name resolution for my system and resolver and retire the DNS server running on another Linux box.

Looking through the documentation some, it looks like I'd want to do DNS resolver overrides to have as many entries as I would have had in a zone file in the overrides to accomplish the same thing? If that is the case, it would be more elegant [to me] to have this configured in a bind zone and served out that way.

If this just isn't going to work like how I think it would, I'll still use pfSense, but I'll have to keep that DNS service I wanted to retire and have all of the clients point to that.

Any other advice would be greatly appreciated.

bingo600

@uquevedo
I'm using two linux Bind servers as my main DNS subsystem.
And i'm using ISC-DHCP on the same linux server(s) just one active.

Then i'm using pfsense Unbound in forwarding mode , pointing to the two linux servers, for DNS. And the pfSense DHCP Relay for forwarding queries to my linux servers.

I did that because :

1:
I already had that running when i switched to pfSense.

2:
I wanted to be able to resolve my DHCP clients via DNS.
pfSense DHCP restarts unbound (DNS Resolver) , when adding a DHCP entry , leaving the DNS system unresponsible for much too long time.

Edit:
The reason that i forward from pfSense unbound to the Linux DNS'es, is:
Then i can set all my clients to ask pfSense (in ISC-DHCP), and pfSense will ask the Linux DNS'es. And then i just have to permit Client DNS to access my pfSense interfaces.

One of my DNS'es is just a Raspi3, running as Bind slave via my primary DNS

/Bingo

uquevedo

@bingo600 Thanks for the response, what you are doing sounds like what I'm trying to make pfSense do, but it's looking more and more like that won't be possible.

I've gotten a little more familiar with the ISC-DHCP because of this project and I'm also running a Raspberry PI with Ubuntu on it for bind DNS, so it looks like I'll be looking into how I can get the ISC-DHCP setup on that system as well and do the dns integration with the dhcp.

Any pointers on that part since that's what I was hoping to do with the pfSense? Or just go find is ISC documentation for both?

Thanks for everyone else confirming that this wasn't going to work quite like I hoped!

bingo600

@uquevedo
I have used these when i made it.

Dynamic dns
See: https://wiki.debian.org/DDNS
See: https://spin.atomicobject.com/2012/04/03/setting-up-bind9-and-dhcp3-on-ubuntu-with-dynamic-dns/

Make sure your "ddns.key" files contain the same for isc-dhcpd , and bind9

cat /etc/dhcp/ddns.key 
key DDNS_UPDATE {
        algorithm HMAC-MD5.SIG-ALG.REG.INT;
        secret "***Secret generated key***";
};

cat /etc/bind/ddns.key 
key DDNS_UPDATE {
        algorithm HMAC-MD5.SIG-ALG.REG.INT;
        secret "***Secret generated key***";
};

This excerpt IMHO contains the "tricky part" for the /etc/dhcp/dhcpd.conf


#
# Sample configuration file for ISC dhcpd for Debian
#
#

#
# Leases are here /var/lib/dhcp/dhcpd.leases
#

#
# Dynamic dns
# See: https://wiki.debian.org/DDNS
# See: https://spin.atomicobject.com/2012/04/03/setting-up-bind9-and-dhcp3-on-ubuntu-with-dynamic-dns/
#

#
# key used for dynamic dns update
#
include "/etc/dhcp/ddns.key";

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-updates           on;
ddns-update-style      interim;
ignore                 client-updates;
#allow                  client-updates;
update-static-leases   on;

ddns-domainname "mydomain.org.";
ddns-rev-domainname "in-addr.arpa.";

# option definitions common to all supported networks...
option domain-name "mydomain.org";
option domain-name-servers ns1.mydomain.org;

default-lease-time 1800;
max-lease-time 7200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative;

And for Bind9 , all zones can be updated by ddns , of the correct key is supplied.

//
//Include Dynamic-DNS key , for update
//
include "/etc/bind/ddns.key";


zone "mydomain.org" {
        type master;
        file "/var/cache/bind/mydomain.org";
        allow-update { key DDNS_UPDATE; };
        allow-query { "local-nets"; };
        zone-statistics yes;
        notify yes;
        //also-notify { };
};

zone "1.168.192.in-addr.arpa" {
        type master;
        file "/var/cache/bind/1.168.192.in-addr.arpa";
        allow-update { key DDNS_UPDATE; };
        allow-query { "local-nets"; };
        zone-statistics yes;
        notify yes;
        //also-notify { };
};

The rest is "just hard work" ... lots of typing.
But you know that, since you're experienced with Bind

Edit2:
pfSense forwarding to linux dns'es.
My ip's in top are masked

System -> General setup

Unbound

In unbound "Custom Options", you might have to set your local zones "transparent" , else it will drop any RFC1918 answers from the linux server(s)

/Bingo

uquevedo

@bingo600 Excellent, thanks for all of this information!

uquevedo

Just a quick update on this, over this last weekend, I finally implemented pfSense with the forwarding of DNS/DHCP to one of my Linux systems where I configured the DHCP with static IP assignments, and to my initial shock, I got everything right and everything is "just working".

Thanks for the information and pointers on how to get this configured.

Now to figure out how to get the hostnames I have configured in the DHCP static assignments to populate instead of the hostname that the devices are reporting...