RE: [dhcwg] Host Name option considerations draft

[Richard Barr Hibbs <[e-mail]>]

RE: [dhcwg] Host Name option considerations draft
  -----Original Message-----
  From: Bernie Volz (EUD) [mailto:[e-mail]]
  Sent: Tuesday, March 05, 2002 12:30

   Barr, I believe regarding your issue:

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

  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.

  Bernie:  of course, that is a simple way to parse the name, but it ignores
multi-part host names (such as "mike.inside.sales") -- I'll agree that it is
probably the only way that a server or client could parse the name, absent
much additional information

   ---

  >      "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 like this better than what Mike was suggesting because I could easily
see a
  case, such as your (2) below that should work and thus the client can not
simply
  see if the Host Name has one or more dots to determine whether it is fully
qualified.
  I would suggest that (a) if the host name has NO dots, the client should
add the
  domain name. If the host name has one or more dots, the client should only
add
  the domain name if the host name does not end in the domain name.

  >2.  Host Name:  "mike.inside.sales"
  >    Domain Name:  "bluebear.co.uk"

  Bernie-- examples always help:

  suppose a client receives my example (2) --  the correct FQDN should be
"mike.inside.sales.bluebear.co.uk"

  if the client were to receive Host Name:
"mike.inside.sales.bluebear.co.uk" and Domain Name: "bluebear.co.uk" then a
simple string comparison yields the same result by preventing duplication of
"bluebear.co.uk"

  but what if the client were to receive Host Name:
"mike.inside.sales.bluebear" and Domain Name: "bluebear.co.uk" -- in this
contrived example, we know the correct result, but in general, I don't think
you can assert that two sequential parts of a name cannot be duplicated.  It
really depends entirely on how the RR's for the domain "bluebear.co.uk" are
recorded in DNS.  I'll defer to the experts on name matching for DNS as to
whether names like "bluebear.bluebear.co.uk" are permitted.

  ---

  Perhaps I missed it, but can we be clear about whether the trailing dot
MUST NOT
  be included. And, for backwards compability, a client (and server) should
remove
  any trailing dot if it does exist (this applies to the Host Name, Domain
Name,
  and FQDN options).

  your comments also suggested that clients should be prepared to deal with
malformed host names, such as names ending with a separator (dot) or two
consecutive separators -- they don't have to correct malformed names, but
should be prepared to handle them in a predictable way.

  ---

  One thing that wasn't clear to me (and perhaps it is specified in RFC
2131?), but
  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.

  This raises the questions of what should the client do if it "requests" a
host name by sending one in the discover message, but the server responds
with a name the client doesn't like?  Who owns the name (Carl tried to cover
that point) and what recourse is there for a client who doesn't like an
offered option value?  Some additional discussion may be needed.


  --Barr