A DKIM RR added in an inline-signing zone is not served
Ubuntu 19.10
bind9 9.15.4
opendkim 2.11.0~alpha-12
bind9 domain configuration:
zone "exmaple.com"
{
type master;
file "/etc/bind/db.example.com";
// Publishing and activating dnssec keys
auto-dnssec maintain;
// Using inline signing
inline-signing yes;
...
The private key & RR have been generated with:
opendkim-genkey -s mail -d example.com -h <algorithm>
The added record begins with:
mail._domainkey IN TXT ( "v=DKIM1; h=<algorithm>; k=rsa; "
...
I followed all the steps outlined in the official bind9 documentation regarding "Adding DKIM Records with BIND9"/Directly Editing your DNS Zone.
Checking the result after successfully thawing the server:
# named-checkzone -D -f raw -o - example.com db.example.com.signed|grep DKIM
zone example.com/IN: loaded serial 2019101515 (DNSSEC signed)
OK
mail._domainkey.example.com. 604800 IN TXT "v=DKIM1; h=<algorithm>; k=rsa; "
...
However it does not serve the DKIM RR on the primary server:
# dig @localhost TXT example.com|grep DKIM
#
On top of that issue, the secondary is not aware of the change at all despite the zone transfer:
15-Oct-2019 16:54:59.075 xfer-out: info: client @0xaaaaaaaaaaa w.x.y.z#54219 (example.com): transfer of 'example.com/IN': IXFR started (serial 2019092407 -> 2019101515)
15-Oct-2019 16:54:59.075 xfer-out: info: client @0xaaaaaaaaaaa w.x.y.z#54219 (example.com): transfer of 'example.com/IN': IXFR ended: 1 messages, 14 records, 1412 bytes, 0.001 secs (1412000 bytes/sec)
15-Oct-2019 16:55:14.078 xfer-out: info: client @xbbbbbbbbbbbb w.x.y.z#58529 (example.com): transfer of 'example.com/IN': AXFR started (serial 2019101515)
15-Oct-2019 16:55:14.078 xfer-out: info: client @xbbbbbbbbbbbb w.x.y.z#58529 (example.com): transfer of 'example.com/IN': AXFR ended: 1 messages, 36 records, 2906 bytes, 0.001 secs (2906000 bytes/sec)
# named-checkzone -D -f raw -o - example.com db.example.com.signed|grep DKIM
zone example.com/IN: loaded serial 2019092407 (DNSSEC signed)
OK
#
# dig @localhost TXT example.com|grep DKIM
#
The loaded zone unexpectedly matches the old one.
Am I missing something?