Discuss mailing list

[Jeff Taylor <shdwdrgn AT sourpuss.net>]

Regarding your various questions...

I am using LDAP to store everything.  The users are simply the accounts created from the opennic members page (http://www.opennicproject.org/members/).  Each user account can also be given access to various scopes, such as T2operators or registrars, and this controls who has access to what pieces of information in LDAP.

For storing the domains, I started with a standard DNS schema and added some new attributes such as expiration date the owner of the record.  Domains can be transferred to another user by changing the ownership records, and multiple users can own a single domain (allowing mutual administration).

In regards to your plan for sharing domain data between servers... this was the entire purpose of storing the data in LDAP, and something I have been trying to achieve for a long time.  The LDAP records can be read by any T1 operators, and modified by any registrars, so any TLD operator would be able to provide a registrar page which allows access to all of the domains stored in LDAP.  I already have some tools built which allows a T1operator to generate current BIND9 zone files for each TLD from the LDAP data.

LDAP allows for multi-master configurations.  We currently have three master servers available, which are always kept in sync.  You don't need to make queries to the masters of each TLD, because all of the data is available in LDAP and will tell you instantly if a domain is available for registration.  If multiple requests are made for the same domain, the first one registered will be the one that is used.  If multiple changes are made to a single domain at one time, the last change sent will be the one that is available.

One other advantage of using LDAP... there are no concerns of injection attacks like you have my SQL.  LDAP doesn't care what you are storing in each field.  It doesn't try to read or interpret the data going in.  This means that when writing code, a programmer has to do more work themselves for obtaining the exact data they want, but it also means an attacker cannot obtain access to data they don't have permissions for.

On 03/08/2014 01:58 AM, Alejandro Bonet wrote:

Propposed draft of protocol between registries:

- Each registry web has a public http url to receive requests.
- Each registry web has a public key and a private key.
- There is a central registry for each tld, and secondary registries
for that tld.

When an user indetified in one registry(A) want to register a new
domain under a tld,
the registry(A) makes a dig test against the master dns server of that tld.

If the domain is not available, the registry(A) web says that to the user. End.

If the domain is available, the registry(A) sends a request to central
registry(B) of that tld.

The data to send in this request can be of two types:

1- New Domain (with domain name and user email for whois)
2- Resource Record Change (with name, RR type, TTL and RR content)

The central registry(B) must answer to the secondary registry(A) with
OK, or ERROR.
In the first case, the master dns is updated.

This can be done with some variables in the http request:

mode=NEW or RRCH (new domain or reource record change)
registry= (the domain name of the registry making the request)
email= (the email of the owner of the domain if NEW, for whois porpouses)
name= (the name of the domain)
rrtype= (the resource record type if it is the case)
rrdata= (the content of the resource record)
rrttl= (the TTL of the resource record)

This is a "draft". Without cyphering or ssl certificates...
It could be useful for initial tests, but of course, then it must be
autenticated and cyphered...

I like very much the open cyphering program SECCURE (it is in all the
debian repositories)
from Bertram Poettering. I have good personal relation with the
author. The program is
"The State of The Art" in cryptography. It uses elliptic curves model,
stronger than prime numbers used on ssl with shorter keys. It is the
program we use to cypher IBU currency
transactions protocol. Very simple to create key pairs, cipher,
decipher, sign, autenticate files
or strings, etc with simple shell comands. And of course is open
source and free.

Alejandro Bonet
albogoal AT gmail.com


2014-03-08 9:16 GMT+01:00, Alejandro Bonet <albogoal AT gmail.com>:

Please, forget most of my last email about this issue (but not the
essence of that):

1.- Tests can be done with DIG against the master DNS server for the tld.
2.- The protocol must exchange only CHANGES in Resource Records
(autenticated and ciphered with key pair)
3.- There is no need to download anything: The secondary registries
dont need to be
slave dns servers for the tld, but if they are so, bind9 will do the
work automatically...

Alejandro Bonet
albogoal AT gmail.com


2014-03-08 9:01 GMT+01:00, Alejandro Bonet <albogoal AT gmail.com>:

Perhaps we must define a "standard protocol between registries".

The protocol only could need three functions:

1.- Test if a domain is already registered in another registry or not
(its free).
2.- Register a new domain with the "registry number" (perhaps public
key).
3.- Download all the RRs of one registry from another, to build zone
files.

I think this can be well done with http queries and XML answers...
Perhaps with some kind of public/private keys, or ssl certificates to
ciphering...


Alejandro Bonet
albogoal AT gmail.com


2014-03-08 8:52 GMT+01:00, Alejandro Bonet <albogoal AT gmail.com>:

Good work, Jeff...

Can i ask you which data tables are you using in your model?

In the registro.ibu i have three tables:

One for users (owners of the domains, with emails and hashed passwords)
Another for SLDs (second level domains with owners and creation and
expiration dates)
Another for THLDs (third level domains or DNS Resource Records with
SLDs, RR names, RR types and RR contents)

From that i generate the zone file automatically for bind9 each time
anybody make a change...

Alejandro Bonet
albogoal AT gmail.com

PD: Im also building a list of most country and city names and big
trade marks as "at first view unregistrable names"...



2014-03-08 7:30 GMT+01:00, Hospedaje Web y Servidores Dedicados
<ventas AT dedicados.com.mx>:

great Jeff, i want one .parody =D


Ing. Alejandro M.
Hospedaje Web y Servidores Dedicados
http://www.dedicados.com.mx
------
correo / msn: ventas AT dedicados.com.mx
skype: dedicados
------

El 08/03/2014 12:27 a. m., Jeff Taylor escribió:

I am very close to opening up a new site for registering .oss and
.parody domain names.  I'm still working on a few features, but for
the most part the new code is ready to go.

The benefits...
- This time I actually know what I'm doing!  When I wrote the original
registration site, I barely had a grasp on how DNS worked, and that is
apparent in the mixed screens available for entering fields.
- Like the reg.for.free site, this new page will allow you to create a
basic DNS zone for your domain that is hosted here, or you can choose
to use your own nameservers and build your records as you see fit.
- There will be actual expirations on domains, with emails sent out to
notify owners of yearly renewals.
- I have support built in for other languages, and have been working
with others to get translations for the bulk of the text.

The pitfalls...
- I still suck at website design.  The theming I built is horrible,
but the new engine has been designed with flexibility in mind, so at
some point in the future I hope someone else can do better, and
possibly offer different methods of building the DNS data.


One of the features of the new code I wrote is that it will perform
validations on the information entered.  While bring the current data
for OSS and Parody into the new system, I discovered that a large
number of registered domains don't actually have valid data, and are
probably not even being used.  There appears to only be 3 valid
domains under parody, so I will open up that TLD on the new system
first before moving OSS over.

This should start happening next week, depending on my available
time.  I'll make announcements as I get things moved around...



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

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