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.

Could I suggest a technical solution to a social problem?

You could add a column to the records table containing a username/id, default value NULL. You then add a way of specifying this field in the existing system.

You still have the existing system for managing records working exactly the same, however you now have the ability to assign ownership of new records (or existing ones) to a specific user. You could add a simple text field to the record editor to specify this.

Once records have a user associated with them you can provide whatever management interface is appropriate. If you wanted to let users create new records then ownership would be assigned at creation time.

An "ideal system" would allow multiple users to be associated with records, however I think that complicates things too much for this use case. Having records be editable by coordinators or their owner is probably sufficient functionality whilst keeping the old system unchanged.

In social terms: Adding self-service doesn't mean you have to get rid of all the checkouts and call-centres. It does reduce the workload, though. ;)

Thanks, Mike, M6XCV

On 10 May 2017 at 21:54, G1FEF via 44Net 44net@hamradio.ucsd.edu wrote:

(Please trim inclusions from previous messages) _______________________________________________ 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 https://u4477715.ct.sendgrid.net/wf/click?upn=iw7y0u5dIhrvOZEkHKa-2Fswt5YRPKHFUyaoA3gGtuwLg-3D_hzVA6CorwLLoBNMa4L2WJ-2FCatrCa33kwc-2F5ZLK3-2BWtJM0raTbi8HEZMjSq4gtQc8u7AHQRl4CnE18-2Bx6vleA-2BbezoiBfvicNQk16n7h1YDFXXLSPkPaIKXqWNMe8-2F-2B82ccbxdRSivNj2MjDgMbZSJKGbVjZ1-2BGeczS3O0nXi-2FWrcldJwBUb7VXAS4zNnYehh4966cHlyIRg5-2FE9ReVmJH3Gg0JUafycxBC9oqQWz2Yw-3D 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@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://u4477715.ct.sendgrid.net/wf/click?upn=Ki4chJONuNfM0VomxEE-2Boe-2FANb... 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@hamradio.ucsd.edu https://u4477715.ct.sendgrid.net/wf/click?upn=vS4GjSiF-2F5vYmfX5tr6ez81-2Fej...