Subject: [weirds] bootstrapping name servers and entities

From: Andy Newton <[email-masked]>
Date: Sat, 29 Jun 2013 12:07:39 +0000

The current bootstrapping discussions have avoided entities and name
servers, most likely because these are identifiers that are not easily
mapped to authoritative registries. Though a bootstrapping process for
these object types may not be exact, it might be possible to create a
system that is best effort.

For nameservers, the bootstrapping process could be to look at the TLD of
the nameserver name. For example, a bootstrap of ns1.example.com would
point a client at the .com registry. That's not perfect, but its better
than nothing.

With entities, we can borrow a notion that is in use by the RIRs. Contacts
in the RIR system are generally suffixed with an identifier for the RIR.
Examples: ABC123-ARIN, ABC123-RIPE, ABC123-AP (for APNIC), etcŠ

It might be possible to establish a registry for entity suffixes. The
bootstrap process would be to redirect to the authoritative server in the
registry if a suffix is recognized. For instance, an entity identifier of
ABC123-ORG would got to the .org servers.

Comments? Suggestions?

-andy

---

From: "John Levine" <[email-masked]>
Date: 29 Jun 2013 15:56:23 -0000

>ABC123-ORG would got to the .org servers.

Is this a problem we have to solve?  As far as I know, there's nothing
keeping several name registries or registrars from using the same
handles and assigning them to different people.

I agree that asking the TLD servers about host names is reasonable.
Given the way that DNS glue works, that'll be the right place to ask
about 99.9% of the time.

R's,
John

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 1 Jul 2013 00:34:15 +0000

Hi Andy,

>system that is best effort.

What's the use case for doing a global lookup on an entity handle?  These
handles don't have any significance or meaning outside of the context of
the registry they're created in, whereas domains, IP networks, AS numbers,
and nameservers all do have a life of their own.

An entity handle is most likely to only be seen in the context of a result
from a previous lookup, in which case it would be wise to include the
"self" link for any RDAP response such that the problem of knowing where
that entity handle might be found can be translated to handing around
entity "self" links instead of handles.

(Or make the handle a URI instead of an opaque string).

A global search for an entity by name or other attributes has more of a
use case in my mind, but how to bootstrap for *search* is an even hairier
problem, I think.

  Byron