Set domain and search entries correctly

[Sven]

The problem occures, if you want your DHCP server to deliver the
domain-search entries too.

The dhcp-option for this is #119 (RFC3397).

 Example in dhcpd.conf:
  option dns-domain-search-list code 119 = string;
  option dns-domain-search-list "private.anders.local anders.local";

If you use the 'domain-name' option instead

  option domain-name "private.anders.local anders.local";

it will work under Linux (it will create a 'search' line), but other
systems (like MacOSX) will fail (because they create a 'domain'
line, which did not allow more than one domain entry).

If would be better, if the 'domain-name' option will create the 'domain'
line in the '/etc/resolv.conf' and use the (correct) option to set
the 'search' line.

The patch tries to make it backward compatible and sets the 'search'
line, as before but only sets the first domain name as 'domain'.

[Sven (anders-anduras)]

This is the patch to correct the problem.

[Sven (anders-anduras)]

I'm running Ubuntu Edgy with dhcp3 version: 3.0.4-6ubuntu6

[Sven (anders-anduras)]

To work correctly you should also adapt the config of the dhclient.
(file: /etc/dhcp3/dhclient.conf).

You only have to add the new option and a request for it.

[Martin Pitt (pitti)]

Hmm, defining a new option in dhclient.conf looks a bit weird -- shouldn't this go into the actual code?

[Sven (anders-anduras)]

Not all (even too few) options are supported by default. Don't ask my why...

As you can see here:
  http://www.iana.org/assignments/bootp-dhcp-parameters
this as an official option.

So defining it, is a normal procedure (as we do it ourselves every day).

[Sven (anders-anduras)]

I updated the patch for Feisty.
(And corrected it, because it was reversed...)

[Andrew Pollock (apollock)]

ObRelevance: I'm the Debian dhcp3 maintainer, and I've been extensively testing domain-search support in DHCP 3.1.x in Debian

The domain-search attribute is a new type, not a string, which is encoded differently on the wire.

Adding

  option dns-domain-search-list code 119 = string;

to dhcpd.conf and/or dhclient.conf will probably work fine if both the client and the server are the same pre-3.1.x version, but if the server is 3.1.x or some other server that supports the domain-search option correctly, it'll be sending it as the new domain list type, which will most probably get mangled by the client if understood at all.

I do not recommend hacking such functionality into pre-3.1.x versions of DHCP. I also do not consider the functionality to be production-ready yet in 3.1.0 (and 3.1.1 is not looking much better yet either).

[Sven (anders-anduras)]

Andrew Pollock schrieb:
> ObRelevance: I'm the Debian dhcp3 maintainer, and I've been extensively
> testing domain-search support in DHCP 3.1.x in Debian
>
> The domain-search attribute is a new type, not a string, which is
> encoded differently on the wire.
>
> Adding
>
> option dns-domain-search-list code 119 = string;
>
> to dhcpd.conf and/or dhclient.conf will probably work fine if both the
> client and the server are the same pre-3.1.x version, but if the server
> is 3.1.x or some other server that supports the domain-search option
> correctly, it'll be sending it as the new domain list type, which will
> most probably get mangled by the client if understood at all.
>
> I do not recommend hacking such functionality into pre-3.1.x versions of
> DHCP. I also do not consider the functionality to be production-ready
> yet in 3.1.0 (and 3.1.1 is not looking much better yet either).
>

Hmm, I do not understand. I the RFC I found it's a string (see below).
Did I misinterpreted it?

And I'm using here a dhcp-3.0.4 server and a dhcp-3.0.6 client - without problems.
Furthermore I'm using MacOS-X which honour the flag and it's working correctly
too...

Where did you read that it's a new type? And what format?

From the RFC3397:
-----------------
2. Domain Search Option Format

   The code for this option is 119.

    0 1 2 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 119 | Len | Searchstring...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Searchstring...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In the above diagram, Searchstring is a string specifying the
   searchlist. If the length of the searchlist exceeds the maximum
   permissible within a single option (255 octets), then multiple
   options MAY be used, as described in "Encoding Long Options in the
   Dynamic Host Configuration Protocol (DHCPv4)" [RFC3396].

Regards
 Sven Anders

--
 Sven Anders <email address hidden> () Ascii Ribbon Campaign
                                                 /\ Support plain text e-mail
 ANDURAS service solutions AG
 Innstraße 71 - 94036 Passau - Germany
 Web: www.anduras.de - Tel: [phone] - Fax: [phone]

Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032
Mitglieder des Vorstands: Sven Anders, Marcus Junker
Vorsitzender des Aufsichtsrats: Dr. Thomas Träger

[Andrew Pollock (apollock)]

If you look at the source code, which is always a wonderful place to achieve enlightenment, in common/tables.c, in the comments, you'll see it talks about option names, formats and codes. In 3.1.0, they added a new option code, D, which is a domain list. This is different from the various string types that have already existed.

I'm very surprised that a pre 3.1.0 DHCP server with a manually set DHCP option for domain-search is being correctly interpreted by MacOS X, but hey, if it works, and you can't wait for the 3.1 series to stabilise, knock yourself out. I guess you're only at risk of breaking people who try to use the option.

[Sven (anders-anduras)]

Andrew Pollock schrieb:
> If you look at the source code, which is always a wonderful place to
> achieve enlightenment, in common/tables.c, in the comments, you'll see
> it talks about option names, formats and codes. In 3.1.0, they added a
> new option code, D, which is a domain list. This is different from the
> various string types that have already existed.
>
> I'm very surprised that a pre 3.1.0 DHCP server with a manually set DHCP
> option for domain-search is being correctly interpreted by MacOS X, but
> hey, if it works, and you can't wait for the 3.1 series to stabilise,
> knock yourself out. I guess you're only at risk of breaking people who
> try to use the option.

Ok, I archived enlightment! ;-)

As far as I understand (by taking a quick look at the code), they only
introduced a new type because the domain search list is compressed
using a special technique described in RFC1035. This technique uses
pointers to prior occurrences. In the RFC3397 using the techique is a
MUST, but because it only saves space it works without using it too.
In the configuration file and the resolv.conf file it's always a
string.

I will try to use the 3.1 release of the dhcp3-client and we will see,
if this solves my problems. Thanks for the hint!

Regards
 Sven

--
 Sven Anders <email address hidden> () Ascii Ribbon Campaign
                                                 /\ Support plain text e-mail
 ANDURAS service solutions AG
 Innstraße 71 - 94036 Passau - Germany
 Web: www.anduras.de - Tel: [phone] - Fax: [phone]

Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032
Mitglieder des Vorstands: Sven Anders, Marcus Junker
Vorsitzender des Aufsichtsrats: Dr. Thomas Träger

[Steve Langasek (vorlon)]

Is this bug still an issue in jaunty, which has dhcp3 3.1.1?

[Sven (anders-anduras)]

It works for me in the following configuration:

DHCP Server 3.1.1 on Intrepid
Client with NetworkManager 0.7.1 on Jaunty

[Clint Byrum (clint-fewbar)]

No +1's, no more comments, and purportedly at least one person saw it as fixed in Jaunty. Closing as Fix Released.