Date: Thu, 29 Jul 2004 21:15:36 -0400
From: Edward Lewis <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
Sorry I'm coming to this very very late, but I looked quite a bit ahead
in the list, and didn't see a reply like the one I'd like to make (though
I don't claim an exhaustive search - I still am > 200 messages behind).
| At 0:42 +0300 7/30/04, Pekka Savola wrote:
| >Rather, it's "the minimum how long the DNS server asserts that this
| >address corresponding to the name I asked will be valid".
|
| This is what I am afraid of. ;)
Pekka used the wrong word. "valid" isn't what he really meant,
"consistent" was.
| A DNS server makes no assurance of the accuracy, etc., of the data it
| serves.
This is all 100% irrelevant to the point at hand (though perhaps justified
by the use of the word "valid" in the earlier message).
What matters here is that if I get an answer with a TTL of N, I can
reasonably expect that the answer will be consistent for the next N
seconds - technically I can even demand it, but almost no DNS operators
bother to use the TTL correctly enough for that (neither do they mostly
care that for a period the end users are getting old answers).
An application that gets an answer that says TTL=N and queries again for
the same query within the next N seconds is just imposing needless work
on the network - whether anyone cares or not is a different question, most
people don't - but it is also imposing needless costs and delays on the
application, and an application that is aiming for snappy response is going
to want to minimise that.
Note that unless the application is bypassing DNS caching (and has a way
to achieve that reliably, in the presence of devices that redirect
packets aimed at certain ports to other than the address in the packet)
asking again within the TTL period is pointless - even if the auth server
has changed the data in the intervening period, the cache has no way to
know that, and is simply going to return the same answers again.
The TTL is just as vital a part of the DNS answer as the RDATA, and should
have always been exposed to the end applications - the only thing that
prevented that from happening was the way that the the API was shoe-horned
into the old gethostbyname() and struct hostinfo which fetched its data from
HOSTS.TXT (via /etc/hosts) and for which there was no TTL concept. If
it hadn't been for that, the TTL would almost certainly have been exposed
from the beginning. That it remains unexposed after we have invented new
APIs is a travesty.
| Although DNS is quite capable of carrying changing information
| (thanks to dynamic update), I don't think any application would be
| wise to rely on polling DNS to discover changed data.
I disagree with that as well. The DNS is how the clients find the
address to connect to. If the server is supposed to be providing a
service for name N, and the DNS says that name N translates into address
X, then the server must answer to address X. If the DNS changes the
address mapping from X to Y, then at that point, and only at that point,
the server needs to be listening on Y (doesn't hurt to have started
earlier, but achieves nothing very useful).
| This entire thread is from my reacting to the desire to expose the
| TTL from the resolver to application. My message is mostly one of
| concern - that applications need to understand what the TTL means.
Absolutely, I agree with that. But it isn't that hard.
The problem with treating the DNS data as "timeless" as an earlier
message from you claimed, is that most people treat timeless as
meaning "eternal" or "forever" - where I suspect that you probably
really meant "no time values supplied". Providing an explicit
time to live should at least get applications to stop treating the
data as if it came from /etc/hosts, and could really never change
(or not without a local human to cause it, who can also touch the
applications at the same time).
| From my experience (going back in time), I'd try to avoid the TTL as
| a meaningful interface element - perhaps just from the principle of
| network layering. If you view the application as a layer above DNS,
| then using DNS internal data (the TTL) is a "layering violation."
This is simply nonsense - both as a concept ("layering" applies to models,
which are anaylsis tools, and should be left to that realm) and in particular
in this case, the TTL is part of the answer - separated from the RDATA to make
it easier for fairly dumb caches.
| Remember - TTL's don't account for the rapidity of dynamic updates -
| and I think that's more important in the example you've described.
No, they don't - but nor do caches, unless the TTLs are set so as to
cause that to happen - and it is the caches that give the vast majority
of the answers, not the auth servers (auth servers spend most of their
effort giving negative answers, not positive ones).
kre
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
