Discuss mailing list

[Jeff Taylor <shdwdrgn AT sourpuss.net>]

I have been working on some back-end code to store zone info in the LDAP server we already have running.  DNS info is fairly straightforward, and all I really need to add on top of that is ownership info (LDAP user ID which could already contain contact name and email address).  The scripts I am working with are straightforward... one script will take a standard bind9 zone file and convert it to LDIF format (a flat-text file that can be sent to LDAP with a single command).  The second script reverses the process, reading a domain from LDAP and creating a bind9 zone file.  The idea is to *store* the info in LDAP, but still use standard flat-text files for bind9 to operate from.  Any registrar software then has the choice of working with the LDAP data directly, or generating simple bind9 zone files that can then be pushed into LDAP for data updates.

As far as backups, this would mean that every server running an LDAP host would have a local copy of everything.  Data bursts would only occur when a new registrar needs to grab the entire set of data, otherwise traffic would be very light.  In addition, I have a high level of redundancy on my own servers... The data is backed up every day, with recursive restores available for a 6-month period.  The backups are stored on a raid-1 array.  I'm sure others may have their own backup solutions, so we should be able to guarantee plenty of data redundancy from multiple geographic locations.

Ideally, what I would like to see is that most (or all) of the TLDs get stored in LDAP, and new registrar software written which allows registration and modification of domains from any TLD present in LDAP.  Registration could occur from any TLD site, so there is no reliance on a single operator for helping people troubleshoot their domain info.  And of course there is no chance of an operator losing all the domain data.  Also, if an operator decides to abandon their TLD, or OpenNic (its happened before), we still retain all of the information needed to continue supporting the affected TLD.


On 02/06/2013 05:43 PM, Jamyn Shanley wrote:
> Given the vast majority of the data would be text (sql databases, flat files, whatever) which generally compresses very well in transit, I think it would be pretty low overhead. I doubt there is more than 10g of userdata total. Duplicate data would not need to be re-transmitted, as rsync only sends the changes since the last update. So if a server backed up yesterday and then 200 accounts were added today, rsync would only send the data for those 200 accounts.
>
> Who would pay for the backup server? Well, I could provide one for free.
> Or, we could go a different route and encrypt the backups on the server side before transit, and then store the backup on a free or almost free solution (SpiderOak, DropBox, whatever).
>
>
>
>
> On Wed, Feb 6, 2013 at 6:28 PM, Peter Green <peter AT greenpete.free <mailto:peter AT greenpete.free>> wrote:
>

> Can I make one other suggestion? Mandatory TLD backups
> (rsync+encrypted, whatever) to some "central" OpenNIC machine or
> other backup service.

An interesting idea but would that mean a substantial amount of data
to be backed up and who would pay for the backup server?

Peter

>
>
> --------
> You are a member of the OpenNIC Discuss list.
> You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org <mailto:discuss-unsubscribe AT lists.opennicproject.org>
>
>