[HamWAN PSDR] DNS mapping

[Dean Gibson AE7Q]

Gotcha (in the sense I understand).  Check out my current setup, for 
reasonableness.  Possible bugs:

 1. 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.
 2. 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.
 3. 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).
 4. The "All Yo' Stuff", apparently being intended to be inclusive,
    could include "Your DNS records".

Going to dinner now ...

-- Dean

On 2014-06-08 21:18, Tom Hayward wrote:
> On Sun, Jun 8, 2014 at 8:42 PM, Dean Gibson AE7Q <hamwan at ae7q.com> wrote:
>> OK, after disabling the 44.x.x.x route, Firefox accepts the LoTW certificate for http://encrypted.hamwan.org, 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.
> 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.
>
>> After re-enabling the 44.x.x.x route, https://encrypted.hamwan.org 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.
> 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.
>
>> 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.
> It sounds like you're in the Host section, not the DNS record section.
>
> https://encrypted.hamwan.org/host/new
>
> Knowing your background, I think reading the code might help you understand the relationships:
> https://github.com/HamWAN/hamwan-portal/blob/master/portal/models.py#L50
>
> (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.
>
> https://encrypted.hamwan.org/dns/new/
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20140608/bd59a9e2/attachment.html>