I have inherited management of a set of AD servers running AD-backed DNS. One of them is running DHCP.
For IP ranges which are served by this Windows DHCP server, the in-addr.arpa zones are being served authoritatively by the AD DNS servers to allow AD to be happy with itself and allow dynamic DNS to work properly.
For each of these in-addr.arpa zones, I am also pulling secondary from my unix/linux name servers running BIND9.
I have begun frequently seeing errors like this in my logs on the *nix servers:
Jun 8 13:40:07 ns1 named: general: warning: '184.108.40.206.in-addr.arpa/PTR/IN': TTL differs in rdataset, adjusting 900 -> 1200
I understand from a technical, DNS-perspective what is happening here. There are >1 records for the 220.127.116.11.in-addr.arpa and they have different TTLs. BIND is normalizing the TTLs and informing me about it. I have confirmed that this is the case by grabbing a manual AXFR of the zone:
ns1 0 /home/jj33 ># xfer 37.19.172.in-addr.arpa ad-dns | grep '^3\.' < 18.104.22.168.in-addr.arpa. 900 IN PTR 0509-l3-tmbxt.example.ad. 22.214.171.124.in-addr.arpa. 1200 IN PTR 0402-3p2jf41.example.ad.
In looking at the Windows DNS and DHCP tools, it seems very likely based on the lease time that 0402-3p2jf41.example.ad either returned its lease or went away and never came back, allowing the lease to expire. 0509-l3-tmbxt.example.ad came along, picked up the IP, and inserted its name for the 126.96.36.199.in-addr.arpa record.
So, with all the explanation done, I have several questions:
- In the DDNS process, who actually defines the TTL of the reverse record? The DNS server, the DHCP server, or the DHCP client?
- Why are the stale in-addr.arpa records not being deleted? Should the DNS server know to delete existing DDNS names when a new DDNS name is submitted?
- Why would this suddenly start occurring? This system has been running for years with this only happeneing a coupld of times before, and always with the same IP address. In the last few days it has happened multiple times with multiple IPs.
- Would scavenging help? We don't currently have it turned on. While I'm going to look into it for its own merits, I'm not sure it would help in this situation since the default seems to be 7 days before scavenging.
- Does this situation require action, or if I ignore it will "something" purge the stale records eventually (I really, really hate waiting for divine intervention, but it seems odd that we wouldn't have faced this before).
Aside from the questions, can anyone share any hard-won experience related to this issue? Thanks.
UPDATE 1: It appears that, on a per-RR level, scavenging is actually turned on. It is turned on at the DNS server level, it is turned off at the zone level, and now that I have the advanced view turned on I can see that it's turned on for dynamically-inserted records as well. So, it's not an issue of scavenging not working, it's an issue of the 7 day lag plus the (apparently new?) TTL differences.
UPDATE 2: The DHCP scope also has "Discard A and PTR records when lease is deleted" checked. This feels like a failure on the part of the DHCP server since the lease for the original PTR is gone from the DHCP server...
Thanks for your answers so far. I'm digesting them and gathering information to see if the noise I'm seeing is a lot of records generating a few logs each or a few records generating a lot of logs each. Also, auditing my PTRs to see if this double-record thing is common but I'm only noticing it because the TTLs have started to mismatch. I'm leaning toward this being a non-issue that scavenging will address but I'd still like to understand where the differing TTLs come from