Linux DNS problems

Maybe even that posting was too much information. Simplified to 3 questions:

1) Are DNS journal files supposed to automatically get rolled into the zone files? Mine are not. They grow to 10's of thousands of lines. If they are supposed to, why would mine not be doing so? If they are not supposed to, next questions ...

2) Since my journal files grow forever, I use `rndc -V sync -clean` to update the zone file. Is this command supposed to clean out the journal file completely? It does not do so for me. If it is supposed to, why wouldn't mine be getting cleared? If not, next question ...

3) After running `rndc -V sync -clean` my journal files still contains all the hosts in the LAN, but more importantly, it still contains hostnames and IP that haven't been used for 6 months to over a year. Why are these still in the journal file? Som of these entries are interfering with current hosts having the same IP.

1) DDNS entries are saved in the journal file.  If you want to dump them, freeze and thaw the zone(s).

2) The entries may get written to the ascii db file but the journal file never goes away.

3) The entries persist until you remove them.

I did do the freeze/thaw thing. Are you saying that these ancient zone and journal entries NEVER go away unless manually removed? Seems like that makes the expiration times in the zone files pointless. How does one remove entries from the journal file anyway? They aren't ASCII. Will removing them from the journal, then freeze/thaw remove them from the zone file? I thought DNS was more automatic than this. Seems like a lot of ongoing work for network administrators.

I''l check out nsupdate after this post.

DHCP does do updates, here is the relevant bit of dhcpd.conf:

authoritative;

# see http://blog.bigdinosaur.org/running-bind9-and-isc-dhcp/
ddns-updates on;
update-static-leases on;
allow unknown-clients;  # default, deprecated (man dhcpd.conf)
ignore client-updates;  # see https://www.centos.org/forums/viewtopic.php?t=29256, man dhcpd.conf: ignore clien
t-updates
ddns-update-style interim;
default-lease-time 86400;

Select allOpen in new window

And clients do seem to update themselves. One example of a Windows client:

Apr 12 01:41:27 mail dhcpd: DHCPREQUEST for 192.168.0.52 from 00:24:8c:0f:f1:d0 via eth1
Apr 12 01:41:27 mail dhcpd: DHCPACK on 192.168.0.52 to 00:24:8c:0f:f1:d0 via eth1
Apr 12 01:41:27 mail named[8179]: client 192.168.0.2#60256: updating zone 'hprs.local/IN': update unsuccessful: charmaine.hprs.local: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Apr 12 01:41:27 mail named[8179]: client 192.168.0.2#60256: updating zone 'hprs.local/IN': deleting rrset at 'charmaine.hprs.local' A
Apr 12 01:41:27 mail named[8179]: client 192.168.0.2#60256: updating zone 'hprs.local/IN': adding an RR at 'charmaine.hprs.local' A
Apr 12 01:41:27 mail named[8179]: client 192.168.0.52#54261: updating zone 'hprs.local/IN': deleting rrset at 'charmaine.hprs.local' AAAA
Apr 12 01:41:27 mail named[8179]: client 192.168.0.52#54261: updating zone 'hprs.local/IN': deleting rrset at 'charmaine.hprs.local' A
Apr 12 01:41:27 mail named[8179]: client 192.168.0.52#54261: updating zone 'hprs.local/IN': adding an RR at 'charmaine.hprs.local' A
Apr 12 01:41:27 mail dhcpd: Added new forward map from charmaine.hprs.local. to 192.168.0.52
Apr 12 01:41:27 mail named[8179]: client 192.168.0.2#60256: updating zone '0.168.192.in-addr.arpa/IN': deleting rrset at '52.0.168.192.in-addr.arpa' PTR
Apr 12 01:41:27 mail named[8179]: client 192.168.0.2#60256: updating zone '0.168.192.in-addr.arpa/IN': adding an RR at '52.0.168.192.in-addr.arpa' PTR
Apr 12 01:41:27 mail dhcpd: Added reverse map from 52.0.168.192.in-addr.arpa. to charmaine.hprs.local.
Apr 12 01:41:27 mail named[8179]: client 192.168.0.52#57983: updating zone 'hprs.local/IN': deleting rrset at 'charmaine.hprs.local' AAAA
Apr 12 01:41:27 mail named[8179]: client 192.168.0.52#57983: updating zone 'hprs.local/IN': deleting rrset at 'charmaine.hprs.local' A
Apr 12 01:41:27 mail named[8179]: client 192.168.0.52#57983: updating zone 'hprs.local/IN': adding an RR at 'charmaine.hprs.local' A

