<!DOCTYPE html>

<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <div class="moz-cite-prefix">On 24/09/2025 05:42, Alessandro Vesely

      wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:637390d0-8ade-411c-9a53-1d22df1ffea1@tana.it">On Tue

      23/Sep/2025 01:55:51 +0200 Mark Andrews wrote:

      <br>

      <blockquote type="cite" style="color: #007cff;">Whenever a zone is

        changed the serial needs to be updated so that secondary servers

        know when to transfer the updated content.   When a zone is

        signed the updating takes place more often as RRSIG records need

        to be periodically updated.  If you have views the serials in

        each view are independent of each other unless you take steps to

        keep them the same. Additionally when you use inline signing the

        serial of the signed zone is independent of the unsigned zone as

        the signed zone has the periodical updates the unsigned zone

        doesn’t.   Additionally two inline zones using the same unsigned

        zone will sign zone content at different times and in different

        orders to each other.

        <br>

      </blockquote>

      <br>

      <br>

      I just copy the (edited) internal zone file to the public one,

      replacing things like NATted addresses.  Since I only edit the

      internal files, I know the external are in sync because they have

      the same (non signed) serial.

      <br>

      <br>

      <br>

      <blockquote type="cite" style="color: #007cff;">When checking zone

        serials for consistency all the above needs to be taken into

        account.  The scripts work when you query the correct instance

        of the zone when using views and when there is not an inline

        signer on the secondary.

        <br>

      </blockquote>

      <br>

      <br>

      The script I ran just issues a few queries using Python's

      dns.resolver.  I don't see how it could check for consistency (or

      determine that some resolvers use different views). <br>

    </blockquote>

    <p>The tool you're using might be looking at NS records and then

      querying the authoritative servers directly, possibly in addition

      to the asking the configured resolver? (What do the internal zone

      file NS records point to? And when you "copy the (edited) internal

      zone file to the public one, replacing things like NATted

      addresses", are you also updating those?)</p>

    <p>Nick.</p>

  </body>

</html>