Post by Alfred HönesI guess everybody once saw RFC 3397 as a functional replacement
for option 15, since the DSL (#119) allows a compact representation
of multiple domain names by making use of domain name compression
as in the DNS protocol. (This pretty much matches your previous
comment on space conservation.)
Not precisely. There is some value in informing some clients of their
'domain name', as being separate from their domain-search list. Although at
one time these two were one in the same (and in time, people began to
identify with it only for domain search behavior), the domain name can
actually feed other behaviors, and is useful to some clients separately from
their domain-search configuration.
We have actually heard a proposal not too long ago to add a domain-name
option to the DHCPv6 lineup of options for this purpose.
Post by Alfred HönesFrom a DNS resolver implentation point of view, any system that
supports the configuration of a DSL would admit and prefer a _list_
of domain names, if it's the intent of the administrator to provide it.
Since, for a conceptual domain search, list order matters,
whereas the order of different DHCP options is arbitrary,
it does not make sense to have both options in a DHCP response.
It is certainly true that it would be inappropriate to concatenate the two
together in some way.
Note that some DNS resolvers (as configured from /etc/resolv.conf for
example) are sensitive to the order in which these options are configured.
Configuring the domain-search path before the domain-name results in an
implicit domain-seach path equal to the domain-name, which probably isn't
what the client desires.
It's not very tractable to reference all of these client-specific behaviors
for digesting configuration state in IETF protocols. So far it doesn't seem
to have been a problem to ask clients to do what they find the most useful.
Post by Alfred Höneso DHCP servers SHOULD implement option 119; it looks like good
implementations should have the ability to send a single
domain name supplied by their configuration for a particular
client (or group of clients) in either #15 or #119 format;
Sure, I guess. Most DHCP servers support arbitrary options anyway - you
generally do not need a software upgrade to support new option definitions,
but instead have some facility to configure a value for any option code.
Seems like this would lack teeth.
o DHCP clients that would like to get domain search information
Post by Alfred HönesSHOULD request option 119; if it is configured with a domain
search list by other means, it SHOULD NOT request either
(note that a configured DSL MUST NOT be overwritten via DHCP);
o DHCP clients SHOULD NOT request both options 119 and 15,
unless they have an implementation-specific way to resolve
ambiguities resulting from both being received;
That's not useful. A client that supports both domain-name and
domain-search-list is better served by requesting both, because it cannot
predict what the server 1) is capable of and 2) is configured to supply. A
good implementation would wish to operate in whatever environment it finds
itself.
o DHCP servers SHOULD supply options 15 and 119 only if they
Post by Alfred Höneshave been requested to do so; gratuitous supply is a waste
of packet space (see note on preconfigured DSL above);
I don't know why you would enumerate this since it is explicit in RFC 2131
Parameter-Request-List (PRL) processing. Unless you are trying to specify a
behavior for when the PRL is not present, that is different from that
specified in RFC 2131? Let me suggest that this is not a useful
enumeration. If there is some DSL client implementation that concerns you,
it may be better to simply reference RFC 2131 on the subject of conformance.
Post by Alfred Höneso DHCP servers SHOULD ignore requests to supply both #15 and #119
and only send #119 in such case.
That's ridiculous. We are not going to start updating, testing, and
distributing DHCP software every time there's a new option out the door that
looks familiar, and encode special rules for specific code points in DHCP
parser code. The rules and exceptions just to make a DHCP packet would grow
without bounds.
If domain-name and domain-search both appear on the PRL, and both are
configured, send both. Sure, it wastes packet space in the order of tens of
octets, big deal.
If you want to preserve DHCPv4 payload space, Ted Lemon long ago suggested a
much more useful general platform - instrumenting the PRL so that clients
could specify sets of options of which they only want one option in reply.
Servers that don't support the instrumenting option codes simply wouldn't
have values to return for those codes anyway, and just wouldn't have the
space savings benefit. Realistically, this has never been an issue to date,
so no one has looked towards implementing this (but as time wears on, it
continues to be a growing threat).