<div dir="ltr">Hi John.<div>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:</div><div><ul><li>All servers, with all IP addresses.</li><li>SOA and NS records of working zones and the troublesome RPZ zone.</li><li>Which servers are authoritative for each of the NS records, what addresses they resolve to and how the secondaries do that resolving.</li><li>Does the primary treat *this* secondary any differently? e.g. is it listed in an "also-notify" clause perhaps?</li><li>full configs (named-checkconf, as you have already done. But if it's only you looking at them, drop the "x")</li><li>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.</li></ul></div><div>HTH, Greg</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 27 Jan 2023 at 00:50, John Thurston <<a href="mailto:john.thurston@alaska.gov">john.thurston@alaska.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>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 <u>not</u>
also performing such gratuitous AXFRs of its other zones. Of note,
the secondary in question has a "twin", for which the output of <font face="monospace">named-checkconf -px</font> is identical
(excepting the host-specific keys used for rndc access). That
"twin" is behaving as expected.</p>
<p>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.<br>
</p>
<p>The SOA-record for my RPZ looks like so:</p>
<p>;; ANSWER SECTION:<br>
<font face="monospace">rpz.local. 300 IN SOA rpz.local.
<a href="http://hostmaster.state.ak.us" target="_blank">hostmaster.state.ak.us</a>. 22 3600 1800 432000 60</font><br>
</p>
<p>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:</p>
<p>
</p><blockquote type="cite">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)<br>
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)<br>
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)<br>
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)<br>
</blockquote>
<p></p>
<p>When I dump the zone database from the secondary (<font face="monospace">rndc dumpdb -zone rpz.local</font>), I can see
the RPZ in it with the expected serial number and all of the
expected records.</p>
<p>And after typing all of the above, I did an <font face="monospace">rndc status</font> to get the versions of each,
and discovered that the "twins" are not actually twins! <br>
</p>
<p>The troublesome host is: 9.18.11-1+ubuntu18.04.1+isc+2-Ubuntu</p>
<p>Its "twin" is: 9.18.10-1+ubuntu18.04.1+isc+1-Ubuntu</p>
<p>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</p>
<p>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?<br>
</p>
<pre cols="72">--
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
<a href="mailto:John.Thurston@alaska.gov" target="_blank">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska</pre>
</div>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>