DNS TTLs revisited

Robert Gahl bgahl at bawcsa.org
Fri Feb 6 00:44:48 UTC 2004


At 04:02 PM 2/5/2004, Barry Margolin wrote:

>In article <bvuho7$2ath$1 at sf1.isc.org>, Robert Gahl <bgahl at bawcsa.org>
>wrote:
>
> > Thus my question: Do earlier versions of BIND lack the ability to 
> recognize
> > the specific setting of TTLs on individual hosts?
>
>This is a meaningless question.  That's the *only* place that TTLs
>exist.  If they didn't recognize this, they wouldn't recognize TTLs at
>all, since there are no other TTLs to recognize.

I'm sorry it is meaningless. It was the only way I knew to phrase it.

>The "default TTL" of the zone is not communicated at all in the DNS
>protocol, it's only a syntactic convenience used when named parses the
>zone file.  There's absolutely no way for a client of the server to tell
>the difference between explicit per-record TTLs and TTLs inherited from
>the default.

Thanks. This does help me understand it a bit better.

>Are you sure that your changes have propagated to all your slave
>servers?  And how long after you changed the TTL on the record did you
>do your tests?  If it was less than the old TTL, then you're just seeing
>records that are still in the caches, because the old TTL allowed them
>to stay around for a day.

I haven't made a change in months (until today). That is what is so 
confusing. Here is an example (and, granted, it isn't like running "dig" on 
a remote site, but you'll get the idea):

>web <bgahl>: dig ssl-hints.netflame.cc
>
>; <<>> DiG 8.2 <<>> ssl-hints.netflame.cc
>;; res options: init recurs defnam dnsrch
>;; got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
>;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
>;; QUERY SECTION:
>;;      ssl-hints.netflame.cc, type = A, class = IN
>
>;; ANSWER SECTION:
>ssl-hints.netflame.cc.  30S IN A        63.146.119.84
>
>;; AUTHORITY SECTION:
>netflame.cc.            18h26m5s IN NS  ns2.netflame.cc.
>netflame.cc.            18h26m5s IN NS  ns1.netflame.cc.
>
>;; ADDITIONAL SECTION:
>ns1.netflame.cc.        18h26m5s IN A   65.200.204.52
>ns2.netflame.cc.        24m25s IN A     63.146.119.80
>
>;; Total query time: 5 msec
>;; FROM: web to SERVER: default -- 63.146.119.75
>;; WHEN: Thu Feb  5 16:39:43 2004
>;; MSG SIZE  sent: 39  rcvd: 123

This is correct. It is what I expect. However, go to this link:

http://ntcanuck.com/net/tools/dig/index.php?dns=&qry=ssl-hints.netflame.cc&cls=IN&typ=ANY&cmdQuery=Query

It sure doesn't say 30 seconds.

At any rate, the answer is, all bind versions get the TTL they should. Why 
our remote customer (and this link, which is unrelated to them) get 
something altogether bogus is, well, bogus. That was the answer I was 
hoping to get (i.e., I haven't done something wrong).

Again, I apologize for jumping ahead on resolving this problem by assuming 
there was a problem in TTL interpretation. There isn't. Whatever the 
problem is, it's not how I've defined the TTLs.

Thanks for your patience.


===
Bob Gahl Bicycle (Ryan Vanguard) Mobile ||     @
     ARPA/Internet: bgahl at bawcsa.org     ||  !_ \
    URL: http://www.bawcsa.org/bgahl/    ||  (*)-~--+--(*)
"Sahn joong moe low ful how jee yah ching wong" - "When the
mountain has no tigers, the monkey will also declare himself
king." Chinese Proverb



More information about the bind-users mailing list