19 Jan
2016
19 Jan
'16
7:45 a.m.
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(a)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(a)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(a)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>
>