Re: draft-ietf-dhc-dhcp-dns-02.txt

Dikran Kassabian <deke@isc.upenn.edu> Fri, 01 November 1996 19:31 UTC

Received: from cnri by ietf.org id aa26852; 1 Nov 96 14:31 EST
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa17835; 1 Nov 96 14:31 EST
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA25556; Fri, 1 Nov 1996 14:22:47 -0500
Date: Fri, 1 Nov 1996 14:22:47 -0500
Message-Id: <199611011757.MAA09496@geordi.dccs.upenn.edu>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: Dikran Kassabian <deke@isc.upenn.edu>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Re: draft-ietf-dhc-dhcp-dns-02.txt
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
X-Mailer: Mail User's Shell (7.2.5 10/14/92)

Is there a separate list for discussion of DHCP interaction with DNS
and the dynamic updates to DNS?  Is this really a question for the
namedroppers list?  Please pardon me if I'm asking this in the wrong place.

I've re-read draft-ietf-dhc-dhcp-dns-02.txt and also
draft-ietf-dnsind-dynDNS-09.txt.

I'm trying to convince myself one way or the other that there is
provision for a DHCP client to specify a client FQDN option in the DHCP
transaction which is for a DNS zone other than the zone usually
associated with the address assigned by the DHCP server itself, and
that under the right circumstances that request can be honored.

For example, can I visit MIT and boot up my laptop using DHCP (talking
to some MIT DHCP server) to acquire the address but then specify a 
upenn.edu FQDN?

I'd specify foo.upenn.edu in my DHCP client FQDN option, and the ZNAME
in the Zone Section of the DNS update would be upenn.edu.  The DHCP
server would originate the PTR record update request at the DNS server
responsible for the address space (at MIT in my example) from which my 
address has been defined, and either the client (my laptop) or the DHCP 
server would originate a dynDNS update request to the DNS server with 
authority for the upenn.edu zone.

Setting policies aside for the moment, what is wrong with this model?
Looks to me like the two DNS servers involved must authenticate and
authorize the request.  Perhaps this is possible given Domain Name
System Security Extensions (I'm still reading and re-reading
draft-ietf-dnssec-secext-10.txt and draft-ietf-dnssec-update-02.txt
to get a better understanding).  I briefly wondered whether this
wouldn't actually be easier if the DHCP client was responsible for
both the A and PTR record updates.  But that perhaps creates as
many problems as it solves.

Pointers to the right reading material and lists would be greatly
appreciated.  Commentary from the draft authors, of course, would
be wonderful.

-------
Deke Kassabian, Manager, Network Engineering 
Information Systems and Computing, University of Pennsylvania
Voice:215-898-9293   FAX:215-898-9348   Email: <deke@isc.upenn.edu>