Subdomains for DHCP-enabled clients

Kevin Darcy kcd at daimlerchrysler.com
Wed Apr 4 21:40:33 UTC 2007


Off-topic. This is not a DHCP list.

I've already given my recommendation that you use FQDNs exclusively. If 
you follow that advice, then the absence or presence or contents of DHCP 
Option 15 are of no consequence. If you ignore that advice, you're on 
your own.

                                                                         
                                    - Kevin

Phusion wrote:
> On 4/3/07, Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>   
>> Phusion wrote:
>>     
>>> I have been working on setting up DHCP and DNS and have been having
>>> problems with dynamic DNS for the DHCP enabled clients. I have a zone
>>> file for test.com for servers, etc, and another zone for DHCP-enabled
>>> clients named mdnlan.test.com. Currently, the DHCP-enabled clients get
>>> an IP address and have a computer name of hostname.mdnlan.test.com.
>>> These clients use dynamic DNS and update the mdnlan.test.com zone
>>> file. Servers have DNS names of hostname.test.com and accordingly are
>>> in the test.com zone file. Here is an example of what I can't get
>>> working. Here are the computer names.
>>>
>>> DNS server = smdndns.test.com
>>> Test PC (DHCP client) = testpc.mdnlan.test.com
>>>
>>> Ping from testpc.mdnlan.test.com to smdndns = fails
>>> Ping from testpc.mdnlan.test.com to smdndns.test.com = works
>>>
>>> Ping from smdndns.test.com to testpc = fails
>>> Ping from smdndns.test.com to testpc.mdnlan.test.com = works
>>>
>>> I assume the problem has to do with the domain suffix or domain search
>>> list. How can I go about changing this on the server so computers on
>>> both domains can talk to each other. Also, I would prefer not to have
>>> to manually add the server entries to both the test.com zone and the
>>> mdnlan.test.com zone file.
>>>
>>>
>>>       
>> You don't change this on the server, you change this on the client. For
>> a DHCP-enabled client, you can supply a "domain name" option (Option
>> #15) from the DHCP server, which should be honored by the client.
>> Otherwise, you'll need to statically configure the client with this.
>>
>> Generally speaking, though, from a DNS infrastructure perspective, it's
>> better to get into the habit of using FQDNs (fully-qualified domain
>> names) for everything. That gives you the most efficient DNS resolution,
>> with no ambiguity.
>>
>>
>>                                     - Kevin
>>
>>
>>
>>
>>     
>
> Here is a copy of my current dhcpd.conf file for the DHCP-enabled clients.
>
> option domain-name "mdnlan.test.com";
> option domain-name-servers smdndnsp1.test.com;
> option option-176 code 176 = string;
>
> default-lease-time 1800;
> max-lease-time 3600;
> authoritative;
> ddns-domainname "mdnlan.test.com";
> ddns-update-style interim;
> one-lease-per-client true;
> pid-file-name "/var/run/dhcpd.pid";
> log-facility local7;
>
> key mdnlan {
>         algorithm HMAC-MD5.SIG-ALG.REG.INT;
>         secret yfmizFMbQwJGDEAscbDv9+bnnxHUkzKoNbDvBm8pUEiwBZBkjEFni5RDvE9l5eRh5iVa9DzZaEo/iqLSErL6Pg==;
> };
>
> zone 1.1.10.in-addr.arpa. {
>         key mdnlan;
>         primary 127.0.0.1;
> }
>
> zone mdnlan.test.com. {
>         key mdnlan;
>         primary 127.0.0.1;
> }
>
> subnet 10.1.1.0 netmask 255.255.255.0 {
>   option routers 10.1.1.1;
>   pool {
>     range 10.1.1.100 10.1.1.150;
>   }
> }
>
> Let me know if I should make a change.
>
> Phusion
>
>
>
>
>   



More information about the bind-users mailing list