Dns-operations mailing list

["Panesar, Amrit" <apanesar AT 4195tech.com>]

As far as LDAP is concerned, are we limited to the standard ASCII or is UTF-8 allowed as well?

On Fri, Feb 8, 2013 at 1:54 PM, Jeff Taylor <shdwdrgn AT sourpuss.net> wrote:

I thought I should get some notes out here as to what direction I am heading, and where I'm hoping to take this.  There will be a lot of info in this first email, so when you reply, please just cut out the specific parts you want to discuss so the emails don't get too hard to navigate through...

The basic concept I am pursuing is as follows...

A universal database of a users (this is already in place)
- Username and real name (possibly include IRC nicks for reference?)
- Password usedfor logging in to all OpenNic services
- Records to control each user's access level (server logins, TLD registrations, etc)
- Valid email address and other contact info

A unified service which collects ALL data for TLDs
- Date created
- Current manager(s) (tied to LDAP user records)
- Master server (or LDAP if it is managed from here)

A unified service which collects ALL data for each domain
- All DNS records
- Date created
- Last date renewed
- Date that domain expires
- Current owner(s) (tied to LDAP user records)

All of the T1 operators currently use BIND9, and I don't see a problem with sticking with that.  Part of the overall project is getting data back and forth between both the registrar websites and the DNS zone files.  For the DNS side, I already have some working scripts... zone2ldap and ldap2zone.  These both use the dnsdomain2.schema, which seems fairly standard.  I can take an existing zone file for a TLD and break it down into an LDIF file, which is fed into LDAP.  Alternatively, I can request the zone file for an individual domain (and in the future, for the entire TLD), and have a zone file generated which can be used directly by BIND to propagate the data through DNS.  These back-end scripts will hopefully make it very easy to incorporate LDAP access directly into any existing registrar websites, and give us a stepping stone from which to built a new registrar website that handles all aspects of domain management and TLD creation/retirement.

The culmination of all this will be the registrar website...

For TLD management, we would use the LDAP user access levels to control who can make these changes.  It should be a very easy process to add a new TLD and define who will administer it, however we should also consider the option that any TLD listed under LDAP should also allow administration from any other TLD-level operator. At the TLD level, we should also define such things as allowing new domain to be created instantly, or require admin approval.  We could also have an option that once a user has been approved for their first domain, they will be allowed to instantly create new domains? We also want to define the default registration periods under each TLD.  For example, having a domain initially registered for 1 month (requiring the user to come back and 'prove' their interest in maintaining the domain), with renewals being allowed for 1 year at a time.  We might also want to define that if a domain has an invalid DNS record for a certain period (such as pointing to NS servers that don't resolve the domain), the domain will automatically expire. And we want to define how long each TLD will reserve an expired domain name before it is completely erased and made available for someone else to register.  Of course the software would have to email users when their domain is about to expire, and possibly include a hash-link in the email that takes them directly to the renewal page.  And we could include flags for certain automated checks - such as if the TLD policy requires each domains to have an active web page or mail server, or something else.  Flags should be considered for any TLD policy which we can automatically check through code.

Domain management should definitely contain both 'easy' and 'advanced' options.  A simple setup may not require anything more than the user defining the IP address they want to point to for their @ and WWW records, with the assumption that OpenNic will provide the nameservers for that domain.  When explaining any options on the website, we should always include a brief description suitable for those who are not familiar with DNS, followed by a detailed technical description for those who understand.  For example, and advanced screen would give the option of nameserver management by either OpenNic or the user.  The simple description would be "We take care of the details, or you manage it yourself", whereas the details would explain that if you want to run your own nameserver, you need to fill in NS records here with your IP addresses, enter a nameserver record such as ns1.mydomain.free, and then go to <link> to test your zone records once you have them configured...  The 'easy' config screens should probably always default to OpenNic hosting the nameserver, and only provide basic records - A, AAAA, CNAME, and MX (maybe TXT and RP?).  The 'advanced' screens would provide full configuration of all record types and subdomains.  In either case, once the user is finished making changes, there should be a submit button which pushes the new information through named-checkconf to validate the configuration, and provide immediate feedback if there are any errors.

Finally, there is scheduled maintenance.  When a user edits a domain record, it should be immediately pushed into LDAP, however at regular intervals (maybe every 10-15 minutes?) that server will need to check to see what domains have been updated, and generate a new zone file for those domains, which in turn would send out a new zone file for the TLD.  What we need to do is ensure that overlapping serials are not sent out if 2 different users are working on their respective .tld domains at the same time.  To manage this, we might consider having four T1 servers designated as the official updaters.  Each would have their respective timeslots every hour in which they check if any records have changed under each TLD, and if so a new TLD zone file would be generated.  This way there is no chance of conflicting zone files being created, and if one of the servers is offline, we still wouldn't have more than a 30-minute gap before a new zone file was sent out by the next server.  We would also want a tool which lets us immediately generate a full TLD zone when needed.  There should be some discussion as to how we prevent conflicting records, but we want to get updates out there as often as possible.  One alternative might be more frequent checks for updates, and changing to an alternate serial format like YYMMDDIIII (where I is minutes in the day, up to 1439).

I think that's about it.  Overall, the project would give us a fully distributed system for handling domain registration, and we would have the ability to manage domains from ALL TLDs in a single location.  We could use dns round-robin to spread the load between multiple websites, and we eliminate the problem with lost information or admins dropping out of sight.  There are probably flaws with this approach, but if we handle security properly, we should be able to provide a better service and present a consistent look&feel to all aspects of OpenNic's web presence.

----
To unsubscribe, email dns-operations-unsubscribe@lists.opennicproject.org