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

From: Mark Stapp <[email-masked]>
Date: Mon, 5 Apr 1999 10:27:55 -0400 (EDT)

Barr,

Thanks very much for your comments. It sounds to me as if we're converging
on a couple of points. First, the issue of domain-name encoding. I'm very
concerned about breaking the population of existing MS clients which speak
this option. I'd like to suggest that we use the third bit in the fqdn
option's 'flags' field to indicate the nature of the encoding. A zero in
that position will indicate that the fqdn is ASCII, a one will indicate
that DNS encoding has been used. Clients should use dns encoding, and the
server should reply with the encoding that the client has used.

Second, you describe very clearly one of the administrative situations in
which the DHCP server has a role that's central to the maintainance of DNS
information. As you describe it, dhcp administrators do not want to give
access to DNS to arbitrary clients, and do not want to oversee key
distribution to every 'trusted' client. They'd even prefer not to
distribute complete domain names to their DHCP clients manually, relying
instead on DHCP replies to tell the clients about the domains they're in
dynamically. The more centrally managed servers are the authoritative
source for DNS updates, and may even be the authoritative source for
clients' hostnames. Since the servers are 'on' all of the time, they are
less likely to leave orphaned DNS names. That's a model that must be
supported by the draft.

Under the policy you describe, DHCP servers need to be able to tell clients
that the servers will perform A and PTR updates, since the servers know
that the clients do not have the appropriate credentials to do so. In
addition, the DHCP servers need to be able to inform clients of the domain
name that will be representing the client. I think both of those properties
are in the current draft, in that the server can use the option's flags to
indicate to the client that the server will perform both DNS updates. I
will try to make the 'local policy' case clear, and I will make explicit
the possibility that the server may return an fqdn option (and/or
host-name+domain-name option pair) that is meant to tell a client what DNS
name it has, rather than just echoing the client's choice.

A few more comments inline:

At 11:08 AM 4/2/99 -0800, HIBBS, BARR (PB) wrote:
>
>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]
>

I used the word "arbitrary" in the sense of "unpredictable", to mean that
the what the server will do should be controllable and defined. I agree
that the DHCP server may be the authority for the DNS naming of DHCP
clients, and that a client's DNS name may bear no resemblance to the 'host
name' that a Win95 user configures into his or her own PC.

>[ ... 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]
>

Agreed.

[ snip... ]

>
>> >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]
>

There has been a proposal for 'expirable' DNS records, but I don't know how
far it has gotten. There's an important trade-off here: if the records
don't expire, the updaters don't have to refresh them as the clients'
leases are extended, and that saves work and complexity. If clients are
going to perform updates, and if we believe that clients may be shut down
or moved frequently, then expirable records will be very useful.

>[ ... 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]
>

Yes, I'll add an appendix to the next revision.

>> >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]
>

This is reasonable, but I'm a little concerned about the encoding issue. If
the fqdn option uses DNS encoding, the fqdn data may need to be re-encoded
mapped to fit into the existing host-name and domain-name options.

Mark