2

I maintain a large DNS zone using BIND 9.8.2 on RHEL 6. Let's call it example.edu. It has a main zone file for example.edu as well as subdomains with separate zone files like abc.example.edu, qrs.example.edu and xyz.example.edu all of which allow 'interim-style' dynamic DNS updates from our DHCP server (RHEL 5, ISC-dhcpd version 3.0.5). An example DHCPD configuration might contain:

shared-network "Some DATA VLAN 220 10.102.32.0/23" {
    subnet 10.102.32.0 netmask 255.255.254.0 {
            option subnet-mask 255.255.254.0;
            option routers 10.102.32.1;
            option domain-name "qrs.example.edu";
            ddns-domainname "qrs.example.edu";
            default-lease-time 86400;
            max-lease-time 86400;

            range 10.102.32.5 10.102.32.247;
            range 10.102.33.5 10.102.33.247;
            group {
                    option domain-name "qrs.example.edu";
                    ddns-domainname "qrs.example.edu";
            }
    }
}

And everything in this configuration works as expected (yes, the domain options in the group { } stanza are redundant, we'll get to that later). The zone file for qrs.example.edu gets updated automatically as new hosts are assigned to or removed from it and everything is right with the world.

However, if we want to use a group { } stanza to change the subdomain that a host gets registered in, we start to see inconsistent behavior. Using the following:

shared-network "Some DATA VLAN 220 10.102.32.0/23" {
    subnet 10.102.32.0 netmask 255.255.254.0 {
            option subnet-mask 255.255.254.0;
            option routers 10.102.32.1;
            option domain-name "qrs.example.edu";
            ddns-domainname "qrs.example.edu";
            default-lease-time 86400;
            max-lease-time 86400;

            range 10.102.32.5 10.102.32.247;
            range 10.102.33.5 10.102.33.247;
            group {
                    option domain-name "abc.example.edu";
                    ddns-domainname "abc.example.edu";

                    host foo
                    {ddns-hostname "foo"; fixed-address 10.102.33.248; hardware ethernet 00:11:22:aa:bb:cc;}
            }
    }
}

We see the zone file for example.edu is updated (not the one for abc.example.edu) with the DNS configuration of:

$ORIGIN abc.example.edu
$TTL 86400    ; 1 day
foo             A        10.102.33.248
                TXT      "31ThisIsSomeHostnameHashFromDHCP"

Which is broken, since the host A record is not in the abc.example.edu zone file so it can be resolved. FWIW, PTR records work fine from what I'm able to tell, since they're not as broken up and the forward zone is.

So, if you've stayed with me so far, my question is: why do we see this behavior discrepancy when using the domain-name or ddns-domainname configuration options in a group { } stanza vs. a subnet { } stanza?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.