Subject: [weirds] DNS Bootstrapping revisited

From: Jay Daley <[email-masked]>
Date: Thu, 21 Nov 2013 17:35:22 -0300

I have spent an hour checking the list and I am struggling to see for certain what were the blocking issues, so apologies if I've go this wrong.  As I understand it they are:

0.  how to do something that works across names/numbers/atronomical objects/etc
1.  http and/or https
2.  where to place them
3.  URL part beyond the domain name
4.  javascript access to the DNS
5.  nobody uses SRV/NAPTR

My suggestions (and these are not meant to sound harsh, just trying to cut through here) are

0.  Don't try.  Do it differently for each.  I only know names and so this is only for names,  I'm sure someone who knows numbers can do that easy enough.

1.  For the purposes of SRV define two protocol identifiers rdap and rdaps 

_rdap._tcp 0 0 80  rdap.net.nz
_rdaps._tcp 0 0 443 rdap.net.nz

2.  Under the right TLD not .arpa (dear god please!).  If we want to count uk.com etc as TLDs then first look one level up or trust the redirection mechanism.  Either way it's not a bootstrapping issue.

3.  We're all grown ups and know how to use domain names properly, no need for full URLs.

4.  Let people build services that do that for Javascript programmers.  Otherwise we start to ask how do we support this on Fortran 77 and so on.  None of our business.

5.  If we only knew where to look (this is my original list of 17 but John Levine has found another 20):

for c in nz uk au at dk fr de hu ie li lu nl no re si se ch; do
 dig +short _nicname._tcp.$c srv
done

Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 21 Nov 2013 15:51:31 -0500

Le 2013-11-21 à 15:35, Jay Daley <[email-masked]> a écrit :

> I have spent an hour checking the list and I am struggling to see for certain what were the blocking issues, so apologies if I've go this wrong.

the current direction that we had some agreement on (while I can not say at the moment wg concensus) is to look into the IANA registries method. So my todo is to write a -01 version of the bootstrap draft about IANA registries going into more details. I shall publish next week.

Regards, Marc.

>  As I understand it they are:
> 
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: "John Levine" <[email-masked]>
Date: 21 Nov 2013 22:10:09 -0000

>2.  Under the right TLD not .arpa (dear god please!). 

Just for the record, why not?  The assumption is that IANA would add
an RDAP server field to whatever you use now to update your NS
and signature records.

---

From: Jay Daley <[email-masked]>
Date: Thu, 21 Nov 2013 22:02:06 -0300

> an RDAP server field to whatever you use now to update your NS

Primarily so that we (registries) have full control over this.  As in we can change instantly, we can add multiple records with different preference fields, and so on.  It is also bad practice to bring IANA into the operational provisioning loop any more than is absolutely necessary as they are inevitably a single point of failure, it makes up dependent on the service levels and restricts us to their policies.

Jay

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 22 Nov 2013 08:17:28 -0500

Le 2013-11-21 à 20:02, Jay Daley <[email-masked]> a écrit :

> Primarily so that we (registries) have full control over this.  As in we can change instantly, we can add multiple records with different preference fields, and so on.  It is also bad practice to bring IANA into the operational provisioning loop

We are not talking about IANA in the operational loop. IANA registry will be used as today (which lists the whois server for each tld) to define the authoritative URL for the RDAP server for the TLDs. Then, the registry operator is able to change its DNS entries (A, AAAA, CNAME,...) as he wish, real-time, as well as also provide URL redirection if needed. These are all steps that are under full control of the rdap server operator without any intervention of IANA.

Marc.

> any more than is absolutely necessary as they are inevitably a single point of failure, it makes up dependent on the service levels and restricts us to their policies.
> 
> Jay
> 
> -- 
> Jay Daley
> Chief Executive

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 22 Nov 2013 10:36:17 -0500

So BIND has pretty much the same startup problem we are trying to solve. It
needs to know the location of the root servers. IANA has a page providing
instructions at http://www.iana.org/domains/root/files

One of the ways to get the BIND root "hints" file is
   wget http://www.internic.net/domain/named.root

For RDAP, all we need is similar links to names.root and numbers.root
files.

We also need a registration process for RDAP providers to configure their
entries in the root files. The DNS Root Zone Management provides a pretty
good model for this at http://www.iana.org/domains/root/manage

BIND gets an up-to-date root server list from servers in the root hints
file, so you don't need to update the root hints file after installation.
An RDAP root file would need to be updated, but not very frequently. Just
put the wget in a weekly cron.

This is the IANA bootstrap proposal. If it is good enough for BIND (and
other DNS servers), why isn't it good enough for RDAP?

-Ernie

On Fri, Nov 22, 2013 at 8:17 AM, Marc Blanchet <[email-masked]>wrote:

> > Primarily so that we (registries) have full control over this.  As in we
> can change instantly, we can add multiple records with different preference
> fields, and so on.  It is also bad practice to bring IANA into the
> operational provisioning loop
>
> We are not talking about IANA in the operational loop. IANA registry will
> be used as today (which lists the whois server for each tld) to define the
> authoritative URL for the RDAP server for the TLDs. Then, the registry
> operator is able to change its DNS entries (A, AAAA, CNAME,...) as he wish,
> real-time, as well as also provide URL redirection if needed. These are all
> steps that are under full control of the rdap server operator without any
> intervention of IANA.
>
> Marc.
>
> > any more than is absolutely necessary as they are inevitably a single
> point of failure, it makes up dependent on the service levels and restricts
> us to their policies.
> >
> > Jay
> >
> > --
> > Jay Daley
> > Chief Executive

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 22 Nov 2013 10:43:44 -0500

Le 2013-11-22 à 10:36, Ernie Dainow <[email-masked]> a écrit :

> So BIND has pretty much the same startup problem we are trying to solve. It needs to know the location of the root servers. IANA has a page providing instructions at http://www.iana.org/domains/root/files
> 
> For RDAP, all we need is similar links to names.root and numbers.root files. 
> 
> We also need a registration process for RDAP providers to configure their entries in the root files. The DNS Root Zone Management provides a pretty good model for this at http://www.iana.org/domains/root/manage
> 
> BIND gets an up-to-date root server list from servers in the root hints file, so you don't need to update the root hints file after installation. An RDAP root file would need to be updated, but not very frequently. Just put the wget in a weekly cron.
> 
> This is the IANA bootstrap proposal. If it is good enough for BIND (and other DNS servers), why isn't it good enough for RDAP?
> 

I don't know if you were asking me the question, but we are in complete agreement here. This is exactly what I've been saying (but differently) about the IANA bootstrap proposal.  Two registry files: one for numbers, one for names. Stable, does not change often, updated through the current IANA process with the owners of these name/number spaces. It is then up to the implementation to decide when to refresh the data it already has.

Again, as I wrote earlier, from the conversations we are having, I'm getting the direction of taking the IANA-based approach and will update the draft shortly to add more infos as we discussed. 

Marc.

> -Ernie
> 
> 
> On Fri, Nov 22, 2013 at 8:17 AM, Marc Blanchet <[email-masked]> wrote:

---

From: John R Levine <[email-masked]>
Date: Fri, 22 Nov 2013 11:16:13 -0500 (EST)

>> other DNS servers), why isn't it good enough for RDAP?

Because BIND is a daemon, and starts up maybe once every couple of months 
when a system reboots or there's a new version of BIND.  RDAP clients are 
normal applications and start up every time someone makes a query.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 22 Nov 2013 12:35:18 -0500

Bind needs to be reloaded every time there is a zone change, and it reads
all config files. On a large zone this is more than every couple of months.

In any case, reading a bootstrap file is not an issue. The overhead to read
a local file is insignificant compared to the overall client processing of
a query. I have sample code that reads and parses an IANA numbers file of
12 KB into a hash table. It takes .5 msec.

By comparison with a DNS based bootstrap, looking up a DNS record varies
widely but may be 25-130 msec (from a survey of several whois servers).
This may be as little as 10 msec if the record is cached. The best case is
still more than an order of magnitude slower than reading a local file.

