Discussion:
DNS TTLs revisited
(too old to reply)
Robert Gahl
2004-02-05 19:29:35 UTC
Permalink
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: ***@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 19:54:11 UTC
Permalink
Post by Robert Gahl
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.
Post by Robert Gahl
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
Post by Robert Gahl
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...
Post by Robert Gahl
Thanks.
===
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 22:00:58 UTC
Permalink
Post by Robert Gahl
Post by Robert Gahl
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.
Post by Robert Gahl
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
Post by Robert Gahl
the individual value (30 sec)?
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: ***@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 22:07:56 UTC
Permalink
Post by Robert Gahl
Post by Robert Gahl
Post by Robert Gahl
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
Post by Robert Gahl
Post by Robert Gahl
seconds.
Post by Robert Gahl
Does this play well across all DNS? I haven't done this until 9.x,
so I
Post by Robert Gahl
Post by Robert Gahl
Post by Robert Gahl
don't know about version 8 or, for that matter, version 4. Is there
a
Post by Robert Gahl
Post by Robert Gahl
Post by Robert Gahl
version out there where they only take the domain value (1 day)
rather
Post by Robert Gahl
Post by Robert Gahl
than
Post by Robert Gahl
the individual value (30 sec)?
Reality is that, regardless of how you configure your zone db file, all
RR
Post by Robert Gahl
Post by Robert Gahl
always carry an explicit TTL.
So, then, I assume that reversing my logic would be a good thing? That
is,
Post by Robert Gahl
set the default to 30 seconds and then explicitly set each and every
(but
Post by Robert Gahl
non-applicable to this situation) IN A record to 86400 seconds, so in
the
Post by Robert Gahl
event that someone isn't seeing the individual TTL values, they are
picking
Post by Robert Gahl
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...
Post by Robert Gahl
Gads, this bothers me to do this :( I will, but I don't like it.
===
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 22:57:09 UTC
Permalink
Post by David Botham
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.
Post by David Botham
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.
Post by David Botham
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.
Post by David Botham
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: ***@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-06 00:09:17 UTC
Permalink
Post by Robert Gahl
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, ***@alum.mit.edu
Arlington, MA
Kevin Darcy
2004-02-06 00:14:25 UTC
Permalink
Post by Robert Gahl
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.
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-06 00:49:51 UTC
Permalink
Post by Robert Gahl
Post by Robert Gahl
Thus my question: Do earlier versions of BIND lack the ability to
recognize
Post by Robert Gahl
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.
Post by Robert Gahl
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.
Post by Robert Gahl
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
Post by Robert Gahl
web <bgahl>: dig ssl-hints.netflame.cc
; <<>> DiG 8.2 <<>> ssl-hints.netflame.cc
;; res options: init recurs defnam dnsrch
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; ssl-hints.netflame.cc, type = A, class = IN
ssl-hints.netflame.cc. 30S IN A 63.146.119.84
netflame.cc. 18h26m5s IN NS ns2.netflame.cc.
netflame.cc. 18h26m5s IN NS ns1.netflame.cc.
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: ***@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-06 01:18:51 UTC
Permalink
Post by Robert Gahl
Post by Robert Gahl
Post by Robert Gahl
Thus my question: Do earlier versions of BIND lack the ability to
recognize
Post by Robert Gahl
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.
Post by Robert Gahl
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.
Post by Robert Gahl
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
Post by Robert Gahl
web <bgahl>: dig ssl-hints.netflame.cc
; <<>> DiG 8.2 <<>> ssl-hints.netflame.cc
;; res options: init recurs defnam dnsrch
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; ssl-hints.netflame.cc, type = A, class = IN
ssl-hints.netflame.cc. 30S IN A 63.146.119.84
netflame.cc. 18h26m5s IN NS ns2.netflame.cc.
netflame.cc. 18h26m5s IN NS ns1.netflame.cc.
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
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.
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

Loading...