[tz] Blocked USNO sites was: Updated Public Domain leapseconds.list

[Brian Inglis]

On 2019-07-06 13:27, Chris Woodbury wrote:>> On Sat Jul 6 16:12:26 UTC 2019,
Brian Inglis wrote:
>>> On 2019-07-05 15:55, Chris Woodbury wrote:
>>> # This NTP leap-second file was created with data obtained from
>>> # the United States Naval Observatory (USNO) MAIA FTP server.
>>> #  Find it at: <ftp://maia.usno.navy.mil/ser7/leapsec.dat>
>>> #   See: http://maia.usno.navy.mil/ser7/ser7.txt
>> Seems to be some DNS resolver and network blocking, possibly only outside 
>> the US, to maia.usno.navy.mil and www.usno.navy.mil; interactive web 
>> browser access and Naval Oceanography Portal to tycho.usno.navy.mil and
>> aa.usno.navy.mil mostly work, but web browser ftp access does not, and non
>> web browser resolution and access do not, e.g. host or wget; however
>> everything resolves and is accessible form the browser and command line
>> from toshi.nofs.navy.mil.>> Some other previous reports back this up, but there were no followups to
>> say whether issues were temporary and cleared up, or persisted and were
>> permanent.>> It may be possible that lookups or accesses may be rate limited to deter
>> intrusions, or entries may have expired because they may be offline for
>> July 4 thru the weekend, or sites may be blocked due to lack of monitoring
>> staff or funding for non-defense services.
> DoD sites are subject to frequent attack from the Internet.  One of their
> defense strategies is to "go turtle"". Sometimes they're not there at all
> but, more often, they isolate just portion of their "space".  (TRACERT ends
> in never-neverland.)  I have discovered that, when this happens, the Navy.Mil
> and USNO.Navy.Mil DNS servers are often not reachable.  As a result, while
> USNO sites are actually available though the Naval Oceanographic Portal (NoP)
> (point of presence (PoP) in Portsmouth, VA), their DNS entries are not.  I,
> personally, solved part of this problem by adding the USNO sites I use to
> /etc/host (or its Windows equivalent, %WINDIR%\System32\drivers\etc\hosts).
> These are:
> 199.211.133.23  maia.usno.navy.mil
> 199.211.133.93  aa.usno.navy.mil
> 199.211.133.239 tycho.usno.navy.mil
> # Charon is a USNO.Navy.Mil DNS server on the NOP
> 199.211.133.5    charon.usno.navy.mil charon.nofs.navy.mil
> 192.68.148.66    charon.nofs.navy.mil
> 192.68.148.80    toshi.nofs.navy.mil
> MAIA also has backup servers for their data at NASA
> Goldstone Space Flight Center (cddis.gsfc.nasa.gov)
> and, as Brian mentioned, toshi.nofs.navy.mil.
> (At this instant, MAIA and Toshi are unavailable via
> HTTP but FTP is just fine (with /etc/host entries).
> If one is running a local DNS server, adding a pointer to
> USNO.Navy.Mil with a Charon.USNO.Navy.Mil NS RR
> might help the cause...
> Since I've done these things (particularly the /etc/hosts
> entries), I rarely have problems reaching USNO sites.
> Also, sometimes, DoD restrict themselves to Secure DNS.
> As I've got (some of) the certificate information installed,
> I may not have problems where others might.
> Lastly, occasionally I can't reach MAIA via HTTP but FTP works
> just fine.  (I've just change my references to ser7.dat to FTP
> for that reason.)

Thanks for those tips: I already installed the DoD Entrust and DIA CA cert
packages in my desktop and command line environments just to ameliorate access
problems.
I will take your advice gratefully and add time and data servers to hosts,
appropriate checks to scripts to let me know if address and name no longer
match, and alternate protocols as well in data retrieval scripts.
Looks like we will all have to get used to using alternate, backup, and fallback
sites and protocols for some of these data sources, and being more patient. ;^>

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.