Dynamic DNS with a Custom Domain

Landmine

Limp Gawd
Joined
Oct 19, 2011
Messages
402
What is the best service out there for running a dynamic dns setup with a custom domain.

For example:
Primary Domain: mydomain.com
Dynamic Domains:

1234MainSt.mydomain.com
1234Broadway.mydomain.com

I'd love to install a tray app and allow it to update a subdomain to the dynamic ip address. This service could save me a lot of money since currently we pay for static ip's. We are looking for around 100 subdomains.
 
What services are you running that need to be publicly accessible? I only ask because moving from static to dynamic will introduce some TTL issues that you should be aware of. Essentially, the best you can say is that your hosts will "eventually" resolve correctly.

I've used dyndns for my work, and it did a pretty good job. Haven't used it in a while though, so keep that in mind.
 
We have very basic building monitoring systems that run on port 80 (Apache Webserver)

Also, as a side not, disabling the client from access any other domain is key as these computers are often placed in insecure locations. So the computer that belongs to a single subdomain can only edit and update the single subdomain it belongs to.
 
TTL is a non-issue in the modern internet era, and "resolve eventually" is quite a bit of FUD...

http://dyn.com/dns/dyn-standard-dns/

They make their own updater that sits in the tray and will only update the subdomain it's configured to update.

Done.

Next?
 
TTL is a non-issue in the modern internet era, and "resolve eventually" is quite a bit of FUD...
Is it? Basic DNS principles would suggest it'd be a difficult problem to solve, so I'd love to hear how someone figured it out. Unless they set the TTL to something ridiculously low like 5 seconds. But that'd cause massive load on their infrastructure.

I ran into the issues this past weekend with some host migrations; the TTLs on the records were set to 3 hours, so it took a while for the name changes to propagate.

EDIT: Found this: http://dyn.com/blog/dyn-tech-everything-you-ever-wanted-to-know-about-ttls/ which suggests TTL considerations are not so much "FUD" as a...um.."consideration". So yes, if you are dealing with dynamic hosts then you will have a "resolve eventually" situation ( be it 6 seconds, 60 seconds, 60 minutes...whatever you set your TTL to + caching time of your DNS hop ).
 
Last edited:
Get a DNS provider with hidden primary support and run your own local auth DNS that you can update using regular RFC2136 updates.
 
Is it? Basic DNS principles would suggest it'd be a difficult problem to solve, so I'd love to hear how someone figured it out. Unless they set the TTL to something ridiculously low like 5 seconds. But that'd cause massive load on their infrastructure.

That's the thing though, they solved the problem. If you know the IP address is going to change often, you set the TTL low and you have an update client. Simply be aware of how often your updater changes and you take that and add a TTL for good measure and you have a pretty damn good idea how long it's going to be down. Using Dyn's updater and a 60 second TTL, if I have an IP change, I expect 11 minutes of downtime max. I move along with my life during that time. Or, if I really care, I can run inadyn or another update client and tweak the check interval to be faster.

Super low TTLs are great. They really don't cause a massive load on infrastructure because most people who have dynamic IPs are not running huge sites, and don't have large number of people attempting to reach their sites. Even huge sites that have low TTLs and massive query counts aren't a big deal - it's DNS. Single servers handling 50K+ queries per second is common. Hell, my VPS can handle 20K queries per second.. Besides, with low TTLs your DNS can change quickly if something bad happens (DNS based loadbalancing and failover and other advanced features come to mind)

By and large people who use dynamic DNS are hosting their own stuff at home, or are using security cameras they want to access remotely.

I ran into the issues this past weekend with some host migrations; the TTLs on the records were set to 3 hours, so it took a while for the name changes to propagate.

You had problems because you didn't prepare for your migration properly. Sorry.
You should have set your TTL to 60 seconds or lower in preparation for the move.

EDIT: Found this: http://dyn.com/blog/dyn-tech-everything-you-ever-wanted-to-know-about-ttls/ which suggests TTL considerations are not so much "FUD" as a...um.."consideration". So yes, if you are dealing with dynamic hosts then you will have a "resolve eventually" situation ( be it 6 seconds, 60 seconds, 60 minutes...whatever you set your TTL to + caching time of your DNS hop ).

What, precisely, is a "DNS hop"?

Your "resolve eventually" is just the remainder on your TTL from your recursive server.

Code:
dig domain.tld @yourdnsserver

This will give you the remainder of the TTL. It's not an "eventually" thing. It's a very precise thing that you can measure.

Long and short is, your name will resolve within a TTL of your update client sending the update and it getting pushed to edge. Assuming your TTL isn't set stupidly high for a dynamic IP (over 60s), then you're in business.
 
Get a DNS provider with hidden primary support and run your own local auth DNS that you can update using regular RFC2136 updates.

I'm not aware of any RFC2136-capable tray clients for windows machines as the OP was looking for. Do you know of any?

Through googling I found GnuDIP, which looks like it .. might? work with a windows client for this application, but I'm pretty sure it's more designed for ISPs with one network.
 
What's the mechanism that Windows itself uses if you check "Update DNS" in network properties?

Edit: Nevermind, brainfart. Cygwin+nsupdate and some tray tool? No idea. This belongs on the router not a client.
 
