AW: Extending dynamic address range w/ DDNS

[Frank Stanek]

Hello,

of course you are correct. How could I have overlooked this?! :)
It's working as intended now. Thank you very much!

Also thanks for the hint about the .0 and .255 addresses. We
haven't had any trouble with those so far, I guess all the clients
we have don't have any problems with these any more. But I have
made a remark in our documentation so we think about it if we
ever encounter any strange behavior.

Regards
Frank



----- Originalnachricht -----
Von: "Simon Hobson" <dhcp1 at thehobsons.co.uk>
Gesendet: Die, 16.3.2010 14:00
An: "Users of ISC DHCP" <dhcp-users at lists.isc.org>
Betreff: Re: Extending dynamic address range w/ DDNS

Frank Stanek wrote:

>we have been assigned a /22 IP address range for internal use. Of this
>range we have been using a /24 range for dynamic clients with DDNS
>updates (dhcpd 3.0.3, BIND 9.4.3-P3), the other three /24 ranges are
>currently reserved for static hosts and other things. On the BIND
>side we have one static forward zone and one dynamic one. As for the
>reverse zones we have four: one dynamic zone and three static ones (one
>for each of the /24 ranges).
>
>The relevant part of the dhcpd configuration looks like this:
>subnet 172.16.0.0 netmask 255.255.252.0 {
>     authoritative;
>     range 172.16.2.0 172.16.2.255;
>     default-lease-time 172800;
>     max-lease-time 345600;
>     zone dynamic.intern. { primary 127.0.0.1; key key_ddns; }
>     zone 2.16.172.in-addr.arpa. { primary 127.0.0.1; key key_ddns; }
>     allow unknown-clients;
># ...
>}
>
>Now this dynamic range is getting too small because of an increase
>in the number of dynamic clients. We tried to extend the range like
>this
>range 172.16.1.30 172.16.2.255;
>but then obviously only the 2.16.172.in-addr.arpa. zone will get updated,
>not the 1.16.172.in-addr.arpa. zone. Adding the 1.16.172 zone does not
>work because it seems dhcpd does not recognize which zone should be updated
>based on the IP address it hands out.

Take the zone declarations out of the subnet declaration, they should 
be in the global scope.
Define zones for both 1.16.172.in-addr.arpa and 2.16.172.in-addr.arpa 
and it should all happen automagically.

Also, while it is in fact completely valid to have 172.16.1.30 to 
172.16.2.255 in one range, in practice it has been advised to leave 
.0 and .255 out - apparently there are some badly behaved clients 
that can't cope with .0 or .255 on the assumption that they are 
network and broadcast addresses. So you would split the range thus :
pool {
   range 172.16.1.30 172.16.1.254;
   range 172.16.2.1 172.16.2.254;
}
-- 
Simon Hobson

dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users