Hi
Someone know what currently the ampr.org DNS allow to enter ?
I know of A and MX ... is there other ? (example SPF) ?
Any Info Welcome ..
Regards
Ronen - 4Z4ZQ
Ronen Pinchooks (4Z4ZQ) WebSitehttp://www.ronen.org/ www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com
At the moment, A, MX, and CNAME are handled by the robot. Anything else requires me to edit it in by hand.
Some day we'll improve on the whole process, but there is a matter of some 41,431 records on file that would have to be converted, and that has always been the stumbling block. It is essential that every record in whatever the new system is be owned by someone who is responsible for it, and we have no way of assigning ownership to about half of the records we have on file now. The rest we have the email address that submitted them.
At one time I attempted to correlate those email addresses with the email addresses registered in the portal, but there are a lot of records where the email address on the record isn't in the portal.
And every time I mention leaving out any of the existing records, I get email from extremely upset people who are gnashing their teeth and pulling their hair about losing an old-time IP address assignment, even if it's unroutable.
So far it hasn't been worth the flak.
There are a lot of people using AMPRNet who aren't on this mailing list and so notifying people of any impending action is problematic. - Brian
On Wed, May 10, 2017 at 07:18:53PM +0000, R P wrote:
Someone know what currently the ampr.org DNS allow to enter ? I know of A and MX ... is there other ? (example SPF) ? Any Info Welcome .. Regards Ronen - 4Z4ZQ
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.
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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
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...
Difficult to implement, but maybe we'll have to.
A complication is that a significant number of DNS updates are done by external automation (eg, hamnetdb). It (or at least its interface to the DNS robot) will have to change too. I don't know if the developers of that package are still active.
Perhaps this is the next thing for me to work on after the router settles down.
Thank you. - Brian
On Thu, May 11, 2017 at 01:48:52AM +0100, M6XCV (Mike) wrote:
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
Ronen,
If you mean what records can you request your coordinator to enter...
Any valid DNS record for hosts/IPs you are allocated can be submitted for the DNS Zones AMPR.ORG. and 44.IN-ADDR.ARPA.
- Lynwood KB3VWG
PS: I think the record you mentioned is actually a TXT record.