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

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sun, 1 Aug 2004 09:14:19 +0900 (JST)

> On the other hand, introducing an new ai_ttl field at the end of struct
> addrinfo can be done without any effect on binaries (since the field offsets of
> the other fields do not change, and freeaddrinfo() will free the correct size
> structure). Applications which want to use ai_ttl would then do
> 
> 	call getaddrinfo...
> #ifdef _GETADDRINFO_AI_TTL
> 	ttl = ai->ai_tll;
> #else
> 	ttl = 30;	/* Or some other constant */
> #endif
> 
> While this is more painful than if we'd included ai_ttl from the start,
> it seems to be less painful than standardizing getrrsetbyname() to
> ensure portability of that interface across platforms.

	getaddrinfo() is not a DNS-only function; it can lookup hostname-to
	address using /etc/hosts, NIS, LDAP, whatever you have.  what value
	would you put in to ai_ttl when the lookup is done by non-DNS method?

itojun

--
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: 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

---

From: [email-masked]
Date: Mon, 02 Aug 2004 07:03:01 +0900

>On Sun, 1 Aug 2004, Jun-ichiro itojun Hagino wrote:
>-1, unless something else is provided?

	then what do you expect application to do with the data?  when does
	it expire?  any fabricated value (-1, 0, whatever) in ai_ttl is
	problematical to TTL-aware application, IMHO.  what i'm suggesting
	is to use DNS-only API like getrrrsetbyname() if you want TTL.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Mon, 2 Aug 2004 01:48:53 +0300 (EEST)

> 	is to use DNS-only API like getrrrsetbyname() if you want TTL.

Let's assume that currently apps keep records forever, i.e., "-1" 
(infinite).

If apps would use TTL info to requery the addresses now and then, 
telling them that a particular record has infinite lifetime (because 
lifetime information wasn't provided) seems like pretty much equal to 
the situation now -- i.e., it doesn't make situations worse. (And 
infinite would actually probably be rather accurate esp. with 
/etc/hosts).

getrrsetbyname has the generic problem that the applications don't
want to care about the lookup mechanism used.  /etc/hosts or whatever
is just as fine as DNS.  Thus I think only apps which specifically
know that they definitely want their answers to come from DNS (and not
from hosts file or whateveR) can use getrrsetname.  But I don't think
the majority cares, or should need to care.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 01 Aug 2004 21:51:32 -0400

On 7/31/2004 8:37 PM, Paul Vixie wrote:

> i don't think expansing getaddrinfo/getnameinfo to return ttl is the
> right approach.  we need a "getrrsetbyname" for dns-aware applications
> that returns ttl, security status, and so on.

"rrset" is the right target, too.

apps that try to do their own load-balancing and whatnot need to be given
the original unordered set, not a random member of the set

---

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: Robert Elz <[email-masked]>
Date: Thu, 26 Aug 2004 12:46:59 +0700

Date:        Thu, 29 Jul 2004 21:15:36 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06020403bd2f4d764c4b@[192.168.1.100]>

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