19 Jan
2016
19 Jan
'16
7:27 a.m.
Here is my suggestion:
Get portal.ampr.org setup so that whenever an address or block is setup,
the account associated with that address or block can make DNS entries (of
all types). Have the portal update the DNS records for AMPR.ORG.
Have a clear process to delegate blocks of /24 or larger to have DNS
delegated (forward and reverse).
Put out a general announcement that the old hosts file will be deprecated.
Have a script to pull a current hosts file out from the live DNS for those
who want the database but are not connected to the DNS server on a
continual basis.
Kill the old hosts file.
Every active station, that has a portal account goes back in and sets their
DNS records. No attempt to migrate the old hosts file at all.
If a station doesn't have a portal account, direct them to create it and
then they can manage the DNS records for their block or address.
de K7VE
On Mon, Jan 18, 2016 at 3:00 PM, Brian Kantor <Brian(a)ucsd.edu> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Mon, Jan 18, 2016 at 10:37:04PM -0000, John Wiseman wrote:
--
------------------------------
John D. Hays
K7VE
PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>
Are we saying that ampr.org names and presumably
44 addresses are only
valid
if they have a gateway associated with them?
It's been suggested that I use the portal's networks list instead of the
encap file since there are clearly networks which are not tunneled.
I've had addresses with dns entries allocated
since the early 90's which
I
use from time to time for testing on rf networks
which don't have an
associated gateway. The chances are that by now the only record of that
allocation is the DNS entries. I guess I could just abandon them and
request
a new allocation, and attach it to a dummy
gateway.
I'm suggesting that as a first cut at clearing up the DNS mess. I suspect
that your radio-only DNS entries would be sacrificed in such a cleanup
and I don't know offhand how to get around that since their subnets are
not registered in the portal. If there's not too many of them, you could
send me a list and I could add them into the portal as radio-connected.
Does Chris know about them so he won't accidently assign them to someone
else?
The portal has a set of 'connection' tickboxes; this is used to indicate
how the network is connected to the Internet. It really should be a
pulldown menu allowing only one choice but that plea has been rejected.
Even if no box is ticked, the network is registered with the portal and
could be ANDed with the DNS - in other words, we'd use the portal's list
of known networks instead of literally the encap file. That list would
include all of the encap file, plus all the otherwise-connected subnets.
In other words, what I'm suggesting is that if the portal doesn't list
the enclosing subnet of a DNS entry, that DNS entry would go away.
- Brian
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net