Being able to delegate forward and reverse dns shouldn't be limited to a class C and larger. I have multiple commercial connections less than a /24 and can do that now. That should be up to the end user.
Sent from my iPhone
On Jan 18, 2016, at 7:27 PM, K7VE - John k7ve@k7ve.org wrote:
(Please trim inclusions from previous messages) _______________________________________________ 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@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________
On Mon, Jan 18, 2016 at 10:37:04PM -0000, John Wiseman wrote: 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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
--
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