Subject: [Ietf-not43] "whois"-data for .no-domain and LDAP

From: [email-masked] (Stig Venaas)
Date: Fri, 7 Dec 2001 14:12:22 +0100

I'm working on storing the "whois" data for the .no (Norway) ccTLD in
LDAP. The main reasons for us are:

We want a read-only database separate from the one we use internally for
"whois" use. LDAP is optimized for fast searches, and we make it even
faster by using a different data structure. To serve typical whois-
requests today, we need to join quite a lot of SQL tables.

Authentication. Treat registrars and random internet users differently,
and know who is accessing the data.

Structured output and standardized query language.

Due to the last point, we need to have restrictions on what types of
searches should be allowed on different parts of the data, and what
data to give back to whom. And also restrict size of result sets.
Most LDAP servers have very powerful ways to do this. I'm now trying
to implement our policy using ACLs on OpenLDAP. It's not easy, but
most of it should be possible to implement. The main thing missing
right now, is that we would like a query rate limit, similar to what
we today have on port 43. This is something I probably will
implement for OpenLDAP. Since we have authentication, we might also
have different limits on anonymous and authenticated requests, and
we won't have a limit per IP address for authenticated requests.
Netscape has a plug-in API which might also show up in OpenLDAP. I
guess some other servers have that as well. That might make it
possible to implement special stuff like this without having source
access and patching code.

I should say a few words about the LDAP schema I'm using. It's based
on what we have in our port 43 daemon, which again is based on what
forms people fill out to do registrations and updates. We have the
following objects: organization, domain, registrar, person, role and
nameserver.

In LDAP it looks like this:

dn: organizationHandle=ORG26O-NORID, o=organizations, dc=norid, dc=no
objectClass: noridOrganization
organizationHandle: ORG26O-NORID
o: UNINETT AS
organizationNumber:
postalAddress:
telephoneNumber:
facsimileTelephoneNumber:
mail:

dn: dc=uninett, dc=no, o=domains, dc=norid, dc=no
objectClass: noridDomain
objectClass: noridContact
associatedDomain: uninett.no
organizationHandle: ORG26O-NORID
created: 1999-11-15 00:00:00
registrarHandle: REG2-NORID
techContactHandle: UH1R-NORID
legalContactHandle: PK60P-NORID
billContactHandle: UR1R-NORID
zoneContactHandle: UH1R-NORID
nameserverHandle: BENO1H-NORID
nameserverHandle: AUN1H-NORID
nameserverHandle: NAC1H-NORID

dn: registrarHandle=REG2-NORID, o=registrars, dc=norid, dc=no
objectClass: noridRegistrar
objectClass: noridContact
registrarHandle: REG2-NORID
organizationHandle: ORG26O-NORID
techContactHandle: UH1R-NORID
billContactHandle: LS231P-NORID
legalContactHandle: LS231P-NORID

dn: personHandle=SV67P-NORID, o=persons, dc=norid, dc=no
objectClass: noridPerson
personHandle: SV67P-NORID
cn: Stig Venaas
givenName: Stig
sn: Venaas
organizationHandle: VCVS1O-NORID
postalAddress:
telephoneNumber:
facsimiletelephoneNumber:
mail:

dn: roleHandle=UH1R-NORID, o=roles, dc=norid, dc=no
objectClass: noridRole
objectClass: noridContact
roleHandle: UH1R-NORID
cn: UNINETT Hostmaster
organizationHandle: ORG26O-NORID
postalAddress:
telephoneNumber:
facsimiletelephoneNumber:
mail:
techContactHandle: HE1P-NORID
techContactHandle: AL86P-NORID
techContactHandle: PAE7P-NORID
techContactHandle: JG1P-NORID
techContactHandle: SV61P-NORID

dn: nameserverHandle=NAC1H-NORID, o=nameservers, dc=norid, dc=no
objectClass: noridNameserver
objectClass: noridContact
nameserverHandle: NAC1H-NORID
cn: nac.no
ipHostNumber: 129.240.2.40
techContactHandle: UH1R-NORID

Fairly straightforward. I would welcome comments on this, I'm sure
there are things I haven't thought of, this is my initial attempt.
In the long run I'm interested in the idea of removing handles, and
just have referrals/URLs/DNs to objects. For instance for contacts.
It's hard for us to do this now though. It could be interesting to
have a way to allow both. Handles are used today when people fill
out forms or contact us, and in other administrative tasks, it's not
so easy to simply remove them.

I should re-read this before I post it, but no time right now, I want
to get this done with, so bare with me if there are some errors in there.

Comments?

Stig

---

From: [email-masked] (Andrew Newton)
Date: Fri, 7 Dec 2001 09:33:59 -0500

Stig,

This is very interesting.  Is the server operational yet,
and if so, is there a URL for it?

My other comments are in-line:

> requests today, we need to join quite a lot of SQL tables.

Is this an artifact of a legacy relational schema, or more a problem
of determining the actual search type specified by the whois client?

> and know who is accessing the data.

I think many registries will have to start thinking seriously about
this, as  a wide open service conflicts with much legislation.
How are you planning on handling this?  Will your authentication
scheme be username/password?

> access and patching code.

OpenLDAP has a very similar database API (I believe they both grew
out of the UMich code), however the Netscape API is more robust.
In addition, Netscape also offers a separate "bind" API.  Now that
I've sung the praises of Netscape (which we use for RLDAP), I think
the use of OpenLDAP would be better.  Netscape's recent decisions
to take away the API documentation (and therefore support) in some
versions only to add it back in later versions is a little annoying.
I've also been non-plussed about their recent support for the 4.1x
versions.

Our analysis of OpenLDAP at the time of implementation was that the
back-end API was good enough but the base server did not support
V3.  Well, that has long since passed, and if we were to implement
again today, the decision would most likely be with OpenLDAP.

Mike Schiraldi did implement the back-whois back-end using OpenLDAP,
and it has been released as open-source.

> so easy to simply remove them.

This is a very good idea, I think.  And you bring up a very
valid point about concerning legacy. Handles should be deprecated
and URL referrals should be the way to go.  Is there a problem
with constructing the DN for the URL using the handle?  Such as,
the user enters HANDLEX and therefore within your local system
you know the DN would be cn=HANDLEX,ou=contacts,dc=uninett,dc=no?

-andy

-- 
Andrew Newton
VeriSign Applied Research
[email-masked]