Re: [dhcwg] Option 119 (Domain Search Option) and Option 15 (Domain Name Option)

[David Hankins <[e-mail]>]

On Tue, Nov 30, 2010 at 12:53 PM, Alfred HÎnes <[e-mail]> wrote:

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

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

Therefore, I propose the following rules:
>
>  o  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
>    SHOULD 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
>    have 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.


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