Re: New I-Ds on ftp.bucknell.edu

"Edie E. Gunter" <edie@watson.ibm.com> Mon, 19 February 1996 14:41 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15204; 19 Feb 96 9:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa15195; 19 Feb 96 9:41 EST
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa27257; 19 Feb 96 9:41 EST
Received: from localhost by reef.bucknell.edu with SMTP (5.65/IDA-1.2.8) id AA27305; Mon, 19 Feb 1996 09:31:56 -0500
Date: Mon, 19 Feb 1996 09:31:56 -0500
Message-Id: <9602191421.AA17928@edisto.watson.ibm.com>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
X-Orig-Sender: dhcp-v4@bucknell.edu
Precedence: bulk
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Edie E. Gunter" <edie@watson.ibm.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Re: New I-Ds on ftp.bucknell.edu
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

   Sorry if this is a duplicate...the bucknell mailer bounced
	it back to me.


> 1.  What is the rationale for allowing both the client and server to
> 	initiate updates to the A RR record?  Is it simply for the
> 	client to get confirmation of the change?

Normally, one thinks of a client as owning its name.  This
ownership, then, suggests that it is more logical for the
client to perform name->IPaddress (A RR) updates.

There is also the more practical issue of mobility.  If a
user takes his PC to another site in another
town or country, that user will probably want a local IP
address, but will want to keep his same name.  In this
case, the user/client is more likely to know the DNS
server to which the A RR update should be sent than a DHCP
server in a far away place.

> 3.  Even if the suggested option is maintained, I'd still favor
> 	having the servers submit all updates as this simplifies the
> 	protocol specifications immensely by eliminating the need for
> 	the flag within the option and answering the first discussion
>	question as to whether a server can override the client.

I would disagree.  In particular, I think in a secure DNS,
having DHCP servers update A RRs would make management of
the KEY next to impossible for the case where a PC moves
among multiple domains.

> 4.  I'm unclear as to why one would include lease information within
>	DNS. < stuff deleted >

DNS needs to know the lease expiration so that it can ensure
that the A/PTR RR's expire when the DHCP lease expires.  On
renewal of a lease, a client and/or server will send updates
to DNS.  This will effectively extend the expiration of the RRs.

> 	It seems a simpler approach would be to require a packet be
>	sent to DNS whenever a lease expires or is released by the
>	client. <more stuff deleted>

Waiting until the lease expires isn't going to work in a secure
DNS.  The expiration of the A/PTR RR's must be set up when the
RR's are added/updated.  Making the expiration arbitrarily far
into the future, assuming you'll be told when a lease expires or
when it's been released doesn't seem like a good idea to me.

Edie