Re: [dhcwg] Host Name option considerations draft

	Thanks to Barr and Bernie for the comments.

>       if a DHCP server supplies both Host Name and Domain Name
>       options to a client, the host name SHOULD NOT be fully-
>       qualified
> 
> *corollary one* -- the Domain Name option also SHOULD NOT be fully-qualified

	I'm being slow in understanding what you're asking here.
Is it that we should say the Domain Name option SHOULD NOT contain
the host name?

> *corollary two* -- the name formed by concatenating Host Name and Domain
> Name MUST be the Fully-Qualified Domain Name of the host, that is, there
> should be no other prefixes or suffixes added to the Host Name and Domain
> Name parts in creating the FQDN

	Including, as Bernie pointed out, language clarifying what to do
with a trailing dot.

>       if a DHCP server supplies only a Host Name option, the host
>       name SHOULD be fully qualified; the server MUST append only DNS
>       domain names in forming a fully-qualified name
> 
> Carl, I don't understand your point here:  if the Host Name part IS
> fully-qualified, how can any other information be added to it and make an
> understandable name?  For example, if the Host Name part is
> "rabbit.warren.org" what could be appended that makes any sense?

	I see this caused more confusion than it was intended to prevent.  :-)
The point is this:  in constructing the FQDN, the server should use only
DNS, and not be distracted by any of the other naming services which also
claim to have domain names.

>       a client MUST check to see whether a Host Name option contains
>       a fully-qualified name and if so, MUST NOT append the value of
>       the Domain Name option (if present) in forming its fully-
>       qualified domain name
> 
> Carl, I think "MUST" is too strong here, plus I think this wording calls for
> a specific level of sophistication in a client where it really should be an
> implementation decision.  Having said that, if I understand this point
> correctly, to mean that you are trying to guide a client so that invalid
> FQDNs are not unintentionally created, I agree with the concept.  How about
> wording such as:
> 
>       "a client SHOULD check for the presence of both Host Name
>       and Domain Name options, forming the FQDN by appending the
>       Domain Name to the Host Name.  A client MAY wish to compare
>       the Host Name option to the Domain Name option to verify
>       that the Host Name option does not include the Domain Name
>       part before concatenating the parts."

	I'd prefer to invert this if it allows us to keep the MUST:

	a client MUST NOT attempt to form its FQDN by concatenating
	the values of the Host Name and Domain Name options without
	first verifying that the Domain Name value is not already
	present (i.e. as the suffix) in the Host Name value

>       since a Host Name option's value may be fully-qualified only by
>       supplying the DNS domain name, a client that receives a fully-
>       qualified name in the Host Name option MAY infer the DNS domain
>       name from the suffix of the supplied host name.  This inference
>       remains valid even in the presence of client configuration
>       information or policies that prefer other name services in
>       favor of, or in place of, DNS.
> 
> Carl, I don't understand what you're saying here.  Perhaps a few examples
> will show you my confusion:
> 
> 1.  Host Name:  "mike"
>     Domain Name:  "inside.sales.bluebear.co.uk"
> 
> 2.  Host Name:  "mike.inside.sales"
>     Domain Name:  "bluebear.co.uk"
> 
> 3.  Host Name:  "mike.inside.sales.bluebear.co.uk"
>     Domain Name:  ""
...
> In (3), the Host Name *is* the FQDN, but how do I parse it properly into a
> "DNS domain name" given that simple rules such as "use the last two parts of
> the name" (which works for things like "dot.com") renders the DNS domain
> name as "co.uk" which I don't think is what you intend.

	Bernie's take on it is what is intended:

| The host would remove the first label to produce the Domain Name, hence
| "inside.sales.bluebear.co.uk". That's all it can and should do.

