Closed systemcrash closed 1 year ago
While you're there, decrease the field width to something smaller
The current SOA implementation follows the RFC 1035 which says times in SOA are expressed in seconds:
All times are in units of seconds.
We tested this with bind, knot and with a few providers exposing the SOA records: timers are reported in the correct unit in happyDomain.
Could you please check if this is something related to your domain name provider/authoritative server? (when asking with dig
/nslookup
/drill
the SOA record of your domain, if it reports seconds whereas in happyDomain it exposes nanoseconds, then the issue should be fixed in the provider implementation (we rely on dnscontrol for this), not in the web interface).
Noted the field width to fix.
dig returns everything as expected - always has. we keep a close eye on our DNS.
If the blame lies with the external lib, you're better positioned to sending a PR - I don't really know that code-base, or how yours uses theirs...
I'm pulling in via the Dynamic DNS or axfrddns from bind locally.
Another hint: if I look at the "View my zone" which presents everything which HD has, in text, all values there are correct.
Zone Serial is correct.
But every value which is a time.Duration
is... wrong.
Oh weird. The fault is totally on our side, we messed up during the frontend migration, the type behavior is indeed wrong and always returns nanoseconds.
Should be fixed in 1711a4736eb607eb152670ac1fac4bcdb1ede95e.
Confirmed.
Cosmetic, but view-only looks like this (at least on firefox):
I got HD to NXDOMAIN from my NS.
But it displays the following, where all times are too large by 1e9. Divide by 1e9 to fix them: e.g. should be 3600s