Gratuitous AXFRs of RPZ after 9.18.11

[John Thurston]

I have a primary server and a couple of secondaries. After making 
adjustments to my RPZ yesterday (which almost never change), I noticed 
an oddity. One of my secondaries is performing gratuitous AXFRs of the 
RPZ. This isn't a huge performance issue, as my RPZ is only 7.3KB. I 
want to understand why it is doing this, when other secondaries are not 
and when this secondary is _not_ also performing such gratuitous AXFRs 
of its other zones. Of note, the secondary in question has a "twin", for 
which the output of named-checkconf -px is identical (excepting the 
host-specific keys used for rndc access). That "twin" is behaving as 
expected.

To recap, the troublesome server has several secondary zones defined. 
All but the RPZ is transferring as expected. The troublesome server has 
a "twin", which is behaving correctly for all of the secondary zones.

The SOA-record for my RPZ looks like so:

;; ANSWER SECTION:
rpz.local.  300  IN   SOA  rpz.local. hostmaster.state.ak.us. 22 3600 
1800 432000 60

And I can see my several secondaries querying the primary for the 
SOA-record on a regular basis. With a 'refresh' value in the SOA of only 
3600, this is what I expect to see. What I don't expect to see, is the 
troublesome secondary then follows each of those queries for the SOA 
with an AXFR request, like so:

> 26-Jan-2023 15:25:40.175 client @0x7f19691c1280 
> 10.213.96.197#37631/key from-azw (rpz.local): view azw: query: 
> rpz.local IN SOA -SE(0) (10.203.163.72)
> 26-Jan-2023 15:25:40.274 client @0x7f1968118970 
> 10.213.96.197#44769/key from-azw (rpz.local): view azw: query: 
> rpz.local IN AXFR -ST (10.203.163.72)
> 26-Jan-2023 15:27:10.665 client @0x7f196925d6f0 
> 10.213.96.197#60123/key from-azw (rpz.local): view azw: query: 
> rpz.local IN SOA -SE(0) (10.203.163.72)
> 26-Jan-2023 15:27:10.763 client @0x7f1968118970 
> 10.213.96.197#46011/key from-azw (rpz.local): view azw: query: 
> rpz.local IN AXFR -ST (10.203.163.72)

When I dump the zone database from the secondary (rndc dumpdb -zone 
rpz.local), I can see the RPZ in it with the expected serial number and 
all of the expected records.

And after typing all of the above, I did an rndc status to get the 
versions of each, and discovered that the "twins" are not actually twins!

The troublesome host is:    9.18.11-1+ubuntu18.04.1+isc+2-Ubuntu

Its "twin" is:    9.18.10-1+ubuntu18.04.1+isc+1-Ubuntu

And now when I study my xfer.log more closely, the behavior changed this 
morning when I  completed the update from 9.18.10 -> 9.18.11

I'm not yet ready to revert, because this isn't affecting my business 
(this is a really small zone). Is anyone else seeing similar behavior?

-- 
--
Do things because you should, not just because you can.

John Thurston    907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230126/9902d406/attachment.htm>