Select allOpen in new window

There is a fine line between a client and a server for this stuff in my mind. How do you distinguish them?

Also, all the Windows clients seem to get updated as shown by the log above. However, I have four Linux host: the infamous 192.168.0.3, 192.168.0.5, 192.168.0.102 and 192.168.0.99. The first 3 are Slackware, the last is ubuntu. These show problems in the dhpcd log. There is NOTHING AT ALL for 192.168.0.3 which has dual hostnames in the zone/journal file of darkstar and webserver.

The 192.168.0.5 host has the following in the dhcpd.log:

Apr 12 07:01:49 mail dhcpd: DHCPREQUEST for 192.168.0.5 from f4:6d:04:60:04:38 via eth1
Apr 12 07:01:49 mail dhcpd: DHCPACK on 192.168.0.5 to f4:6d:04:60:04:38 via eth1
Apr 12 07:01:49 mail dhcpd: Forward map from OHPRSstorage.hprs.local. to 192.168.0.5 FAILED: Has an address record but no DHCID, not mine.

Select allOpen in new window

What's that mean? 192.168.0.99 has the following:

Apr 12 15:58:44 mail named[1453]: client 192.168.0.2#22982: updating zone 'hprs.local/IN': update unsuccessful: labrat.hprs.local: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Apr 12 15:58:44 mail named[1453]: client 192.168.0.2#22982: updating zone 'hprs.local/IN': update unsuccessful: labrat.hprs.local/TXT: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
Apr 12 15:58:44 mail dhcpd: Forward map from labrat.hprs.local. to 192.168.0.99 FAILED: Has an address record but no DHCID, not mine.

Select allOpen in new window

These look bad, but I don't know what a DHCID is. This host is also in the zone/journal file with multiple host names: labrat, uCommon and ubuntu. As with "darkstar" for Slackware, I believe "ubuntu" is the default hostname after initially installing ubuntu and before completely setting up the network.

Host 192.168.0.102 has no errors, but no apparent updates as with the Windows hosts:

Apr 12 11:04:54 mail dhcpd: DHCPREQUEST for 192.168.0.102 from 00:09:5b:8c:e5:14 (vaio) via eth1
Apr 12 11:04:54 mail dhcpd: DHCPACK on 192.168.0.102 to 00:09:5b:8c:e5:14 (vaio) via eth1

Select allOpen in new window

(That it for Apr 12 for this host!)

So, perhaps I can follow the chain of error up another link. Is there a problem with the Linux dhcp clients updating the dhcpd on the DNS/DHCP server?

what version of dhcpd are you running?

isc-dhcpd-4.3.4

dhcpd should send an nsupdate to remove any entries after the lease expires.

are these duplicate machines cloning a mac address from the previous server?

So, more info on the DHCP config ...

The only host actually getting its IP in a non-static way from DHCPD is vaio IP 192.168.0.102. My active lease report:

+------------------------------------------------------------------------------
| DHCPD ACTIVE LEASES REPORT
+-----------------+-------------------+----------------------+-----------------
| IP Address      | MAC Address       | Expires (days,H:M:S) | Client Hostname
+-----------------+-------------------+----------------------+-----------------
| 192.168.0.102   | 00:09:5b:8c:e5:14 |             16:06:35 | vaio
+-----------------+-------------------+----------------------+-----------------
| Total Active Leases: 1
| Report generated (UTC): 2016-04-12 22:58:18
+------------------------------------------------------------------------------

Select allOpen in new window

All the other hosts in the network have IP either statically allocated in dhcpd.conf:

# Web Server (Linux)
host webserver {
    hardware ethernet 60:A4:4C:61:9C:FE;
    fixed-address 192.168.0.3;
}

Select allOpen in new window

Or, in a couple of instances in the zone file:

security                A       192.168.0.24
$TTL 1200       ; 20 minutes

Select allOpen in new window

The reason for the latter is that host 192.168.0.24 wants to publish its hostname as LocalHost even if explicitly given a name in the dhcpd.conf file. Setting the IP on the device itself (not using dhcp) and setting this entry in the zone file seemed the only way to override that.

But setting in the zone file is the exception. All the Windows workstations and the Linux hosts I mentioned are all given static IPs in the dhcpd.conf file. The reason for this is to catch any stray devices that connect to the LAN and to provide explicit paths for Remote Desktop and VNC.

dhcpd should send an nsupdate to remove any entries after the lease expires.

Given what I've said, is that still true if the IPs are statically allocated and not strictly leases?

are these duplicate machines cloning a mac address from the previous server?

No, duplicates darkstar/webserver are the same machine with MAC 60:A4:4C:61:9C:FE, labrat, ubuntu and uCommon are two machines one of which has MAC D0:67:E5:4F:02:6D and the other has MAC 2C:56:DC:76:A9:5A, but all three hostnames have the same IP in the journal/zone files. ubuntu and uCommon have not been online in over 6 months.

It appears that the DNS resolver grabs the first entry in the zone file corresponding to the requested IP. Thanfully, labrat sorts before ubuntu and uCommon so everything appears to work for it. Unfortunately, darkstar sorts before webserver, so I always get darkstar when doing e.g. `host 192.168.0.3`.

Am I clarifying or obfuscating?

btw, nsupdate run manually doesn't appear to have worked:

$ nsupdate
> update delete darkstar.hprs.local A
> send
> quit
1 19:27:40 root@mail:~
$ host 192.168.0.3
3.0.168.192.in-addr.arpa domain name pointer darkstar.hprs.local

Select allOpen in new window

i am not too keen on clients updating the DNS..., that means EVERYONE on the network can update the DNS.
also update server records....
So i have the DHCPD authenticate itself with the DNS server for updates. (using a key).

On my system the jnl files do clean out..., so the problem may be that the are not emptied completely after sync.
maybe due to conflicts.  Any address may be reused after their lease expires. So another system may reuse the address, so there is no need to have duplicate addresses.

The DHCID is the TXT record that is entered together with ip address.
isc-dhcp may be used in a redundant configuration where more then one server is active on one network segment.
this is one of the ways to see who is responsible for an address.
Also these may be entries from DHCP servers active on other subnets. So a DHCP server needs to check before updating. and turn away if the DHCID is not compatible.

DHCP client will indicate that is whishes to reuse a previous address...
if free a DHCP server may allow that.... (this may override a reservation ).

Also be sure to clean out the TXT entries btw....
nsupdate
update delete darkstart.hprs.local TXT
update delete 3.0.168.192.in-addr.arpa TXT
send
quit

A DNS is  a database of (name, tag, value) triplets

where names are stored with a tag (server, A) , (domain, MX), (1.0.0.127.in-add.arpa, PTR)  and may produce values.
The values are not exactly sorted but stored as they are in the database, and rotated on the query side with each query done to the server. (the answer may be cached, and the cache manager may or may not rotate them as well).
A resolver may also pick the first presented and use just that... (early server loadbalancing was done with multiple DNS entries for the same server)

noci:

