> 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
A side note: if we are running any RBL tests on that machine, 8.8.8.8 & friends may not be the best choice. > > 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 I flushed DNS cache at Google some 24 hours ago at https://developers.google.com/speed/public-dns/cache, and still it seems to show stale data. > But this site shows consistent DNS all around the globe: > > https://dnschecker.org/#A/sa-update.dnswl.org > <https://dnschecker.org/#A/sa-update.dnswl.org> That IP is also not in the zone file any more. > 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 Only the glue was added to the parent, not the NS entry itself. Thanks, fixed. > - I would recommend NS record TTLs be 86400 (1 day) and A record TTLs of 3600 > or 7200. Indeed, that makes sense. Fixed. > (SOA) - Any particular reason why the serial isn't in the standard format of > YYYMMDDnn? What you have now should be fine. Just curious. Yes :) We create the zone from source files and thus need to automatically create the SOA serial. And this being in a makefile, having a daily incrementing „nn“ is not trivial. That’s why we have SOASERIAL=`date '+%y%m%d%H%M‘` > 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. 8.8.8.8 & friends are handled differently for most DNSxL zones, because otherwise freeriders will hind behind those resolvers. In our case, they see a zone which is slightly different from the rest (basically without NS records for the list.dnswl.org <http://list.dnswl.org/> zone). # dig txt amiblocked.dnswl.org @8.8.8.8 +short "yes" "You are blocked from using list.dnswl.org through public nameservers“ I asked on https://groups.google.com/group/public-dns-discuss <https://groups.google.com/group/public-dns-discuss> for any further hints. — Matthias
