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
- New I-Ds on ftp.bucknell.edu Ralph Droms
- Re: New I-Ds on ftp.bucknell.edu Michael J. Lewis
- Re: New I-Ds on ftp.bucknell.edu bound
- Re: New I-Ds on ftp.bucknell.edu Yakov Rekhter
- Re: New I-Ds on ftp.bucknell.edu Yakov Rekhter
- Re: New I-Ds on ftp.bucknell.edu Edie E. Gunter
- Re: New I-Ds on ftp.bucknell.edu bound
- Re: New I-Ds on ftp.bucknell.edu Edie E. Gunter
- Re: New I-Ds on ftp.bucknell.edu bound