On Thu 25/Sep/2025 08:15:05 +0200 Nick Tait wrote:
On 24/09/2025 21:36, Alessandro Vesely wrote:
On Wed 24/Sep/2025 08:25:40 +0200 Nick Tait wrote:
On 24/09/2025 05:42, Alessandro Vesely wrote:
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).
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?
The script is https://github.com/hannob/alwaysdns. 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?
(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?)
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.
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 /domain/".
Nice option.
I now reloaded my zone file, and the resulting serials are 2025092580 for the
internal view and 2025092579 for the external. (Previously they were
2025060981 and 2025060980 respectively.) It seems the external view is
consistently behind by one.
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?
That's right. However, I'm not going to implement it. (It would require to
edit the external zones and derive the internal ones rather than the other way
around.)
Thanks
Ale
--
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list.
