Dynamic DNS *SERVER*?

rcfa

Is there any support (planned) in pfSense for SERVING dynamic DNS records?

In particular I have the following scenario in mind: several pfSense boxes build a VPN. One of them has a permanent, fixed IP address, the others are configured with DHCP.

Since all of them are (potentially) remote, it's key that they can be administered remotely, for that I want to be able to use host names within my own domain, for which I already serve all the DNS up myself.
It would be rather convenient if the pfSense box with the fixed IP address would act as primary DNS server, and the other units could update their IP address as needed. All of them would be accessible by their regular host names.

The update protocol from the POV of the dynamic DNS client should be industry standard, i.e. work with a variety of publicly available update tools. The server side doesn't have to be ISP grade, i.e. since this is my internal infrastructure, there's no need for separate user accounts and all that sort of stuff, but of course, if it were there, it wouldn't hurt either.

Is anything like this hidden in pfSense, planned, or are there things that could be easily added? A google search revealed GnuDIP (which maybe someone has adapted/installed on pfSense) but that's as far as I have gotten so far. I rather ask than reinvent the wheel….

jimp

There is a standard, RFC 2136, and pfSense supports that as a client :-)

It isn't supported now, but if you use bind or some other DNS server that would supports receiving RFC 2136 updates from clients it could work for hostnames on your own domain.

Also I have my domains hosted with namecheap, and there is a namecheap dyndns client in pfSense 2.0, so that's how I use my own hostnames in some cases. In others I use CNAMEs to the actual hostnames, such as:

boxa.example.com -> CNAME boxa.dyndns.org

And then when I go to boxa.example.com it follows the trail and finds the real IP.

rcfa

I was thinking of using CNAME entries with some junk domain offered by DynDNS, however, what's the issue on TTL with CNAMEs? Do the TTL values specified for the domain hold, or do CNAMES always get dynamically resolved, and thus use the TTL that's supplied by the junk domain's DNS server, i.e in this hypothetical case, by DynDNS?

In other words, if I have fwGateway.example.com pointing to trash.dynDNS.com, and example.com lists a TTL of 123456, and dynDNS.com lists a TTL of 30, which of the two applies if a machine resolves fwGateway.example.com twice within e.g. 3600 seconds?

My setup is in so far a bit more complicated, as I have publicly known DNS servers that host the DNS for my domain. The problem is, that due to my primary ISP's unwillingness to route my class-C network, the entire public class-C net I have is routed through a VPN to a co-hosting location where the other endpoint of that VPN is.

So even though I host my own DNS for my primary domain e.g. example.com, I need a secondary domain, e.g. example.net to supply the DNS info for my VPN network infrastructure, and at least one or two machines that are part of that have dynamic addresses, while the main hub at the colocation provider has a fixed IP. So if that machine, which is going to run pfSense, could serve according to RFC 2136 rather than be just a client according to that RFC, I wouldn't have to rely on a variety of external providers, since I like to keep as much of the infrastructure under private control.

A major internet outage aside, I'd like to be the only person I have to yell at when things don't work the way they should ;)

Now, you mention bind. I thought there's a bind package for pfSense. Does that mean if I install that, it should work?

jimp

There is no bind package for pfSense. There is an unbound package, and a tinydns package, but neither of those support RFC updates like that.

I have never had any problems doing my CNAME method, I believe the TTL of the last A record is respected, so if the example.com domain had a high TTL that only controls the CNAME response, not how long the next hop in the chain of records is held.

My updates are nearly immediate, even though the TTL on my domain is rather long by comparison.

rcfa

Thanks for the info. Doing the extra level of indirection isn't perfect, but at least I can keep my configuration data mostly independent from third party stuff, such that in the case of any changes I only need to alter a CNAME entry and not a bunch of VPN configurations.

Would be great, though, to have server side RFC 2136 support at some point in the future…