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.thurs...@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.thurs...@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@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users >
-- 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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
