Subject: RE: comments on dhcp-dns-09 from a large production DDNS site

From: Diana Lane <[email-masked]>
Date: Sat, 10 Apr 1999 02:03:00 -0400 (EDT)

I apologize for the lack of attributions.  Microsoft Outlook makes
it difficult to tell who says what.

	When two clients ask for the same name, is it a "decidable problem"
to
	determine whether the same name request is due to desired
round-robin use
	or an administrative error?  Would a DHCP server then need be told
what
	names are shared and which are unique?  I'm not certain the DHCP
server can
	make the distinction.

	I would like to present an answer from the perspective of an
organization with several tens of thousands of names in dynamically
updatable zones.  Given a zone on a server that supports dynamic updates,
where some names in the zone belong to statically addressed servers
performing business-critical functions, one does not want one's DHCP
server(s) to blithely send updates that replace those servers' A records and
PTR records with those of a DHCP client that happens to send the same
hostname as the server in its DHCPREQUEST.  That would be a Bad Thing.

	I have seen two vendors' approaches to the problem of name
collisions.  Neither meets my needs in supporting my customers.  One
approach is to disambiguate the name a client sends by appending extra
characters if the name sent in the hostname option field is the same as an
existing domain name.  This has a rather nasty tendency to break certain
applications that rely on a specific PTR record being returned.

	The other approach is to replace any existing resource record by
that domain name with the new domain name and data, regardless of any other
factors.  This approach provides no protection against server names being
usurped by PCs, printers, or other DHCP clients.

	I would like to see something such as the following process:

*	If the domain name does not already exist, add the new resource
record.
*	If the domain name does exist, check for the existence of a TXT
record with that domain name and a specific extension (say, "-noupdate").
*	If that TXT record does not exist, update the client's A and PTR
records.
*	If that TXT record does exist, DO NOT send any DNS updates and (at
the administrator's discretion) send in the DHCPOFFER to the client a
specific set of options defined as a policy (for example, a special domain
name server that resolves all names to the IP address of an HTTP server
whose default page is a set of instructions to the end user - not all
deployed clients support a wide range of options so sending an http server
option might not have the desired effect).

	There are some caveats associated with this approach:  The initial
DNS lookups and prerequisite queries would need to be performed before the
DHCPOFFER so that any policy-specific options could be included in the
DHCPOFFER.  The actual update, if any, could be performed after the DHCPACK
was sent in order to avoid updates for incomplete transactions.  I do not
know what effect this would have on server response time.  In addition,
Windows NT clients complain loudly via an obnoxious dialog box if they are
sent options they did not request.  This could be considered desirable as it
will almost certainly result in the user opening a trouble ticket (which
will lead to the client name being changed to something acceptable).

Diana Lane
Senior Network Engineer
Wal-Mart Stores, Inc.
501/277-3177
"Be gentle to all, and stern with yourself." - Teresa of Avila