0

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

mt42
  • 121
  • 4
  • 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. – Patrick Mevzek Dec 10 '21 at 16:31
  • 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 ... – mt42 Dec 10 '21 at 21:53
  • 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. – mt42 Dec 10 '21 at 22:00
  • 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. – mt42 Dec 10 '21 at 22:03
  • "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. – Patrick Mevzek Dec 10 '21 at 22:35
  • 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 "/". . Note the "not hostnames" so it explains why you can't use them as hostnames later on, that is on purpose. – Patrick Mevzek Dec 10 '21 at 22:35
  • "I thought of two zone names sharing the same file database ... " You can, but not with dynamic updates. – Patrick Mevzek Dec 10 '21 at 22:38
  • 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! – mt42 Dec 11 '21 at 00:39
  • 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`. – mt42 Dec 14 '21 at 09:00
  • Zone alias directive is just a thought that occurred, any method of updating sub /24 subnets would do :-) – mt42 Dec 14 '21 at 09:10

0 Answers0