Hi Rial,
It’s not code that’s the problem - the portal already has a front end written to fully
manage DNS in the
ampr.org <http://ampr.org/> zone, I’ve even got the code for the
API ready, it’s more of a social / logistics problem as Brian mentioned. I’m sure we’ll
get there at some point.
Regards,
Chris
On 10 May 2017, at 21:40, Rial Sloan
<N0OTZ(a)n00tz.net> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
I was the lead architect and backend engineer for a migration from my
company's legacy two-server Tiny(DJB) DNS implementation to a 4-server
geo-redundant DNS based on PowerDNS that uses a multi-master (using
Tungsten) replicated MySQL backend in about a weeks work including
testing the migrated data off the public access. We intended to use it
for generating and provisioning new records for our mass email
application, but it was a feature that never got priority during the
development lifecycle of that app. We use the poweradmin web code
(
https://github.com/poweradmin/poweradmin) to provide a management
front-end and dictate ACLs. While we have internally created and
assigned tenant relationships to most of the parent zones, we don't
actually give our customers direct access to edit their zone (we're an
MSP and a lot of our customers would break things because they don't
understand DNS). There are some zones that did not have adequate notes
and documentation during migration similar in practice to half the
41431 records you mentioned not having a discernible owner, and we
assigned those records directly to our "support staff" tenant -- in
our practice on AMPRNet this could potentially be delegated to all of
the coordinators.
Moving to something like this would enable portal code to speak
directly to the DNS database backend (potentially eliminating the need
to modify the robot to handle the newer type requests) adding
redundancy (and self-healing) to DNS. PowerDNS also supports mrtg/rrd
output so reporting could be established on some kind of status
monitoring page as part of the portal. I wouldn't mind helping with a
deployment of a similar model for the ARDC related zones, if there is
interest and available development support.
I just mind-vomited everything I typed above and I'm not sure how much
of what pieces of a solution in my head actually transcribed to an
actionable RFC that could be understood by the mailing list. I'll
check back in on this thread later this evening.
--
Rial F Sloan II
N0OTZ
AMPRNet Volunteer Coordinator - State of Georgia
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net