i am not too keen on clients updating the DNS..., that means EVERYONE on the network can update the DNS.
 also update server records....

Yes, but the DNS/DHCP server is also a Windows-style domain controller (Samba4) and instructions on setting that up  said the domain Windows workstations will want to update the zone files. If they cannot, you will continuously get the syslog message:

syslog:Jul 30 20:35:20 mail named[792]: client 192.168.0.101#58026: update 'hprs.local/IN' denied

So i have the DHCPD authenticate itself with the DNS server for updates. (using a key).

My dhcpd permits updates:

ddns-updates on;
update-static-leases on;
allow unknown-clients;  # default, deprecated (man dhcpd.conf)
ignore client-updates;  # see https://www.centos.org/forums/viewtopic.php?t=29256, man dhcpd.conf: ignore clien
t-updates
ddns-update-style interim;

Select allOpen in new window

And the DNS permits local LAN hosts and the local host (for dhcpd itself), named.conf:

zone "hprs.local." IN {
        type master;
        allow-update { 192.168.0.0/24; 127.0.0.1; };           // local DHCP server
        file "/etc/samba/private/dns/hprs.local.zone";
        check-names ignore;
};

Select allOpen in new window

Likewise for the reverse zone. I think that is all correct (but have much self-doubt).

On my system the jnl files do clean out..., so the problem may be that the are not emptied completely after sync.
 maybe due to conflicts.

Hmmm, so if I get desperate (which I am close to), could I just remove the journal files (after probably stopping named and dhcpd first)?

Any address may be reused after their lease expires. So another system may reuse the address, so there is no need to have duplicate addresses.

As mentioned, most of my IP assignments are statically assigned in dhcpd.conf. I suppose that would throw a wrench into the notion of reusing?

 The DHCID is the TXT record that is entered together with ip address.
 isc-dhcp may be used in a redundant configuration where more then one server is active on one network segment.
 this is one of the ways to see who is responsible for an address.
 Also these may be entries from DHCP servers active on other subnets. So a DHCP server needs to check before updating. and turn away if the DHCID is not compatible.

That makes sense. In this case there are no other (or shouldn't be) DHCP servers. So why do you suppose I;m getting that DHCID error?

Apr 12 19:01:49 mail dhcpd: DHCPREQUEST for 192.168.0.5 from f4:6d:04:60:04:38 via eth1
Apr 12 19:01:49 mail dhcpd: DHCPACK on 192.168.0.5 to f4:6d:04:60:04:38 via eth1
Apr 12 19:01:49 mail dhcpd: Forward map from OHPRSstorage.hprs.local. to 192.168.0.5 FAILED: Has an address record but no DHCID, not mine.

Select allOpen in new window

DHCP client will indicate that is whishes to reuse a previous address...
 if free a DHCP server may allow that.... (this may override a reservation ).

So, why then would my Linux dhcp clients NOT be doing this? Because of the reservation in dhcpd.conf? That is, if host darkstar got the IP 192.168.0.3 based on its MAC, then that host's name was changed to webserver, why would the darkstar name be kept in the journal/zone files? That's the bit that's really stumping me.

 Also be sure to clean out the TXT entries btw....
 nsupdate
 update delete darkstart.hprs.local TXT
 update delete 3.0.168.192.in-addr.arpa TXT
 send
 quit

Tried that, got:

$ nsupdate
> update delete darkstar.hprs.local TXT
> update delete 3.0.168.192.in-addr.arpa TXT
> send
update failed: NOTZONE

Select allOpen in new window

If I leave off the "update delete 3.0.168.192.in-addr.arpa TXT", it doesn't fail, And! Lo and Behold! darkstar is no longer in the journal file! Maybe some progress, but why the failure with the reverse look-up?

 A DNS is  a database of (name, tag, value) triplets  where names are stored with a tag (server, A) , (domain, MX), (1.0.0.127.in-add.arpa, PTR)  and may produce values.
 The values are not exactly sorted but stored as they are in the database, and rotated on the query side with each query done to the server. (the answer may be cached, and the cache manager may or may not rotate them as well).
 A resolver may also pick the first presented and use just that... (early server loadbalancing was done with multiple DNS entries for the same server)

That could explain why multiple names are permitted for the same IP. However, despite all this good info I still can't get rid of my !@#$ darkstar from the zone/journal files.

Is it time for desperation  and I should just delete the journal files and hand-edit the zone files? Other idea?

Semi good news! I tried the nsupdate thing again, this time with a '.' at the end of arpa:

$ nsupdate
> update delete 3.0.168.192.in-addr.arpa. A
> update delete 3.0.168.192.in-addr.arpa. TXT
> update delete 3.0.168.192.in-addr.arpa. PTR
> send
> quit

Select allOpen in new window

(I added A and PTR based on monkey-typing things I saw on the web; no clue if that was a good or bad thing to do) No error this time AND darkstar was not in the journal file or the reverse zone file. I then did freeze/thaw on the hprs.local zone and darkstar was no longer in the zone file. Yeah! Only problem now is 192.168.0.3 is not in the reverse zone file, so `host 192.168.0.3` fails. I'll do more research, but suggestions are welcome.

More progress. I guess I didn't need the A and TXT records in my previous post of updating the reverse zone. The reverse zone file only has PTR record. I did the following:

$ nsupdate
> update add 3.0.168.192.172.in-addr.arpa. 3600 PTR webserver.hprs.local.
> send

Select allOpen in new window

I then did freeze/thaw on hprs.local and now I have the reverse lookup:

$ host 192.168.0.3
3.0.168.192.in-addr.arpa domain name pointer webserver.hprs.local.

Getting there. However webserver is not in the reverse zone file db.192.168.0. Looking at its journal file I get:

$ named-checkzone -Dj hprs.local /etc/samba/private/dns/db.192.168.0 | more
/etc/samba/private/dns/db.192.168.0:3: ignoring out-of-zone data (0.168.192.in-addr.arpa)
/etc/samba/private/dns/db.192.168.0:13: ignoring out-of-zone data (102.0.168.192.in-addr.arpa)
:
: (lines removed)
:
/etc/samba/private/dns/db.192.168.0:37: ignoring out-of-zone data (59.0.168.192.in-addr.arpa)
/etc/samba/private/dns/db.192.168.0:38: ignoring out-of-zone data (99.0.168.192.in-addr.arpa)
zone hprs.local/IN: journal rollforward failed: journal out of sync with zone
zone hprs.local/IN: not loaded due to errors.

Select allOpen in new window

This site: http://www.utternerd.org/journal-rollforward-failed-out-of-sync-with-zone suggests the way to fix that is to delete the offending zone file and restart bind. And voila! that worked! After restarting bind webserver was back in the reverse zone file!

I'm going to use the above procedures to clear out all the crap entries in my zone, reverse zone and journal files, then I'll post several question whose answers by you EEs will hopefully help me understand all this.

I believe I've succeeded in cleaning up my zone files. I'll post what I did, then post a follow-up message of questions which, I hope, this lengthy question doesn't completely discourage answering.

Here's what I did to remove the crap zonefile host entries:

$ nsupdate
> update delete RNP0026735563AB.hprs.local TXT
> update delete RNP0026735563AB.hprs.local A
>
> update delete 20.0.168.192.in-addr.arpa. PTR
> 
> update add 20.0.168.192.in-addr.arpa. 3600 PTR ricoh.hprs.local.
> send

Select allOpen in new window

In this example, host names "RNP0026735563AB" and "ricoh" both had the IP 192.168.0.20. The name I want to keep is 'ricoh'. The first two 'update delete's remove the zone file entries for "RNP0026735563AB" and the 3rd one removes its reverse-zonefile PTR entry. There needs either to be a blank line before the deletion of the reverse zone PTR, or the command "send", otherwise the update fails with "update failed: REFUSED". Likewise before the "add".

I did not remove the zonefile entry for host ricoh, so its A and TXT records are still there. But, the rev-zone entry for 192.168.0.24 is gone and `host 192.168.0.24` fails, while `host ricoh` succeeds. So, lastly, I've added the reverse entry with the `add update` command.

I did this for all the bogus entries and the `host` commands by name and IP all worked and all `host` command for the bogus names failed.

All these `host` commands worked even without updating the zone files from the journal files, as expected.

Next I had the "no DHCID" problem from one of my Linux hosts. Trying to simply have that host re-query an IP the dhcpd server didn't work (using `etc/rc.d/rc.inet1 eth0_restart` on Slackware):

Apr 13 00:20:38 mail dhcpd: DHCPRELEASE of 192.168.0.5 from f4:6d:04:60:04:38 via eth1 (not found)
Apr 13 00:20:40 mail dhcpd: DHCPDISCOVER from f4:6d:04:60:04:38 via eth1
Apr 13 00:20:40 mail dhcpd: DHCPOFFER on 192.168.0.5 to f4:6d:04:60:04:38 via eth1
Apr 13 00:20:40 mail dhcpd: DHCPREQUEST for 192.168.0.5 (192.168.0.2) from f4:6d:04:60:04:38 via eth1
Apr 13 00:20:40 mail dhcpd: DHCPACK on 192.168.0.5 to f4:6d:04:60:04:38 via eth1
Apr 13 00:20:41 mail named[18117]: client 192.168.0.2#22982: updating zone 'hprs.local/IN': update unsuccessful: OHPRSstorage.hprs.local: 'name not in use' prerequisite not satisfied (YXDOMAIN)
Apr 13 00:20:41 mail named[18117]: client 192.168.0.2#22982: updating zone 'hprs.local/IN': update unsuccessful: OHPRSstorage.hprs.local/TXT: 'RRset exists (value dependent)' prerequisite not satisfied (NXRRSET)
Apr 13 00:20:41 mail dhcpd: Forward map from OHPRSstorage.hprs.local. to 192.168.0.5 FAILED: Has an address record but no DHCID, not mine.

Select allOpen in new window

Web research indicated that I had to remove the apparently bad A and TXT records. I did this using `nsupdate`, then had the host re-request the dhcpd server again and voila!, it worked! Note that I had to delete both the A and TXT records. I thought could just delete the TXT record because this is supposedly the DHCID, but that didn't work.

I did end up manually deleting the journal files after starting this process (after freezing) to no apparent harm. It is interesting to note that after deleting the journal files and then doing some updates the command

named-checkzone -Dj hprs.local /etc/samba/private/dns/hprs.local.zone.jnl

no longer worked. It gave me dozens of lines of message saying something about "malformed" this and "bad character" here and "newline" there ... However, the command:

named-journalprint /etc/samba/private/dns/hprs.local.zone.jnl

worked fine. Possibly a version problem?

That's the fix. Next post, some questions.

(a good link for nsupdate examples: http://superuser.com/questions/977132/when-using-nsupdate-to-update-both-a-and-ptr-records-why-do-i-get-update-faile)

After doing the nsupdates, I could do `host <name>` and `host <IP>` and they both worked without doing the freeze/thaw procedure. As expected. Also as expected, the changes were in the journal files, but not yet in the zone/reverse files.

Questions:

1) Do the journal files EVER get automatically rolled into the zone/reverse files or is it always supposed to be an manual procedure using freeze/thaw or sync -clean?

2) In the future, if I re-use an IP for a different hostname, do I have to manually update these zonefiles as I've done in the course of this question, is nothing for this automated? For example, if Charmaine quits and her computer (hostname charmaine) is given to her replacement, Betty, and the computer gets renamed to 'betty', but I want to still have the same IP, will I be right back in the same situation? Is DNS/DHCPD not smart enough to replace charmaine with betty for IP 192.168.0.57, or will I have to `nsupdate` to remove references to charmaine?

1) No not that i know of..., no need realy., The zone file + jnl work together.
Removing the JNL file  should be done while the server is DOWN.....
rm doesn't just remove the file, rm lowers the usage count of a file, and removes a directory entry.
any process that opens the file also has incremented the file usage.
The OS will remove the inode/(file on disk unique reference)  when the usage count drops to 0.
So it might still live in the background, again causing a zone corruption after you restart the name daemon.....
Best is to ONLY use the provided tools...
Updating the zone through rnds did clear my journals, then again those were clean from the start and also  only updated through DNS/DHCP combo.

2a) Please keep in mind DNS and DHCP are completely separate systems that can work together. (and should to a better user experience) they also have a compelte different view & requirements ..
DNS is there primary for humans who can recognize names far better than long strings of numbers.
DHCP is there to support communication of hardware.
2b) So it depends..., the administration of DHCP isn't perfect. If left alone it will most probably work very nicely
but manual intervention might break stuf, reboots might. During updates slight semantic differences might leave traces.
If clients update the DNS then there is no one deleting records if you change disks in a system, of install a new system etc. if systems crash they surely won't delete stale records.
DHCP only cares about providing IP addresses to systems inquiring for one. It does updating DNS on the side...
There is a large range of DHCP clients all having their quirs/bugs/peculiarities...

