To:
Daniel Senie <dts@senie.com>
CC:
Robert Elz <kre@munnari.OZ.AU>, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se
From:
Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Date:
Thu, 9 Aug 2001 02:18:28 +0859 ()
In-Reply-To:
<5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> from DanielSenie at "Aug 8, 2001 12:12:15 pm"
Sender:
owner-dnsop@cafax.se
Subject:
Re: (ngtrans) Joint DNSEXT & NGTRANS summary
Daniel; > > | Not to mention melting the 'net under ever increasing DNS load, since > > we'd > > | no longer be able to cache anything. > > > >Huh??? > > > >No-one ever said anything about changing the definition or use of the > >TTL field in DNS replies. If you get a TTL that says an address is > >valid for a day, then you can keep using it for a day without checking > >again. Or you can check again every 5 minutes if you want to, but > >the answers will just keep coming back from your local cache, each with > >a TTL 5 minutes shorter than the previous time... > > Reread what Keith wrote. that he is crazy? > If applications are going to use DNS to check for > changes in addressing, how is caching going to help? Caching helps because applications won't check DNS again until TTL expires and even if it does cache will supress actual query. Caching helps other applications share the result of query. > 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 interpreted the > periodic lookup as being a way for applications to find out that a remote > machine has migrated to a new address. If local caches mask that migration, > how's that help? You are merely saying that DNS TTL should not be unnecessarily small. DNS semantics is that if TTL expires applications still relying on the answer should query again. BTW, it is also possible to modify applications to carry information that addresses change occurred and a list of new addresses. Masataka Ohta