Join Log in
Score:0
mt42 avatar Server

ISC-DHCP and BIND 9 DNS: DDNS update fails for /27 subnet

ph flag
mt42

I have a problem with DDNS update with ISC-DHCP server.

My /etc/dhcp/dhcpd.conf subnet section that doesn't work is:

subnet 193.198.186.192 netmask 255.255.255.224 {
  range 193.198.186.200 193.198.186.222; # MT 20211210
  option subnet-mask 255.255.255.224;
  option domain-name-servers 161.53.235.3, 161.53.2.70;
  option domain-name "slava.alu.hr";
  ddns-domainname "slava.alu.hr";
  zone slava.alu.hr. {
   primary 127.0.0.1;
   key DDNS_UPDATE;
  }
  zone 192-27.186.198.193.in-addr.arpa. {
   primary 127.0.0.1;
   key DDNS_UPDATE;
  }
  option broadcast-address 193.198.186.223;
  option routers 193.198.186.193;
  default-lease-time 43200;
  max-lease-time 86400;
}

My network delegation for my 193.198.186.192/27 is a literal 192/27.186.198.193.in-addr.arpa. and they do not appear willing to change it.

See here:

root@domac:~# host -t any 193.198.186.195
195.186.198.193.in-addr.arpa is an alias for 195.192/27.186.198.193.in-addr.arpa.
195.192/27.186.198.193.in-addr.arpa domain name pointer test-record.slava.alu.hr.
root@domac:~#

This mandates my /etc/bind/named.conf.local entry to:

zone "192/27.186.198.193.in-addr.arpa" in {
        type master;
        file "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
        allow-update { key DDNS_UPDATE; };
};

However, ISC DHCPd considers an "/" in zone name a syntax error.

Is there a way to tell to either BIND or ISC DHCPd to accept different names in /etc/bind/named.conf.local and /etc/dhcp/dhcpd.conf zone declarations?

When I change declaration in dhcpd.conf to:

  zone 186.198.193.in-addr.arpa. {
   primary 127.0.0.1;
   key DDNS_UPDATE;
  }

and /etc/bind/named.conf.local entry to:

zone "186.198.193.in-addr.arpa" in {
        type master;
        file "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
        allow-update { key DDNS_UPDATE; };
};

then dynamic DHCPd update works:

Dec 10 15:42:59 domac dhcpd[11512]: DHCPREQUEST for 193.198.186.211 from e8:48:b8:5b:8c:46 (LAPTOP-MTODOROV) via 193.198.186.193
Dec 10 15:42:59 domac dhcpd[11512]: DHCPACK on 193.198.186.211 to e8:48:b8:5b:8c:46 (LAPTOP-MTODOROV) via 193.198.186.193
Dec 10 15:42:59 domac dhcpd[11512]: Added new forward map from LAPTOP-MTODOROV.slava.alu.hr to 193.198.186.211
Dec 10 15:42:59 domac dhcpd[11512]: Added reverse map from 211.186.198.193.in-addr.arpa. to LAPTOP-MTODOROV.slava.alu.hr

and I can see it from my DNS server's realm:

root@domac:~# host laptop-mtodorov.slava.alu.hr
LAPTOP-MTODOROV.slava.alu.hr has address 193.198.186.211
root@domac:~# host -t any 193.198.186.211
211.186.198.193.in-addr.arpa domain name pointer LAPTOP-MTODOROV.slava.alu.hr.
root@domac:~#

... but now the DNS delegation is broken. I can't possibly have the entire 186.198.193.in-addr.arpa. zone for our domain's subnet, and neither will they approve dynamic updates on the central DNS server.

I can't seem to have both, unless there is a way to instruct DHCP or BIND to add to a zone with a different name in BIND from that in DHCP.

I seem to be running out of options.

Thank you very much if you know an answer.

Kind regards, Marvin

P.S.

I have tried the following and it did not work:

zone "192-27.186.198.193.in-addr.arpa" in {
        type master;
        file "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
};

zone "186.198.193.in-addr.arpa" in {
        type master;
        file "/var/cache/bind/192-27.186.198.193.in-addr.arpa.db";
        allow-update { key DDNS_UPDATE; };
};

(Two zones with the same file.)

What I got was:

root@domac:/etc/bind# named-checkconf
/etc/bind/named.conf.local:49: writeable file '/var/cache/bind/192-27.186.198.193.in-addr.arpa.db': already in use: /etc/bind/named.conf.local:44
root@domac:/etc/bind#

