Gratuitous AXFRs of RPZ after 9.18.11

[Greg Choules]

Hi John.
Personally, I would start by drawing a picture (I like pictures) of all the
players in the game and gathering data, leaving nothing out, including:

   - All servers, with all IP addresses.
   - SOA and NS records of working zones and the troublesome RPZ zone.
   - Which servers are authoritative for each of the NS records, what
   addresses they resolve to and how the secondaries do that resolving.
   - Does the primary treat *this* secondary any differently? e.g. is it
   listed in an "also-notify" clause perhaps?
   - full configs (named-checkconf, as you have already done. But if it's
   only you looking at them, drop the "x")
   - pcaps on a working and the troublesome box (and on the primary) and a
   lot of time in Wireshark. There *must* be *something* different going on.
   *If* it turns out that 9.18.11 is behaving incorrectly, ISC will want to
   know.

HTH, Greg

On Fri, 27 Jan 2023 at 00:50, John Thurston <john.thurston at alaska.gov>
wrote:

> 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-8591John.Thurston at alaska.gov
> Department of Administration
> State of Alaska
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230127/8d050f8f/attachment-0001.htm>