From: Bob Proulx via rockbox <rockbox_at_cool.haxx.se>
Date: Fri, 18 Dec 2020 19:04:48 -0700

Solomon Peachy via rockbox wrote:
> On Fri, Dec 18, 2020 at 10:32:47PM +0100, Michael Sparmann via rockbox wrote:
> > Indeed, there is now a DNSSEC issue (some DNSKEYs expired yesterday).
> > Luckily not one on Haxx' side, but at ShaftNet.
> > (See https://dnsviz.net/d/www.rockbox.org/dnssec/ for details about the
> > issue.)
>
> It appears that the secondary DNS for shaftnet (hosted by the registrar,
> ie gandi.net) isn't synchronizing master zone updates in a timely
> manner.

I know you said you did not have control of the domain.

But it appears the last zone update was on 2020-08-17 some time ago.
And the secondaries seem to be in sync with the primaries.

    rwp_at_angst:~$ dig rockbox.org ns +short
    ns1.haxx.se.
    ns.amplitut.de.

    rwp_at_angst:~$ dig _at_ns1.haxx.se rockbox.org soa +short
    mail.rockbox.org. daniel.rockbox.org. 2020081701 43200 15 604800 43200

    rwp_at_angst:~$ dig _at_ns.amplitut.de rockbox.org soa +short
    mail.rockbox.org. daniel.rockbox.org. 2020081701 43200 15 604800 43200

    2020081701 ; Serial Number in date format
    43200 ; Secondaries refresh after 12 hours
    15 ; Secondaries retry after 15 seconds
    604800 ; Secondaries expire after 7 days
    43200 ; Minimum cached TTL 12 hours

I think the 15 seconds for retry of secondaries is too short. More
typical would be 300 seconds. But whatever. The rest are not what I
pick but are not completely unreasonable.

If the serial numbers were ever found to be different between the
nameservers then that is absolute indication that they are not
syncing between primary and secondary. That is always seen for some
few minutes when a zone is updated and the serial number increased.
To avoid load spikes the secondaries are scheduled a few minutes later
for a zone transfer.

> > I'm still lost what the problem could have been before that key expired
> > though.
>
> It very well could be this same problem; if things have been falling out
> of sync, then depending on which nameserver is contacted, stale results
> could be served.

It's still very stable and reliable for most of us. Therefore I am
still thinking it is related to the mobile clients on various
different networks being different on different networks.

Such as if IPv4 routes work but IPv6 routes happen to fail on one
network but not a different network. If both IPv6 and IPv4 addresses
are provided then the default dual stack configuration is that IPv6
will be preferred and used. But IPv6 is still not everywhere.

For example my home ISP still as of this day has no support for IPv6
and therefore all of my home connections are IPv4 because that is the
only networking I have available there. But if I am almost anywhere
else then my mobile device gets an IPv6 address and IPv6 connectivity
is then used by default.

> Not sure why this is suddenly having issues (things have been stable for
> years) but I'll keep an eye on it.

It's likely something in the greater surrounding environment that has
changed rather than something directly rockbox.org itself.

Bob


-------------------------------------------------------------------
Unsubscribe: http://cool.haxx.se/cgi-bin/mailman/listinfo/rockbox
FAQ: http://www.rockbox.org/twiki/bin/view/Main/GeneralFAQ
Etiquette: http://www.rockbox.org/mail/etiquette.html
Received on 2020-12-18