2

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!

2 Answers 2

2

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.

1
  • I tried to make my question a bit more clearer and added a follow up question please tell me if I should add some more information.
    – Thuy
    Nov 13, 2012 at 7:31
0

I would expect this is for a relatively low volume case. Servers which need high volumes of reliable DNS lookups belong on a static IP address. If so, tuning TTLs shouldn't be that important.

It is difficult to give good advice with partial information. The following responses have worked for me. As I only have limited information, the answer may not be appropriate in your case.

In choosing a TTL for this case, I would look at the TTL on the source of the IP address. If you are using DHCP with a lease of over a minute or two a TTL of 10 seconds could be extreme.

If you are providing an internal DYNDNS service for DHCP clients, a TTL half or a quarter of the Lease time. Your TTL for an externally facing service getting its address dynamically, you may want a shorter TTL.

Factors to consider will be where the data will be cached, how frequently address changes will occur, and how important that there be no discontinuity of service. You should also consider where misdirected connections may land. Internal to the organization or dead addresses are likely less of a concern, than an server on the Internet that you have no control of.

EDIT:: Whatever TTL you specify some DNS servers will ignore it an cache for their own TTL. I believe this is more likely to occur with shorter TTLs. A few years ago there was a rash of botnets using fast-flux DNS to try to avoid detection. I did see reports that ignoring short TTLs and caching for a longer time was one approach used to deal with these servers.

You also need to deal with negative caching. Bind 9 uses the minimum TTL as the negative cache period. (In your case, this appears to be 10h40, which is far longer than your positive TTL.) For a dynamic service you likely want them the same.

I would expect your clients to fall into three classes (who may have different needs):

  • Users with rather stable IP addresses, and are running public services on dynamic IPs resulting in relatively frequent DNS queries.
  • Users with rather stable IP addresses, who occasionally access there servers remotely.
  • Road warriors who are often disconnected, but who wish to be reachable when connected.

Determining which types of users you have can be done my monitoring queries and updates to your DNS. It will take time to determine this kind of data. Of importance in determining TTL is determining how long after the last query an update occurs. Examining this value over time may help determine a reasonable TTL. Examining query frequency and source IP distribution versus update frequency may also be helpful. This is data which you can use to tune your TTL value(s) over time.

2
  • I added some more information and added a follow up question please tell me if I should add some more information.
    – Thuy
    Nov 13, 2012 at 7:32
  • @Thuy Updated my response. The differences you see from home may be either negative caching, or the positive TTL value being substituted. Check the TTL value you see when you do a host name look-up.
    – BillThor
    Nov 14, 2012 at 6:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .