Subject: RE: draft-ietf-dhc-dhcp-dns-09.txt

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Fri, 2 Apr 1999 14:12:48 -0500 (EST)

Mark, Robert, et al.,

I realize I'm jumping into the middle of the conversation but I want to add
my two cents' worth...

my comments are inline...

--Barr

> ----------
> From: 	Mark Stapp[SMTP:[email-masked]]
> Sent: 	Friday, March 26, 1999 4:17 PM
> To: 	Multiple recipients of list
> Subject: 	Re: draft-ietf-dhc-dhcp-dns-09.txt
> 
[ ... stuff deleted ... ]

> >Most importantly (and then in decreasing order thereafter), I think, is
> ...
> >
> >   In addition, if the Client FQDN option carried in the DHCPREQUEST
> >   message has its Flags field set to 1, then the server MUST originate
> >   an update for the A RR (associated with the FQDN carried in the
> >   option).
> >
> [ ... ]
> >  The MUST in the
> >quoted text needs to be (at a minimum) qualified, to indicate that this
> need
> >only be attempted if the the dhcp server has the necessary credentials
> for
> >the FQDN supplied.
> 
--yes, I agree about the presumed delegation of authority that Robert
raises, but how can this be determined a priori by the client and server?
Presumably, if the DNS server has been configured to require credentials for
add/update/delete of A records then somehow the necessary mechanism for
distribution of credentials has been accomplished.  If the administrators
wish for clients to be able (or required) to delegate A record updates to
the DHCP server, then the server will also have the necessary credentials.
But how does the client know this to be the case?  It seems to me that in
order to avoid an administrative nightmare involving key management the
client probably should not be able to selectively delegate A record updates
to the server:  I believe that either the client will always do so or never
do so, not select who performs the update using this option. [Barr] 

> I'll try to make this clearer. The purpose of this flag is to allow the
> client to indicate to the server that the client will _not_ perform an
> update on the client's name. The draft certainly shouldn't imply that the
> server should act in an arbitrary way in that case, especially if the
> server knows that it cannot update a name like the one the client has
> sent.
> 
--I have always been uncomfortable with the notion that the client makes
this determination.  I firmly believe that it is an administrative choice,
not a client choice.  I think that in practice arbitrary behavior may not
only be appropriate, but also the norm.  To me, the choice of which party
updates the A record is a policy issue, and I further assert that the whole
idea that the client is authoritative for its FQDN may be faulty.  In our
case, we wish to be able to supply a client its FQDN through the option 12
(hostname) and option 15 (domain name) mechanism, choosing an identifier
that conveys no particular information such as human's name, location, or
function.  Given that, by our policy choice, the client is told its name by
the server, the server is authoritative for both the FQDN and the address,
and we would never permit the client to "choose" to update the A record
itself.  I recognize that other organizations may have a different
perspective, but I must insist that this I-D not preclude the appropriate
administrative authority from establishing local policies that usurp the
function proposed by this option. [Barr]

[ ... stuff deleted ... ]

> >Also, the encoding of the domain name
> >field isn't stated.  I'd strongly suggest encoding it using the same
> method
> >that is used in DNS packets (without name compression, of course), rather
> >than attempting to encode it as a text string (which leads to all kinds
> of
> >complications).
> 
> The fqdn option is a DHCP option, and it's currently an ASCII string like
> the existing host-name and domain-name options. I'm inclined to leave it
> that way unless there's clear agreement that it's insufficient.
> 
--Mark, we are entering an era when the encoding of strings will become
increasingly important.  For robustness, I thing you should specify NVT
ASCII here if that's what you mean. [Barr]

> >Next most importantly, there seems to be no discussion about what should
> be
> >done in the event of a conflict - that is, where a dhcp server has been 
> >configured to supply a particular host name to the client, yet the client
> >uses this new option to request a different fqdn.
> 
> This is really an administrative matter. Sites may choose to allow their
> servers to accept clients' suggestions, or rely on the servers' own
> notions
> of the names the clients should receive. I'll add words to that effect.
> 
--unfortunately, this is a bigger problem:  some well-known and
widely-deployed clients do not accept server setting their hostname using
option 12, and hence, are not able to specify FQDN.  That doesn't mean that
the server shouldn't be given the authority to specify the FQDN, or that a
client must always accept the name... again, this is a local policy issue,
and the draft should not force one behavior or another, but accept that a
policy overrides the choice. [Barr]

