On 3/14/19 12:40 AM, Matthias Leisi wrote:
Am 14.03.2019 um 05:17 schrieb root <[email protected]>:
Fetching sa-update URLs from http://spamassassin.apache.org/updates/MIRRORED.BY
http://sa-update.dnswl.org/ (78.47.167.123): 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 sa-update.dnswl.org <http://sa-update.dnswl.org/>
(…)
sa-update.dnswl.org. 21600 IN A 116.203.4.105
# dig +trace -t soa dnswl.org <http://dnswl.org/>
dnswl.org. 21600 IN SOA zone-ns1.dnswl.org.
admins.dnswl.org. 1903112142 3600 1200 302400 21600
„1903112142“ is 2019-03-11 21:42 (in CET), ie three days ago.
I see that the old IP 78.47.167.123 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.
sa-vm1:/etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
Interestingly, if I run digs from the server I see both the old and the
new IP:
davej@sa-vm1:~$ dig @8.8.8.8 sa-update.dnswl.org +short
116.203.4.105
davej@sa-vm1:~$ dig @8.8.8.8 sa-update.dnswl.org +short
78.47.167.123
davej@sa-vm1:~$ dig @8.8.8.8 sa-update.dnswl.org +short
116.203.4.105
davej@sa-vm1:~$ dig @8.8.8.8 sa-update.dnswl.org +short
116.203.4.105
davej@sa-vm1:~$ dig @8.8.8.8 sa-update.dnswl.org +short
116.203.4.105
davej@sa-vm1:~$ dig @8.8.8.8 sa-update.dnswl.org +short
116.203.4.105
davej@sa-vm1:~$ dig @8.8.8.8 sa-update.dnswl.org +short
78.47.167.123
But this site shows consistent DNS all around the globe:
https://dnschecker.org/#A/sa-update.dnswl.org
I am only seeing minor DNS hosting issues that shouldn't cause any problems:
https://intodns.com/dnswl.org
- zone-ns3.dnswl.org 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 dnswl.org with these:
https://intodns.com/apache.org
https://intodns.com/spamassassin.org
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,
Dave
