Re: Gratuitous AXFRs of RPZ after 9.18.11
I was never able to uncover the underlying problem with that update. The only clue I had was the service remained in "activating" state, rather than "running". named was listening as expected, was transfering zone data, was caching and serving the correct data, but didn't seem to recognize it had the same data when it next retrieved the SOA record. I eventually restored the secondary host from backup, and performed the upgrade from 9.18.10 --> 9.18.11 again. It behaves exactly as expected; retrieving the SOA record, recognizing it already has that serial number, and waiting patiently for the refresh interval to expire before checking again. -- Do things because you should, not just because you can. John Thurston907-465-8591 john.thurs...@alaska.gov Department of Administration State of Alaska On 1/27/2023 1:53 AM, Ondřej Surý wrote: FTR I am not aware of any change between 9.18.10 and 9.18.11 that might cause the described behaviour. That said - in addition to what Greg said, I would suggest increasing the log level to small debug levels if you can and perhaps something will stand out-- 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
Re: Gratuitous AXFRs of RPZ after 9.18.11
> On 27. 1. 2023, at 1:49, John Thurston wrote: > 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 Hi John, FTR I am not aware of any change between 9.18.10 and 9.18.11 that might cause the described behaviour. That said - in addition to what Greg said, I would suggest increasing the log level to small debug levels if you can and perhaps something will stand out Ondrej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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
Re: Gratuitous AXFRs of RPZ after 9.18.11
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 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 Thurston907-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
Gratuitous AXFRs of RPZ after 9.18.11
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 Thurston907-465-8591 john.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
