<!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 21:36, Alessandro Vesely
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:72316616-2df0-48a2-b234-5edba801d217@tana.it">On Wed
      24/Sep/2025 08:25:40 +0200 Nick Tait wrote:
      <br>
      <blockquote type="cite">On 24/09/2025 05:42, Alessandro Vesely
        wrote:
        <br>
        <blockquote type="cite">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>
        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?
        <br>
      </blockquote>
      The script is <a class="moz-txt-link-freetext" href="https://github.com/hannob/alwaysdns">https://github.com/hannob/alwaysdns</a>.  It is
      charmingly simple in its downloading and comparing all SOA
      records.  I assume signed serials have definitely disqualified
      this synchronization checking technique.  Are there any
      alternatives?
      <br>
      <br>
      <blockquote type="cite">(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?)
        <br>
      </blockquote>
      This is an old bash script I've been tinkering with for years. 
      Internal and public zones live in two parallel directories.  For
      each internal zone file it generates the public copy on a
      temporary file using sed.  If that temporary is different from the
      current one, all .jbk, .signed, .signed.jnl of that zone are
      marked for deletion.  If there are any files so marked at the end,
      named is stopped, the files are removed, and named is restarted. 
      The script doesn't check the serial numbers.</blockquote>
    <p>Looking at the script it does indeed appear to be using the
      resolver to query the domain for NS records, and then querying
      each name server for its SOA record, and comparing the serial
      numbers. This is basically the same as what you would get by
      running "dig +nssearch <i>domain</i>".</p>
    <p>It sounds like the NS records in your internal zone file include
      both internal and external authoritative servers? If so you can
      remove the external ones and the problem should go away? You'll
      just need to make sure that when you "copy the (edited) internal
      zone file to the public one, replacing things like NATted
      addresses", you also replace the internal NS records with the
      external ones?</p>
    <p>Nick.</p>
  </body>
</html>