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

[Yakov Rekhter <[e-mail]>]

> Some initial comments/questions on draft-ietf-dhc-dhcp-dns-00.txt    - 
> DHCP-DNS interaction (Yakov Rekhter)
> 
> 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?
> 
> 2.  If DNS updates were restricted to the server realm, then it seems
> 	that currently existing techniques could be used to initiate
> 	the DNS change request rather than the suggested option.  The
> 	flag introducted in the new option would obviously not be 
> 	needed; the domain name should come from the server anyway since
> 	the client should not know which domain it is in.  The host 
> 	name component of the FQDN might then be provided by the 
> 	existing host name option (12).  
> 
> 	This effectively makes a host name (from client) and DNS name 
> 	(from server) combination the trigger to cause a dynamic DNS
> 	update.  One would lose the ability provided by a separate 
> 	option of avoiding a DNS update even though both host and domain
> 	name were set although in our environment, I can't foresee any
> 	time when we would want to prevent a DNS update.
> 
> 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.
> 
> 4.  I'm unclear as to why one would include lease information within
> 	DNS.  It that information is present, it seems that the DNS
> 	entry could be expired without requiring a packet from the 
> 	server.  However, including this information raises a number
> 	of questions regarind the handling of renew/rebind requests.
> 	Would a server (following an ACK) send an update request to DNS?
> 	Since the DNS entry should already be present, will DNS ignore 
> 	the request as a duplicate (leaving the current expiration time)
> 	or will it update the internal TTL time to the new lease?
> 
> 	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.  It would be the server's responsibility to send the
> 	packet.  I guess a server could send notification if a lease
> 	is deleted at the server but this is such a vague area anyway
> 	(the client isn't notified so why should DNS be?) I'd just 
>  	as soon leave it out of the document so as not to encourage 
> 	it use.