On 2009, Oct 21, at 00:14, [email protected] wrote:
> asfar as I know DHCP can only assign one default domain, you can
> however
> set a series of search domains. Check to see if that solves your
> problem.
On 2009, Oct 21, at 08:23, Jeremy Charles wrote:
> There is indeed an RFC that provides a DHCP option for this.
> However, our testing and a bunch of Google both seem to agree that
> the option doesn't take a lot of effect. The root of the problem is
> that DHCP clients don't tend to request that option from the DHCP
> server.
These messages prompted me to re-visit this since I had looked at it
at one time several years ago and was unable to get it working when it
was merely academic to me, but I have a need for it now and figured
I'd follow-up on the research to see what the current state-of-the art
was.
To my pleasant surprise I discovered that in at least one case it does
work and I have a little more work to do to find if it works on more
systems than just my initial test.
I'm using ISC DHCP 3.1 and it appears they added the following option
in this version [from 'man dhcp-options']:
> option domain-search domain-list;
>
> The domain-search option specifies a 'search list' of
> Domain Names to
> be used by the client to locate not-fully-qualified
> domain names.
> The difference between this option and historic use of
> the domain-
> name option for the same ends is that this option is
> encoded in
> RFC1035 compressed labels on the wire. For example:
>
> option domain-search "example.com", "sales.example.com",
> "eng.example.com";
Note particularly the format of the arguments on that option as some
of the initial web searches had me trying something like this:
> option domain-search "example.com sales.example.com eng.example.com";
That is wrong, be sure to use the separately quoted domains as in the
man page:
> option domain-search "example.com", "sales.example.com", "eng.example.com
> ";
Looking deeper it looks like it should have been possible with the
older 3.0 as well if you manually encoded the domain elements using a
length-value encoding:
> option domain-search code 119 = text;
> option domain-search "\007example\003com\000\005sales\007example
> \003com\000\003eng\007example\003com\000";
But I have not verified that in practice.
On the client side I've successfully tested Mac OS 10.6 and had some
problems with Windows XP (as is typical for me, I'll be grabbing one
of the more experienced Windows people here after some meetings to do
more testing there).
Here are some of the references I found in my journey:
The definitive source on the DHCP option:
RFC3397: Dynamic Host Configuration Protocol (DHCP) Domain Search
Option
<http://tools.ietf.org/html/rfc3397>
A random Microsoft page showing they should have some level of domain-
search support:
DHCP Search Options
<http://technet.microsoft.com/en-us/library/dd572752(office.13).aspx>
The mailing-list post showing what my error was back when I tried this
previously with ISC DHCP 3.0:
Subject: setting the DNS search string
<https://lists.isc.org/mailman/htdig/dhcp-users/2009-March/008326.html>
And most importantly, the man page for the new ISC DHCP version that
actually contained a correct example, though I need to submit a
documentation bug report since the section on "domain-list" that
described the string format as needed for "domain-search" does not
reflect what is actually needed and is more correctly depicted farther
down in the same document.
> The big show-stopper for us is that our VPN system (Cisco ASA with
> the Anyconnect client) simply refuses to allow passing of more than
> a single "default domain" to the clients. We do have a product
> enhancement request in with them, but you never know what the result
> will be on those sorts of things.
That sounds annoying, good luck with the RFE!
Hope this helps,
Philip
_______________________________________________
Tech mailing list
[email protected]
http://lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
http://lopsa.org/
