1

We have a stealth master which has several zone secured with DNSSEC. We recently upgraded to 9.11 and enabled auto-maintain and inline-update for DNSSEC. The initial zone resign and load went smoothly. However, when I now update the master zone records and serial number the changed zone is not transferred to the authoritative slaves. In fact I cannot find any evidence that the changes in the master zone file have had any effect whatsoever.

drill drill harte-lyne.ca gives this:

;; ANSWER SECTION:
harte-lyne.ca.  172800  IN  SOA dns01.harte-lyne.ca. nameservice.harte-lyne.ca. 2019040501 10800 3600 1209600 7200

but the serial number in the master file is this: 2019041603

rndc reload harte-lyne.ca produces this:
zone reload up-to-date

rndc freeze and thaw do not work as the zone is defined in named.conf as a master and not as a dynamic zone.

What is the technique used to cause bind to resign and reload a modified master zone file immediately following a manual update?

If I run rndc zonestatus then I get this:

# rndc zonestatus harte-lyne.ca
name: harte-lyne.ca
type: master
files: /usr/local/etc/namedb/master/harte-lyne.ca.hosts
serial: 2019041603
signed serial: 2019041617
nodes: 1198
last loaded: Tue, 16 Apr 2019 19:50:26 GMT
secure: yes
inline signing: yes
key maintenance: automatic
next key event: Wed, 17 Apr 2019 13:51:16 GMT
next resign node: _22._tcp.inet17.mississauga.harte-lyne.ca/NSEC
next resign time: Wed, 17 Apr 2019 13:46:37 GMT
dynamic: no
reconfigurable via modzone: no

This tells me that the zone is being updated and resigned on a schedule. But how do I force an immediate update and notify following a manual change to the master zone file?

The significance of the next resign node also escapes me. I have not been able to locate an explanation of this in the available documentation, including the 9.11 admin guide.

James B. Byrne
  • 337
  • 1
  • 4
  • 14
  • Does querying the master directly return the appropriate records? Ie, is this about inline-signing etc or rather about zone transfers? – Håkan Lindqvist Apr 17 '19 at 13:31
  • Yesterday, immediately after making the changes to the primary master, performing a dig or drill on that service returned the expected RR. Similar queries to the public services did not return the newly added host. I repeated this experiment while replying and the same behaviour was observed. It seems that the issue is zone transfers. A zone notify is sent to the slaves: `notify: zone harte-lyne.ca/IN/public (signed): sending notifies (serial 2019041701)` but there is no record of it being received by the slaves. – James B. Byrne Apr 17 '19 at 14:14
  • 1
    In that case it sounds like the problem is with notify/zone transfers rather than the signing aspect of things. Who are you notifying? Are there firewall rules that could interfere? Do the slaves successfully update on the refresh interval? – Håkan Lindqvist Apr 17 '19 at 14:18
  • We are notifying our public dns authoritative slaves. There is no firewall between the local slaves and the stealth master. The slaves are apparently updating on some sort of regular schedule as evidenced by the most recent SOA serial on the slave: `harte-lyne.ca. 2019041617`. – James B. Byrne Apr 17 '19 at 14:38
  • 1
    Well, this is embarrassing. It seems that during testing whilst switching from one master to the other we commented out all but one of the authoritative slaves from the `also-notify` clause. That explains the lack of any activity on the remote end. Thanks for pointing me in the right direction. It would have taken me much longer to twig to this on my own, – James B. Byrne Apr 17 '19 at 14:45

0 Answers0