0

I recently moved our hidden DNS master service to a new host, DNS38. The original master service is still running but is not being polled at the present time.

The old master, and all the authoritative slaves, are running bind-9.11. The new master host is running bind-9.16.

DNSSEC is enabled for the domain I am dealing with. We use dnssec-validation auto; and auto-dnssec maintain; inline-signing yes; for the zone.

My question relates to loading changes made to the master zone file not being visible to the slave servers.

Using rndc I see this:

rndc zonestatus harte-lyne.ca
name: harte-lyne.ca
type: primary
files: /usr/local/etc/namedb/signtest/harte-lyne.ca.hosts
serial: 2022012604
signed serial: 2022012199
nodes: 1320
last loaded: Tue, 25 Jan 2022 17:38:23 GMT
secure: yes
inline signing: yes
key maintenance: automatic
next key event: Thu, 27 Jan 2022 17:00:50 GMT
next resign node: _22._tcp.inet05.hamilton.harte-lyne.ca/NSEC
next resign time: Thu, 27 Jan 2022 19:51:36 GMT
dynamic: no
reconfigurable via modzone: no

The thing that interests me here is that while the serial of the zone file is 2022012604 the serial of the signed zone file is 2022012199, which is less than the first serial. I believe the signed zones maintain a separate serial sequence but I have been unable to find documentation to confirm or refute this.

In any case, I have made changes to the zone file on the master and reloaded them using rndc reload harte-lyne.ca. This change was duly queued and the serial number of the updated zone file shows in the zonestatus report. However, the changes to the zone do not appear when queried.

# find a changed RR
grep dns01.internal /usr/local/etc/namedb/signtest/harte-lyne.ca.hosts
dns01.internal.harte-lyne.ca.           CNAME dns33.internal.harte-lyne.ca.

# check the validity of the zone file
named-checkzone -i local harte-lyne.ca /usr/local/etc/namedb/signtest/harte-lyne.ca.hosts #  zone configuration test ignore samba errors
zone harte-lyne.ca/IN: loaded serial 2022012701
OK

# reload the zone
rndc reload harte-lyne.ca.
zone reload queued

# check the serial number 
rndc zonestatus harte-lyne.ca.
name: harte-lyne.ca.
type: primary
files: /usr/local/etc/namedb/signed/harte-lyne.ca.hosts
serial: 2022012701
signed serial: 2022012199
nodes: 1311
last loaded: Tue, 25 Jan 2022 17:38:23 GMT
secure: yes
inline signing: yes
key maintenance: automatic
next key event: Thu, 27 Jan 2022 17:00:50 GMT
next resign node: _22._tcp.inet05.hamilton.harte-lyne.ca/NSEC
next resign time: Thu, 27 Jan 2022 19:51:36 GMT
dynamic: no
reconfigurable via modzone: no

Here I have reloaded the zone with a new serial number (2022012701) containing a valid CNAME RR for dns01.internal.harte-lyne.ca. However, if I then dig/drill the master service I do not get a response:

drill @dns38.harte-lyne.ca dns01.internal.harte-lyne.ca
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 54421
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 
;; QUESTION SECTION:
;; dns01.internal.harte-lyne.ca.    IN  A

;; ANSWER SECTION:

;; AUTHORITY SECTION:
harte-lyne.ca.  7200    IN  SOA harte-lyne.ca. nameservice.harte-lyne.ca. 2022012199 10800 3600 1209600 7200

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 216.185.71.38
;; WHEN: Thu Jan 27 11:51:57 2022
;; MSG SIZE  rcvd: 107

The SOA record returned has the serial number 2022012199, which matches the one provided by zonestatus after the reload of the domain. But there is no answer to the query.

I have noted no other anomalies relating to this change. The slaves are transferring from the master without error. But the master does not seem to want to acknowledge that a change has actually occurred.

It seems to me that this has something to do with signing the new RR. It has been more than five years since I set this up and I have no notes covering this particular situation. Moreover,I cannot recall encountering this before. What step am I missing?

4
  • "In any case, I have made changes to the zone file on the master" How? Did you froze the zone before changes? Jan 27, 2022 at 18:09
  • I just edited the hosts file directly, as I have done many times on the original 9.11 master. No, I did not freeze the zone as it is not dynamic and I never have done this in the past. Jan 27, 2022 at 18:18
  • "I just edited the hosts file directly," Never do that on a live zone! See rndc freeze and rndc thaw commands. Jan 27, 2022 at 20:13
  • The zone is not dynamic. freeze and thaw only apply to dynamic zones. They are invalid rndc instructions otherwise: rndc freeze harte-lyne.ca rndc: 'freeze' failed: not dynamic Jan 27, 2022 at 20:58

1 Answer 1

0

The issue was caused by the journal file being out of sync with the hosts file. Removing the .jnl file and then reloading the domain solved the problem.

1
  • The journal file of what? If the zone is not dynamic, there shouldn't be a journal file... Jul 14, 2022 at 18:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .