Linux – Optimizing TTL values for DYNDNS service

domain-name-systemdyndnslinuxnameserverttl

I've finally gotten my own DYNDNS working but I am looking for some advice on optimizing it.

Edit: Basiclly I got a Domain at a registrar that I point to my own nameservers where I keep my own records. I'm using nsupdate to update records. I want users to be able to register, get a subdomain they can point to a device that got a dynamic IP thus making it 'static'.

An example of a dynamic update http://ip.seveas.net/dnsgraph/png/client1.epnddns.com/?skip_.=on&show_A=Show

Basiclly I want to achieve the fastest resolve, if I can call it that. Meaning the least amount of time that a user have to wait after he/she updated their subdomain till they actually can use it/resolve it. Without pushing the server to a halt, think +1000 users. If that makes sense?

So I'm wondering about the TTL values for SOA, my nameservers and what to give dynamiclly created subdomains that users might update quite frequently.

Another question is, in the example about with client1. It seems to resolve fine on other devices or for other users but from my home with the IP that I also used to update the record, it seems rather random if it connects or not. Could it be something funky in my setup or can it have something to do with that I updated the records from my home IP?

my first nameserver values

$ORIGIN .
$TTL 38400      ; 10 hours 40 minutes
mydomain.com             IN SOA  ns3.mydomain.com. admin.mydomain.com. (
                                2880848856 ; serial
                                28800      ; refresh (8 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                38400      ; minimum (10 hours 40 minutes)
                                )
                        NS      ns3.mydomain.com.
                        NS      ns4.mydomain.com.
                        A       66.33.x.x
$ORIGIN mydomain.com.
$TTL 10 ; 10 seconds
client1                 A       75.119.x.x
$TTL 38400      ; 10 hours 40 minutes
ns3                     A       64.111.x.x
ns4                     A       67.205.x.x
www                     A       66.33.x.x

my second nameservers values

$ORIGIN .
$TTL 38400      ; 10 hours 40 minutes
mydomain.com             IN SOA  ns4.mydomain.com. admin.mydomain.com. (
                                2006071806 ; serial
                                28800      ; refresh (8 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                38400      ; minimum (10 hours 40 minutes)
                                )
                        NS      ns3.mydomain.com.
                        NS      ns4.mydomain.com.
                        A       66.33.x.x
$ORIGIN mydomain.com.
$TTL 10 ; 10 seconds
client1                 A       75.119.x.x
$TTL 38400      ; 10 hours 40 minutes
ns3                     A       64.111.x.x
ns4                     A       67.205.x.x
www                     A       66.33.x.x

Other than that, are there other ways to optimize it?

Thanks in advance for any insight or advice given!

Best Answer

You wrote:

I was wondering if there was someone out there who could give me some pointers on optimizing it to get the fastest resolves without pushing the service too much.

Could you be a little clearer about what you are trying to accomplish by adjusting your TTL value?

As I presume you know, the TTL controls (or should control -- not every nameserver actually honors it properly) how long your resource records can stay in the cache of a non-authoritative nameserver.

Clients who are trying to resolve queries for your records will ("may" might be a better way to put it) receive faster resolution if they are able to get an answer from the cache of their local recursing resolver. So in that sense a longer TTL allows other nameservers to cache your RR data longer, yielding a higher probability that clients querying can have their queries satisfied from cache. In this sense, high TTL tends to improve client query resolution speed.

However, you need to balance this against the problem of non-authoritative servers caching incorrect data. When your data changes (for example because you have moved to a different IP address, or changed the target of a record) other nameservers are allowed to cache the old data for up to TTL seconds. So if you are changing your data frequently (e.g. moving to new IP addresses often, or changing the contents of your zone) you will wish to lower your TTL.

As currently specified, your question does not really provide any guidance as to how fast your data changes so it's not possible to usefully advise you more specifically about what TTL values are appropriate. They will depend very much on your use pattern.