Re: [dhcwg] Host Name option considerations draft

[Carl Smith <[e-mail]>]

	OK.  This

> *corollary one* -- the Domain Name option also SHOULD NOT be
> fully-qualified

I didn't understand, but this

> I meant that we should discourage both the Host and Domain
> Name options from containing identical information -- a client
> implementation could, of course, deal with it in some consistent way, but it
> really would be better practice to avoid confusing duplications of data --
> and the best way really is if the Host Name and Domain Name options do not
> contain identical or overlapping information

certainly makes sense.

> > > 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.
> >
> ...look at what you wrote, again:  in the first part you specified the
> client sending the Host Name OPTION and in the second, requesting the Host
> Name in the Parameter Request List -- the two are not the same thing, which
> is where my disagreement arose.

	Yes, I know they're not the same thing (which is why I wrote that
``perhaps a bit more should be said'' when I extended it to include the
Parameter Request List.  There are now two questions to consider

	-  if a client sends a Host Name option and the server responds with
	   a different name from the one the client requested, what must the
	   client do?

	-  if a client requests a Host Name option be returned, must it accept
	   the value the server returns, or choose to use its own?

The language in the draft addresses only the first of these:  if a client sends
a Host Name option and the server responds with a Host Name option, the client
needs to use the value the server returned, not continue the use of the one it
(merely) requested.
	The second one is more tenuous, but I believe the same argument can be
made:  by requesting a Host Name option be returned, is the client agreeing to
use the value or is it just hoping to get lucky?  If it's the latter, then the
client should instead simply ask DNS what name corresponds to the address the
server leased it.

> > 	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.
> >
> ...hard to fight a nearly 90% market share, though.....

	Who's fighting?  We're merely writing a document that captures what the
WG feels good implementations ought to do.  Someone with 90% market share could
easily ignore us, but at least we've given vendors a description of what we'd
like to see them do.  If we don't at least do that, we'll not have those good
implementations to choose from when we get the opportunity to do so.

> > >    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).
> >
> ...I'm not convinced that having just the Domain Name option is sufficient,
> but my major issue is really our expectation of behavior seems to be placing
> more of a burden on clients than they can be relied upon to perform....

	Yep, I believe that's true.  Servers always had to be written to
protect themselves from bad clients.  In this case the burden is more on
the clients to protect themselves from bad servers.

> > > 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.
> >
> ...good point, although I will assert that if a client uses a different FQDN
> in the DNS update from what it would be expected to construct from Host Name
> and Domain Name, then that client is seriously broken....

	Agreed.  The only question I had was whether we had data that would
suggest it was worthwhile to insist that servers perform the check.

> > | 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.
> >
> ...and I've also seen instances where clients certainly don't follow these
> guidelines, but expect that option values won't change between an offer and
> an ack.  A reasonable expectation is that certain values (e.g., Host Name
> and Domain Name) will not be changed by the server.

	I'm happy to add something to this draft that says the Host Name's
value should not change, but as you suggest the problem is larger than just
one or two options.

			Carl

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg