Domain name resolution not checked by updatedns() routine
-
I recently had a disconcerting event with pfSense and DynDNS. I'm running the 2.0.1-RELEASE of PfSense and have a free account with DynDNS.com (or I suppose dyn.com these days). I'm using the "DynDNS (dynamic)" option as the service type in the pfSense Dynamic DNS client.
I rebooted my firewall to check some bios settings and apparently I was offline long enough that my cable ISP re-assigned my IP to another customer. I didn't realize this initially and made some additional changes to the firewall rules. Periodically, and especially after any rules changes, I conduct basic tests to ensure everything is still appropriately locked down. To my surprise, my firewall was now responding to ICMP requests. After some checking, I ran nslookup and realized my domain name was still linked to my old IP and the DynDNS registration hadn't been updated (even though the routine clearly ran on startup per the system logs). I was pinging another machine that had been given my old address. I tried forcing an update by going to the Dynamic Service page on the webGUI, changing a few things, changing them back & clicking Save. While this caused the updatedns() routine to run, no action was taken since 25 days hadn't passed since the last update. In the end, I logged into the DynDNS site and manually updated my IP.
I've seen other threads discuss adjusting the cron settings, but wouldn't this only makes the routine decide that nothing needs to be done at more frequent intervals (if the 25-day limit hadn't been reached)?
My point in raising this issue isn't whether or not the pfSense dyndns routine correctly updated my registration with my newly-assigned IP on startup. While this is clearly a concern, I have no way to refute that this didn't happen because the free version of DynDNS doesn't include logs. I'm trying to determine whether this is truly a nefarious act, or something else I have yet to discover.
My point, or rather request, is for the pfSense updatedns routine to incorporate a nslookup or dig command in addition to comparing the current WAN IP with the cached version. From what I can tell, there's no check of the IP currently associated with the domain name. Wouldn't this be a good security feature to add to pfSense? Wouldn't a log entry noting that the DNS registration changed and it wasn't by pfSense be useful? Or perhaps the scrolling yellow banner at the top of the webGUI to better draw attention?
-
Does your WAN interface have a public IP address or a private IP address (e.g. 192,168.x.y)?
I rebooted my firewall to check some bios settings and apparently I was offline long enough that my cable ISP re-assigned my IP to another customer. I didn't realize this initially and made some additional changes to the firewall rules. Periodically, and especially after any rules changes, I conduct basic tests to ensure everything is still appropriately locked down. To my surprise, my firewall was now responding to ICMP requests.
Sounds like an issue with your firewall rules.
After some checking, I ran nslookup and realized my domain name was still linked to my old IP and the DynDNS registration hadn't been updated (even though the routine clearly ran on startup per the system logs).
Name registration changes take a while to trickle through to all name servers.
I was pinging another machine that had been given my old address.
The ICMP response you mentioned earlier was to you ping yourself by hostname, not by IP address?
I tried forcing an update by going to the Dynamic Service page on the webGUI, changing a few things, changing them back & clicking Save. While this caused the updatedns() routine to run, no action was taken since 25 days hadn't passed since the last update.
The last time I looked at this the DNS update attempt is always made on startup and afer 25 days and after the public IP address has changed (but if the monitored interface has a private IP address an address check is made daily at 2AM).
Unless I have missed something, what you have observed could be a consequence of the (to be expected) delay in propagation of name registration changes - for example it takes some time for changes in registration at dyn.com to be observed at the DNS you are using (even if it is also dyn.com).
-
wallabybob, thanks for the reply!
My WAN interface has a public IP address: 24.217.x.y
Correct, the ICMP response I mentioned earlier was a ping to my hostname. Once I figured out what was going on, I pinged my newly assigned IP address directly and everything was as it should be (e.g. firewall rules were okay and my pfSense machine wasn't replying to pings).
Hmmm, the name registration propagation delay was something I hadn't considered. Are we talking seconds, minutes or hours? I suppose since I'm using the free service I'm not at the top of the priority list for changes. If this is the case, it be nice if Dyn highlighted this difference between their free and paid services.
-
Hmmm, the name registration propagation delay was something I hadn't considered. Are we talking seconds, minutes or hours?
If I recall correctly, one of the FAQ style pages on Dyn.com or OpenDNS.com suggested it could be of the order of minutes rather than hours. But I think that was for name changes to propagate to their own servers. It could take longer for changes to become visible in other servers.