Subject: DHCP Domain Name

From: Stuart Cheshire <[email-masked]>
Date: Tue, 22 Feb 2000 20:24:54 -0800

I can't believe how vague the RFCs are some times:

>3.17. Domain Name
>
>   This option specifies the domain name that client should use when
>   resolving hostnames via the Domain Name System.
>
>   The code for this option is 15.  Its minimum length is 1.
>
>    Code   Len        Domain Name
>   +-----+-----+-----+-----+-----+-----+--
>   |  15 |  n  |  d1 |  d2 |  d3 |  d4 |  ...
>   +-----+-----+-----+-----+-----+-----+--

This is obviously supposed to be a fully qualified domain name, since it 
is specifying the default domain to use for *unqualified* name lookups 
when the user types something like "telnet bob".

Does that mean that it is supposed to be a fully qualified domain name 
ending in a dot, i.e. "apple.com."?

Or, since we know it *must* be a fully qualified domain name, is the 
final trailing dot superfluous?

Am I supposed to assume that the final trailing dot

(c) MUST be present
(b) MUST NOT be present
(c) MAY or MAY NOT be present (but the client MUST treat all domain names 
as fully qualified whether or not they have a trailing dot)?

The server I generally use for testing doesn't give any clue -- it just 
lets the administrator type in whatever they want and sends that as the 
Domain Name option (even if it begins with digits or contains illegal 
characters like spaces).

Stuart Cheshire <[email-masked]>
 * <A HREF="http://ResComp.Stanford.EDU/~cheshire/">Web Page</A>
 * Wizard Without Portfolio, Apple Computer

---

From: "HIBBS, BARR (SBCSI)" <[email-masked]>
Date: Wed, 23 Feb 2000 09:25:53 -0800

> I can't believe how vague the RFCs are some times:
...so what else is new....??

> when the user types something like "telnet bob".
...oops!  option 15 is NOT the "Fully-Qualified Domain Name (FQDN)" because
it lacks the hostname portion (carried in option 12)....

...are we having fun yet?

> ending in a dot, i.e. "apple.com."?
...no...  it should be considered the string to be appended to the hostname
portion (option 12), with a period (.) inserted between the two....

> final trailing dot superfluous?
...a trailing period should NOT be present....

> as fully qualified whether or not they have a trailing dot)?
...(b)... with the added caveat that option 15 is NOT the FQDN, just the
domain name part....

> Domain Name option (even if it begins with digits or contains illegal 
...with apologies to Robert Elz and others, Domain Names MAY begin with ANY
character except the separator (period) and may contain ANY character
(again, the separator cannot be used as an element of the name).  However,
and this is a BIG gotcha, there are many cases where such Domain names DON'T
work with existing implementations of everything from mail service to web
browsers....  There is no simple over-arching rule for how to construct
domain names that work in all circumstances, so there cannot be a simple
rule covering the contents of the options 12 and 15 strings....

--Barr

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 28 Feb 2000 15:28:16 -0800

>option 15 is NOT the "Fully-Qualified Domain Name (FQDN)"
>because it lacks the hostname portion (carried in option 12)....
>
>it should be considered the string to be appended to the hostname

Sadly, this answer left me more confused than before I asked the 
question. I'll try again, limiting myself to binary questions this time.

1. If I want to specify one or more search domains that the client should 
try for unqualified DNS name lookups (i.e. the equivalent of the "search" 
directive in /etc/resolv.conf) is option 15 the correct option?

[YES] / [NO]

2. If yes, is the name fully qualified? (I already know that it is NOT a 
HOST name -- that's not what I'm asking. It is the name of a domain 
within which the client should search. Is it the fully qualified name of 
that domain, or can it be relative to something else?)

[Fully qualified] / [Relative]

3. If fully qualified, is the name supposed to end with a dot, like other 
fully qualified names are supposed to (but rarely do)?

[YES] / [NO]

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 28 Feb 2000 16:05:47 -0800

>> 1. If I want to specify one or more search domains that the client
>> should try for unqualified DNS name lookups (i.e. the equivalent of
>> the "search" directive in /etc/resolv.conf) is option 15 the correct
>> option?
>> 
>> [YES] / [NO]
>
>No.  The DHCP protocol currently provides no mechanism for the server
>to hand this information to the client.  It must be configured directly
>on the client.
>
>Mark Sirota, Technical Lead, Network Systems and Services
>University of Pennsylvania, Information Systems and Computing
>[email-masked], 215/573-7214

>option 15 is the name of the domain of which the host is a member, but
>is unrelated to the domain name(s) that should be searched by the host

Well, that sucks. One more thing that Mac OS has been doing wrong for all 
these years.

(Why does RFC 2132 say, "This option specifies the domain name that 
client should use when resolving hostnames..."? It seems like there is a 
missing "does not" in that sentence.)