DNS Domain in DHCP question?

[Kyle McDonald]

Nikolai Lusan wrote:
> Greetings all,
>
> Firstly I'd like to point out that this really isn't bind related at
> all, and should probably be somewhere to do with whichever dhcp server
> you are using.
>   
Ok. I appologize. I thought I's find an audience here with more chance 
of having seen this problem, and able to provide helpfull suggestions. 
In hindsight I should have gone to a DHCP server list though I guess.
>
> On Mon, 2008-10-06 at 14:10 -0400, Kyle McDonald wrote:
>   
>> I actually liked the fact that the 'domain' directive in the resolv.conf 
>> used search parent domains automatically. (aside: Any pointers to the 
>> discussions around the logic of turning that behavior off? I'm curious 
>> to learn :) )
>>     
>
> Well you can "turn it off" by not having a search parameter in there at
> all.
>
>   
Yes. I can use 'domain' instead. But in this case not using search 
doesn't help, because as I said, 'domain' no longer works as it used to.


The RFC 1535 I just read (which has valid security concerns and I 
understand it all better now,) appears to have been around a while. This 
explains the switchover I saw a while ago to using search in preference 
to domain. However for the longest time the resolvers I were using still 
allowed the old behavior for 'domain'. So switching got me the old 
behavior back.

> How do you figure that there is no point in having search domains in a
> *nix resolv.conf? this method allows users and programs to simply refer
> to machines by a short name and have the system resolve them correctly
> by appending the search domains one at a time and searching those for
> resolution. This is still a useful function.
>
>   
Recently I've noticed that the old behavior of  'domain' is gone, so for 
example this:

domain one.two.three.com

is now no different than:

search one.two.three.com

So I had asked "why ever use 'domain'?" I don't think that's an 
unreasonable question.

Reading the RFC mentioned above, it appears that at least some resolvers 
allow the resolv.conf to configure (define the bouandary between local 
and public DNS control) this locally. That seems like a good comprimise, 
I'll have to look into that, but I'm not sure how I'll get the DHCP 
client to put this in the dynamically created resolv.conf.

>> I can't seem to get DHCP to supply both foo.bar.com and bar.com, so my 
>> real question is, What do other people do to solve, or work around this 
>> problem??
>>     
>
> DHCP only allows for a singe domain-name option (this is the domain name
> that should be appended to the machine name to give the FQDN). If you
> want more than one search domain there there is more than one way to
> specify it:
>   
At the risk of taking this post off-topic again,
>        1) have a static resolv.conf with your search domains and
>           nameservers configured, then tell dhcp-client not to update 
>           the resolv.conf file.
>   
That kind of defeats the purpose of using dynamic host configuration, no?
>        2) use a tool like resolvconf to control how the resolv.conf is 
>           built this way you can specify your search domains and have 
>           them included in the file every time.
>   
I've never heard of this, this is a tool that is used locally on the 
client to configure how the resolv.conf is made from the info DHCP 
returns? I'll have to look into that.
>        3) use a tool like puppet to control the contents of the 
>           resolv.conf file after the network is up (warning: this will
>           most likely result in your resolv.conf changing regularly as
>           dhcp timeouts occur and then puppet rebuilds the file again.).
>
>   
That doesn't sound right, if the package above will work for me.
> Not all thing DNS are relevant to BIND.
>
>   
Good point. I appologize.

   Thanks for the help.

      -Kyle