Subject: getaddrinfo/TTL and resolver application-interface

From: Pekka Savola <[email-masked]>
Date: Tue, 27 Jul 2004 12:49:35 +0300 (EEST)

[ Moderators note: This post needed manual approval.

   Either because it was posted by a non-subscriber or because it contained
   to many characters (> 20000).

   With the massive amount of spam, it is easy to miss and therefore
   delete posts that need manual approval.

   Please fix your subscription addresses or shorten your postings by adding 
   links instead of attachments ] 

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?

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.

from draft-ietf-dnsop-ipv6-dns-issues-08.txt:

8.2  Renumbering Procedures and Applications' Use of DNS
                                                                                                                
   One of the most difficult problems of systematic IP address
   renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
   an application which looks up a DNS name disregards information such
   as TTL, and uses the result obtained from DNS as long as it happens
   to be stored in the memory of the application.  For applications
   which run for a long time, this could be days, weeks or even months;
   some applications may be clever enough to organize the data
   structures and functions in such a manner that look-ups get refreshed
   now and then.
                                                                                                                
   While the issue appears to have a clear solution, "fix the
   applications", practically this is not reasonable immediate advice;
   the TTL information is not typically available in the APIs and
   libraries (so, the advice becomes "fix the applications, APIs and
   libraries"), and a lot more analysis is needed on how to practically
   go about to achieve the ultimate goal of avoiding using the names
   longer than expected.

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

--
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: Miek Gieben <[email-masked]>
Date: Tue, 27 Jul 2004 13:06:31 +0200

[On 27 Jul, @11:49, Pekka wrote in "getaddrinfo/TTL and resolver a ..."]
> 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....

> IMHO, it seem to be worth adding the TTL information to getaddrinfo()  

grtz,
--Miek

---

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

> > IMHO, it seem to be worth adding the TTL information to getaddrinfo()  

	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

---

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).

---

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

> 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

---

From: Paul Vixie <[email-masked]>
Date: Sun, 01 Aug 2004 00:37:10 +0000

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.  it should be in an rfc,
like the advanced ipv6 api document.  it should be pushed toward posix.

isc had proposed this to some of our funding agencies but i believe it
was "too much too soon" at the time.  perhaps MODA will pick it up now.

re:

> To: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked],
> 	[email-masked]
> Subject: Re: [dnsop] Re: getaddrinfo/TTL and resolver application-interface
> X-Mailer: Cue version 0.8 (040717-1035/itojun)
> Date: Sun,  1 Aug 2004 09:14:19 +0900 (JST)
> From: [email-masked] (Jun-ichiro itojun Hagino)
> Sender: [email-masked]
>