Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I setup a local name server (BIND on OS-X) and was pleased that 'dig' response times were very short (2nd query onwards). However, if I wait a short period (5s) the response time goes up again - the request is once more being forwarded to the remote server (OpenDNS). I guess the TTL is short but I don't see a TTL value in the dig response. Where can it be found? Is it likely to be short for most web servers and does this negate any advantage from having a local server?

My DSL modem (from Huawei) must be ignoring the TTL as its responses (using dig @192.168.1.1 etc) are a few ms even after waiting many minutes bewteen requests, against several hundred ms when my local server has to forward the request. Is this common with such modems or just chinese ones? My initial interest in using a local server was a desire for faster browsing and a suspicion of chinese products. Am I paranoid in the latter?

Update

The questions were based on the false premise that the TTL was very short. Now that I know where the TTL is shown in the dig output, I can see that it is not short enough to be the cause of the local server re-requesting the upstream server. Any ideas on the cause of this would be welcome. Also it is evident that the modem is not ignoring the TTL. I still don't trust it though...

share|improve this question
    
How do you know that BIND is making a second back-end query? What did you watch, and how? Don't build hypotheses based upon nothing but assumptions. Collect data first. Read server logs. Watch network traffic. Dump caches. –  JdeBP Jan 31 '12 at 13:49
    
@JdeBP: thanks! I doubted you, but you are right. I unplugged the Ethernet cable and tried digging ibm.com again. To my surprise, this had the same result; hundreds of ms response time the first time and a few ms if repeated quickly. I imagine there is some disk access going on that is slowing it down - but there I am jumping to conclusions again. (Interestingly, ping can't resolve ibm.com with the cable unplugged, implying that it is not using the local server!) –  William Morris Jan 31 '12 at 16:11
add comment

3 Answers

The dig utility displays the TTL value by default. Here is a sample output:

khaled@khaled-pc:~$ dig www.google.com

; <<>> DiG 9.7.1-P2 <<>> www.google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1350
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;www.google.com.            IN  A

;; ANSWER SECTION:
www.google.com.     64131   IN  CNAME   www.l.google.com.
www.l.google.com.   109 IN  A   209.85.147.147
www.l.google.com.   109 IN  A   209.85.147.99
www.l.google.com.   109 IN  A   209.85.147.103
www.l.google.com.   109 IN  A   209.85.147.104
www.l.google.com.   109 IN  A   209.85.147.105
www.l.google.com.   109 IN  A   209.85.147.106

;; AUTHORITY SECTION:
google.com.     32366   IN  NS  ns4.google.com.
google.com.     32366   IN  NS  ns3.google.com.
google.com.     32366   IN  NS  ns1.google.com.
google.com.     32366   IN  NS  ns2.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.     236936  IN  A   216.239.32.10
ns2.google.com.     236936  IN  A   216.239.34.10
ns3.google.com.     236936  IN  A   216.239.36.10
ns4.google.com.     236936  IN  A   216.239.38.10

You can use the option +ttlid to include TTL values and +nottlid to NOT include them. The TTL value is the one before IN in each row.

share|improve this answer
    
Thanks. There must be some other reason for the request being repeated so soon. Actually it is more like 5s, not the 10-20s I stated earlier - edited above. –  William Morris Jan 30 '12 at 15:32
add comment

It's not normal to have a short TTL for servers. Some people use those short TTLs as a failover technique, but most people have gone in a different direction these days.

You'll find the TTL right before the IN A section:

15:05:35 root@oxygen:~> dig example.com

; <<>> DiG 9.5.1-P1 <<>> example.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15248
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;example.com.           IN  A

;; ANSWER SECTION:
example.com.        172800  IN  A   192.0.43.10

;; AUTHORITY SECTION:
example.com.        172800  IN  NS  b.iana-servers.net.
example.com.        172800  IN  NS  a.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net. 265 IN  A   199.43.132.53
b.iana-servers.net. 265 IN  A   199.43.133.53

;; Query time: 115 msec
;; SERVER: 84.91.3.120#53(84.91.3.120)
;; WHEN: Mon Jan 30 15:05:41 2012
;; MSG SIZE  rcvd: 125
share|improve this answer
    
Thanks. There must be some other reason for the request being repeated so soon. Actually it is more like 5s, not the 10-20s I stated earlier - edited above. –  William Morris Jan 30 '12 at 15:35
add comment

Most DSL router / modems don't cache DNS answers, they just proxy queries directly to the ISPs resolvers.

So the delay you're seeing there is simply round-trip-time to your ISP.

share|improve this answer
    
the modem is set to resolve using OpenDNS, not the ISP. I guess it is caching, as the second and subsequent calls to "dig ibm.com" with the modem condigured as the computer's DNS server are in the 3-30ms range while the first is in the 150-500ms range (round trip to OpenDNS). With only response times to go on, this is just speculation, of course :-) –  William Morris Feb 1 '12 at 13:43
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.