DNS Bind - DNS TTLs revisited

Author

DNS TTLs revisited

Robert Gahl

2004-02-05, 6:33 am

My company is the holder of the domain netflame.cc

While the TTL on the domain has been set to 24 hours, we have set an
individual TTL on one particular machine (ssl-hints.netflame.cc) to 30 seconds.

My question is this:

Does this play well across all DNS? I haven't done this until 9.x, so I
don't know about version 8 or, for that matter, version 4. Is there a
version out there where they only take the domain value (1 day) rather than
the individual value (30 sec)?

Thanks.

===
Bob Gahl Bicycle (Ryan Vanguard) Mobile || @
ARPA/Internet: bgahl@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

David Botham

2004-02-05, 6:33 am

bind-users-bounce@isc.org wrote on 02/05/2004 02:25:15 PM:

quote:

> My company is the holder of the domain netflame.cc
>
> While the TTL on the domain has been set to 24 hours, we have set an
> individual TTL on one particular machine (ssl-hints.netflame.cc) to 30

seconds.

quote:

>
> My question is this:
>
> Does this play well across all DNS? I haven't done this until 9.x, so I
> don't know about version 8 or, for that matter, version 4. Is there a
> version out there where they only take the domain value (1 day) rather

than

quote:

> the individual value (30 sec)?

Reality is that, regardless of how you configure your zone db file, all RR
always carry an explicit TTL.

Dave...

quote:

>
> Thanks.
>
> ===
> Bob Gahl Bicycle (Ryan Vanguard) Mobile || @
> ARPA/Internet: bgahl@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
>
>

Robert Gahl

2004-02-05, 8:33 am

At 11:51 AM 2/5/2004, David Botham wrote:

>bind-users-bounce@isc.org wrote on 02/05/2004 02:25:15 PM:
> seconds.
> than
>
>Reality is that, regardless of how you configure your zone db file, all RR
>always carry an explicit TTL.

So, then, I assume that reversing my logic would be a good thing? That is,
set the default to 30 seconds and then explicitly set each and every (but
non-applicable to this situation) IN A record to 86400 seconds, so in the
event that someone isn't seeing the individual TTL values, they are picking
the right default value (30 seconds).

Gads, this bothers me to do this

I will, but I don't like it.

===
Bob Gahl Bicycle (Ryan Vanguard) Mobile || @
ARPA/Internet: bgahl@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

David Botham

2004-02-05, 8:33 am

bind-users-bounce@isc.org wrote on 02/05/2004 04:55:19 PM:
> At 11:51 AM 2/5/2004, David Botham wrote:
>
>
30[color=blue]
so I[color=blue]
a[color=blue]
rather[color=blue]
RR[color=blue]
>
> So, then, I assume that reversing my logic would be a good thing? That
is,
> set the default to 30 seconds and then explicitly set each and every
(but
> non-applicable to this situation) IN A record to 86400 seconds, so in
the
> event that someone isn't seeing the individual TTL values, they are
picking
> the right default value (30 seconds).

No. What I was trying to say is that when you configure a zone database
file, you use a $TTL statement to set the default TTL for every RR in the
zone where one is not explicitly stated.

When the name server loads the zone, it inserts each RR into memory with
an explicit TTL on it (if you were able to look into memory, you would see
this).

Another place to see this effect is to look at the backup file of a slave
zone. You will notice that regardless of how you typed the information
into the master zone database file (by using the single $TTL directive),
each and every RR in the backup copy of zone on the slave has an explicit
TTL.

In the end, if you want a TTL of 30 seconds set for just one RR, then,
explicitly state one for that RR and use the $TTL directive for the rest.

You may be interested in reading RFC2308, particulary section 4.

http://www.ietf.org/rfc/rfc2308.txt?number=2308

Hope this helps.

Dave...

>
> Gads, this bothers me to do this

I will, but I don't like it.
>
>
> ===
> Bob Gahl Bicycle (Ryan Vanguard) Mobile || @
> ARPA/Internet: bgahl@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
>
>

Robert Gahl

2004-02-05, 9:33 am

At 02:04 PM 2/5/2004, David Botham wrote:

>No. What I was trying to say is that when you configure a zone database
>file, you use a $TTL statement to set the default TTL for every RR in the
>zone where one is not explicitly stated.

Yes, I have done this in each and every zone file. It was originally set to
86400.

>When the name server loads the zone, it inserts each RR into memory with
>an explicit TTL on it (if you were able to look into memory, you would see
>this).

No argument. I understand what the default TTL is for and how it operates.

