How would you feel about ARIN being the root of a registry hierarchy
that
works similar to the DNS? In that case, ARIN would not necessarily hold
the route information, they would just be at the top of the search hierarchy just like the root name servers are at the top of the DNS hierarchy. ARIN would authoritatively identify the leaseholder of an address block and give you a pointer to that leaseholder's LDAP server where you could query for whatever info they have available. This could
include route registry info.
I don't know that the other RIRs would be willing to promote ARIN to the position once held by the IANA as the arbitor of all IP address space. That said, why replicate the DNS?
Once this improved IP address registry catches on, then I would expect the root to move up to IANA but for now, IANA has delegated large chunks of address space to ARIN to administer. In any case, I don't want to replicate the DNS. It works just fine as it is and I want to leave it alone. I especially don't want to expand the role of the DNS by adding features to it. LDAP is a more general purpose directory protocol. It's expandable and there are lots of tools available to work with it. If you want to integrate your directory to the DNS you simply use your domain name as base of your hierarchy. But there is no reason why we couldn't integrate it to the IP address allocation hierarchy as well. The easiest way to start this is to come up with a standard LDAP schema to replace rwhois and move forward from there. I'm not suggesting that we all start running LDAP servers instead of DNS, but some people may find it useful to integrate the two even tighter using something like ldapdns http://www.nimh.org/code/ldapdns/ or ldap2dns http://ldap2dns.tiscover.com/ --Michael Dillon
On Tuesday, Mar 4, 2003, at 07:44 Canada/Eastern, Michael.Dillon@radianz.com wrote:
In any case, I don't want to replicate the DNS. It works just fine as it is and I want to leave it alone. I especially don't want to expand the role of the DNS by adding features to it.
I think Bill's point was that if a distributed database is required to contain routing policy, why not use existing distributed database infrastructure to host it (i.e. the DNS). In this context, deployment of LDAP-accessible databases (which you advocate) is "replicating the DNS" (which you mention you don't want to do). There was once a domain named under int which contained RPSL-ish content in TXT records, by way of example. I forget what it was called, now. I think it is fair to say that the delegation chain in the DNS is demonstrably more effective in allowing authoritative records to be located than the ad-hoc partial-mesh of mirroring and key replication currently found in the IRR. For example, there seem to be all kinds of people who will helpfully add route objects to the IRR on your behalf, regardless of the fact that the result is multiple, conflicting records. Joe
on 3/5/2003 8:58 PM Joe Abley wrote:
I think Bill's point was that if a distributed database is required to contain routing policy, why not use existing distributed database infrastructure to host it (i.e. the DNS).
I think it is fair to say that the delegation chain in the DNS is demonstrably more effective in allowing authoritative records to be located than the ad-hoc partial-mesh of mirroring and key replication currently found in the IRR.
Delegation is different from content. Using DNS for delegation information makes a lot of sense, but trying to use it for complex content is just a bad idea. DNS is great for lightweight fast lookups of public-access data, but its not well suited to complex query structures, authenticated access, or multi-dimensional, time-sensitive data. As an analogy, everybody agrees that DNS should (must) be used for tasks like ~find the mail server, but nobody should seriously argue that we should use DNS to hold ~RFC822/MIME messages and entities. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
participants (3)
-
Eric A. Hall -
Joe Abley -
Michael.Dillon＠radianz.com