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

From: [email-masked] (by way of Ralph Droms)
Date: Sun, 28 Mar 1999 13:40:56 -0500 (EST)

message sent to [email-masked] by [email-masked] follows.
------------------------------------------------------------------
    Date:        Fri, 26 Mar 1999 18:39:39 -0500
    From:        Mark Stapp <[email-masked]>
    Message-ID:  <[email-masked]>

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

OK, that makes more sense.  I do think the text needs to be written more
with that slant in that case.

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

All I meant was that the server should never do any updates unless it has
the necessary credentials.   I would have thought that a self evident
restriction, though I may have phrased it badly.

  | The fqdn option is a DHCP option, and it's currently an ASCII string like
  | the existing host-name and domain-name options.

Is it?   I didn't see where the draft says that.   I'm also not sure
about the host-name option.   It's been a while since I checked, but I
had the impression that the host name in that option was just a counted
sequence of bytes (since it has no defined internal structure there's no
need for anything more, and no rationale for it either).

The domain name option I agree, that's a problem.

  | I'm inclined to leave it
  | that way unless there's clear agreement that it's insufficient.

By duplicating DNS format encoding you're guaranteeing that you can
represent any FQDN that the DNS can represent, which has to be sufficient.
As soon as you start altering the representation, difficulties can result
later.   Eg: there is some demand for a better specification of domain names
in international character sets, not just ascii (and also some resistance).
What will happen there isn't clear yet (it is pretty clear that basically
nothing needs to be done to the basic DNS spec to achieve it though).
It would be a pity if it turns out that limitations on DHCP restrict names
more than the DNS will allow.  One obvious example is that to use a pure
text form, some quoting scheme is needed to embed the "problem" characters
(like '.') when they form a part of a label, as distinct from being the
separator betwwwn labels.   The DNS allows that, its packet format doesn't
even notice, and it has defined quoting methods to embed such things in
zone files.   But a quoted name can be longer than 255 bytes (in its
quoted form), and would not fit in your fqdn option.   In DNS binary format
none of that can be an issue - whatever happens, the DNS binary packet limits
are pretty much set in concrete required to maintain compatability.

Unless there's a very good reason to use text formats (in which case the
actual text format to use needs to be precisely stated, don't just assume
it is "obvious", it isn't) using the DNS binary format in any protocol which
is basically carrying binary encoded date (which DHCP certainly is) seems
like an obvious "right" choice to me (even if it does mean an extra few lines
of code to deal with it).

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

Ah, I see what you mean, this occurs only when a client is attempting
to confirm (and usually extend) its lease.   I think it would not hurt to
add something to make that clear, lest anyone be tempted to read the text
as implying that servers have some mechanism for arbitrarily terminating
client leases, without client co-operation.   (It is a thing I occasionally
see people asking how to do, since it is basically impossible to achieve,
avoiding anyone being given a "but see RFCnnnn where it says ..." type
argument).

  | The sentence you've quoted appears immediately after this one: "The
  | following describes behavior of a DHCP client that implements the Client
  | FQDN option."

Sure, but "implements" and "desires to use" aren't the same thing.

  | Sites whose administrators don't care about this option can
  | use clients which don't implement it.

That is unreasonable.   As you say ...

  | Hopefully, the cooperation that the
  | draft describes is useful, and clients will implement it.

Yes, hopefully clients will implement it.   Hopefully all clients will
implement it.   That doesn't mean that all sites will desire to use it.
And if all clients implement it, the "use a client which doesn't implememt
it" option for the site goes away...

Avoid over specification - unless there is a very good operational reason
for a MUST, don't give one.    The only reason I can see for requiring
the client to include the FQDN option is when it is requesting the server
to do something with the data.   In that case, obviously the server needs
the value from the option to be able to function.   If the server isn't
required to do anything with the fqdn, then there's no reason for the
client to supply the data - regardless of whether or not the clients
implementation supports it, and regardless of what dynamic dns interactions
the client may intend to make.

  | Dangling names are seen as a very real administrative problem in many
  | organizations.

Sure, and they're seen as no problem at all in others.

  | There are popular clients which do release their leases, and
  | their behavior needs to be accounted for in the draft.

Yes, I agree.

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

That's a value judgement, in what should be something left to individual
sites to determine which they prefer.   Some certainly prefer that stray
names be deleted when they're not in use.  Others may prefer that the names
be left as they were until they need to be updated to reflect the next address
they obtain.   Others may prefer that the A record be deleted, and replaced
by a TXT record (or something) as a placeholder, so the name is retained, but
the old A record isn't.    This is all for local site determination, and
need not be specified by this draft.

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

What will be useful in this area isn't clear yet.   I'm not sure that its
certain that the dnssec add on for secure updates (secupd) will survive
in anything like its current form, or ever be implemented.  Perhaps.  It
may just turn out that tsig (or something more like it) is sufficient to
cover all dynamic update cases.   Since none of this is deployed anywhere
yet, we just dont' know.

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

What started me wondering, was in attempting to determine whether the
server could provide any information which would assist the client in
sending the data for the fqdn option.   There's the easy case where the
client has simply been configured, via some other means, with its desired
fqdn (which may happen for workstations, and similar things, which have a
user sitting in front of them).  That is pretty straight forward.   But for
devices with no human around to configure the fqdn, but where the device
might just know enough of what it thinks it ought be called as a hostname
at least.   But the domain name in which that name ought be installed
is likely to be unknown.   The question is whether the server might supply
a domainname option in the dhcpoffer response to the dhcpdiscover,  and
then the client construct its full name for the fqdn in the dhcprequest
packet from that domain name.    Is that reasonable, simply wrong, ...

Sometimes it seems to me that seeing a simple example (the most simple
probably most common case) and a complex example (with everything done the
most perverse way that you can imagine it might be) can illustrate the
reasonable usage boundaries of the protocol.

Thanks for the response (and I'm still not on the dhcp-v4 list).

kre