Por que esse comportamento de atualização de DNS dinâmico do DHCP é inconsistente?

Question

Eu mantenho uma grande zona DNS usando o BIND 9.8.2 no RHEL 6. Vamos chamá-lo de example.edu . Ele tem um arquivo de zona principal para example.edu , bem como subdomínios com arquivos de zona separados, como abc.example.edu , qrs.example.edu e xyz.example.edu , que permitem atualizações de DNS dinâmicas no estilo 'temporário' do nosso servidor DHCP (RHEL 5, ISC-dhcpd versão 3.0.5). Um exemplo de configuração do DHCPD pode conter:

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";
            }
    }
}

E tudo nessa configuração funciona como esperado (sim, as opções de domínio na sub-rotina group { } são redundantes, veremos isso depois). O arquivo de zona para qrs.example.edu é atualizado automaticamente conforme novos hosts são atribuídos ou removidos e tudo está certo no mundo.

No entanto, se quisermos usar uma sub-rotina group { } para alterar o subdomínio no qual um host é registrado, começaremos a ver um comportamento inconsistente. Usando o seguinte:

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;}
            }
    }
}

Observamos que o arquivo de zona para example.edu está atualizado (não o de abc.example.edu ) com a configuração de DNS de:

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

O que está quebrado, já que o registro A do host não está no arquivo abc.example.edu zone, portanto, ele pode ser resolvido. FWIW, os registros PTR funcionam bem do que eu sou capaz de dizer, já que não estão tão fragmentados e a zona de redirecionamento é.

Então, se você ficou comigo até agora, minha pergunta é: por que vemos essa discrepância de comportamento ao usar as opções de configuração domain-name ou ddns-domainname em uma sub-rotina group { } vs. a subnet { } estrofe?