-Ernie

---

From: John R Levine <[email-masked]>
Date: Fri, 22 Nov 2013 15:18:37 -0500 (EST)

> a query.

I'm not worried about parsing the file, I'm worried about an extra HTTP 
fetch from IANA on every RDAP transaction.  I realize that IANA says they 
can probably deal with it, but ugh.

I'm increasingly coming to the conclusion that we should punt on the 
bootstrap issue, and perhaps revisit it later when we find out what people 
actually do.

R's,
John

PS: Haven't we had this argument before?

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 22 Nov 2013 15:30:14 -0500

Le 2013-11-22 à 15:18, John R Levine <[email-masked]> a écrit :

> I'm not worried about parsing the file, I'm worried about an extra HTTP fetch from IANA on every RDAP transaction.

that is not what we are working on. What we are working on is a way for clients to find authoritative data. It does not mean nor intended to, that they should be fetching the file for all requests. It does not make sense.

>  I realize that IANA says they can probably deal with it, but ugh.

We have to be prepared for the worst case. And IANA said fine. But fetching every time is not the right solution, not only from a standards perspective, but from an implementation perspective. 

> 
> I'm increasingly coming to the conclusion that we should punt on the bootstrap issue, and perhaps revisit it later when we find out what people actually do.

we know what they do right now. It is all sorts of heuristics, and various community services, with no clear authoritative way. We are just trying to tell them that the next version, based on RDAP, they should go _there_ instead of another round of approximate heuristics.  End of it. Then the implementors will decide how they will cache/update the data. We will provide some guidelines in the draft, as we discussed before.

Maybe I should push the new version of the draft asap so that we concentrate on the text, including revs, instead on re-arguing again and again.... Will push a new version early next week.

Marc.

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 22 Nov 2013 16:26:47 -0500

On 2013-11-22 3:18 PM, John R Levine wrote:
>
> I'm not worried about parsing the file, I'm worried about an extra 
> HTTP fetch from IANA on every RDAP transaction.  I realize that IANA 
> says they can probably deal with it, but ugh.
>
What I  suggested was wget from IANA once a week.

-Ernie

---

From: Andy Newton <[email-masked]>
Date: Fri, 22 Nov 2013 22:08:51 +0000

On 11/21/13 3:51 PM, "Marc Blanchet" <[email-masked]> wrote:

>the current direction that we had some agreement on (while I can not say
>at the moment wg concensus) is to look into the IANA registries method.
>So my todo is to write a -01 version of the bootstrap draft about IANA
>registries going into more details. I shall publish next week.

I thought we had momentum in this direction as well. For what it is worth,
this is the method I've implemented in both NicInfo and my bootstrap
server.

-andy

---

From: Chris Wright <[email-masked]>
Date: Sat, 23 Nov 2013 01:24:11 +0000

For the record, I would once again like to re-iterate my support for a DNS based bootstrap as suggested by Jay, preferably one that involves looking up a record in the TLD zone file..

The IANA registry approach is problematic for us registry operators for a number of reasons