Nice try :-( The programmers were clever enough to prevent this hack!

Any idea how to make two zones refer to the same zone database, one that would match the assigned delegation zone, and the other that would match the 186.198.193.in-addr.arpa zone that ISC DHCP only knows how to update?

  1. I have even tried to enclose 192/27.186.198.193.in-addr.arpa in quotes to avoid the syntax error, and I got this:

    Dec 10 23:17:45 domac dhcpd[26555]: /etc/dhcp/dhcpd.conf line 187: expecting hostname. Dec 10 23:17:45 domac isc-dhcp-server[26545]: /etc/dhcp/dhcpd.conf line 187: expecting hostname. Dec 10 23:17:45 domac isc-dhcp-server[26545]: zone "192/27.186.198.193.in-addr.arpa." Dec 10 23:17:45 domac isc-dhcp-server[26545]: ^ Dec 10 23:17:45 domac isc-dhcp-server[26545]: Configuration file errors encountered -- exiting Dec 10 23:17:45 domac isc-dhcp-server[26545]: exiting. Dec 10 23:17:45 domac dhcpd[26555]: zone "192/27.186.198.193.in-addr.arpa."

So, this didn't work either. The only hope is finding a way to use the same DNS zone database with two zone names. That isn't so rare case I suppose, there should be a provision for such case?

Marvin

63
0 + 0
Patrick Mevzek avatar
cn flag
Patrick Mevzek
See RFC2317 again for the in-addr.arpa classless delegation. It is only the CNAME records that should have the names with the `/` which is then legit for a CNAME, but indeed not legit for a NS (delegation). If you have a CNAME to `129.128/26.2.0.192.in-addr.arpa.` the zone to delegate is `2.0.192.in-addr.arpa.` So in your case the delegation should be for `186.198.193.in-addr.arpa` not `192/27.186.198.193.in-addr.arpa` and then adjust the resource records in it of course.
0
Reply
mt42 avatar
ph flag
mt42
I understood that DHCP wants to update `186.198.193.in-addr.arpa`, and it cannot syntactically handle `192/27.186.198.193.in-addr.arpa`. But I was delegated `192/27.186.198.193.in-addr.arpa` from the upper level admins and I can't change that. I can't dynamically update to that zone either. I thought of two zone names sharing the same file database ... One zone defined for delegation and read-only, and the other for DDNS updates from DHCP with the same database. Will BIND 9.1.5 allow for such hack? I am reading the BIND reference, but no such case appeared ...
0
Reply
mt42 avatar
ph flag
mt42
I cannot dynamically or otherwise update `186.198.193.in-addr.arpa` for I am neither an owner nor am I allowed dynamic updates to that zone. It is shared by several organizations. I have to think of a workaround. It is the problem because public, non-NAT IP addresses are being assigned over NAT.
0
Reply
mt42 avatar
ph flag
mt42
I am also delegated `192/27.186.198.193.in-addr.arpa` from the upper level and I cannot change that either. I have to think of using both names for the same zone data, one read-only and the other dynamically updated by ISC DHCP.
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
"I cannot dynamically or otherwise update 186.198.193.in-addr.arpa for I am neither an owner nor am I allowed dynamic updates to that zone. It is shared by several organizations." Which is exactly what RFC2317 deals with. Have a look at it.
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
Also you can use any zone name in fact and replace `/` by `-` if simpler for your use case. It is spelled out in the RFC: The examples here use "/" because it was felt to be more visible and pedantic reviewers felt that the 'these are not hostnames' argument needed to be repeated. We advise you not to be so pedantic, and to not precisely copy the above examples, e.g. substitute a more conservative character, such as hyphen, for "/". </quote>. Note the "not hostnames" so it explains why you can't use them as hostnames later on, that is on purpose.
0
Reply
Patrick Mevzek avatar
cn flag
Patrick Mevzek
"I thought of two zone names sharing the same file database ... " You can, but not with dynamic updates.
0
Reply
mt42 avatar
ph flag
mt42
Until a better solution emerges, I have used the workaround described here: https://serverfault.com/questions/806875/how-to-tell-isc-dhcp-correct-zone-for-reverse-zone-ddns-update Thank you anyway, Patrick!
0
Reply
mt42 avatar
ph flag
mt42
I've read the RFC 2317 in entirety, but I do not own the delegation zone so I cannot change or replace `/` by `-`. I was forced to dynamically update an auxiliary zone and delegate CNAME records from delegated zone to the dynamically updated aux zone. But this is a workaround and a trick. Resolvers are sometimes confused with multiple CNAME redirections. A real solution would be to update DHCP source to add a zone alias directive (in quotes, so it could syntactically process the `/`), so it could update zones like `192/27.186.198.193.in-addr.arpa`.
0
Reply
mt42 avatar
ph flag
mt42
Zone alias directive is just a thought that occurred, any method of updating sub /24 subnets would do :-)
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.