Mark Mc Nicholas <
[hidden email]> wrote:
> Below are the config's of DHCPD & Bind,
> ====DHCPD Config====
>
> ddns-updates on;
> ddns-update-style interim;
> update-static-leases on;
> key sun-key { algorithm hmac-md5; secret "123456789";}
> allow unknown-clients;
> use-host-decl-names on;
>
> zone i.home.ie.{
> primary moto.i.home.ie;
> key sun-key;
> }
>
> # Common to all subnets
> option domain-name "home.ie";
> default-lease-time 1800;
> max-lease-time 14400;
> authoritative;
> allow unknown-clients;
>
> subnet 172.17.2.0 netmask 255.255.255.128 {
> range 172.17.2.41 172.17.2.100;
> default-lease-time 1800;
> max-lease-time 14400;
> authoritative;
> option routers 172.17.2.1;
> option domain-name-servers 172.17.2.4,192.168.252.1 ;
> option domain-name "i.home.ie";
> option domain-search "i.home.ie";
> option ntp-servers 193.1.219.116,193.1.31.66;
> ddns-domainname "i.home.ie.";
> ddns-rev-domainname "in-addr.arpa.";
>
> host skynet09{
> hardware ethernet AC:CF:23:8D:10:60;
> fixed-address 172.17.2.39;
> ddns-hostname "skynet009";
> }
> }
The first thing to note is that you have a host declaration within a subnet. Host declarations are always global in scope, but do have inheritance - this can cause some "interesting" effects if the client pops up on another subnet. So, while it's not directly relevant to the problem you are enquiring about - put your host declarations in the global scope and save yourself some pain later on ;-)
> Bind Logs of an Update
>
> named[1563]: client 172.17.2.4#28949: updating zone 'i.home.ie/IN': update unsuccessful: skynet001.i.home.ie: 'name not in use' prerequisite not satisfied (YXDOMAIN)
> named[1563]: client 172.17.2.4#28949: signer "sun-key" approved
> named[1563]: client 172.17.2.4#28949: updating zone 'i.home.ie/IN': deleting rrset at 'skynet001.i.home.ie' A
> named[1563]: client 172.17.2.4#28949: updating zone 'i.home.ie/IN': adding an RR at 'skynet001.i.home.ie' A
> named[1563]: client 172.17.2.4#28949: signer "sun-key" approved
>
> DHCP Logs for the same device
> dhcpd[6271]: DHCPREQUEST for 172.17.2.31 from ac:cf:23:8d:77:56 via eth0
> dhcpd[6271]: DHCPACK on 172.17.2.31 to ac:cf:23:8d:77:56 via eth0
> dhcpd[6271]: Added new forward map from skynet001.i.home.ie. to 172.17.2.31
> dhcpd[6271]: Added reverse map from 31.2.17.172.in-addr.arpa. to skynet001.i.home.ie.
OK, that's all normal.
But, I see 172.17.2.31 is not in the range (172.17.2.41 to 172.17.2.100) defined for dynamic clients, so I'm guessing that you have trimmed out a host declaration for skynet001 ? If so, then the answer is simple - DNS entries for these hosts are not automatically removed, because there is no mechanism to do so.
More detail on that.
When a host gets a lease from a static address assignment in a host declaration, there is no lease created by the server to go with it. Because it's a static assignment, there's no need to track it, and so there's a shortcut where from the client PoV it gets a lease, but the server doesn't bother recording it.
As there is no lease recorded by the server, there's nothing to expire, and so nothing to trigger removal of the corresponding DDNS entries.
Also, without the "update-static-leases on;" statement, you also would not get DNS updates on "lease" issue.
If you need DDNS updates to remove the entries, then you'll have to use "real" leases. You can get much the same effect by creating a "reserved" lease. You can do this (AIUI) on a running server via OMAPI, or after stopping the server you can do it by editing the leases file to add/edit a lease with the "Reserved" keyword.
A reserved lease acts just like any other dynamic lease (gets issued, renewed, expires, etc) except that it will never be re-assigned to another client.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Locked