- IANA interactions are not quick or easy for us, it can take extended time to get changes made (sometimes they happen quickly but sometimes they don't)
- IANA is not subject to any SLAs or performance measures - they do what they do as best as they can, I'd prefer to be in control and not at the mercy of IANA
- Co-ordinating changes with IANA is almost impossible, they give no timeframe for changes, and things generally automagically happen randomly, without notice or co-ordination and generally in US time zones, which is normally middle of the night for us (for example if we were to move our WEIRDS server somewhere else)
	(of course the move would be done in such a way that old and new URL would be operating for a period of time etc., however, I would prefer to know exactly when changes are occurring so support staff can be on alert for problems, and have a rollback that can be done in seconds if required. And yes, changing the location of a WERIDS server won't happen that often, but when it does, the end users will be the first to complain when something goes wrong)
- Even though we all know that retrieving the file from IANA once a week is all that is required (although is it, that means when I make a change, it could take up to a week before it is propagated)... we all know that there will be people who will retrieve the file on every lookup - why not use the system that is designed for these types of quick high speed lookups (DNS).

Frankly I still do not see the downside... many DNS queries are performed to load any modern web page going out... if it's good enough for loading a web page, then it is good enough for WERIDS... a DNS query will need to be done to resolve the domain in the actual URL anyway...  (unless its an IP).. so I'm not convinced by the arguments that say looking up in a local file is faster... (I mean of course it is... but does it really matter)... 

Thanks

Chris

-----Original Message-----
From: weirds [mailto:[email-masked]] On Behalf Of Andy Newton
Sent: Saturday, 23 November 2013 9:09 AM
To: Marc Blanchet; Jay Daley
Cc: [email-masked] Group
Subject: Re: [weirds] DNS Bootstrapping revisited

On 11/21/13 3:51 PM, "Marc Blanchet" <[email-masked]> wrote:

>the current direction that we had some agreement on (while I can not 
>say at the moment wg concensus) is to look into the IANA registries method.

I thought we had momentum in this direction as well. For what it is worth, this is the method I've implemented in both NicInfo and my bootstrap server.

-andy

---

From: Kim Davies <[email-masked]>
Date: Sun, 24 Nov 2013 08:26:12 -0800

Hi folks,

Without expressing an opinion on the best technical approach here, a few comments on ICANN's capabilities to help reach an informed decision:

> 	(of course the move would be done in such a way that old and new URL would be operating for a period of time etc., however, I would prefer to know exactly when changes are occurring so support sta…

I think most of these observations likely relate to the process of managing data pertaining to the root zone delegations, which is required to go through three parties (ICANN, as the IANA operator; US Department of Commerce and Verisign) for various complex non-technical reasons. While there are published SLAs and performance measures for these functions, I do not believe they are indicative of how ICANN is capable of implementing new services which are not encumbered in the same fashion. For example, at the request of the TLD management community, ICANN rolled out the Interim Trust Anchor Repository (ITAR) as a fully automated system. Updates to that system were effected immediately after the TLD manager authorized their change requests. We'd be happy to agree SLAs on such services with the community.

kim

---

From: dmitry kohmanyuk <[email-masked]>
Date: Mon, 25 Nov 2013 00:08:31 +0200

> Without expressing an opinion on the best technical approach here, a few comments on ICANN's capabilities to help reach an informed decision:

Thank you Kim for message and offer to develop SLAs with community.

A few comments from (small) TLD operator:

Implementing "in-zone" SRV records is easy option; we can do it for WEIRDS (we do for WHOIS).

Having said that, and partially agreeing with comments about dependency of IANA process on external factors (although they are likely to be absent in potential WEIRDS registry), i however support a bootstrap method which "non-in-bailwick" or "out-of-band", be it IANA or (potentially different) third party.

Such method would make your bootstrap independent on zone you need a server for, and would prevent cascading failures.  WHOIS services now are independent of it, providing IANA records are used, and hostname in question is outside domain (and IP literal may be an option to consider by the way, if only as last-resort.)

Bootstrapping by in-zone records also does not work for numbers (especially AS records) nicely.

Therefore I think "external" bootstrapping should be an option to a protocol. It can be also noted that bootstrapping file can be synthesized by (slightly more complicated) weekly cron script from DNS root zone and appropriate SRV records, perhaps with a few hardcoded in case of paranoia.

-- dk@ (back to my Sunday night lurking)

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 25 Nov 2013 12:07:36 +0000

> From: weirds [mailto:[email-masked]] On Behalf Of Chris Wright
> Sent: Friday, November 22, 2013 8:24 PM
> To: Andy Newton; Marc Blanchet; Jay Daley

[snip]

> Frankly I still do not see the downside... many DNS queries are
> performed to load any modern web page going out... if it's good enough
> for loading a web page, then it is good enough for WERIDS... a DNS
> query will need to be done to resolve the domain in the actual URL
> anyway...  (unless its an IP).. so I'm not convinced by the arguments
> that say looking up in a local file is faster... (I mean of course it
> is... but does it really matter)...

I'm back to asking this question: what information does a client possess that will allow it to bootstrap a lookup query for an entity like "XXXX"? For a domain search like "example*"? I don't see how it's possible with either the DNS or IANA approaches.

Scott

---

From: "John Levine" <[email-masked]>
Date: 25 Nov 2013 18:01:12 -0000

>I'm back to asking this question: what information does a client possess that will allow it to bootstrap a lookup query for an
>entity like "XXXX"? For a domain search like "example*"? I don't see how it's possible with either the DNS or IANA approaches.

Good questions.

For entities, it is my impression that the only place you'll get an
entity handle is from a prior RDAP query, so I think the response
should include the URL prefix of the place to send subsequent
queries.

The scenario I'm thinking about is one where you ask about, say, ic.ac.uk.

You query http://uk.rdap-servers.net/.mnottingham/domain/ic.ac.uk

That's Nominet, which does a 302 redirect you to Janet, something like

http://rdap.ja.net/.mnottingham/domain/ic.ac.uk

The answer comes from rdap.ja.net, and that's where entity queries
should go.  In a lot of clients, it is painful to figure out what
redirect happen, e.g., if you're shell scripting with wget, you have
to parse out the status reports it prints as it's fetching stuff.
Putting the URL in the response would make life easier.

For the domain search, it's always been my impression that searches
across domains don't work, or at best work flakily.  It happens that
.com and .net use the same server, so wildcard searches get results
from both, but I really don't want to try to bake anything like that
into the protocol.  We should say that you need to identify the server
that has answers for the TLD or group of domains you're interested in,
and send queries there.  The phrase "group of domains" is left
undefined.

R's,
John

---

From: Jay Daley <[email-masked]>
Date: Tue, 26 Nov 2013 17:40:42 +1300

> I'm back to asking this question: what information does a client possess that will allow it to bootstrap a lookup query for an entity like "XXXX"? For a domain search like "example*"? I don't see h…

I not convinced this is a problem that the protocol needs to solve rather than another unspecified part of the WEIRDS ecosystem.  For example the obvious answer to your question is "everywhere" - i.e. the client must contact every RDAP server and place the query with each one.  Equally it is highly likely that people will build gateways that accept a single query, fan out the query and collect the results to provide an aggregated answer.   All we need do is note that as a possible solution.

Jay

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 26 Nov 2013 12:02:18 +0000

> From: Jay Daley [mailto:[email-masked]]
> Sent: Monday, November 25, 2013 11:41 PM
> To: Hollenbeck, Scott
> > I'm back to asking this question: what information does a client
> possess that will allow it to bootstrap a lookup query for an entity
> like "XXXX"? For a domain search like "example*"? I don't see how it's
> possible with either the DNS or IANA approaches.
> 
> 
> I not convinced this is a problem that the protocol needs to solve
> rather than another unspecified part of the WEIRDS ecosystem.  For
> example the obvious answer to your question is "everywhere" - i.e. the
> client must contact every RDAP server and place the query with each
> one.  Equally it is highly likely that people will build gateways that
> accept a single query, fan out the query and collect the results to
> provide an aggregated answer.   All we need do is note that as a
> possible solution.

Do you think we should specify how to bootstrap some queries and not others?

I can't imagine any implementer adopting either of the approaches described above. They require either client or server to maintain a list of all servers, a list like that will not be static - and now we have list to maintain and find. Ugh.

I'm not convinced this is a problem for us, either. We can't bootstrap all query types, and if we can't do that a partial solution is going to cause confusion. We're better off having server names specified as client inputs.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 26 Nov 2013 12:09:36 +0000

> From: John Levine [mailto:[email-masked]]
> Sent: Monday, November 25, 2013 1:01 PM
> To: [email-masked]
> Cc: Hollenbeck, Scott
> possess that will allow it to bootstrap a lookup query for an
> >entity like "XXXX"? For a domain search like "example*"? I don't see
> how it's possible with either the DNS or IANA approaches.
> 
> Good questions.
> 

[snip]

Sure, that could work, but it requires that first query. What if a human has an entity handle written down on a piece of paper and wants to look it up? Fail, unless they know the name of the server to send the query to.
 
> and send queries there.  The phrase "group of domains" is left

Yes, the only way this could work is if the identity of the server is known prior to sending the query - and that's my point. If bootstrapping remains a problem to be addressed we should be very clear about the limitations and types of queries that it cannot address.

Scott

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 26 Nov 2013 10:12:42 -0200

Is bootstrapping some queries and not all acceptable for the WG ?

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 26 Nov 2013 12:17:14 +0000

> From: Carlos M. Martinez [mailto:[email-masked]]
> Sent: Tuesday, November 26, 2013 7:13 AM
> To: Hollenbeck, Scott; John Levine; [email-masked]

Good question. As I said, "If bootstrapping remains a problem to be addressed we should be very clear about the limitations and types of queries that it cannot address".

Scott

---

From: John R Levine <[email-masked]>
Date: Tue, 26 Nov 2013 10:38:30 -0500 (EST)

> Sure, that could work, but it requires that first query. What if a human has an entity handle written down on a piece of paper and wants to look it up? Fail, unless they know the name of the server…

We're stuck with that problem.  I have a old printout with the handles 
ANTAGUS-MNT and AI-300624 on it.  Now what?  Some handles give you a hint 
of what the registry is, but many don't.  Even for the ones with a hint, 
now we'd need a whole new flavor of bootstrap to turn the handle hint into 
something it can look up.

Regards,

---

From: Ernie Dainow <[email-masked]>
Date: Tue, 26 Nov 2013 11:42:38 -0500

Since handles are local to a particular server, the only way to make them
globally unique is to add some more information. This could be done fairly
simply by having RDAP servers prefix all handles with an identifier such as
tld.rdap. The backend databases don't need to be changed. The RDAP server
simply adds the prefix when returning handles in query responses and strips
off the prefix when a handle is received in a query before doing a database
lookup.

-Ernie

On Tue, Nov 26, 2013 at 10:38 AM, John R Levine <[email-masked]> wrote:

> Sure, that could work, but it requires that first query. What if a human
>> has an entity handle written down on a piece of paper and wants to look it
>> up? Fail, unless they know the name of the server to send the query to.
>>
>

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 26 Nov 2013 14:44:15 -0200

But... isn't the key problem here knowing *where* the databases
containing each handle are ?

On 11/26/13, 2:42 PM, Ernie Dainow wrote:
> Since handles are local to a particular server, the only way to make
> them globally unique is to add some more information. This could be done
> fairly simply by having RDAP servers prefix all handles with an
> identifier such as tld.rdap. The backend databases don't need to be
> changed. The RDAP server simply adds the prefix when returning handles
> in query responses and strips off the prefix when a handle is received
> in a query before doing a database lookup.
> 
> -Ernie
> 
> 
> 
> On Tue, Nov 26, 2013 at 10:38 AM, John R Levine <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>         Sure, that could work, but it requires that first query. What if
>         a human has an entity handle written down on a piece of paper
>         and wants to look it up? Fail, unless they know the name of the
>         server to send the query to.
> 
> 
>     We're stuck with that problem.  I have a old printout with the
>     handles ANTAGUS-MNT and AI-300624 on it.  Now what?  Some handles
>     give you a hint of what the registry is, but many don't.  Even for
>     the ones with a hint, now we'd need a whole new flavor of bootstrap
>     to turn the handle hint into something it can look up.
> 
> 
>     Regards,
>     John Levine, [email-masked] <mailto:[email-masked]>, Taughannock
>     Networks, Trumansburg NY
>     _________________________________________________
>     weirds mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/weirds
>     <https://www.ietf.org/mailman/listinfo/weirds>
> 
> 
> 
>

---

From: Andy Newton <[email-masked]>
Date: Tue, 26 Nov 2013 16:51:48 +0000

From: Ernie Dainow <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 26, 2013 11:42 AM
To: John R Levine <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] DNS Bootstrapping revisited

Since handles are local to a particular server, the only way to make them globally unique is to add some more information. This could be done fairly simply by having RDAP servers prefix all handles with an identifier such as tld.rdap. The backend databases don't need to be changed. The RDAP server simply adds the prefix when returning handles in query responses and strips off the prefix when a handle is received in a query before doing a database lookup.

Actually, the RIRs already do this but with postfixing an identifier. And I've got code in NicInfo and the bootstrap server that take advantage of it to determine where to send these types of entity queries.

-andy

---

From: John R Levine <[email-masked]>
Date: Tue, 26 Nov 2013 12:39:14 -0500 (EST)

> tld.rdap.

That's not so great, since there will be a lot of RDAP servers that aren't 
TLDs.  (I should be running one for watkins-glen.ny.us, Andy runs one for 
ARIN.)

What's the advantage of adding a prefix that has to be looked up using 
some yet to be defined process to find the appropriate server, versus just 
putting the name of the server in the response?

R's,
John

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Tue, 26 Nov 2013 15:42:17 -0200

I'll answer my own call for opinions:

"I'd forget about bootstrapping entities"

There it is, I said it.

:)

~Carlos

On 11/26/13, 3:39 PM, John R Levine wrote:
> That's not so great, since there will be a lot of RDAP servers that
> aren't TLDs.  (I should be running one for watkins-glen.ny.us, Andy runs
> one for ARIN.)
> 
> some yet to be defined process to find the appropriate server, versus
> just putting the name of the server in the response?
> 
> R's,
> John
> 
>

