IP Aliases versus DNS
-
Greetings!
New to pfSense and I have an observation. Let me toss it out there and see what others think.
I have a smallish network with private (LAN) servers, and public (DMZ) servers, and I'm running authoritative DNS in the DMZ and caching DNS in the LAN. I also have a 3-bit subnet of public IP addresses and access to my ISP's rDNS for my subnet. In my authoritative DNS I have selected one of my domains/zones to denote all network interfaces on my servers and other network devices (it's okay, I restrict zone transfers). So even though the public cannot directly get to the machines on my LAN (192.168.1.0/24) or my DMZ (172.16.1.0/24) I have the machines living there defined in my DNS zone (and subzones). I've also defined all my public IP addresses, even though they don't correspond to physical machines (and my definitions match what I've set up for rDNS). For other domains, I use CNAMEs to steer traffic to the appropriate public IP, and then it's pfSense's job to move that traffic to the appropriate DMZ machine.
Maybe I'm blind, but I don't see a way to use FQDNs in pfSense, except through aliases. And if I do use FQDNs in the definition of aliases, they sometimes throw errors (e.g. in 1-1 NAT). And even when error free, when I define aliases (for IP addresses), what I type into pfSense is redundant to what I type into my DNS zone–in other words I'm doing it twice. Yes, I get a shorter name with an alias, which is okay, but not a selling point for me.
Alias to FQDN examples:
vrt -> vrt.mydomain.net.
...
pbo -> pbo.mydomain.net.
vrt_dmz -> vrt0.dmz.mydomain.net.
...
pbo_dmz -> pbo0.dmz.mydomain.net.Typing the longish FQDNs into the virtual IP list, NAT, the firewall rules, etc. is perfectly fine. Why create aliases for A records when A records (or AAAA records) are aliases (of IP addresses) to begin with?
What would be cool beyond compare is if BIND were included with pfSense, AND INTEGRATED INTO THE PFSENSE INTERFACE AND WAY OF DOING THINGS. Then only use pfSense's IP aliases for groups of FQDN's (when you don't want a single FQDN to equate to a group of IP addresses). But everywhere in pfSense when you mean an FQDN, use an FQDN. Of course we'd still need aliases for port numbers. (Oh yeah, and make 1-1 NAT accept aliases [better yet FQDNs] for the WAN address.)
I assume you use Unbound as the integrated caching DNS server. When I say BIND I mean to use it as an authoritative DNS server–not a caching server. Also, it'd be very cool to control which interfaces BIND was active on.
So what do people think: Would it be valuable to integrate an authoritative DNS server into pfSense? Would it be welcome to define names to IP addresses in only one place?
-
There is a BIND package for those who want a full blown DNS server. The built-in DNS Forwarder or Resolver are better suited for the vast majority. You can add hostnames to Forwarder and Resolver. DHCP leases are automatically registered if you enable that option.
FQDNs must be in aliases because of how they're handled underneath. Doing otherwise would introduce a lot of back end complexity with little to no benefit for most all purposes. Some things like 1:1 NAT don't allow the use of such aliases because they can resolve to multiple IPs, which would break the ruleset or potentially introduce other complications.
Was there somewhere you were using aliases with FQDNs that threw ruleset loading errors, or was that just in reference to input validation preventing such configs?
Thanks for the feedback.
-
Thanks for the quick response.
First: Broken 1-1 NAT. Ah-ha, I get it. I tried to use an IP alias as the target for 1-1 NAT, where the alias is defined using a FQDN. That threw an error. There is no way for pfSense to really know what's going on with that FQDN. Yeah, it resolves to a single IP address now… but what about next week? If I go to my DNS zone and add another address, because there's no integration between pfSense and my DNS server, 1-1 NAT would fail as soon as pfSense picked up the new values, and I'd have no clue why.
Okay, I just peeked at it. Seems 1-1 NAT is accepting an alias which is defined using a FQDN. I guess pfSense did a lookup and decided there's only a single IP address behind the FQDN behind the alias. Well dang. What I really want is a load balanced virtual host behind the 1-1 NAT. Gotta try that next.
Second: I'm not going to configure a forwarder or resolver that's accessible from the WAN. What I need is an authoritative DNS for the domain names I control and the information I want to make public, and BIND is a fine choice.
Since a common function when setting up a firewall/edge router is thinking about IP addresses, and giving those addresses memorable handles is useful, a facility like aliases is wonderful. Except we already have DNS to do exactly that thing. Plus DNS must exist (in my case), but aliases are optional. What I really want is integration between BIND and the pfSense web GUI. I want a BIND tab in the web GUI, and I want pfSense to understand and use what I've put in my zones. Putting BIND on the firewall box is okay, but without the integration there's little advantage to doing it that way.
Of course those pfSense users who are not running public hosts, will not need a public authoritative DNS server, and so won't want the complexity of BIND.
Thanks again.
-
What I really want is integration between BIND and the pfSense web GUI. I want a BIND tab in the web GUI, and I want pfSense to understand and use what I've put in my zones.
Yeah. So install the BIND package (already there) and point pfSense to it (already there; frankly, it's absolutely not any different from using dnsmasq or unbound)…
-
That's awesome. I was under the impression the webGUI didn't interface to BIND. I'll give it a shot.
