Re: domain name to dynamic IP address mapping

Masataka Ohta <mohta@necom830.cc.titech.ac.jp> Fri, 20 August 1993 12:35 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02426; 20 Aug 93 8:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02421; 20 Aug 93 8:35 EDT
Received: from ucdavis.ucdavis.edu by CNRI.Reston.VA.US id aa07689; 20 Aug 93 8:35 EDT
Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA23505; Fri, 20 Aug 93 04:50:14 PDT
X-Orig-Sender: ietf-ppp-request@ucdavis.edu
Received: from necom830.cc.titech.ac.jp by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA23072; Fri, 20 Aug 93 04:31:07 PDT
Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 20 Aug 93 20:26:02 +0900
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Masataka Ohta <mohta@necom830.cc.titech.ac.jp>
Return-Path: <mohta@necom830.cc.titech.ac.jp>
Message-Id: <9308201126.AA17694@necom830.cc.titech.ac.jp>
Subject: Re: domain name to dynamic IP address mapping
To: Greg Skinner <gds@ficus.cs.ucla.edu>
Date: Fri, 20 Aug 1993 20:26:00 -0000
Cc: host-conf@sol.cs.bucknell.edu, ietf-ppp@ucdavis.edu, mobile-ip@parc.xerox.com, namedroppers@nic.ddn.mil, pip@thumper.bellcore.com
In-Reply-To: <9308192229.AA15272@york.cs.ucla.edu>; from "Greg Skinner" at Aug 19, 93 3:29 pm
X-Mailer: ELM [version 2.3 PL11]

> Why is SNMP being considered as a way to manage the DNS?  It seems to
> me that the DNS access mechanism should be extended to include dynamic
> updates, removals, etc without SNMP.

Such extension of DNS is discussed in DNS WG.

The proble is that the update can not be guaranteed to be quick. The
update speed depends on the quality of connectivity between name servers
and between a nameserver and a client.

DNS depends on connectivity (between two hosts whose name is known but
IP address might not be known, which implies mapping from hostnames to
IP address is also necessary). So, in general, connectivity can not
depends on DNS. One possible way to break such a loop is to provide glue
information by hand. Glue A records for nameservers and files such as
named.boot and resolv.conf of bind provide such glue information. But,
then, the glue information is not expected to be updated quickly.

That is, mobile protocol can not depend on DNS to get rapidly changing IP
address, if mobile hosts are expected to act as nameservers. And, as
large amount of the future hosts are expected to be mobile, they are
expected to be able to act as nameservers, I think.

Also, I think Pip can not expect DNS to return the quiuckly updated
current address of some host, though it seems to be assuming so now.
If some connection is down and PCMP is generated, one can't expect
healthy connectivity. So, quick updated of DNS is often impossible. In Pip
case, DNS should return all the possible addresses, which does not
vary so often, from which Pip header server can select the most
appropriate one (I'm also Cc:ing to pip ML).

						Masataka Ohta