<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
OK, after disabling the 44.x.x.x route, Firefox accepts the LoTW
certificate for <a class="moz-txt-link-freetext" href="http://encrypted.hamwan.org">http://encrypted.hamwan.org</a>, and your web pages
work. FYI: In Internet Explorer (which I tested for you, but don't
normally use), there's a long, LONG pause before it asks me to
confirm using the LoTW certificate, and then an even longer pause
before your web page comes up, that denies access.<br>
<br>
After re-enabling the 44.x.x.x route, <a class="moz-txt-link-freetext" href="https://encrypted.hamwan.org">https://encrypted.hamwan.org</a>
still works in Firefox (even after restarting it) -- I hope that's
not a bug, because traceroute is showing a direct 44.x.x.x path to
it.<br>
<br>
However, when I get to my page for adding DNS records, the
terminology used fails me, even after 15 years of running BIND with
a number of domains and subdomains, and teaching it at the U.
Washington:<br>
<ol>
<li>I know the distinction between a "hostname" and an "interface"
on a host, but not in a DNS record.</li>
<li>I know what an "interface" is in a route, but not in a DNS
record.</li>
</ol>
Is that terminology in the RFC?<br>
<br>
Somehow I changed the PTR record to be what I want. However, I'm at
a loss as to the difference between creating a "host" (which
apparently wants a MAC address, a lat/long, but not an IP address!),
and just creating an "A" record. So, I deleted everything and
manually added the "A" record. As a result, when I click on the
"Your hosts" tab, there's nothing, not even a listing header. I'd
gladly use the "Create Host" page, except that I no idea what to do
with the "interface" fields. I have no idea what the "Primary"
checkbox is for (more terminology issues). I know what "primary"
and "slave" mean in terms of NS records, but not for a host.<br>
<br>
Also, when I do a DNS search for my callsign on your web page, I see
all three of my desired DNS records. However, when I use "DIG", I
see:<br>
<font color="#3366ff"><tt><i><small><br>
dig @a.ns.hamwan.net ns1.ae7q.hamwan.net. ae7q.hamwan.net.
ns -x 44.24.240.173<br>
<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR,
id: 52006<br>
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 0<br>
<br>
;; QUESTION SECTION:<br>
;ns1.ae7q.hamwan.net. IN A<br>
<br>
;; AUTHORITY SECTION:<br>
<font color="#cc0000">ae7q.hamwan.net. 3600
IN NS ns1.ae7q.hamwan.net</font>.<br>
<br>
;; Query time: 65 msec<br>
;; SERVER: 44.24.244.2#53(44.24.244.2)<br>
;; WHEN: Sun Jun 8 20:03:05 2014<br>
;; MSG SIZE rcvd: 51<br>
<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR,
id: 40908<br>
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 0<br>
<br>
;; QUESTION SECTION:<br>
;ae7q.hamwan.net. IN NS<br>
<br>
;; AUTHORITY SECTION:<br>
<font color="#009900">ae7q.hamwan.net. 3600
IN NS ns1.ae7q.hamwan.net</font>.<br>
<br>
;; Query time: 86 msec<br>
;; SERVER: 44.24.244.2#53(44.24.244.2)<br>
;; WHEN: Sun Jun 8 20:03:05 2014<br>
;; MSG SIZE rcvd: 51<br>
<br>
<br>
; <<>> DiG 9.2.4 <<>>
@a.ns.hamwan.net ns1.ae7q.hamwan.net. ae7q.hamwan.net. -x
44.24.240.173<br>
; (1 server found)<br>
;; global options: printcmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: NOERROR,
id: 22989<br>
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0,
ADDITIONAL: 0<br>
<br>
;; QUESTION SECTION:<br>
;173.240.24.44.in-addr.arpa. IN PTR<br>
<br>
;; ANSWER SECTION:<br>
<font color="#009900">173.240.24.44.in-addr.arpa. 3600
IN PTR ns1.ae7q.hamwan.net.</font><br>
<br>
;; Query time: 24 msec<br>
;; SERVER: 44.24.244.2#53(44.24.244.2)<br>
;; WHEN: Sun Jun 8 20:03:05 2014<br>
;; MSG SIZE rcvd: 77</small></i></tt></font><br>
<br>
<br>
Note that there is no A record pointing to 44.24.240.173 (the PTR
record is correct). I've spent a couple hours trying to get it to
show up in DIG, to no avail. It didn't show up in DIG even before I
deleted the "host" entry.<br>
<br>
Also, the query for the NS record doesn't return an ANSWER section;
it just returns an AUTHORITY section (which happens to contain the
"answer"). That's not what I see when I query for NS records for
subdomains for (as an example) "u.washington.edu".<br>
<br>
I'm glad I'm retired and have the time to spend on this ... This is
your guys' network, and in a sense, I'm just playing around. You
should run DNS as you want. However, If someone like me has these
issues (I'm a perfectionist), I'll bet others are going to be lost
...<br>
<br>
<div class="moz-cite-prefix">On 2014-06-08 18:18, Tom Hayward wrote:<br>
</div>
<blockquote
cite="mid:CAFXO5Z0vfKA-e-xfMjeZFu7n8VWGcDgBHArZSTHw4OxzFSrbCQ@mail.gmail.com"
type="cite">
<pre wrap="">On Sun, Jun 8, 2014 at 5:24 PM, Dean Gibson AE7Q <a class="moz-txt-link-rfc2396E" href="mailto:hamwan@ae7q.com"><hamwan@ae7q.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This requires a specific (and non-current) version of a specific browser (eg, Opera) ?!?!?!?
</pre>
</blockquote>
<pre wrap="">
Dean,
The portal can be accessed from a few different protocols/configurations:
<a class="moz-txt-link-freetext" href="http://portal.hamwan.org/">http://portal.hamwan.org/</a> - plain old HTTP. This can be used to access parts of the portal that do not require authentication, like record listings and the map (e.g., <a class="moz-txt-link-freetext" href="http://portal.hamwan.org/dns/all/">http://portal.hamwan.org/dns/all/</a> ). We don't suggest logging in here because your username and password would be sent in the clear.
<a class="moz-txt-link-freetext" href="https://portal.hamwan.org/">https://portal.hamwan.org/</a> - HTTP over non-cipher (not encrypted), authenticated SSL. This is a Part-97-friendly way to authenticate with the portal. We have SSL configured to request a Logbook of the World certificate and only negotiate SSL with null ciphers. Most browsers don't allow null ciphers, so they will report an SSL cipher mismatch. I found that Opera 12.16, the most recent version of Opera released for Linux, has an option to allow null ciphers. I wrote up some instructions for this and left the sections for other browsers blank. You or anyone else who wants to experiment is welcome to experiment and come up with some instructions for other browsers.
<a class="moz-txt-link-freetext" href="http://encrypted.hamwan.org/">http://encrypted.hamwan.org/</a> - redirects to <a class="moz-txt-link-freetext" href="https://encrypted.hamwan.org/">https://encrypted.hamwan.org/</a>
<a class="moz-txt-link-freetext" href="https://encrypted.hamwan.org/">https://encrypted.hamwan.org/</a> - HTTP over encrypted, authenticated SSL. This is configured for standard, encrypted SSL, so it is NOT allowed over Part 97, but should work with normal browser settings.
The content is the same at all of these addresses; it's just the protocols that differ.
By the way, the SSL configuration may not be compatible with Internet Explorer; I never tested it. I seem to recall something about Internet Explorer not liking optional SSL authentication (as opposed to forced or disabled). Firefox, Chrome, Safari, and Opera are tested and working.
If you've done all this and it's still asking you to authenticate, there may be a bug in my code that pulls your callsign out of the LoTW certificate.
Tom KD7LXL
</pre>
</blockquote>
</body>
</html>