Re: (ngtrans) Joint DNSEXT & NGTRANS summary

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Wed, 08 Aug 2001 12:12:15 -0400
    From:        Daniel Senie <dts@senie.com>
    Message-ID:  <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net>

  | Reread what Keith wrote.

It was actually what Keith quoted that Otha-san wrote, not that
that really matters.

  | If applications are going to use DNS to check for 
  | changes in addressing, how is caching going to help?

It isn't going to help, but it isn't going to be eliminated either.

  | You're suggesting the 
  | local caches just answer the every-5-minute lookups, but that's useless if 
  | the DNS lookups are used as a part of multihoming.

I'm not sure of the relevance of multihoming - it was renumbering we
were discussing, but never mind.

  | I interpreted the 
  | periodic lookup as being a way for applications to find out that a remote 
  | machine has migrated to a new address.

Yes.

  | If local caches mask that migration, how's that help?

It is giving the answer (as authorised by the owner of the data).

Consider what happens now, and forget about long lived applications
periodically polling - instead consider a series of short lived
applications (like web page accesses, which do a DNS lookup for
every URL usually).

Given that caches answer now for those queries, for as long as the
TTL allows, do you really see any difference at all?

  | Multihoming has to involve resiliancy. If the addresses are cached for a 
  | day, saying "oh, your application will start working again tomorrow" is 
  | unlikely to cut it.

No.   But that's never been the idea.

  | So, I guess the question back to the original point was, what information 
  | is going to be IN those lookups that happen every 5 minutes?

Nothing, which is why a sane app wouldn't do that, only when the TTL
it originally received (assuming it is using an API that reveals the TTL
of course) has expired.  On the other hnd, other than increased traffic
at the local DNS cache, checking the address more frequently doesn't hurt
either.

  | If that 
  | information needs to change on a minute by minute basis (or a 5 minute by 5 
  | minute basis) then caching is not going to help.

No.   Somehow I think you're missing the context of this whole discussion
though.

  | So, the question is, to 
  | use this effectively, do zones have to be set up with their TTL set to 60 
  | seconds?

No, bit when you set a TTL on a record in the DNS, that's a promise that
the data isn't going to change from the time someone fetches the record
until the TTL has expired.

No-one is planning on altering that.   That is, that's true today, and
will remain true tomorrow (you can cache this answer for at least 6
months...)

The effect is that you need to handle TTLs and address changes together.
The old address needs to remain valid while any RRs that were handed out
are still alive.   That's the DNS, and will remain.

kre