>Another place to see this effect is to look at the backup file of a slave
>zone. You will notice that regardless of how you typed the information
>into the master zone database file (by using the single $TTL directive),
>each and every RR in the backup copy of zone on the slave has an explicit
>TTL.

And, this is what I did. I had a default TTL of 86400 in the zone. On the
particular host:

ssl-hints.netflame.cc

I set an explicit TTL of 30 seconds to over-ride the default of 86400.
However, despite doing this, I have gotten some evidence that this explicit
TTL is not being read (i.e., do a dig on ssl-hints.netflame.cc and some
servers are reporting 86400, not 30, despite the fact that when I do it
from yet other servers, it is showing 30 like it should).

Thus my question: Do earlier versions of BIND lack the ability to recognize
the specific setting of TTLs on individual hosts?

If this is true (i.e., older versions of BIND lack the ability to recognize
explicit setting of TTL on specific hosts), then reversing my logic seems
to way to handle this. Set the default to 30 and then set everything I
don't want to be 30 to be 86400. It's a horrible way to fix this, but fix
it, it would.

>In the end, if you want a TTL of 30 seconds set for just one RR, then,
>explicitly state one for that RR and use the $TTL directive for the rest.

This is what I originally did, and to date, it had appeared to work just
fine. However, as of today, I'm not so confident any more because I have
seen some DNS queries on specific servers (but can't get anyone to answer
me as to what version of BIND, if indeed, they are running BIND) that say
86400, not 30.

This is what prompted me to contact the list.

Perhaps I'm not doing a good job of phrasing the situation.

===
Bob Gahl Bicycle (Ryan Vanguard) Mobile || @
ARPA/Internet: bgahl@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

Barry Margolin

2004-02-05, 10:33 am

In article <bvuho7$2ath$1@sf1.isc.org>, Robert Gahl <bgahl@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.

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.

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.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA

Kevin Darcy

2004-02-05, 11:33 am

Robert Gahl wrote:

>My company is the holder of the domain netflame.cc
>
>While the TTL on the domain has been set to 24 hours, we have set an
>individual TTL on one particular machine (ssl-hints.netflame.cc) to 30 seconds.
>
>My question is this:
>
>Does this play well across all DNS? I haven't done this until 9.x, so I
>don't know about version 8 or, for that matter, version 4. Is there a
>version out there where they only take the domain value (1 day) rather than
>the individual value (30 sec)?
>
Within the context of zonefile parsing, an explicit TTL always overrides
any "implicit" TTL, such as whatever is specified in the $TTL directive,
or the SOA MINTTL value (where applicable).

- Kevin

Robert Gahl

2004-02-05, 11:33 am

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

>In article <bvuho7$2ath$1@sf1.isc.org>, Robert Gahl <bgahl@bawcsa.org>
>wrote:
>
> recognize
>
>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/i...&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@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

Kevin Darcy

2004-02-05, 12:33 pm

Robert Gahl wrote:

>At 04:02 PM 2/5/2004, Barry Margolin wrote:
>
>
>
>
>I'm sorry it is meaningless. It was the only way I knew to phrase it.
>
>
>
>
>Thanks. This does help me understand it a bit better.
>
>
>
>
>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):
>
>
>
>
>This is correct. It is what I expect. However, go to this link:
>
>http://ntcanuck.com/net/tools/dig/i...&cmdQuery=Query
>
>It sure doesn't say 30 seconds.
>
You have both a CNAME record and an A record for ssl-hints.netflame.cc.
That's illegal.

Also, it looks like you accidentally reduced the TTL on your NS records
to 30 seconds. Bad.

% dig ssl-hints.netflame.cc any @ns2.netflame.cc

; <<>> DiG 9.2.2rc1 <<>> ssl-hints.netflame.cc any @ns2.netflame.cc
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16742
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ssl-hints.netflame.cc. IN ANY

;; ANSWER SECTION:
ssl-hints.netflame.cc. 30 IN CNAME ssl-log.netflame.cc.

;; AUTHORITY SECTION:
netflame.cc. 30 IN NS ns1.netflame.cc.
netflame.cc. 30 IN NS ns2.netflame.cc.

;; ADDITIONAL SECTION:
ns1.netflame.cc. 86400 IN A 65.200.204.52
ns2.netflame.cc. 86400 IN A 63.146.119.80

;; Query time: 61 msec
;; SERVER: 63.146.119.80#53(ns2.netflame.cc)
;; WHEN: Thu Feb 5 20:08:34 2004
;; MSG SIZE rcvd: 129

- Kevin