Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface

From: Erik Nordmark <[email-masked]>
Date: Sun, 1 Aug 2004 07:05:26 -0700 (PDT)

> My point is - applications developers ought to rely on DNS at it's 
> service's face value, not by inferring anything in the ancillary 
> data.  If application developers try to read between the lines, we 
> muddle the architecture of the Internet and will end up with a "house 
> of cards."

If we started with a blank sheet of paper that might work; but we 
unfortunaly have to deal with the existing house of cards.

When I try to tell application/middleware developpers to stop
retaining information returned by getaddrinfo/gethostbyname forever
and instead requery every time the information is needed it isn't well
received. The perception is that application caching (more or less forever)
work in the majority of cases so why is doing something different
the app developpers problem.

Hence I think we could collectively be more effective in fixing this
if we could present an API mechanism by which the application/middleware
could find out an upper limit on how long time it should retain
the information in its own cache.
Whether it is quicker and better to do this by standardizing getrrsetbyname
or by extending getaddrinfo is something we can debate once we have an
agreement that this is a useful approach.

  Erik

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Tue, 3 Aug 2004 16:47:03 -0700

>the information in its own cache.

I've thought about replying to this for some time.

I can see that the DNS TTL would be an appropriate measure of time 
that an application can "refer to" an answer it got from a DNS lookup 
- in essence the application is acting like a DNS cache and the TTL 
applies.

But, that's the limit of how an application ought to make use of the 
TTL.  The TTL isn't a necessarily a measure of the volatility of the 
data - e.g., it's not an indication of the "mean time to next 
change," say before the next dynamic update.  Another example, the 
TTL isn't a measure of the useful life of the data - just the amount 
of time that a cache holding of it is "wise."

DNS can offer up the following times - TTL, end of the signature 
validity (under DNSSEC), zone expiration.  Signature validity can be 
a measure of the validity of the data's signature or the measure of 
the validity of the union of the entire chain.  (I.e., just the RRSIG 
for the A record you want, or the "sum" of the times for the root's 
KEY, TLD's DS and KEY, ..., and the A's validity.)

DNS does not have a "next scheduled change" (like there is in things 
like X.509 CRLs), which would probably far more interesting to an 
application.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 3 Aug 2004 17:22:03 -0700 (PDT)

> TTL.  

Agree fully.
And AFAIK this is what the applications do. For whatever reason
they think gethostbyname/getaddrinfo is slow so the application
contains a local cache of the results.

> The TTL isn't a necessarily a measure of the volatility of the 

Agree.

Do you have example of where an application would actually believe that the
data would change after the TTL expires?

   Erik

---

From: Edward Lewis <[email-masked]>
Date: Wed, 4 Aug 2004 08:40:39 -0700

>data would change after the TTL expires?

No, I don't.  I was just imagining the worst-case scenario of an 
application developers "wild imagination." ;)  The last time I did 
any work myself in this area, it was the 80's and I didn't have a TTL 
but did have changing data.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Aug 2004 16:54:43 +0000

(i'm not sure how this thread got started on both namedroppers and dnsop,
or whether it's wise for any thread to ever be in both places, but i'm not
going to be the one to remove either list from the distribution here.)

> > of time that a cache holding of it is "wise."

me too.

> data would change after the TTL expires?

when rsalz first wrote INN he complained that a server administrator
would have to say "innctl reload hosts" whenever his cached dns data
became unavailable.  he asked me for an extension to gethostbyname()'s
"struct hostent" to show ttl, but i considered this unwise since there
was no reasonable default for the case where the hostent had come from
YP/NIS or /etc/hosts.

i can only assume that web browser developers would also like to know
how long it was safe to reuse a hostname->address translation before
going "back out to the wire" to see if it had changed.  right now i
suspect that they have a hardwired time threshold measured in minutes,
which would be nonrespectful toward the loadbalancing people who use
violently short TTL's.

---

From: Roy Badami <[email-masked]>
Date: Wed, 4 Aug 2004 18:14:25 +0100

>>>>> "Paul" == Paul Vixie <[email-masked]> writes:

    Paul> i can only assume that web browser developers would also
    Paul> like to know how long it was safe to reuse a
    Paul> hostname->address translation before going "back out to the
    Paul> wire" to see if it had changed.

FWIW, I believe that the squid web proxy uses the TTL in this way.

      -roy