Link to home
Start Free TrialLog in
Avatar of Mike Paradis
Mike Paradis

asked on

Device browser and/or dns client cache update through web page

Let's be clear that I am not asking about DDNS services since I know what they are.
My question is much more specific.

In fact, this URL explains all the basics and the issues to expect with standard DNS services.
https://www.godaddy.com/help/what-factors-affect-dns-propagation-time-1746

In our case, we have devices which can change IPs very quickly so use DDNS servers of our own. Basically, we have custom DDNS servers which auto update the DNS records.

No matter how the DNS server is updated, the DNS record will take time to propagate around the Internet.

One trick might be to put our DNS server(s) as the first to query but then they end up being used for everything and not the one single use we need them for.

Another might be to give the user a web page to query, to somehow update their local dns as quickly as possible.

The point would be to somehow update their devices DNS (browser, then local DNS client) cache with the current IP for the domain/DNS record in question. Basically a web page that would somehow update their browser/DNS client caches rather than a DNS server hit. In our case, users don't care for the DNS record to propagate across the Internet, they just need to reach the URL by name when the IP has changed, but, as quickly as possible without having to type in the IP.

Other than TTL settings, the question is, are there any other tricks for getting the propagation out as quickly as possible without overloading servers.
Avatar of footech
footech
Flag of United States of America image

Nope, there are no other tricks to reduce DNS propagation time.

Approaching this from a different angle, you could probably create some stable resource like a web page or load balancer type device (like an F5) that would be reached by a non-changing DNS record and would then redirect or do a URL rewrite with an up-to-date IP.

I wouldn't be able to describe what the scripting for the web page would be like (not my area of expertise) but I'm sure it's possible.

A device like an F5 has a ton of traffic routing capabilities.  My experience with them leads me to believe they could handle a scenario like this, but I couldn't guide you further in specifics.
Other than TTL settings, the question is, are there any other tricks for getting the propagation out as quickly as possible without overloading servers.

Lower the TTL. When you're dealing with services like AWS RDS you'll be looking at really low TTL's. They would recommend at most 30 seconds, but if you talk to the AWS 3-5 second TTL is best for RDS fail overs to prevent apps falling over. Everything with DNS propagation comes back to a record's TTL (unless you're talking about registrar changes for NS/WHOIS records). The scenario where GoDaddy talk about ISP's overriding TTL's, it might be done by some places, but it would be very rare. In this day and age I can't say I've seen an ISP tight enough to do it.

So, set a low TTL, and you'll be fine. In what way are you worried about overloading a server? The DNS server? Your server?
If the users which access your service are limited from where they access (for example, they all access from within another company), it's possible for that company to set up a stub zone or conditional forwarder for your domain on their DNS servers.  Clients in that company would then be using their own DNS, but queries for your domain would get resolved by your DNS servers.

However, if users access your service from all over the internet, that wouldn't help.
Avatar of Mike Paradis
Mike Paradis

ASKER

@Learnctx
>So, set a low TTL, and you'll be fine. In what way are you worried about overloading a server? The DNS server? Your server?

The best scenario would be where we host the DNS records but they get pushed out to something that can propagate them faster than we could. We don't want those users to end up having to use our own DNS servers.

@footech
Yes, the users would be all over the net.

>Approaching this from a different angle, you could probably create some stable resource like a web page or load balancer
>type device (like an F5) that would be reached by a non-changing DNS record and would then redirect or do a URL rewrite
>with an up-to-date IP.

That is closer to what I'm interested in. The user goes to a static web page (non changing FQDN) and clicks on their device ID, which in turn redirects them to the device using what ever its current IP is.

In this case, there is almost not even a need for a DNS server, or even if needed, would not matter if the propagation took a while, we would just need some kind of redirection method from a web page.

Does the browser cache the IP of a domain name or is that cached on the devices DNS? I think it is the later but the trick would be if we could update those things instantly to redirect to the correct IP.
I think I have most everything figured out. The only thing I'm not sure about is the following.
I would want to update the records on our DNS servers but do not want public to use them and instead, want to propagate our records out as quickly as possible.

Because of the number of entries, I would also need a DNS server which has it's records in mariadb for example.
In this case, I prefer something Centos based, open source. Looks like this isn't all that difficult, MyDNS, PowerDNS and others all seem to provide database backends and automatic reloads without having to restart the server.

The rest can be solved easily.
ASKER CERTIFIED SOLUTION
Avatar of footech
footech
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
MY last comment was mainly that using a db based dns server that doesn't need to be restarted would be one way of taking care of the problem, though, unrelated to propagation speed in the original question. You already answered that part too. I didn't expect there would be but sometimes, it's better to ask others and see if they have come across something you might never have.

Either way, it seems all I really need is a redirect method. Dns and a redirect might be the answer.