spamassassin-sysadmins mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Jones <>
Subject Re: on - 1 mirror DOWN, 0 mirrors STALE
Date Thu, 14 Mar 2019 08:32:37 GMT
On 3/14/19 12:40 AM, Matthias Leisi wrote:
>> Am 14.03.2019 um 05:17 schrieb root <>:
>> Fetching sa-update URLs from
>> ( DOWN
> Interesting, it seems this script is (sometimes?) picking up the A record which should
have been gone from DNS cache:
> # dig +trace -t a <>
> (…)
>    21600   IN      A
> # dig +trace -t soa <>
>              21600   IN      SOA
1903112142 3600 1200 302400 21600
> „1903112142“ is 2019-03-11 21:42 (in CET), ie three days ago.
> I see that the old IP only appeared every few hours (taken from the Date:
headers in the past few mails):
> Date: Thu, 14 Mar 2019 04:17:05 +0000 (UTC)
> Date: Wed, 13 Mar 2019 19:18:07 +0000 (UTC)
> Date: Wed, 13 Mar 2019 17:18:06 +0000 (UTC)
> Date: Wed, 13 Mar 2019 14:17:24 +0000 (UTC)
> Date: Wed, 13 Mar 2019 12:17:06 +0000 (UTC)
> Is it a DNS issue on sa-vm1, or is it something I overlooked on our end?
> — Matthias

The DNS settings on sa-vm1 are managed by ASF Infra team via Puppet and 
have been set like this for years ever since the server was built new.


Interestingly, if I run digs from the server I see both the old and the 
new IP:

davej@sa-vm1:~$ dig @ +short
davej@sa-vm1:~$ dig @ +short
davej@sa-vm1:~$ dig @ +short
davej@sa-vm1:~$ dig @ +short
davej@sa-vm1:~$ dig @ +short
davej@sa-vm1:~$ dig @ +short
davej@sa-vm1:~$ dig @ +short

But this site shows consistent DNS all around the globe:

I am only seeing minor DNS hosting issues that shouldn't cause any problems:

- should be added at the registrar as a name server 
for consistency

- The SOA record values are a bit odd shouldn't cause any problem.

- I would recommend NS record TTLs be 86400 (1 day) and A record TTLs of 
3600 or 7200.  There's no real benefit of going higher on A records and 
it only causes slower propagation of changes.  I see the NS records at 
the .org level are 86400 TTL but the 8 NS records at the child level 
(your DNS servers) have a TTL of 3600.  NS records at this level 
shouldn't change a lot and there is a benefit gained for setting them to 
86400 TTL.  When you plan to change the NS records at the registrar, 
that normally has to replicate around the Internet so a TTL of 86400 is 
OK since you typically would have both the old and new sets of DNS 
servers up at the same time for 2 or 3 days with identical records 
before shutting down or removing the old NS records.

- Any particular reason why the serial isn't in the standard format of 
YYYMMDDnn?  What you have now should be fine.  Just curious.

Compare with these:

This problem might clear up at Google's DNS servers in Europe soon. 
Google does some "special logic" to try to fix broken authoritative DNS 
servers that I have seen keep zones and previous records alive on the 
Internet when a bad change is made.  In this case, I am not seeing 
anything that bad wrong and the problem doesn't show up in the US like 
it is in France where sa-vm1 is hosted.

Hope this helps,

View raw message