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

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

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

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.

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

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

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

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