DHCP daemon will update DNS if it "owns" the record.  ie. knows from the TXT record that it may handle that record.  Note that in multi LAN  (VLAN) environment you have at least 1 DHCP server per LAN.
A few DHCP daemons can work in tandems per VLAN in wich case they have to coordinate there kind of updates.
(this is by no way an automatic configuration and normaly to DHCP servers on one network segment are a sure way to wreak havoc on that part).
So no TXT record means it should be considered a static entry, which should not change.

I have seen remnants left like that if systems get renamed.
The DHCP Client will request the same IP address as last time, and use a new name.
The DNS Database is a database PER zone without references to other parts.
so there is no link between an A record and a PTR record per se....
zones by name (aka forward lookups) translate a name to a vast array of values.
(CNAME, NS, SOA, A, AAAA, SRV etc. etc. ) while the zones for addresses ( in-addr.arpa & ip6.arpa , aka reverse lookups) only hold PTR records.

But there is nothing (technicaly) against  adding a PTR record to name zone... or adding A , AAAA records to reverse zones. They won't get used most of the time, as they are not expected to exist.

wrt. named-checkzone ... don't supply .JNL files to them they are meant to validate if the name-daemon can use the zones, f.e. after manual editing.   So you need to supply the zone file not the journal
(Zone file is readable ascii, Journal is mostly a binary file).
of use named-checkzone -D -J <journal file> zonename zonefile
(-j implies  -J zonefile.jnl as a journal)  
Check as reference:     man named-checkzone
No surprise that the named-journal print can print the journal... it's it's job to do just that.

Also note that the Zone files (+ journals) are just to survive reboot / named restarts for persistent data.
named actually runs from a memory buffer.


Also it is strange to see DNS zone files in a SAMBA config directory.
Normally DNS zones are stored in /var/bind  or /var/named (older setup) or /var/lib/bind  for more recent setups.
with non persistent files (like slaveserver zone files ) in /var/cache/bind  
Obviously they can be stored anywhere you like but it is atypical.

Oh, by the way...
your forwark lookup zone is:         hprs.local.
while the reverse lookup zone is:  0.168.192.in-addr.arpa.

So this makes no sense:
 named-checkzone -Dj hprs.local /etc/samba/private/dns/db.192.168.0 |

