How do I reliably track a remote host which is using Dynamic DNS?
-
I'm getting very spotty performance out of the captive portal with tracking some hosts which use dynamic dns. These hosts use rapid changes (at most every 5 minutes, sometimes as little as one minute). Here's what I've done so far to try to alleviate the problem:
My name server is running a crontab which updates the IP addresses every minute (radical, I know, but it seems to be necessary).
I have also had my primary name server update it's hosts file (ubuntu which looks at the hosts file first, although I made sure of this with a hosts directive at the top of resolv.conf). I've verified that the server updates itself. This should provide up to the minute information for the captive portal to use in resolving hostnames, but this is not always the case as near as I can tell.I've made sure that pfsense is using the name server first. I have also tried having pfsense use localhost first, but that seemed to actually worsen the situation.
As you all can tell, I'm a little lost here. I would greatly appreciate any suggestions anyone has.
-
Forgive me for not helping, but you have a host that changes its IP address every 1-5 minutes?
I just need to wrap my head around this. They are using a dynamic DNS service to remap the IP address to DNS at that rate? What's the TTL they assign their domain name when it is written to the DNS provider's system?
I'm not sure what the business or technical reason for changing your IP that frequently is, but it breaks a lot of stuff (as you've discovered), it really isn't the way DNS should be implemented, and generates a lot of unnecessary DNS queries.
You're really playing a game of chase to get the current IP address. If you know the dynamic DNS service that these servers are using, I would use their name servers as your primary name servers and query them. You're at the mercy of their TTL, so if it's set for an hour, you're only going to get an update each hour unless you flush your DNS (like you're doing) in a cron job.
Again, I apologize, but I'm still trying to wrap my head around the "why" part of the implementation.