Yes, I'm now aware that there are nameservice problems and I'm working on it. It won't be fixed quickly because it requires manual intervention by several people in many different places around the globe, including the registries.
Thanks all for bringing this to my attention.
- Brian
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
Quick question as I don't know how it is set up now, but aren't the slave servers notified of updates on the master server? In a typical master/slave config the slave servers would be notified by the master server if the zone's serial gets updated.
73,
Ruben - ON3RVH
-----Original Message----- From: 44Net [mailto:44net-bounces+on3rvh=on3rvh.be@hamradio.ucsd.edu] On Behalf Of Rob Janssen Sent: woensdag 30 augustus 2017 11:18 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] ampr.org and 44.in-addr.arpa nameservice
Yes, I'm now aware that there are nameservice problems and I'm working on it. It won't be fixed quickly because it requires manual intervention by several people in many different places around the globe, including the registries.
Thanks all for bringing this to my attention.
- Brian
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
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Yes, when everything is working correctly they are notified of changes within seconds. - Brian
On Wed, Aug 30, 2017 at 09:22:27AM +0000, Ruben ON3RVH wrote:
Quick question as I don't know how it is set up now, but aren't the slave servers notified of updates on the master server? In a typical master/slave config the slave servers would be notified by the master server if the zone's serial gets updated.
73,
Ruben - ON3RVH
Well, I *finally* got the nameservers sorted with Network Solutions and ARIN, so 'intodns' gives us all green for both AMPR.ORG and 44.IN-ADDR.ARPA. - Brian
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
-
Brian Kantor -
Rob Janssen -
Ruben ON3RVH