30 Aug
2017
30 Aug
'17
5:58 p.m.
The problem is that some of the slave nameservers are using
'hamradio.ucsd.edu' as the master nameserver, on 169.228.66.6.
It isn't the master; 'ampr.org' on 44.0.0.1 is the master nameserver.
The nameserver on hamradio had stopped running and so the slaves with
the wrong master weren't getting updates. I restarted it.
This is not a serious issue at this precise moment because 'hamradio' gets
its updates from 'ampr.org' in seconds - they're in adjacent data centers
here at UCSD - but it will be a problem because at some time in the next
few months 'hamradio' is going to be retired and there won't be anything
operating on 169.228.66.6 anymore. So there is time to fix the problem
with the slave nameservers using the wrong master, but it must be fixed.
When 'hamradio' goes away, this mailing list will move also. When I
know where and when I'll announce it.
- Brian
On Wed, Aug 30, 2017 at 11:17:55AM +0200, Rob Janssen wrote:
Well, it appears that the originally envisioned
problem (not all servers uptodate) has
been fixed. The 2nd problem (incorrect servers in org zone) is still open, but that
should affect only the lookup time. It probably explains why ampr.org lookups are
often so slow.
However, when I checked before there were only some servers that were at most 24h
behind.
Maybe they synchronize only once per day.
Was that the "slave nameservers are not updating" issue that you were after?
Or was there another slave that had not been updating for a much longer time?
Generally, 24h out of date should not be that much of an issue. Of course, when it
stopped
syncing completely that would be bad.
Rob