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

From: Mark Stapp <[email-masked]>
Date: Fri, 26 Mar 1999 19:15:08 -0500 (EST)

Robert,

Many thanks for the thorough comments. My responses are inline:

At 09:52 PM 3/26/99 +1100, Robert Elz wrote:
>I have a few difficulties with some of what is in
>
>	draft-ietf-dhc-dhcp-dns-09.txt
>
>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.

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.

>
>  It should probably actually say that it MUST NOT attempt
>to update the A record in any other case.
>
>

I don't think that's correct: the client might not send anything, or the
server might be configured to perform the update (possibly because only it
has the necessary credentials) whether the client sets this flag or not
(see section 3, para. 3).

>
>Then, something, somewhere, needs to actually say explicitly that each of
>the Flags, RCODE1 and RCODE2 fields is one byte long.   That's strongly
>suggested, but never actually stated.  
>

Will do.

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

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

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

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

>
>I believe that the implication that a client using TSIG will automatically
>have authority to update any name in a zone is incorrect.   That might be
>true, but isn't necessarily true (as I understand TSIG).  A TSIG association
>is simply an agreement between a server and a client - that is, it is the
>evidence of that agreement having been made in the past.   Exactly what
>authority that grants to the client is stated nowhere at all, anything is
>possible to be contained in the agreement that TSIG is evidence of.
>It would be quite possible (if a maintenance nightmare) for a server to
>have established separate TSIG associations with every potential client,
>annd then to allow each TSIG association permission to update exactly one
>A record, and nothing else.
>

I believe you're right, and I think it's likely that sites which wish to
have secure dns updates initiated by clients will use DNSSEC. TSIG will be
very useful for sites whose dhcp servers are performing updates.

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

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

>
>Lastly, in this day and age, I think it would be appropriate to incorporate
>into the text for this option the appropriate language to indicate that the
>same thing applies to IPv6 just as it does for IPv4.   There's nothing
>specific to either of those in this option - if the DHCP server is supplying
>an IPv4 address to the client, it should do the appropriate IPv4 (A and PTR)
>updates, if it is supplying an IPv6 address to the client it should update
>the A6 (or AAAA) and whatever is chosen for the PTR equivalent for v6.
>To avoid having this draft hung up on normative references to fluctuating
>ipngwg drafts, I'd just use generalities indicating that if IPv6 addresses
are
>being assigned (using DHCPv6) then updates ought to be made "in a similar way
>to the appropriate RRs".
>
>kre

I'll add a sentence like the one you've quoted to section 2 at the
beginning of the draft.

>
>ps: There's an instance (at least one) of FQND in the text (a typo).
>There are a couple of references to section 7 being the security
>considerations, which is actually section 5 (7 is references, which
>could confuse someone who was sent there to look for security implications).
>

Thanks - I'll clean them up.

Mark