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

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

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

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

---

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: 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.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

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: Pekka Savola <[email-masked]>
Date: Fri, 30 Jul 2004 00:42:54 +0300 (EEST)

> an HTTP client lookup by an hour.  In this case, the TTL is now 7200.
[...]

I don't think the "freshness" is the point here -- at least not for 
me.

Rather, it's "the minimum how long the DNS server asserts that this
address corresponding to the name I asked will be valid".

Rather than discarding the result after the TTL would expire, and
breaking connections (or whatever), the application could re-query the
record after TTL expires to see if it still points to the same
address(es).  And if the TTL it received now is signficantly larger
(e.g., because a cache returned a very low TTL), the new TTL would be
longer, leading to a longer time before the next query.

An interactive client-application like SSH is a bit bad example of 
this.

Instead, consider an SSH daemon which is configued to listen to the
hostname "server.example.net" (not a wildcard address).  The daemon
could run for a month or a year in one go, but the hostname might
change during that time.  It could be beneficial that the application 
could re-query the DNS for "server.example.net" at some intervals (TTL 
could be one indicator here), and change its bindings if the DNS 
changes.

Similarly, consider a mechanism like SCTP or HIP which ties multiple
addresses to a connection.  A hostname might map to 1..N addresses
when the connection is established; during the lifetime of the
connection, the hostname could change to point to an entirely
different set of addresses.  Depending on how the new addresses
corresponding to the end-points are discovered during the session,
this TTL information could be quite useful -- as a means to trigger
how often one should poll for new information (instead of an arbitrary
interval).

There are probably better examples as well..

.

---

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

>address corresponding to the name I asked will be valid".

This is what I am afraid of. ;)

A DNS server makes no assurance of the accuracy, etc., of the data it 
serves.  The server makes no temporal statement of the data either. 
(DNSSEC only "protects" the transfer of data from where the 
administrator enters it to the resolver that last performs the check.)

Also, the servers are not the (ultimate) authority for the data. 
They are just the "publication" mechanism.  (That's when DNSSEC has 
something else sign the data, and has the authoritative servers load 
signed data.)

Statements like "DNS server asserts...will be valid" indicate 
expectations of what DNS does that are higher than reality.  DNS is 
just a plain old, vanilla look up service.

>how often one should poll for new information (instead of an arbitrary

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.  That an 
application element needs to get new data from the DNS ought to be 
triggered by an event internal to the application (such as a sudden 
failure of one application element in hearing from a remote  element).

>There are probably better examples as well..

And this is another troubling statement to me.  The SIKED BOF said 
the same thing and we got grilled.  Unless we have a good taxonomy of 
how DNS is going to be fit under applications, it's hard to know that 
we are designing a "level above DNS" that is as level a playing field 
as the DNS interface.

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

Even if it seems tempting...

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