<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Gotcha (in the sense I understand). Check out my current setup, for
reasonableness. Possible bugs:<br>
<ol>
<li>The DNS records that "Create Host" (and its "edit/update"
variant) creates (A and PTR), do not have a TTL (which I assume
means they pick it up the zone default). Easily edited in "Your
DNS records". Of course, let me know if you would prefer the
field blank, in order to use the zone default.<br>
</li>
<li>For "ether1.paine.ae7q.hamwan.net", "Create Host" would not
allow me to specify an IP address outside of my allocation.
It's useful to have such an A record (obviously without the PTR
record), if only for record-keeping on an interface (eg, mine)
that accesses another network. I created it separately.<br>
</li>
<li>The list of "Your DNS records" does not include the PTR
record, which then must be searched for, in order to edit (eg,
to add the TTL value).</li>
<li>The "All Yo' Stuff", apparently being intended to be
inclusive, could include "Your DNS records".</li>
</ol>
Going to dinner now ...<br>
<br>
-- Dean<br>
<br>
<div class="moz-cite-prefix">On 2014-06-08 21:18, Tom Hayward wrote:<br>
</div>
<blockquote
cite="mid:CAFXO5Z3f3WbJHkYym-7u0GJddZEksOJKdYjdRybmb4bv3qNBbw@mail.gmail.com"
type="cite">
<pre wrap="">On Sun, Jun 8, 2014 at 8:42 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="">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.
</pre>
</blockquote>
<pre wrap="">
Interesting. I'm pretty sure it's stuck trying to deal with the "VerifyClient Optional" piece in SSL--something I've heard is not supported. I'm torn as to how to deal with this. If I simply require client verification (SSL authentication), the error message for those without LoTW certificates will be the browser's protocol error page, not something with the HamWAN logo and an explanation.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
No, not a bug. In case of emergency, there may be a case for using that encrypted interface over Part 97 (i.e., someone will die if they don't get their DNS configured, and they only have access to Chrome at the time...). I put "encrypted" in the domain so that it would be very obvious encryption was part of the protocol and the control operator could decide if that was something they wanted to access over RF.
</pre>
<blockquote type="cite">
<pre wrap="">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:
I know the distinction between a "hostname" and an "interface" on a host, but not in a DNS record.
I know what an "interface" is in a route, but not in a DNS record.
</pre>
</blockquote>
<pre wrap="">
It sounds like you're in the Host section, not the DNS record section.
<a class="moz-txt-link-freetext" href="https://encrypted.hamwan.org/host/new">https://encrypted.hamwan.org/host/new</a>
Knowing your background, I think reading the code might help you understand the relationships:
<a class="moz-txt-link-freetext" href="https://github.com/HamWAN/hamwan-portal/blob/master/portal/models.py#L50">https://github.com/HamWAN/hamwan-portal/blob/master/portal/models.py#L50</a>
(Maybe I should make a UML diagram or something.)
A Host is something we use for tracking assets on the network. For example, each of our sector routers has a Host record with type set to "sector". With a little script I wrote (inspired by Ansible), I can send a command to all sector routers at once. The target list is compiled by querying all hosts with type == sector. Another script can icmp ping all hosts to report their status.
Each host can have zero-to-many IP addresses. Some validation ensures we haven't assigned the same IP address to more than one host. The Host/IPAddress form has a field for "interface" so we can keep track of which interface the IP address was configured on (e.g., ether1 or wlan1).
What does this have to do with DNS? When saving an IP address record, you can select "auto DNS" and "primary". This is *not* a direct interface to bind, but rather a tool to automatically generate some DNS records. If "auto DNS" is checked, an A record will be generated in the following format:
[interface].[hostname].hamwan.net
[hostname] is restricted to something that ends in the callsign you are logged in with, for example "home.ae7q".
The "primary" field can be used in conjunction with "auto DNS" to indicate which interface is the primary for that host. For modems like yours, this will be the public side, wlan1. This will generate a CNAME record in the following format:
[hostname].hamwan.net CNAME [interface].[hostname].hamwan.net
Okay, say you don't select "auto DNS", but you want some A records, CNAMES, and maybe some other DNS record types. This is what the DNS section is for. Any time you're not happy with auto generated records, you can manually enter them in the DNS record section.
<a class="moz-txt-link-freetext" href="https://encrypted.hamwan.org/dns/new/">https://encrypted.hamwan.org/dns/new/</a>
Seeing as you're the first network user to poke around in this management portal, I expect you'll find some bugs and usability issues. Please document this stuff so bugs can be fixed and documentation can be improved.
Tom KD7LXL
</pre>
</blockquote>
</body>
</html>