---

From: Ernie Dainow <[email-masked]>
Date: Tue, 26 Nov 2013 15:02:28 -0500

On 11/26/2013 12:39 PM, John R Levine wrote:
>> them
> aren't TLDs.  (I should be running one for watkins-glen.ny.us, Andy 
> runs one for ARIN.)
>
The only advantage is that it is more compact. If using the server name 
is more universal, then that is fine. It may need to be object.server 
for conformity to current backends that use different namespaces for 
handles for different objects.

So the example in draft-ietf-weirds-json-response-06, p.20
      "handle":"XXXX",
      "links":[
        {
          "value":"http://example.com/entity/XXXX",
          "rel":"self",
          "href":"http://example.com/entity/XXXX",
          "type":"application/rdap+json"
        }
        ...
becomes something like
      "handle":"entity.example.com.rdap-XXXX",
      "links":
      "links":[
        {
"value":"http://example.com/entity/entity.example.com.rdap-XXXX",
          "rel":"self",
"href":"http://example.com/entity/entity.example.com.rdap-XXXX",
          "type":"application/rdap+json"
        }

-Ernie

---

From: "John Levine" <[email-masked]>
Date: 26 Nov 2013 20:22:34 -0000

>Actually, the RIRs already do this but with postfixing an identifier. And I've got code in NicInfo and the
>bootstrap server that take advantage of it to determine where to send these types of entity queries.

Many of the ICANN registries assign their own handles, with no
consistent pattern I can see.  This is a swamp, and I see no need to
try to drain it.

---

From: Jay Daley <[email-masked]>
Date: Wed, 27 Nov 2013 13:03:07 +1300

> Do you think we should specify how to bootstrap some queries and not others?

There are certainly some we should not specify bootstrapping for.

> I can't imagine any implementer adopting either of the approaches described above. They require either client or server to maintain a list of all servers, a list like that will not be static - and…

It's a common way of solving problems but I agree it's not pretty.

Jay

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 30 Nov 2013 20:25:04 -0800

On Tue, Nov 26, 2013 at 4:17 AM, Hollenbeck, Scott <[email-masked]
> wrote:

> Good question. As I said, "If bootstrapping remains a problem to be
> addressed we should be very clear about the limitations and types of
> queries that it cannot address".
>
>
Can you clarify "types of queries"?   Are you talking about something other
than names queries vs. number queries?

-MSK