Difference between revisions of "PowerDNS Admin Web Frontend"
From Linuxnetworks
| (14 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
Also, there are a few existing web-based tools for administrating PowerDNS installations, none of them seem to be good enough for daily work, especially where access for end-users is required. This page should be a starting point to collect requirements from users to describe the needed features for a PowerDNS administration web frontend. | Also, there are a few existing web-based tools for administrating PowerDNS installations, none of them seem to be good enough for daily work, especially where access for end-users is required. This page should be a starting point to collect requirements from users to describe the needed features for a PowerDNS administration web frontend. | ||
| − | * Should be able to work with SQL | + | General: |
| + | * Web-based interface | ||
| + | * Should be able to work with SQL and LDAP based backends | ||
* SQL backend should handle all supported databases | * SQL backend should handle all supported databases | ||
| − | * | + | * DynamicDNS interface (https://www.dyndns.com/developers/specs/) |
| − | + | * Allow managing multiple servers | |
| − | + | * Fully Translatable | |
| + | |||
| + | Authentication/Authorization: | ||
* Support multiple site owners which can change their own records | * Support multiple site owners which can change their own records | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
* User-management should be "under" web server (i.e. use Apache authentication methods) | * User-management should be "under" web server (i.e. use Apache authentication methods) | ||
| + | * Support different authentication and access control sources (database, LDAP, HTTP Auth, etc) | ||
| + | * Hierarchical permission system | ||
| + | |||
| + | DNS records: | ||
| + | * Support creation of all record types | ||
| + | * Dialogs for complex records creating IANA specs/RFC based syntax (e.g. user selects NAPTR-RR and gets a drop-down box with the list of IANA protocols and a text field for the URI. The dialog function then creates the complex syntax of the NAPTR-RR). | ||
| + | * Restrict DNS TTL specifiied range | ||
| + | * Check all existing record types for correctness | ||
| + | ** Disallow duplicates | ||
| + | ** Enforce RFC specs on CNAMEs to ensure compatability | ||
| + | |||
| + | Usability: | ||
| + | * Allow "paging" through database when it contains many thousands of zones/records | ||
| + | * Search for zones/records | ||
| + | * Wizard type interface for adding new domains (Asks for basic A and MX addresses, provides defaults, picks a good default SOA), and then asks for any other services hosted on this domain and hand holds the the user throu the process. Would be nice if when a new user is added to what ever backend, you can trigger a run wizard on first login. | ||
| + | * Built in whois + dns query tool, to check both delegation is correct, and status of replication/zone transfers to slave servers. | ||
| + | * Allow the user to use/create dns-zone templates. These zone-templates can later be used e.g. to reset to default template. Templates should be able to be passed on to from user higher in hierarchy to below. | ||
| + | * Ability to 'test' that MX server actually accepts mail for that domain, and that www. points to a working webserver, mail. points to a pop3/imap server. Shows a test button next to each records, with a list of test to perform against server. | ||
| + | |||
| + | Templates: | ||
| + | * Completely skinable templates for different CIs | ||
| + | * Nice design | ||
| + | |||
| + | Techniques: | ||
* Object-oriented programming | * Object-oriented programming | ||
* Model-View-Controller architecture | * Model-View-Controller architecture | ||
| − | * | + | * Optional AJAX to make it "look good" |
| + | * Use PHP > 5.1 | ||
| + | * Backend Interface to be exported with a RPC interface | ||
| + | ** User Defined Event Driven RPC's configured from admin, ie On Add/Edit/Delete/Login/Logout, etc, to update other services. | ||
| + | ** RPC to allow other apps (ie Other web consoles to push changes into DNS) | ||
| + | |||
| + | Standards: | ||
| + | * XHTML-1.1-strict validation | ||
| + | * CSS 2.1 validation | ||
| + | * Must allow working with lynx/w3m on text consoles (e.g. W3C WAI-CSS-stylesheet) | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Please add your own suggestions to this list or add your comment to the discussion page if you are unsure. | Please add your own suggestions to this list or add your comment to the discussion page if you are unsure. | ||
Latest revision as of 13:46, 28 April 2008
Also, there are a few existing web-based tools for administrating PowerDNS installations, none of them seem to be good enough for daily work, especially where access for end-users is required. This page should be a starting point to collect requirements from users to describe the needed features for a PowerDNS administration web frontend.
General:
- Web-based interface
- Should be able to work with SQL and LDAP based backends
- SQL backend should handle all supported databases
- DynamicDNS interface (https://www.dyndns.com/developers/specs/)
- Allow managing multiple servers
- Fully Translatable
Authentication/Authorization:
- Support multiple site owners which can change their own records
- User-management should be "under" web server (i.e. use Apache authentication methods)
- Support different authentication and access control sources (database, LDAP, HTTP Auth, etc)
- Hierarchical permission system
DNS records:
- Support creation of all record types
- Dialogs for complex records creating IANA specs/RFC based syntax (e.g. user selects NAPTR-RR and gets a drop-down box with the list of IANA protocols and a text field for the URI. The dialog function then creates the complex syntax of the NAPTR-RR).
- Restrict DNS TTL specifiied range
- Check all existing record types for correctness
- Disallow duplicates
- Enforce RFC specs on CNAMEs to ensure compatability
Usability:
- Allow "paging" through database when it contains many thousands of zones/records
- Search for zones/records
- Wizard type interface for adding new domains (Asks for basic A and MX addresses, provides defaults, picks a good default SOA), and then asks for any other services hosted on this domain and hand holds the the user throu the process. Would be nice if when a new user is added to what ever backend, you can trigger a run wizard on first login.
- Built in whois + dns query tool, to check both delegation is correct, and status of replication/zone transfers to slave servers.
- Allow the user to use/create dns-zone templates. These zone-templates can later be used e.g. to reset to default template. Templates should be able to be passed on to from user higher in hierarchy to below.
- Ability to 'test' that MX server actually accepts mail for that domain, and that www. points to a working webserver, mail. points to a pop3/imap server. Shows a test button next to each records, with a list of test to perform against server.
Templates:
- Completely skinable templates for different CIs
- Nice design
Techniques:
- Object-oriented programming
- Model-View-Controller architecture
- Optional AJAX to make it "look good"
- Use PHP > 5.1
- Backend Interface to be exported with a RPC interface
- User Defined Event Driven RPC's configured from admin, ie On Add/Edit/Delete/Login/Logout, etc, to update other services.
- RPC to allow other apps (ie Other web consoles to push changes into DNS)
Standards:
- XHTML-1.1-strict validation
- CSS 2.1 validation
- Must allow working with lynx/w3m on text consoles (e.g. W3C WAI-CSS-stylesheet)
Please add your own suggestions to this list or add your comment to the discussion page if you are unsure.