Asking a check for zone hrps.local    and looking in a file meant for     0.0.168.192.in-addr.arpa. ... 255.0.168.192.in-addr.arpa (only containing PTR/SOA/TXT) records.
you might have meant named-checkzone -Dj 0.168.192.in-addr.arpa /etc/samba/private/dns/db.192.168.0

From the Point of view of DNS there is NO link between zones, that only exists in our imagination.
You operate a DNS server for Both the forward .local domain and you are the address space owner for 192.168.0.0/24... with it's reverse zone.
But on a larger scale the reverse zones are managed by internet connection providers, while the forward zone are provided by name providers.... they might be the same but more often are not.
I have named  zones bought through go-daddy, network solutions (where i delegated the zone management to a private DNS + zoneedit as backup)   while my ISP only whishes to provide a reverse lookup on IPv4 for one name they provide and no IPv6 reverse lookups.

noci: Thanks for the detailed info. I think I'll be good to go for maintaining this going forward. I think you are right in that there are various idiosyncrasies among the various components.

So no TXT record means it should be considered a static entry, which should not change.

Interesting, the Windows workstations are statically defined in dhcpd.conf and have A records in the zone file, but no TXT records. On the other hand, the Linux workstation are also statically defined, but do have TXT records in the zone file! There's an "idiosyncrasy" right there!

Also, even though I've renamed Windows workstations in the past, I don't have any vestigal entries for those workstations, only the Linux workstations. Could be these differences are related to management through the Samba4 domain controller (via RSAT or samba-tool). Samba4 AD/DC does interact with DNS.

Conclusion: Windows workstations seem to take care of themselves pretty well, possibly because of the AD/DC removing joined computer, but if I do any name changing on Linux hosts I'll have to manually remove the old hostname from the zone files.

Also it is strange to see DNS zone files in a SAMBA config directory.
Normally DNS zones are stored in /var/bind  or /var/named (older setup) or /var/lib/bind  for more recent setups.
with non persistent files (like slaveserver zone files ) in /var/cache/bind  
Obviously they can be stored anywhere you like but it is atypical.

Well, it's not atypical for a Samba4 AD/DC deployment. That is where the `samba-tool domain provision` process put things and creates template zone files there. The 'normal' /etc/named.conf needs a line to find those:

include "/etc/samba/private/named.conf";

your forwark lookup zone is:         hprs.local.
while the reverse lookup zone is:  0.168.192.in-addr.arpa.

So this makes no sense:
 named-checkzone -Dj hprs.local /etc/samba/private/dns/db.192.168.0 |

Asking a check for zone hrps.local    and looking in a file meant for     0.0.168.192.in-addr.arpa. ... 255.0.168.192.in-addr.arpa (only containing PTR/SOA/TXT) records.
you might have meant named-checkzone -Dj 0.168.192.in-addr.arpa /etc/samba/private/dns/db.192.168.0

Yes, you're right. Using the syntax you've specified doesn't give the tons of errors. Although it gives me the whole reverse zone (all computer), not just changes. For that I need `named-journalprint /etc/samba/private/dns/db.192.168.0.jnl`. I guess this is the way it's supposed to work, but I could swear `named-checkzone -Dj hprs.local /etc/samba/private/dns/hprs.local.zone.jnl` worked to just show the journal changes ... but possibly bad memory on my part.

Possibly the windows systems add their own DHCP records (and possibly don't delete them) TXT records are used by the isc-dhcp server. (The windows system managers do have a habit of setting up systems that way)
Maybe your DNS setup is kerberized? (AD is effectively a slightly crippled LDAP + Kerberos authentication).
You can specify a different journal file to named-checkzone with -J <journalfile>  
-J implies -j.  then besides the zone, forward zone also the journal can be specified.

I seriously doubt that conflicting info (a zone differing from the zonefile that should) will yield a valid answer.

The setup I have now seems to be working great.  `rndc -V sync -clean` merges and clears out my zone files. The dnsupdate program worked to let me remove old entries.