That's the thing though, they solved the problem. If you know the IP address is going to change often, you set the TTL low and you have an update client. Simply be aware of how often your updater changes and you take that and add a TTL for good measure and you have a pretty damn good idea how long it's going to be down. Using Dyn's updater and a 60 second TTL, if I have an IP change, I expect 11 minutes of downtime max. I move along with my life during that time. Or, if I really care, I can run inadyn or another update client and tweak the check interval to be faster.

Super low TTLs are great. They really don't cause a massive load on infrastructure because most people who have dynamic IPs are not running huge sites, and don't have large number of people attempting to reach their sites. Even huge sites that have low TTLs and massive query counts aren't a big deal - it's DNS. Single servers handling 50K+ queries per second is common. Hell, my VPS can handle 20K queries per second.. Besides, with low TTLs your DNS can change quickly if something bad happens (DNS based loadbalancing and failover and other advanced features come to mind)

By and large people who use dynamic DNS are hosting their own stuff at home, or are using security cameras they want to access remotely.



You had problems because you didn't prepare for your migration properly. Sorry.
You should have set your TTL to 60 seconds or lower in preparation for the move.



What, precisely, is a "DNS hop"?

Your "resolve eventually" is just the remainder on your TTL from your recursive server.

Code:
dig domain.tld @yourdnsserver

This will give you the remainder of the TTL. It's not an "eventually" thing. It's a very precise thing that you can measure.

Long and short is, your name will resolve within a TTL of your update client sending the update and it getting pushed to edge. Assuming your TTL isn't set stupidly high for a dynamic IP (over 60s), then you're in business.
Not quite sure what the argument here is, as you are basically agreeing with what I said, although I can see you are desperate to differentiate your perspective somehow and make my post wrong.

I said that there might be some TTL issues, and that the hosts will eventually resolve correctly. You are saying...basically the same thing. Which, incidentally, you called FUD. So I am understandably confused by your behavior.

Oh, and as for "hop": The DNS servers that the host information is configured on is not the same as the DNS server your workstations are set to use for lookups. ie: "hop". Sometimes, tragically, there will be more than 1 hop, and each properly configured server in the resolution chain will cache per the TTL. So when 3 servers are involved with a 60s TTL, you could have a situation where it doesn't resolve correctly for up to almost 4 minutes ( 3 servers + workstation caching ) ( as an example ).
 
Oh, good, Snarkiness! This always helps...

DNS is a black art to many, so any illumination on the subject can only help.
 
Not quite sure what the argument here is, as you are basically agreeing with what I said, although I can see you are desperate to differentiate your perspective somehow and make my post wrong.

I said that there might be some TTL issues, and that the hosts will eventually resolve correctly. You are saying...basically the same thing. Which, incidentally, you called FUD. So I am understandably confused by your behavior.

Oh, and as for "hop": The DNS servers that the host information is configured on is not the same as the DNS server your workstations are set to use for lookups. ie: "hop". Sometimes, tragically, there will be more than 1 hop, and each properly configured server in the resolution chain will cache per the TTL. So when 3 servers are involved with a 60s TTL, you could have a situation where it doesn't resolve correctly for up to almost 4 minutes ( 3 servers + workstation caching ) ( as an example ).

Not really an argument - making sure everyone has accurate information, that's what we're here for. It's pretty simple. DNS isn't a black art. It's not "eventually" - being informed can tell you when it's going to happen. It's when your resolver's cache clears or the record is updated, and knowing the behavior of the system or using tools available will tell you when this will be.

Are you trying to say that someone would have 3 nested, caching recursive forwarders? I mean ... sure, you can do that, but it's simply doing it wrong.

I mean, what you describe can happen if someone has multiple separate cut zones below the domain, but TTLs generally never change for anything above the domain. Dynamic DNS only affects the subdomain, not the dot, not the TLD, not the delegated nameservers.

The dot has a two day TTL, as do TLDs. The TTLs and the IPs don't really change. (well, they do, but it's an extraordinary occasion when they do)
Your delegated nameservers can change but they also have a 2 day TTL, regardless of what you do. (your apex NS records in the zone file are ignored by the chain)
Your delegated nameservers have the last and final say in what the TTL is going to be. Your recursive resolver, local dns client (part of OS) or web browser can also decide to ignore that number, too, but that's "not my problem" - there are documented numbers for this as well.
 
What's the mechanism that Windows itself uses if you check "Update DNS" in network properties?

Edit: Nevermind, brainfart. Cygwin+nsupdate and some tray tool? No idea. This belongs on the router not a client.

I agree it belongs on a router.. but I've only seen two implementations of 2136 on routers and they were both broken as shit (Apple and Westell).

Update DNS in Windows only works with the DHCP server, not the nameserver itself, pretty sure.
 
mwarps said:
Not really an argument - making sure everyone has accurate information, that's what we're here for. It's pretty simple. DNS isn't a black art. It's not "eventually" - being informed can tell you when it's going to happen. It's when your resolver's cache clears or the record is updated, and knowing the behavior of the system or using tools available will tell you when this will be.
Ah, I see the problem; you don't know what "eventually" means. Not sure how that's "FUD" necessarily, but maybe you don't understand that word either.
 
Last edited:
Back
Top