> >Then wrt ...
> >
> >   If a server terminates a lease on an address prior to the lease
> >   expiration time, the server SHOULD ...
> >
> >Is there actually a DHCP way that can be done? [...]
> 
> A server can reply to a client's request with a NAK, and the client will
> give up its current lease and attempt to acquire a new one. If that
> occurs,
> the server should clean up the DNS.
> 
> >Perhaps less serious ...
> >
> >   If a client that owns/maintains is own FQDN wants to be responsible
> >   for updating the FQDN to IP address mapping for the FQDN and
> >   address(es) used by the client, then the client MUST include the
> >   Client FQDN option in the DHCPREQUEST message originated by the
> >   client.
> >
> >I would have thought that if a client wants to maintain its FQDN to IP
> >mapping, and doesn't care about the address -> name mapping, then it
> ought
> >simply be able to update the A record itself, and there's no need to ever
> >tell the DHCP server anything about it at all. [...]
> 
> The sentence you've quoted appears immediately after this one: "The
> following describes behavior of a DHCP client that implements the Client
> FQDN option." Sites whose administrators don't care about this option can
> use clients which don't implement it. Hopefully, the cooperation that the
> draft describes is useful, and clients will implement it.
> 
--while true, some firewalls require that specific mapping as a
pre-condition for services such as FTP, WWW-browsing, and Telnet.  In such a
situation, allowing the client to update the A record without the server
updating the PTR record would cause the client to suddenly "break,"
something that we should studiously avoid. [Barr]

> >Next:
> >
> >   If a client releases its address lease prior to the lease expiration
> >   time and the client is responsible for updating its A RR(s), the
> >   client SHOULD delete the A RR
> >
> >I'd like to see a justification for that SHOULD (rather than just MAY).
> >In practice, clients rarely release leases anyway, they mostly just
> switch
> >off and go away, abandoning the lease (if it expires before they're ready
> >to use it again). [...]
> 
> Dangling names are seen as a very real administrative problem in many
> organizations. There are popular clients which do release their leases,
> and
> their behavior needs to be accounted for in the draft. If a client accepts
> responsibility for its name, it should make every effort not to leave the
> name behind when it's no longer in use.
> 
--true, but what about the more recalcitrant clients/users?  Can we
generically specify a means to surmount this problem?  For example, can we
tell DNS the lifetime of the resource records? (Robert, I defer to you about
this...)  Should we specify client behavior that does a reverse lookup
before changing its name, deleting the old A record as a pre-condition for
adding a new one?  Or is there some mechanism by which the DNS server itself
purges dangling names? [Barr]

[ ... stuff deleted ... ]

> >I would also like to see an example of a complete DHCP/DynDNS transation
> >(or perhaps 2, to cover the two models) - from the initial DHCPDISCOVER
> >until everything is completed, showing all of the relevant fields (ie:
> >addresses and names, omitting other DHCP options that would normally be
> >included as they're not rrelevant here).   I think it would be also good
> >to mention just what should be done when a lease is renewed - the doc as
> it
> >stands seems to really only cover the case where a lease is initially
> being
> >obtained (and also when it is released).
> >
> >In particular, I'd like this to tell me whether it is envisaged that
> there
> >is any interaction in this area between what the server sends in its
> >DHCPOFFER, and how the client uses the FQDN option of the DHCPREQUEST.
> 
> Do you mean that the text descriptions in 3.4.1 and 3.4.2 aren't complete,
> or just that they aren't as clear as an example would be?
> 
--I agree that a time-sequence diagram would be illustrative, although
unless we are trying to completely specify so much of the implementations,
perhaps it would be well-placed if it were in an appendix? [Barr]

> >Then, a request - I think it is quite common for clients to know the
> >least significant element of the domain name that they want to own, but
> not
> >to care much about what domain it is embedded into.   That is, it would
> be
> >nice for the client to be able to supply just the hostname part, and have
> >the server complete that by appending an appropriate domain name (and
> return
> >the complete thing to the client). [...]
> 
> I agree. I'll make this clearer.
> 
--yes, Robert makes a good point here:  I agree.  However, we have the small
matter of options 12 and 15 to consider.  I have always assumed that if one
were to concatenate options 12 and 15 one would, in effect, be constructing
the client's FQDN.  If the use of this new option permits the server to take
the client's suggested least significant part and append the remainder to
construct an FQDN, then, if either by explicit request or local policy
options 12 and or 15 are also returned to the client, then they MUST be
aligned with the name returned by this option. [Barr]

[ ... stuff deleted ... ]