> 4.1 DHCP Client Considerations and Behavior
> 
>    A DHCP client that uses the Host Name option to request a DNS
>    update MUST be prepared to independently verify the success or
>    failure of the request before using the name in a manner that
>    would imply its validity.  If a DHCP server returns the requested
>    name in the DHCPACK's Host Name option, the client MAY infer that
>    the server has honored its request.
> 
>    There are a number of reasons that a DHCP server may fail to
>    return a Host Name option, so nothing should be inferred from the
>    option's absence in the DHCPACK.  The client MAY supply the option
>    on subsequent RENEW operations as a method of retrying the
>    request.  However, if the Host Name option is absent in the
>    DHCPACK, the client MUST NOT use the requested name until it has
>    verified the validity of the association between it and the IP
>    address supplied in the yiaddr field.  Moreover, if the name
>    returned in the DHCPACK is different from the one requested, the
>    client MUST use the new name.
> 
> So, are you implying that (1) if a client does not request a Host Name
> option from the server [typical of several widely-deployed clients!] but (2)
> the server returns a Host Name option anyway in a DHCPACK, the client should
> accept the [presumably] unwanted name?  I think this will break a whole lot
> of deployed clients.

	That's not the intention.  First, a clarification:  the point is
that if a client sent the Host Name option, it MUST accept the value that
the server returns.  Upon further reflection, perhaps a bit more should
be said:  if a client requests a Host Name via the Parameter Request List,
it MUST accept the value the server returns.
	Second, on a more general note, there's no intention to break extant
implementations, only to outline what we believe correct behavior is today.
However, I don't believe we ought to soften the language (e.g. turn MUSTs
into SHOULDs) simply to cater to those implementations.

>    A DHCP client MAY send either an unqualified or fully-qualified
>    name in the Host Name option.  Clients sending unqualified names
>    are implicitly relying on DHCP servers to associate the clients
>    with the appropriate zone before issuing any updates to DNS.  A
>    DHCP client in INIT state SHOULD fill in the requested host name
>    in the DHCPDISCOVER packet.  It MUST do so in its subsequent
>    DHCPREQUEST packet.
> 
> Here, again, I don't know how the server can reliably parse an FQDN sent in
> the Host Name option.

	It's assumed that the server has some configuration information
that will help it make this decision (for example, the value of a client's
Domain Name option).

> 4.2 DHCP Server Considerations and Behavior
> 
>    Use of the FQDN option makes it possible to easily separate update
>    operations into pieces corresponding to what are thought of as the
>    traditional ownership boundaries:  DHCP servers own the addresses
>    they lease, while the clients own their names.  This boundary is
>    not present when the Host Name option is used:  the implied proxy
>    update request assumes that the DHCP server has sufficient
>    privilege to change both the A and PTR records.  That is, it
>    ``owns'' both.
> 
>    For this and other reasons, use of the FQDN option is preferred:
>    a DHCP server that receives both a Host Name option and a client
>    FQDN option MUST prefer the FQDN option.  In such a case, the
>    server SHOULD behave as if the Host Name option is not present.
> 
> I'm inclined to go further and suggest:
> 
>    "If a server receives both the Host Name option and the FQDN
>    option from a client [for whom DNS updates are being proxied] the
>    fully qualified name formed by appending the Domain Name to the
>    client-supplied Host Name MUST be identical to the FQDN option
>    for the server to update DNS on behalf of the client.  The server
>    SHOULD return an error to the client if the names do not match."
> 
> This is something that has always bothered me about the FQDN option and the
> DHCP-DNS update protocol -- is a mismatch an unintentional accident or an
> attempt to confuse and invalidate DNS records?

	I'd be interested in hearing how many vendors feel the extra
checking this would require would have aided in uncovering either client
confusion or DNS subversives at work.

| One thing that wasn't clear to me (and perhaps it is specified in
| RFC 2131?), bu t for a client REQUEST, does (MUST) a client send the
| Host Name and FQDN options the server sent in the OFFER, or MUST it
| send what it originally sent in the DISCOVER?  From this draft, it
| would appear it MUST send what was in the DISCOVER and not what the
| server may have sent back.

	The closest I could find in 2131 were these two

3.5
	If the client includes a list of parameters in a DHCPDISCOVER
	message, it MUST include that list in any subsequent DHCPREQUEST
	messages.

4.3.2
	If the client included a list of requested
	parameters in a DHCPDISCOVER message, it MUST include that list in
	all subsequent messages.

both of which deal with presence, but do not address a change in value
between DISCOVER and REQUEST.

			Carl

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg