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

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 29 Jul 2004 11:04:33 +0900 (JST)

> [On 27 Jul, @11:49, Pekka wrote in "getaddrinfo/TTL and resolver a ..."]
> > Hi,
> > 
> > draft-gieben-resolver-application-interface-00.txt sketches what kind
> > of information the application and the resolver could have through an
> > interface.  This has been discussed in dnsext at least in Feb 2004.  
> > What has been the outcome?
> 
> nothing yet, we had a lot of discussion about it, but nothing
> materialized out of it.
> 
> Personally I think some other questions also need to be answered,
> like:
> 
> o what service does the DNS actually provide?
> 	(it's a naming service, but application seem to want to know 
> 	more and more about the resolution process. Esp. with DNSSEC).
> 
> o where do applications start and resolvers end?
> 	A seen from the text below, apps now want to know TTLs. Where
> 	does it stop? 
> 
> o Each "application" (IPSEC for instance) has different (security) needs,
>  	and has a different set of "local policy" rules. What kind of
> 	interface is needed to allow for an application to make it's
> 	own policy decisions?
> 
> Following this line of thinking we could come to the conclussion that
> an application wants to know the entire resolving chain, from the root
> down to the leave node.  But when your local resolver does caching
> this might now be available... so there you go....
> 
> > The reason why I got interested was because section 8.2 of
> > draft-ietf-dnsop-ipv6-dns-issues-08.txt (see below)  shows that the
> > application should be able to be aware of the TTL of the records,
> > easily, so that it could discard expired records from the memory if
> > it's built around in such a way that it would be feasible to do so.  
> > As it is, the applications typically query a name when they start and
> > use it forever, irregardless of the TTL.  (And if the
> > application-resolver interface needs work in any case....)
> > 
> > IMHO, it seem to be worth adding the TTL information to getaddrinfo()  
> > functions.

	I object to change getaddrinfo().  getaddrinfo() deployment is ongoing
	and i do not want two variants of getaddrinfo - one with TTL, one
	without TTL, depending on platforms.  it just leads to confusion
	with small benefit just for the sake of small set of users.
	if a user wants TTL info, she can use getrrsetbyname().

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: Thu, 29 Jul 2004 00:49:41 -0700 (PDT)

> 	if a user wants TTL info, she can use getrrsetbyname().

AFAIK getrrsetbyname() isn't a standard so I don't know how good portability
one can get for applications using it.

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.

   Erik

---

From: Edward Lewis <[email-masked]>
Date: Thu, 29 Jul 2004 08:39:25 -0400

I'm not sure who, but apparently someone wrote this to some mailing 
list at some time in the past.

>>  > it's built around in such a way that it would be feasible to do so.

Please recall that the purpose of the TTL is for cache coherency, not 
a statement on the quality nor timeliness of the data in DNS. 
Similarly, the validity periods expressed in the signature records 
are not statements on the validity of the data, but the validity of 
the ancillary security data.

"Expired records" is a concept alien to DNS.  (A zone may be expired 
to a slave server.)

>>  > application-resolver interface needs work in any case....)

DNS is designed to be timeless service.  It's up to applications to 
be as dynamic as they want to be.  If applications assume incorrectly 
about the DNS, havoc will ensue.  Applications should not assume 
anything about the timers and clocks inside DNS.

OT: In my pre-DNS days, I once made my own simple lookup system.  The 
app looked up a name, got the address, and tried to complete the 
handshake of the transport layer.  If that failed, the app would then 
report back to the lookup system that the address was bad.  When the 
app wanted to connect again, it would lookup the name until a new 
address was registered.  If no address was received, it would set a 
timer and try again later.  This was mostly event driven, not 
timer-based - accomplishing what seems to be desired above without 
needing to pass timer information across the lookup service interface.

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."
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

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

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 29 Jul 2004 11:32:22 -0400

> a statement on the quality nor timeliness of the data in DNS. 

I would argue that if an application is using the results of a previous 
DNS lookup which it has stored in memory, then that is "caching" by any 
meaningful definition of the term. And if an app is caching, we should 
provide a way for the app to do so in a coherent manner. This implies 
making the TTL visible. Whether this is in getaddrinfo() or some other 
API, I'm not qualified to comment.

Like others, I've had problems with apps that "lock on" to a particular 
IP address. Particularly in dynamically load-balanced scenarios.

- Kevin

---

From: Edward Lewis <[email-masked]>
Date: Thu, 29 Jul 2004 11:58:50 -0400

At 11:32 -0400 7/29/04, Kevin Darcy wrote:

>I would argue that if an application is using the results of a previous DNS
>lookup which it has stored in memory, then that is "caching" by any meaningful
>definition of the term. And if an app is caching, we should provide a way for
>the app to do so in a coherent manner. This implies making the TTL visible.
>Whether this is in getaddrinfo() or some other API, I'm not qualified to
>comment.

Yes, it is caching by the application and it is up to the application 
to decide how long it will internally cache the data.  (Will SSH 
close a connection after 8 hours because it feels the original lookup 
data is no longer fresh enough?)

The DNS TTL though is not a good measure of freshness - by that I 
mean freshness at the authoritative source.  E.g., on one run an SSH 
client might get an address via a cache that had to get a fresh 
authoritative answer.  In this case, the DNS TTL might be 10800.  On 
a later run, the same client may get the same address - but following 
an HTTP client lookup by an hour.  In this case, the TTL is now 7200.

What does that mean to the SSH client, other than the data was 
sitting in an intermediary for an hour?  It says nothing about the 
freshness of the data at the origin.  (Note that the client can't 
determine that it was sitting in the intermediary - there's no 
indication of how far a TTL has ticked down in a reply.  It might be 
that the source has lowered the TTL.  Also, even if the application 
can be made to decide that it wants fresher data - it can't force the 
cache to get it.  The app would have to do it's own query iteration.)

>Like others, I've had problems with apps that "lock on" to a particular IP
>address. Particularly in dynamically load-balanced scenarios.

I've seen that.  I attribute it to poor application design, not a 
limitation of the interface to DNS (or other lookup service).