Subject: [weirds] Redirection in the RESTful WHOIS world

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 06 Jul 2012 13:11:24 -0300

Hello all,

We submitted a few weeks ago a weirds document
(draft-lacnic-weirds-restwhois-redirects [1]) that documents a piece of
running code we wrote at LACNIC that performs single-point redirection
of RESTful WHOIS queries. The intent of the document, besides
documenting running code, was to spur discussion on the topic of redirects.

At this point, and with the -00 deadline fast approaching, I'll try to
summarize the different view points and possible ways forward.

In any redirection scheme at least one server needs to have a database
that maps resources to authoritative WEIRDS servers, as "200/8 =>
lacnic_weirds, 1/8 => apnic_weirds", etc. There are at least two
possible approaches, one with a set of central redirect-only servers and
a mesh, flat model where weirds servers directly redirect to each other.

Our prototype ([1], [2]) implements the hierarchical model and the
database is fed from IANA's IPv4, IPv6 and ASN registries. We are aware
of the limitations of this approach, mostly in the case of IPv4, but as
this work is intended only to be a quick proof-of-concept this provided
a quick and painless way to build the db.

So, here are the open issues:

1- Is the topic of building the mapping database in the scope of the WG
? We did this for numbers but we must also consider the case of names.

2- Do the hierarchical vs mesh model alternatives need to be documented ?

3- Does the topic need its own draft(s) ?

>From feedback I've received, if the answer to (1) is 'no' then the topic
of redirects should probably be included as simple section (return 30x
pointing to such and such in case of  in other document, probably in the
HTTP draft. If, on the other hand, the answer to (1) is 'yes', then
there is a lot of ground to cover in a one or perhaps, two, documents
(names and numbers) 

Share your thoughts!

Warm regards

Carlos

[1]
http://tools.ietf.org/html/draft-lacnic-weirds-restwhois-redirects-00.txt
[2] http://www.labs.lacnic.net/site/restful-whois (in Spanish, but links
work anyways)

---

From: "John Levine" <[email-masked]>
Date: 6 Jul 2012 23:19:45 -0000

>3- Does the topic need its own draft(s) ?

I don't think it would be a good idea to try to build a top level map
into the spec.  For both names and numbers, the data for a top level
map resides (or reasonably would reside) at IANA, but this group can't
tell IANA what to do.

Also, for names, one could imagine some kludges to bootstrap the map.
A totally unofficial but widely used hack is whois-servers.net, who
publish CNAMES as <tld>.whois-servers.net that point at the servers
for all the TLD WHOIS servers they know.  It's a kludge, but I
wouldn't rule something like that out, since it's a lot lower overhead
than a top level WHOIS server that would likely get a zillion hits
every second.

And of course in the number space the two models coexist, due
to legacy delegations.  Just document the 30x redirect and note
that there has to be some way to pick an initial server for
a query.

R's,
John

---

From: Hugo Salgado <[email-masked]>
Date: Mon, 09 Jul 2012 10:38:49 -0400

> A totally unofficial but widely used hack is whois-servers.net, who

Or rather one maintained by those responsible (RFC2782):
  $ dig _nicname._tcp.cl srv +short
  10 0 43 whois.nic.cl.

Hugo

---

From: Ray Bellis <[email-masked]>
Date: Mon, 9 Jul 2012 17:17:33 +0000

>  $ dig _nicname._tcp.cl srv +short

Did anyone ever solve the "top down" vs "bottom up" problem with _nicname._tcp ?

For example, we probably wouldn't want _nicname._tcp.example.co.uk to take precedence over _nicname._tcp.co.uk  [ or should that be _nicname._tcp.uk - how does a client decide? ]

At the same time, we might want _some_ subdomains to have that authority (e.g. ac.uk).

Is the public suffix list sufficient, or is something more fine-grained required?

Ray

---

From: Patrik Wallström <[email-masked]>
Date: Mon, 9 Jul 2012 21:13:04 +0200

> Is the public suffix list sufficient, or is something more fine-grained required?

Another record at the parent level stating that no more redirection should happen? That would work with the "top down" model.

I don't recall the exact details of the cookies and public suffix list, but that kind of parent level record could solve that problem as well. (Is there a condensed discussion on the problem statement somewhere?)

---

From: "John Levine" <[email-masked]>
Date: 9 Jul 2012 22:25:26 -0000

>Is the public suffix list sufficient, or is something more fine-grained required?

The public suffix list is a crock.  If we want to do SRV records, I
wouldn't be looking at them other than for the TLD.  Surely the various
bits of .UK can figure out how to run a joint referral server if that's
what's needed.

R's,
John

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 10 Jul 2012 10:38:14 +0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Carlos M. Martinez
> Sent: Saturday, July 07, 2012 12:11 AM
> To: <[email-masked]>
> Subject: [weirds] Redirection in the RESTful WHOIS world
> 
> Hello all,
> 
running
> code we wrote at LACNIC that performs single-point redirection of RESTful
> WHOIS queries. The intent of the document, besides documenting running
code,
> was to spur discussion on the topic of redirects.
> 
summarize
> the different view points and possible ways forward.
> 
that
> maps resources to authoritative WEIRDS servers, as "200/8 =>
lacnic_weirds,
> 1/8 => apnic_weirds", etc. There are at least two possible approaches, one
> with a set of central redirect-only servers and a mesh, flat model where
weirds
> servers directly redirect to each other.
> 
database is
> fed from IANA's IPv4, IPv6 and ASN registries. We are aware of the
limitations
> of this approach, mostly in the case of IPv4, but as this work is intended
only to
> be a quick proof-of-concept this provided a quick and painless way to
build the
> db.
> 1- Is the topic of building the mapping database in the scope of the WG ?
We
> did this for numbers but we must also consider the case of names.
> 
I don't think this is included in the WG scope. In my personal point of
view, it is just the mapping details, whether build a database or other RR
to find the URI.

> 2- Do the hierarchical vs mesh model alternatives need to be documented ?

IMHO, it's better to explain these two models, or I'm a little confused with
the text and figure.

> From feedback I've received, if the answer to (1) is 'no' then the topic
of
> redirects should probably be included as simple section (return 30x
pointing to
> such and such in case of  in other document, probably in the HTTP draft.
If, on
> the other hand, the answer to (1) is 'yes', then there is a lot of ground
to cover
> in a one or perhaps, two, documents (names and numbers)
> 

> [2] http://www.labs.lacnic.net/site/restful-whois (in Spanish, but links
work
> anyways) _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Ray Bellis <[email-masked]>
Date: Tue, 10 Jul 2012 08:19:34 +0000

On 9 Jul 2012, at 23:25, John Levine wrote:

> The public suffix list is a crock.

I couldn't possibly comment.

> If we want to do SRV records, I wouldn't be looking at them other than for the TLD.

OK, so start at the top, and stay there :)

> Surely the various bits of .UK can figure out how to run a joint referral server if that's
> what's needed.

Yup, at least with WEIRDS we will finally have an opportunity to implement a standard referral mechanism.

Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 10 Jul 2012 06:59:54 -0400

On Mon, Jul 09, 2012 at 05:17:33PM +0000, Ray Bellis wrote:
> Is the public suffix list sufficient

Heck, no, but this sort of issue is what I'm hoping to tackle with
draft-sullivan-domain-origin-assert.  I've had some comments and am
working on an -01 to appear before the deadline.  A notable problem in
-00 is that it works by name only, and the feedback I had was that it
needs to work by {name, port, scheme}.  More explanations of why I'm
on the completely wrong track would help me abandon this windmill-tilting.

Best,

A 

-- 
Andrew Sullivan
[email-masked]

---

From: SM <[email-masked]>
Date: Tue, 10 Jul 2012 04:00:10 -0700

>The public suffix list is a crock.  If we want to do SRV records, I

:-)

>OK, so start at the top, and stay there :)

Well, the top is out of scope. :-)  It's easy to define what the top 
is.  It's difficult to decide on who to talk to about the top because 
every body wants to be at the top.  if you stay at the top there 
isn't any delegation.  If the top decides to delegate I am not sure 
whether it would it/they would find devolution palatable.

Regards,
-sm

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Tue, 10 Jul 2012 11:05:56 -0300

Hello all,

I did not submit a -00 in the end, but I definitely sense that there is
a problem to solve here.

I believe we need to frame this problem, which i'm also starting to
believe that is fundamentally different for names and numbers.

cheers!

Carlos

On 7/10/12 8:00 AM, SM wrote:
> every body wants to be at the top.  if you stay at the top there isn't
> any delegation.  If the top decides to delegate I am not sure whether
> it would it/they would find devolution palatable.
>
> Regards,
> -sm
> _______________________________________________
> weirds mailing list
> [email-masked]

---

From: Andy Newton <[email-masked]>
Date: Tue, 10 Jul 2012 17:01:07 +0000

On Jul 9, 2012, at 6:25 PM, John Levine wrote:

> If we want to do SRV records

I sure hope we aren't suggesting this on the client end. There are two complications.

1) It makes the clients that much more insane to write. Please let us keep the client requirements simple. However, if the idea is to use DNS records so that servers can synthesize HTTP redirects, that is better. Putting the complexity into the servers is the better choice.

2) SRVs are not enough. HTTP uses URLs and not just domain names, so NAPTR records would be more suitable. U-NAPTR comes to mind.

But for the big picture, standardizing the referral hierarchy is probably a world of hurt. More doable is probably an Informational on what one might expect to see.

-andy

---

From: "John Levine" <[email-masked]>
Date: 10 Jul 2012 21:20:29 -0000

In article <[email-masked]> you write:
>1) It makes the clients that much more insane to write. Please let us keep the client requirements simple. ...

In case it wasn't clear, I was just thinking of using the DNS to
bootstrap the query process.  Take the TLD of a name, the high octet
of an IPv4 address or the high 12 bits (give or take) of an IPv6
address, use the DNS to find an initial server, and then do the
RESTful query which might do further redirections.

The alternative would be a top level redirect server, which would have
to be run by IANA or someone they delegate.  There's nothing wrong
with that if IANA offers to do so, but it'd be a lot of work since it
would presumably get a vast amount of traffic.  The DNS bootstrap
approach would generally have the hints published by people who are
running a WEIRDS server in DNS zones they control, so IANA would stay
out of it.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 11 Jul 2012 09:00:52 +0200

On Tue 10/Jul/2012 23:20:29 +0200 John Levine wrote:
> 
> The alternative would be a top level redirect server, which would
> have to be run by IANA or someone they delegate.  There's nothing
> wrong with that if IANA offers to do so,

It was already said that this group can't tell IANA what to do.  Can
it ask, at least?

> but it'd be a lot of work since it would presumably get a vast
> amount of traffic.

What traffic increment do we expect as a consequence of establishing a
sound, simple way to learn operators' details?  For instance, will
there be a query for each loaded web page, only for shopping ones, or
none at all like now?

---

From: Andy Newton <[email-masked]>
Date: Wed, 11 Jul 2012 10:04:49 +0000

> running a WEIRDS server in DNS zones they control, so IANA would stay

Does the location of whois servers change frequently? For the most part this is static information and engineering this type of bootstrap process seems to be overkill. To the other point, running a top level redirect server doesn't sound that onerous; though I'd prefer this type of solution to allow any interested party into running such a service, not just IANA. (BTW, IANA does operate a top level Whois server today.)

For redirection, there are more interesting cases other than bootstrap -- specifically ERX space in the number registries.

-andy

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 11 Jul 2012 07:58:16 -0400

On Wed, Jul 11, 2012 at 10:04:49AM +0000, Andy Newton wrote:
> 
> Does the location of whois servers change frequently? For the most
> part this is static information and engineering this type of
> bootstrap process seems to be overkill.

Except when it isn't.  When .org was redelegated, I recall dealing
with complaints about "bad whois responses" as late as 2 years after
the redelegation, because people's clients had the Verisign server
name baked into them.  Given the expansion of the root (and the
sometimes, um, optimistic revenue assumptions of prospective registry
operators), I think we can expect redelegations to happen at least
often enough in future that it will be worth having a way to learn the
correct server to ask.

> running such a service, not just IANA. (BTW, IANA does operate a top
> level Whois server today.)

Indeed, and the WHOIS Review Team report that was released not so long
ago (and mentioned on this list) calls for that operation to get a
much larger, with at least a full-service rwhois proxy.

> For redirection, there are more interesting cases other than bootstrap -- specifically ERX space in the number registries.

Yes.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Wed, 11 Jul 2012 10:46:11 -0400

On Jul 11, 2012, at 7:58 AM, Andrew Sullivan wrote:

>> Does the location of whois servers change frequently?

Nope, not frequently at all (in the current world).. But, when they do, hilarity ensues...

>> For the most

The big issue is that this sort of thing will get baked into binaries and packages that almost never get updated….

> often enough in future that it will be worth having a way to learn the

Yup -- there are a large collection of new gTLDs, and (to me at least) many of the business plans seem, um, interesting…

I think it is prudent to assume that there will be a number of failures that will require redelegation and so (probably) movement of the whois servers…

Ain't this fun?!

W

--
"Let's just say that if complete and utter chaos was lightning, he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'."

    -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of Magic)

---

From: "John R Levine" <[email-masked]>
Date: 11 Jul 2012 11:57:29 -0400

> Does the location of whois servers change frequently? For the most part 
> this is static information and engineering this type of bootstrap 
> process seems to be overkill.

The location of any particular WHOIS server won't change very often.  On 
the other hand, if ICANN goes through with the plan to have thousands of 
TLDs, every week something will change.  Even in the IP space, as people 
use more IPv6 space, IANA will allocate new chunks to the RIRs.  You seem 
to be suggesting that we use the equivalent of HOSTS.TXT, which is, well, 
quaint.

> To the other point, running a top level redirect server doesn't sound 
> that onerous; though I'd prefer this type of solution to allow any 
> interested party into running such a service, not just IANA. (BTW, IANA 
> does operate a top level Whois server today.)

You're missing the key problem, the phenomenal load that a toplevel WEIRDS 
server would get.

Among the clever bits of design in the DNS is that zone cuts let it do 
what one might call prefix caching.  If I do a DNS lookup for aaa.bbb.com, 
my local cache remembers the name servers for .COM so that when I look up 
ccc.ddd.com, it already knows the .com server and doesn't have to ask 
again.

Although there are certainly web caches, they only cache exact matches, 
not prefixes.  So if IANA or whoever runs a top level redirector, I'm 
going to point all of my WHOIS lookups there, with local cache hits only 
if I've made the same exact query before.  The .COM WHOIS servers get 
about 1500 queries/second, a rather significant amount of traffic for IANA 
or anyone who's not already running WHOIS at scale to take on.  Yes, IANA 
runs WHOIS for the tiny root and INT zones, but that's hardly the same 
thing.

That's why I want the bootstrap to be in the DNS; it's the only existing 
infrastructure that can handle the load.

> For redirection, there are more interesting cases other than bootstrap 
> -- specifically ERX space in the number registries.

Of course, but I would expect that to be handled by http redirects from 
the old registry.

There are lots of redirects in the name space.  One of particular interest 
to me is that the .US domain still has subregistries for many geographic 
domains, and the subregistry agreement requires that we provide WHOIS.  I 
run one of those subregistries, but have never bothered to provide WHOIS 
because if I did, there would be no way for anyone to find it.  This was 
brought home to me last week when I started getting confirmation mail from 
Godaddy for SSL certificates that one of my registrants had bought.  Here 
in upstate NY things are pretty informal, and five minutes after the first 
message arrived, the phone rang and it was the registrant (the government 
of a nearby county) telling me that they'd ordered them so could I please 
approve them.  But that doesn't scale too well.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

PS: The whois.iana.org server has both an IPv4 address and an IPv6 
address, but the IPv6 address doesn't work, as in I can't connect, can't 
ping, and traceroutes get lost somewhere in NTT's network.  I'd think that 
if anyone actually used it, someone would have noticed and fixed this by 
now.

---

From: Andy Newton <[email-masked]>
Date: Wed, 11 Jul 2012 18:02:29 +0000

On Jul 11, 2012, at 11:57 AM, John R Levine wrote:

> 
> The location of any particular WHOIS server won't change very often.  On the other hand, if ICANN goes through with the plan to have thousands of TLDs, every week something will change.  Even in the IP space, as people use more IPv6 space, IANA will allocate new chunks to the RIRs.  You seem to be suggesting that we use the equivalent of HOSTS.TXT, which is, well, quaint.

I seem to recall a bunch of /8s added into the Whois recently without need of any such mechanism. But I am enjoying the juxtaposition of you arguing that we base a major protocol component on the unfinished plans of ICANN. :)

>> To the other point, running a top level redirect server doesn't sound that onerous; though I'd prefer this type of solution to allow any interested party into running such a service, not just IANA. (BTW, IANA does operate a top level Whois server today.)
> 
> You're missing the key problem, the phenomenal load that a toplevel WEIRDS server would get.

No, I understand.

> Among the clever bits of design in the DNS is that zone cuts let it do what one might call prefix caching.  If I do a DNS lookup for aaa.bbb.com, my local cache remembers the name servers for .COM so that when I look up ccc.ddd.com, it already knows the .com server and doesn't have to ask again.
> 
> Although there are certainly web caches, they only cache exact matches, not prefixes.  So if IANA or whoever runs a top level redirector, I'm going to point all of my WHOIS lookups there, with local cache hits only if I've made the same exact query before.  The .COM WHOIS servers get about 1500 queries/second, a rather significant amount of traffic for IANA or anyone who's not already running WHOIS at scale to take on.  Yes, IANA runs WHOIS for the tiny root and INT zones, but that's hardly the same thing.
> 
> That's why I want the bootstrap to be in the DNS; it's the only existing infrastructure that can handle the load.

For this problem, no it isn't.

Many Whois operators have had SRV records for years, yet the Whois clients that make use of them are in the minority. Using DNS has it problems, and in this instance it is the lack of useful client libraries. We should not ignore that client implementers have thus far steered away from this available solution.

I can easily think of a bootstrap mechanism easier to implement with tools already required for RESTful Whois than using DNS. A "root" redirect server is only one of them.

> PS: The whois.iana.org server has both an IPv4 address and an IPv6 address, but the IPv6 address doesn't work, as in I can't connect, can't ping, and traceroutes get lost somewhere in NTT's network.  I'd think that if anyone actually used it, someone would have noticed and fixed this by now.

I don't speak for the people running this service, but I would not characterize a class of service on one problem report, especially one that could easily be out of their control.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 11 Jul 2012 14:49:30 -0400

> I seem to recall a bunch of /8s added into the Whois recently without 
> need of any such mechanism.

I had to hand edit all seven of last year's /8's into my scripts as I 
noted that lookups were failing.  It was a pain.  But, ...

> But I am enjoying the juxtaposition of you arguing that we base a major 
> protocol component on the unfinished plans of ICANN. :)

Aw, come on.  I would prefer that ICANN admit that the giant TLD expansion 
is a mistake, but it's $300 million too late for that.  It seems more 
likely than not that sometime this decade they'll start adding at least 
hundreds of new TLDs every year, which is not something I would want to 
track by hand.  I agree that the problem is considerably less for IPs, but 
since we need to invent something for names, it might as well work 
everywhere.

> Many Whois operators have had SRV records for years, yet the Whois 
> clients that make use of them are in the minority. Using DNS has it 
> problems, and in this instance it is the lack of useful client libraries.

I don't think it's client libraries, SRV is old enough that support for it 
is pretty good.  I checked for SRV records for the 313 TLDs, and found 35, 
of which 32 were for ccTLDs, and one, .gr, pointed at . presumably to say 
they have no WHOIS.  The only gTLDs were .BIZ and .TRAVEL.  People don't 
look for SRV records because the only spec is a draft that expired in 
2003, and that most TLDs don't implement.  I note that .US has one, so 
I'll try putting up a server for my subdomains and see if anyone finds it.

> I can easily think of a bootstrap mechanism easier to implement with 
> tools already required for RESTful Whois than using DNS. A "root" 
> redirect server is only one of them.

Well, OK. Keeping in mind the scaling issue, what do you suggest?

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Wed, 11 Jul 2012 19:14:24 +0000

On Jul 11, 2012, at 2:49 PM, John R Levine wrote:

> I would prefer that ICANN admit that the giant TLD expansion is a mistake, but it's $300 million too late for that.

Sounds like a beer topic for Vancouver. :)

> I don't think it's client libraries, SRV is old enough that support for it is pretty good.  I checked for SRV records for the 313 TLDs, and found 35, of which 32 were for ccTLDs, and one, .gr, pointed at . presumably to say they have no WHOIS.  The only gTLDs were .BIZ and .TRAVEL.  People don't look for SRV records because the only spec is a draft that expired in 2003, and that most TLDs don't implement.  I note that .US has one, so I'll try putting up a server for my subdomains and see if anyone finds it.

I would suspect that any DNS library that does more than simple name resolution would do SRV and NAPTR. But the issue is that most client implementers do not have or do not want to use them. They require special knowledge of DNS, fail in strange and different ways, and are outside the mainstream of what most Internet programmers play with. In short, it does not meet the criteria of reasonably doable in a bash script.

> Well, OK. Keeping in mind the scaling issue, what do you suggest?

Off the top of my head: a JSON-based, HTTP-fetched hints file with a TTL.

Also, I would not discount redirect servers. I'm sure enterprising individuals would love to provide a service that captures those XHTML eyeballs.

-andy

---

From: "John Levine" <[email-masked]>
Date: 11 Jul 2012 19:48:25 -0000

PS:

> In short, it does not meet the criteria of reasonably doable in a bash script.

I don't claim this is beautiful, but it does look up a TLD's SRV
record and call the appropriate server in nine lines of bash.

-------------------------------------
#!/bin/bash

: "${1:?'need domain to look up'}"

a=$(host -t SRV _nicname._tcp."${1##*.}")

case "$a" in
     *"not found"*) echo Cannot find server, you lose; exit 1 ;;
     *"has SRV record"*)
	eval $(echo "$a" | sed -e 's/.* \([0-9][0-9]*\) \(..*\)/port=\1 host=\2/')
	whois -h $host -p $port "$1"
	;;
esac
-------------------------------------

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Wed, 11 Jul 2012 16:48:57 -0300

Hi!

> I would suspect that any DNS library that does more than simple name resolution would do SRV and NAPTR. But the issue is that most client implementers do not have or do not want to use them. They r…
Well, I think it is doable on a bash script and using "dig +short" :=)

I can't say anything on the failure side though. I don't have enough
experience in using these records to have an opinion.

While I heartily support the use of non-specialized clients, I don't
think we have to restrict ourselves to what the normal 'Joe SixPack
Programmer' would do.

I believe that after they realize the pain of to manually tracking
1000ths of WHOIS servers by hand, they will do a little reading on those
nifty NAPTRs or SVRs.

Bootstraping via DNS has a lot of nice properties including the
possibility of delegating the authority over the WHOIS data to
operators, DNSSEC signing and of course, caching.
> Off the top of my head: a JSON-based, HTTP-fetched hints file with a TTL.
Agreed, it could also work. Maybe we need to work a little bit further
on the pros and cons of each approach.
> Also, I would not discount redirect servers. I'm sure enterprising individuals would love to provide a service that captures those XHTML eyeballs.
Well, that was our first approach, documented on
draft-lacnic-weirds-redirects... but well, I received a some  negative
feedback on the idea.
> -andy
~Carlos

---

From: Andy Newton <[email-masked]>
Date: Wed, 11 Jul 2012 20:17:30 +0000

> record and call the appropriate server in nine lines of bash.

I said "reasonable". You should evaluate $? instead of the case statement. :)

But that's not the complete picture, as HTTP uses URLs and not just domain/port pairs. So either incorporate NAPTR or use URI templates. See where this is going?

-andy

---

From: Andy Newton <[email-masked]>
Date: Wed, 11 Jul 2012 20:18:30 +0000

> draft-lacnic-weirds-redirects... but well, I received a some  negative

As in the Internet should not be commercialized, or was it a technical objection?

-andy

---

From: "John Levine" <[email-masked]>
Date: 11 Jul 2012 20:32:42 -0000

>I said "reasonable". You should evaluate $? instead of the case statement. :)

Tsk, tsk. you didn't try it.  The host command returns 0 either way,
so you have to parse what it says.  If you think this is an
unreasonable bash script, you haven't looked at many bash scripts.

The whole bash thing is a red herring, since if WEIRDS is at all
successful, people will use opaque clients where you just put in the
question and it gives you the answer.  We currently wrap rococo shell
scripts around whois commands, but that's only because it's an
underspecified mess, something that with any luck we will fix.

> But that's not the complete picture, as HTTP uses URLs and not just
> domain/port pairs. So either incorporate NAPTR or use URI templates.
> See where this is going?

Down the black hole of excess complexity?  It is perfectly reasonable
for us to specify that all WEIRDS servers accept the same set of query
URLs for the queries they can answer, and respond on port 80, so the
only thing you need to bootstrap is the host name of the server.  That
also makes redirects a lot more straightforward.

Using URI templates would be adding complication only for the sake of
adding complication, since there is no installed base of incompatible
existing RESTful servers that need to be papered over.  Ditto NAPTR.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 11 Jul 2012 20:34:26 -0000

>As in the Internet should not be commercialized, or was it a technical objection?

Perhaps as in, it would be nice if everyone who asked the same question got the
same answer.

Hey, I have a great idea!  I bet a lot of enterprising people would love to provide
an alternative DNS root server, too.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Wed, 11 Jul 2012 20:58:50 +0000

On Jul 11, 2012, at 4:32 PM, John Levine wrote:

> so you have to parse what it says.

Not on my system.

>  If you think this is an

touché!

> underspecified mess, something that with any luck we will fix.

No, I don't think so. That's not how Whois works today, and I have an apache log file of user agents against our RESTful Whois service that clearly shows people are using all sorts of languages to script these things… the biggest being Javascript. My use of the bash script example is to make people think before adding complexity into the protocol.

BTW, are there in-brower Javascript DNS solutions? I've not looked into that.

> also makes redirects a lot more straightforward.

What about port 443? What about hosting this on the same cluster as my other web systems?

> existing RESTful servers that need to be papered over.  Ditto NAPTR.

No each solves the URL mapping problem given to us by SRV records.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 11 Jul 2012 17:44:09 -0400

>> so you have to parse what it says.

Gotta love that portability.

> BTW, are there in-brower Javascript DNS solutions? I've not looked into that.

Hmmn, a little googlage suggests that there aren't. You'd have to call
out to some web site that will do the lookup for you which rather
defeats the purpose.  I suppose one could use a CNAME kludge of
<tld>.wierdsservers.net or <1.2.3.4.5.6>.weirdsservers.net, analogous
to Rodney's whoisservers.net, that doesn't require a lookup before the
http query.  I don't unalterably hate a daily or weekly pull of a
master JSON file, but it seems more fragile, particularly if we hope that
clients will cache it reasonably, i.e., for more than one query, but not
forever.

> What about port 443?

Sorry, 443 is better.

> What about hosting this on the same cluster as my other web systems?

So get another IP.  The going price is $1/month.  It's hard for me to
imagine an organization large enough that it's worth publishing WHOIS
info, yet so tiny that they can't find a spare IP.

> No each solves the URL mapping problem given to us by SRV records.

What URL mapping problem?  You look up the domain or high bits of the
IP, plug the server host name you get back into the URL, and make your
query.  That server might redirect you, but we know how to deal with
that.

There will be a thousand times as many WIERDS clients as servers, so
given a tradeoff between making it easier to set up a server and
making it easier to do a query, I'll pick the easier query every time.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Thu, 12 Jul 2012 09:12:26 +0000

On Jul 11, 2012, at 5:44 PM, John R Levine wrote:

> http query.

Interesting. Why not XXXX.weirds.arpa?

> making it easier to do a query, I'll pick the easier query every time.

Agreed.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2012 10:08:53 -0400

> Interesting. Why not XXXX.weirds.arpa?

Uh, because I wasn't thinking far enough ahead?  That would involve IANA, 
but in a pretty benign way.  They'd have to update their processes to 
allow entities that have been delegated a TLD or a top level IP range to 
register and update WEIRDS servers, but it'd be no more work than 
maintaining the in-addr zone which they do now.

Regards,

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Fri, 13 Jul 2012 15:09:43 -0300

Well,, now I regret I did not send this email a few days earlier. I was
locked up in some meetings. You will see the mentions to .arpa below :-)

cheers!

Carlos

------------- earlier draft -------------------

Hi,

Rather than redirection the issue seems to be how to bootstrap the whole
RESTful WHOIS tree so redirections can be performed in the most 'cheap'
(meaning both quick and light on requirements) way.

I've read some negative opinions about putting this information on the
DNS, but, I have to say, it really looks like a tempting option.

For numbers it could be very easy, something like putting a specific
record (SRV seems a good match) on the apexes of every reverse zone
operated by each RIR. In our case, for example:

191/8 -> 191.in-addr.arpa.
_restfulwhois._tcp.lacnic.net.    IN SRV    10 60 80
restwhois.labs.lacnic.net.

164.73/16 -> 73.164.in-addr.arpa.
_restfulwhois._tcp.lacnic.net.    IN    SRV 10 60 80   
restwhois.labs.lacnic.net.

For names (and you know it's not my cup of tea and I can be very
foolish, naive or just plain st**d in what I write):

Option #1: Trusting each zone's operator to put a similar record. IMO, a
recipe for failure.

Option #2: Adding SRV records to the tld. zone hand in hand with the NS
records ? Bad: increase tld zone size.

Option #3: Extending the arpa (via something like tld.restwhois.arpa, it
could be _any_ other service zone for that matter.) tree to include SRV
records for names:

carlos.com, registered at ElCheapoDomains -> com.restwhois.arpa.
_restfulwhois._tcp.carlos.com.restwhois.arpa.    IN    SRV    10 60
80    restwhois.elcheaporegistrar.net.

Option #3 obviously needs a lot of work on the part of ICANN in order to
allow registrars to update these SRV registries, or manage them
themselves. Maybe there are other similar approaches that could simplify
this work.

This approach has some interesting advantages, like taking advantage of

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 16 Jul 2012 11:33:53 +0200

> It was already said that this group can't tell IANA what to do.  Can

I don't see why not. 

I don't know where the "can't tell IANA what to do comes from" (where was it said?)

No hats,

--Olaf

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

Science Park 400, 1098 XH Amsterdam, The Netherlands

---

From: Arturo Servin <[email-masked]>
Date: Mon, 16 Jul 2012 06:44:21 -0300

They even have some data!   =)

	http://www.iana.org/domains/root/db/

	http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml

	http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml

	http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml

	This allow to use IANA as top-down solution to find the correct weirds sever, however I must said that after reading some ideas about using DNS, I am tempted. 

Cheers,
as

---

From: SM <[email-masked]>
Date: Mon, 16 Jul 2012 03:47:19 -0700

At 02:44 16-07-2012, Arturo Servin wrote:

>This allow to use IANA as top-down solution to find the correct 
>weirds sever, however I

Yes.

The above, or some existing procedure, can be used by the six 
(number) operators who require the data.

Regards,
-sm

---

From: Arturo Servin <[email-masked]>
Date: Mon, 16 Jul 2012 10:05:35 -0300

>> http://www.iana.org/domains/root/db/

	But not sure about that.

Regards
as

On 16 Jul 2012, at 07:47, SM wrote:

>> This allow to use IANA as top-down solution to find the correct weirds sever, however I
> 
> Yes.
> 
> The above, or some existing procedure, can be used by the six (number) operators who require the data.
> 
> Regards,
> -sm

---

From: SM <[email-masked]>
Date: Mon, 16 Jul 2012 08:28:39 -0700

> >> http://www.iana.org/domains/root/db/

I should have removed that link in my previous message.  There are 
significant differences in the approach adopted by numbers and 
names.  The names part can be described as an intractable problem.

Yes.

Regards,
-sm

---

From: "John Levine" <[email-masked]>
Date: 17 Jul 2012 05:16:38 -0000

>I don't know where the "can't tell IANA what to do comes from" (where was it said?)

Probably me.  RFCs can certainly tell IANA to add stuff to protocol registries.

But I don't see any process for the IETF to tell IANA to run a WEIRDS
server, particularly one that's likely to get an enormous amount of
traffic, unlike their current WHOIS server, and would require significant
amounts of both software development and ongoing ops activity.

R's,
John

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 17 Jul 2012 09:29:24 +0200

> amounts of both software development and ongoing ops activity.

If the IETF thinks running such service is the best engineering solution then I am sure we can work it out. That said, operational considerations (such aligning operational costs with those that benefit) might come into the equation of what is the 'best solution'.

As your WG chair I'd be happy to coordinate once we are a little closer to figuring if establishing a WEIRDs server is a plausible wish of the working group. I am not sure we are there yet.

--Olaf

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

---

From: Andy Newton <[email-masked]>
Date: Tue, 17 Jul 2012 13:06:40 +0000

> As your WG chair I'd be happy to coordinate once we are a little closer to figuring if establishing a WEIRDs server is a plausible wish of the working group. I am not sure we are there yet.

Given the bootstrapping method John outlined using CNAMEs or delegations in weirds.arpa in the "bootstrapping" thread, I don't think anything beyond their normal services is needed of IANA from a server standpoint.

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 17 Jul 2012 13:10:07 +0000

On Jul 12, 2012, at 10:08 AM, John R Levine wrote:

> Uh, because I wasn't thinking far enough ahead?  That would involve IANA, but in a pretty benign way.  They'd have to update their processes to allow entities that have been delegated a TLD or a top level IP range to register and update WEIRDS servers, but it'd be no more work than maintaining the in-addr zone which they do now.

I think this is workable and strikes the right balance for the needs of the clients vs. distributed bootstrapping.

-andy

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 18 Jul 2012 17:25:38 +0200

On Tue 17/Jul/2012 15:10:07 +0200 Andy Newton wrote:
>>>> I suppose one could use a CNAME kludge of 
>>>> <tld>.wierdsservers.net or <1.2.3.4.5.6>.weirdsservers.net,
>>>> analogous to Rodney's whoisservers.net, that doesn't require
>>>> a lookup before the http query.
>>> 
>> Uh, because I wasn't thinking far enough ahead?  That would
>> involve IANA, but in a pretty benign way.  They'd have to update
>> their processes to allow entities that have been delegated a TLD
>> or a top level IP range to register and update WEIRDS servers,
>> but it'd be no more work than maintaining the in-addr zone which
>> they do now.
> 
> I think this is workable and strikes the right balance for the
> needs of the clients vs. distributed bootstrapping.

+1, I'll hum for it if it goes in A.5.2

---

From: Chris Wright <[email-masked]>
Date: Thu, 19 Jul 2012 22:36:26 +1000

Why not a DNS Resource Record that lives in the tld zone file? No need to
have IANA involved then and TLD manager can update as required.

dig -t WEIRDS tad returns URL of weirds service

Or we could potentially use existing records like SRV or NAPTR ?

Thanks

Chris

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Thu, 19 Jul 2012 10:47:41 -0400

I thought about that, but decided against it on the grounds that it will
increase zone size by a sizeable factor, which might not be an issue for
some operators but definitely will hurt others like .com

thoughts?

regards

Carlos

---

From: Hugo Salgado <[email-masked]>
Date: Thu, 19 Jul 2012 10:59:08 -0400

> some operators but definitely will hurt others like .com

The .com zone will only get 1 extra WEIRDS/SRV/NAPTR RR (plus some
RRSIGs and NSEC*).

This mechanism is only to bootstrap the first level. After that, .com
will redirect to weirds servers below its hierarchy using the standard
weirds-restful http redirect, when its needed.

Hugo

---

From: Andy Newton <[email-masked]>
Date: Thu, 19 Jul 2012 15:22:29 +0000

> Or we could potentially use existing records like SRV or NAPTR ?

As previously discussed in this thread, many client implementations operate in an environment that does not have access to this type of information.

-andy

---

From: Chris Wright <[email-masked]>
Date: Fri, 20 Jul 2012 10:02:01 +1000

I'm not sure you understood the idea, 

There would only be one record in the zone file (or maybe a few for redundancy reasons), it’s a bootstrap pointer not a pointer for every domain.

So I don’t think there would be any issue.

Thanks

Chris

-----Original Message-----
From: Carlos Martinez-Cagnazzo [mailto:[email-masked]] 
Sent: Friday, 20 July 2012 12:48 AM
To: Chris Wright
Cc: Alessandro Vesely; [email-masked]
Subject: Re: [weirds] the bootstrap problem, Redirection in the RESTful WHOIS world

I thought about that, but decided against it on the grounds that it will increase zone size by a sizeable factor, which might not be an issue for some operators but definitely will hurt others like .com

thoughts?

regards

Carlos

On 7/19/12 8:36 AM, Chris Wright wrote:
> Why not a DNS Resource Record that lives in the tld zone file? No need 
> to have IANA involved then and TLD manager can update as required.
>
>>>>>> I suppose one could use a CNAME kludge of <tld>.wierdsservers.net 
>>>>>> or <1.2.3.4.5.6>.weirdsservers.net, analogous to Rodney's 
>>>>>> whoisservers.net, that doesn't require a lookup before the http 
>>>>>> query.
>>>> Uh, because I wasn't thinking far enough ahead?  That would involve 
>>>> IANA, but in a pretty benign way.  They'd have to update their 
>>>> processes to allow entities that have been delegated a TLD or a top 
>>>> level IP range to register and update WEIRDS servers, but it'd be 
>>>> no more work than maintaining the in-addr zone which they do now.
>>> I think this is workable and strikes the right balance for the needs 
>>> of the clients vs. distributed bootstrapping.

---

From: Chris Wright <[email-masked]>
Date: Fri, 20 Jul 2012 10:03:47 +1000

Im sorry Andy, I don’t understand your point...

Are you saying that clients will operate in an environment where they can make a HTTP request but can't do DNS resolution? That makes absolutely no sense to me.

Beside the alternative approach being discussed is to have 'records' in XXXX.weirds.arpa. If the client can lookup DNS records in that zone, why cant they look them up in the TLD zone?

Can you expand on your issue a little more so that I understand it.

Thanks

c.

-----Original Message-----
From: Andy Newton [mailto:[email-masked]] 
Sent: Friday, 20 July 2012 1:22 AM
To: Chris Wright
Cc: Alessandro Vesely; [email-masked]
Subject: Re: [weirds] the bootstrap problem, Redirection in the RESTful WHOIS world

-andy

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2012 01:10:46 -0000

>There would only be one record in the zone file

Um, IP addresses don't have zone files.

R's,
John

---

From: Chris Wright <[email-masked]>
Date: Fri, 20 Jul 2012 12:00:19 +1000

They do if you turn them into their reverse DNS form. It works fine.

The only thing to consider is do we want to do top down or bottom up searching..

For example in .au we have registrations at the third level foo.com.au and even 4th level foo.vic.gov.au

If you did it top down you would get the weirds URL from the tld DNS and then be redirected by HTTP down the chain.

If you did it bottom up you would chop off one label from the left at a time, until you found the zone file with the weirds resource record (whichever one that is) in it and then have the URL to do the query.

I'm not sure that either of those are favourable so I offer another solution that builds on the existing one.

What if the bootstrap algorithm went something like this:

If IP address then turn into reverse resolve DNS string else the domain name is the DNS string
Append a known string to the DNS string (eg. 'weirds.arpa')and form the 'lookup string'
Lookup the CNAME, NAPTR, SRV or whichever resource record using the 'lookup string' as the domain name to lookup
The DNS will return either the URL or a CNAME to the server (whichever way we want it to work)
The query proceeds

Now at first glance this may seem like you need to fill the weirds.arpa zone with many records, but not if you consider using wildcards.

So if the com TLD only allows registrations at the 2nd level, they could ask to have
  *.com NAPTR <URL>
In the weirds.arpa zone file.
For au we COULD put these records in
   *.au NAPTR <URL>
   *.com.au NAPTR <URL>
   *.net.au  NAPTR <URL>
Or we COULD only put the au record in and allow the au WhoIs to do HTTP redirects to children
I believe this approach could be used for IP addresses WhoIs too.

So if I was faced with bootstrapping a request for 

example.com.au
I would look up the weirds record for example.com.au.weirds.arpa
And the DNS would match appropriately based on what was configured, and then the https service could redirect if /as required. It is a very flexiable solution.

If I was faced with bootstrapping a request for 203.18.56.11
I would look up the weirds record for 11.56.18.203.in-addr.arpa.weirds.arpa
And so forth..

What do you guys think?

Thanks

Chris

-----Original Message-----
From: John Levine [mailto:[email-masked]] 
Sent: Friday, 20 July 2012 11:11 AM
To: [email-masked]
Cc: Chris Wright
Subject: Re: [weirds] the bootstrap problem, Redirection in the RESTful WHOIS world

R's,
John

---

From: Chris Wright <[email-masked]>
Date: Fri, 20 Jul 2012 12:04:03 +1000

FYI the 'they do if you turn them into their reverse DNS form' was in reply to the IP addresses don't have zone files comment.

Thanks

c.

---

From: "John R Levine" <[email-masked]>
Date: 19 Jul 2012 23:36:57 -0400

> They do if you turn them into their reverse DNS form. It works fine.

Two points.  One is that rDNS zones have never had anything in them other 
than NS, CNAME, and PTR.  You'd hope that nothing strange would happen if 
you put in other stuff, but I wouldn't want to try it without some 
significant testing first.

I thought SRV was a swell idea until Andy reported that a lot of the 
queries to the existing WEIRDS prototype are coming from Javascript 
programs that are running in web browsers.  There is no way to do a DNS 
lookup from Javascript other than the implicit A and AAAA lookup that 
happens when it fetches a URL.  That makes any DNS hack beyond one that 
gives predictable CNAMEs to servers a complete non-starter.

> If IP address then turn into reverse resolve DNS string else the domain 
> name is the DNS string. Append a known string to the DNS string (eg. 
> 'weirds.arpa') and form the 'lookup string' [ and then do something with 
> wildcards ]

> What do you guys think?

Having written my share of DNS client and server software, it's vastly 
overcomplicated.

For names, a CNAME pointing to the server at <tld>.weirds.arpa would work. 
If your ccTLD is subdivided at the second or third level, it's your job to 
set up appropriate referral servers.

For IPv4, <nnn>.weirds.arpa, where NNN is the high octet of the address 
will also work.  IANA has already assigned each /8 to an RIR for WHOIS 
management, nothing new there.

IPv6 is a little tricker, since IANA's allocations were originally /23 and 
have since grown to /12.  If we do x.x.x.x.x.x.weirds.arpa, where the x's 
are the first six hex digits of the address, a zone with an entry for all 
of the allocated space would have about 21K entries.  That's a factor of 
10 bigger than the TLD list (assuming ICANN allocates most of the 1500 
TLDs applied for) but still not ridiculous.  I realize you could shrink 
the zone by using reversing the digits and using wildcards, but then it'd 
refer queries for addresses that aren't allocated to servers that aren't 
expecting them, which doesn't strike me as a good idea.

R's,
John

---

From: Chris Wright <[email-masked]>
Date: Fri, 20 Jul 2012 14:16:53 +1000

Thanks John,

>gives predictable CNAMEs to servers a complete non-starter.

Im not sure that we should dismiss a workable solution simply because one
technology doesn't support it, and it is solvable in that technology, it
would simply need to call to a web service first that 'figured out' what
the correct URL is to send the lookup to. (I.e. some service side script).
That¹s no better or worse of a 'workaround' than the one that was
suggested for the CNAME  / Virtual hosting issue (which seems to be just
use more IPs). If you really want to solve the Javascript problem you just
need a central http starting point to redirect people the right way, but
that¹s ugly (and can you say single point of failure) and I dunno, to me
it just doesn't make sense to design an internet protocol around a
restriction in one piece of technology, which could change in the future
anyway.

I digress though as I still prefer the wildcard solution which would still
allow CNAMES to be used anyway.

As for the 2nd level registrations vs 3rd level registrations, I am fine
having the TLD server redirect further down, was just pointing out that if
we weren't fine with that, the DNS method could be used too. (In fact they
are not mutely exclusive so why not leave it as a choice).

Thanks

Chris

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2012 04:37:37 -0000

>technology doesn't support it

There's going to be a thousand times as many WEIRDS clients as WEIRDS
servers.  Given a choice between adding more complexity to the clients
and adding it to the servers, the correct choice is clearly to do the
work in the servers.

We need some way to bootstrap the queries and find an initial server,
but the simpler the bootstrap the better.  Once the client has found
an initial server, the servers know how to do referrals.

> it would simply need to call to a web service first that 'figured out' what
>the correct URL is to send the lookup to.

A web service?  That would be the initial WEIRDS server found via a
CNAME, and the URL would be returned as a referral.  What would be the
advantage of inventing another web service that sort of does what
WEIRDS already can do?

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 20 Jul 2012 12:45:21 +0200

On Fri 20/Jul/2012 05:36:57 +0200 John R Levine wrote:
> 
> IPv6 is a little tricker, since IANA's allocations were originally /23
> and have since grown to /12.  If we do x.x.x.x.x.x.weirds.arpa, where
> the x's are the first six hex digits of the address, a zone with an
> entry for all of the allocated space would have about 21K entries. 
> That's a factor of 10 bigger than the TLD list (assuming ICANN
> allocates most of the 1500 TLDs applied for) but still not
> ridiculous.  I realize you could shrink the zone by using reversing
> the digits and using wildcards, but then it'd refer queries for
> addresses that aren't allocated to servers that aren't expecting them,
> which doesn't strike me as a good idea.

Would using DNAMEs yield workable practices in this case?

---

From: Dmitry Kohmanyuk <[email-masked]>
Date: Fri, 20 Jul 2012 14:41:44 +0300

On Jul 11, 2012, at 6:57 PM, John R Levine wrote:

> 
> There are lots of redirects in the name space.  One of particular interest to me is that the .US domain still has subregistries for many geographic domains, and the subregistry agreement requires that we provide WHOIS.  I run one of those subregistries, but have never bothered to provide WHOIS because if I did, there would be no way for anyone to find it.  This was brought home to me last week when I started getting confirmation mail from Godaddy for SSL certificates that one of my registrants had bought.  Here in upstate NY things are pretty informal, and five minutes after the first message arrived, the phone rang and it was the registrant (the government of a nearby county) telling me that they'd ordered them so could I please approve them.  But that doesn't scale too well.

in UA ccTLD (which I help to run) we have whois.ua server automagically redirect whois queries to various sub registries when needed.   sample:

% request from 2001:4130::3544:bb73:25bf:6a1e
% This is the Ukrainian Whois query server #F.
% The Whois is subject to Terms of use
% See https://hostmaster.ua/services/
%

% The object shown below is NOT in the UANIC database.
% It has been obtained by querying a remote server:
% (whois.dp.ua) at port 43.
%
% REDIRECT BEGIN

% This is the Dnepropetrovsk Whois query server.
%

domain:           whois.dp.ua
[…]

Our approach does not scale well (as central whois server for UA has 50-something public delegations) but it works fine in ccTLD space.

I would consider using _nicname._tcp.domain.ua approach for those who want to get whois server information directly from delegated domain.

> PS: The whois.iana.org server has both an IPv4 address and an IPv6 address, but the IPv6 address doesn't work, as in I can't connect, can't ping, and traceroutes get lost somewhere in NTT's network…

you must have some problems with your IPv6 connectivity in upstate NY - here in Ukraine, IPv6 address of whois.iana.org works just fine:

$ telnet -6 whois.iana.org nicname
Trying 2620:0:2830:200::59...
Connected to ianawhois.vip.icann.org.
Escape character is '^]'.
ua
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

domain:       UA

organisation: Communication Systems Ltd
address:      vul Vavilovykh 18
address:      Kyiv  04060
address:      Ukraine
[…]

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 20 Jul 2012 08:57:06 -0300

> significant testing first.

This is a red herring, these zones are not special and any RR
supported or not (3597) works just fine. The IP -> ARPA conversion is
done at the DNS client code or stub resolver library level.

> lookup from Javascript other than the implicit A and AAAA lookup that 

So that said _weirds._tcp.TLD IN A works just fine for a limited
bootstrap as long as we could live with a fixed the port. This looks
like a reasonable compromise for simplicity sake.

Fred

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 20 Jul 2012 09:07:54 -0300

Dimitry,

> On Jul 11, 2012, at 6:57 PM, John R Levine wrote:
...
> [?]

Strictly speaking this is actually not a redirection but a proxy whois
server intermediating the query. A RESTFul architecture will provide
us with all the required tools to easily build more scalable systems
with smarter clients.

Fred

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2012 14:49:48 -0000

>done at the DNS client code or stub resolver library level.

We all know that's the theory.  Since there have never been A or
SRV records in rDNS zones, how much are you willing to wager that
all the existing client libraries will properly disregard them?

>bootstrap as long as we could live with a fixed the port.

Since that's not a valid hostname, I think I can pretty much
guarantee that it won't work from Javascript.

R's,
John

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Fri, 20 Jul 2012 10:52:41 -0400

I'm not sure I get what he meant then. Maybe a longish explanation would
help.

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Fri, 20 Jul 2012 11:03:52 -0400

Is it a requirement that a pure JavaScript implementation of a WEIRDS
client must  be possible? If so, we have a pretty strong restriction
that will limit what we can / cannot do.

I believe we should clarify this point before continuing the discussion.

On the other hand, how difficult / heavy to operate would it be to run a
'helper' webservice that basically gives the SRV record to those pesky
pure JS implementations ? Who would run such a service ? All queries /
answers would be very short, right ? And if the information resides in
the DNS, anyone could operate one of these services (i'm not making any
statements here, just popping questions up so we can discuss them)

Looking forward to Vancouver !

Carlos

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2012 16:16:00 -0000

>that will limit what we can / cannot do.

Given that Andy's told us that many, perhaps most, of the existing
users of the existing prototype are using Javascript, it'd be a cruel
joke to say that won't work any more.

>pure JS implementations ?

Could you explain exactly how a "helper" that received an http query
from a web client and returned the hostname for the appropriate server
would be different from a top level WEIRDS server that received an http
query from a web client and returned the URL (including the hostname)
for the appropriate server?

R's,
John

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Fri, 20 Jul 2012 12:51:36 -0400

Hi, see inline

--
Carlos Martinez-Cagnazzo
R+D Engineer
http://www.labs.lacnic.net

> joke to say that won't work any more.
I don't think we're saying that their clients won't work anymore. The
queries will work as always.
> for the appropriate server?
It would provide comparable service, and (hopefully) would provide a
more palatable approach to those folks who are not comfortable with the
idea of a single, top-level WEIRDS referral service. It would allow
bootstrapping the WEIRDS tree without relying on a centralized database.

As I mentioned in earlier emails, I originally wrote about a fully
hierarchical WEIRDS tree, but then I received some well fundamented
negative feedback on the idea.

regards

Carlos

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2012 18:03:31 -0000

>bootstrapping the WEIRDS tree without relying on a centralized database.

I'm still not getting this.  How is the helper server not a
centralized database abd a single top-level referral service?  All
bajillion javascript clients would hit it for every query.  Probably
other clients, too, if they have cruddy DNS client libraries that like
the ones in Javascript.

>negative feedback on the idea.

Right, it has horrible scaling problems.  That's why we want to put
the bootstrap in the DNS, which we know can handle the load.  Needless
to say, putting it in the DNS means that the clients have to make
their own DNS queries.  If they all go through a "helper", the helper
is the bottleneck with the scaling problems.

Conversely, what's the advantage of a helper over CNAMEs in tld.weirds.arpa?

R's,
John

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Fri, 20 Jul 2012 14:22:53 -0400

Hi,

> other clients, too, if they have cruddy DNS client libraries that like
The 'helper' would not have a database, would just perform DNS queries
and return the results in some format to be agreed.
> is the bottleneck with the scaling problems.
'My' helper so to speak would do very little, and there could be many of
them (since there is no database needed). So I guess it would be
possible to operate such a service in a highly distributed way.
> Conversely, what's the advantage of a helper over CNAMEs in tld.weirds.arpa?
Maybe none other than the more refined semantics of the SRV/NAPTR
records. Can you provide some pseudo code of how a JS client would use
these CNAMEs ?

cheers!

Carlos

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 20 Jul 2012 15:53:31 -0300

> SRV records in rDNS zones, how much are you willing to wager that

This is not true RIR have seen in the past requests for glue records
at delegation point on the basis that the reverse tree doesn't depend
on other zones. 

Another prof is that recently we've seen ip6.arpa and in-addr.arpa
delegated to servers below in-addr-servers.arpa and ip6-servers.arpa.

There is nothing special on the protocol or on resolvers libraries
regarding this zones.

> guarantee that it won't work from Javascript.

Right ECMA-262 point to 2396 definition clearly disallow this but
anyway I preferer this as distributed as possible, so we could use a
namespace hack, to prevent namespace conflicts, ala the idna prefix,
ws--weirds.TLD A, instead of a new central database published at an
arpa zone.

Regards,
Fred

---

From: "John R Levine" <[email-masked]>
Date: 20 Jul 2012 14:55:04 -0400

> records. Can you provide some pseudo code of how a JS client would use

To do a lookup for info about xyz.tld, it does a simple string 
transformation to create the URL http://tld.weirds.arpa/xyz.tld/whatever 
(where the xyz.tld/whatever is the restful part of the query) and fetches 
it.  This requires that the server answer on port 80, which I do not think 
is an unreasonable restriction.  If the server would prefer https, it can 
return a redirect to that.  If it's delegated that domain to another 
server, it returns a redirect to the other server.

IP lookups would do roughly the same thing, e.g., to look up information 
about 11.22.33.44 it would look up

http://11.weirds.arpa/11.22.33.44/whatever

Really, this isn't complicated.  It is true that SRV and NAPTR would allow 
us to introduce a great deal of added complexity into clients, but I see 
no benefit from that in this case where there is no installed base of 
WEIRDS server that we have to work around.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Fri, 20 Jul 2012 18:58:44 +0000

Let me propose a compromise on the DNS bootstrapping. It requires a bit more work of the zone maintenance by IANA, but supports both the clients with basic name resolution capabilities and those with advanced resolution capabilities.

The current CNAME proposal is to allow RESTful Whois service operators to register CNAME records under weirds.arpa (or similar). For example, com.weirds.arpa could have a CNAME pointing to VeriSign's shiny new service. If the powers-that-be allow it, John could have ny.us.weirds.arpa CNAME records registered.

Here is the compromise:

Instead of using CNAME records, we allow the registration of A, AAAA, and RFC 4848 u-flag constrained NAPTR records. A service operator would have to register all three types. But that would allow bootstrapping with both basic resolution (using the A/AAAA records) and advanced resolution (using the NAPTR records).

And note, I've restricted the NAPTR registration to RFC 4848 compliant using the u-flag only.

-andy

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2012 20:41:18 -0000

Sorry to seem intransigent, but this still seems to miss some
important points.

My theory is that we need enough of a bootstrap that clients can find
an initial server that is reasonably close to the final server.  By
reasonably close, I mean that it's likely to be the the final server,
or run by the organization that's delegated a subtree to the final
server and so knows where it is.

I'm also concerned about load management.  One WHOIS server (.COM and
.NET) gets 200 queries/second while others like .INT and .MUSEUM
probably don't get 200 queries/week.  Anything that's going to be in
the path to the 200 q/s server has to be run by the same people who
run that server, since they're already prepared to deal with the load,
or else we need a good reason to think that the load on the
intermediate steps will be lower, with the main reason being DNS
caches.

With that in mind:

>The current CNAME proposal is to allow RESTful Whois service operators to
>register CNAME records under weirds.arpa (or similar). For example,
>com.weirds.arpa could have a CNAME pointing to VeriSign's shiny new service.
>If the powers-that-be allow it, John could have ny.us.weirds.arpa CNAME
>records registered.

That last bit is no good, that blows up the DNS caches.  I
deliberately proposed only looking up the last component of a domain
name or the first octet of the IPv4 address, because that will cache
well.  No matter how many .COM names you look up, the client fetches
com.weirds.arpa once from the .arpa servers, and thereafter from the
cache.

The delegation structure of DNS names is extremely irregular.  In my
case, for example, foo.watkins-glen.ny.us would be delegated to me,
but foo.ithaca.ny.us is handled directly by Neustar, with the reasons
for each delegation or non-delegation lost in the mists of history.
In .CA, most names are registered with CIRA at the second level
(foo.ca), but there are plenty at the third (foo.on.ca) and a fair
number at the fourth (foo.toronto.on.ca.)  This is widespread in
ccTLDs and in a few gTLDs like .name.

If you expect to find delegations below the top level via the DNS,
you're pretty much requiring that every WEIRDS query start with a
lookup of the full name in .arpa, which isn't going to cache.  It also
asks the TLDs to publish their delegation tree in the DNS which I
suspect many won't want to do.

I think looking up the first component will get you close enough. (And
I hereby withdraw my proposal to look up the first six digits of IPv6
addresses, see below.)

>Instead of using CNAME records, we allow the registration of A, AAAA, and RFC
>4848 u-flag constrained NAPTR records.

Nope, breaks load management.  The aforementioned 200 q/s WHOIS server
is actually many different servers with different IP addresses.  Look
up whois.crsnic.net or whois.verisign-grs.com and you'll find six name
servers that return a rotating set of A records with 1 second TTL for
the WHOIS servers.  That works fine with a CNAME, but not at all if
you demand that they import the A records into .arpa.  The A records
for the whois servers don't cache, but that's Verisign's decision and
they're bearing the load themselves.

I just don't see the advantage of making the DNS bootrap more
complicated than a CNAME for the first component, and a lot of
disadvantages.

R's,
John

PS: Oh, yeah, about IPv6, with its irregular delegation structure from
IANA.  If your client doesn't happen to have the IANA delegation table
handy it just queries the closest RIR, and each RIR knows how to find
the others.  Given that there are only five RIRs, and the IPv6
delegation table contains only 37 entries and hasn't added a new entry
since 2006, I think that for IPv6, that's reasonable.  We can say that
high volume query clients SHOULD use the table to select a server, and
SHOULD download a new copy of it every year, just in case.

---

From: Andy Newton <[email-masked]>
Date: Fri, 20 Jul 2012 21:04:09 +0000

> com.weirds.arpa once from the .arpa servers, and thereafter from the

Ok. I hadn't quite digested that point.

> I hereby withdraw my proposal to look up the first six digits of IPv6

I'm fine with "close enough" in the bootstrap process.

> they're bearing the load themselves.

I didn't mean to imply just one A or AAAA. They could register multiple.

> complicated than a CNAME for the first component, and a lot of

Remember, this is one of those things we call a "compromise". We know we have one when nobody is completely satisfied with the solution.

> SHOULD download a new copy of it every year, just in case.

I'm fine with this. Not only does that happen with IPv6 today, it also happens with the much more common IPv4 queries.

-andy

---

From: SM <[email-masked]>
Date: Fri, 20 Jul 2012 14:26:10 -0700

At 11:58 20-07-2012, Andy Newton wrote:
>Here is the compromise:
>
>Instead of using CNAME records, we allow the registration of A, 
>AAAA, and RFC 4848 u-flag constrained NAPTR records. A service 
>operator would have to register all three types. But that would 
>allow bootstrapping with both basic resolution (using the A/AAAA 
>records) and advanced resolution (using the NAPTR records).

I don't think that providing two ways to do the same things is the 
better answer.

Regards,
-sm

---

From: "John R Levine" <[email-masked]>
Date: 20 Jul 2012 17:39:03 -0400

> I didn't mean to imply just one A or AAAA. They could register multiple.

Not the same thing.  Verisign is handing out a different A record with a 
one second TTL for each DNS lookup, presumably doing load balancing to 
send traffic to less busy servers.  As I said, works great with a CNAME, 
not with imported A's.

What's the advantage of importing A's rather than using a CNAME?  The 
CNAMEs should cache well, after all, and they let the server operators to 
do internal reconfiguration without needing to involve IANA.

> Remember, this is one of those things we call a "compromise". We know we have one when nobody is completely satisfied with the solution.

I'm not opposed to compromises, but I'm still not seeing any benefit at 
all from more complicated proposals.

Regards,

---

From: Andy Newton <[email-masked]>
Date: Fri, 20 Jul 2012 22:15:20 +0000

On Jul 20, 2012, at 5:39 PM, John R Levine wrote:

> Not the same thing.  Verisign is handing out a different A record with a one second TTL for each DNS lookup, presumably doing load balancing to send traffic to less busy servers.  As I said, works great with a CNAME, not with imported A's.

ah!

> What's the advantage of importing A's rather than using a CNAME?  The CNAMEs should cache well, after all, and they let the server operators to do internal reconfiguration without needing to involve IANA.

The reason for A/AAAA is because CNAME will not co-habitate with NAPTR or any other records on the same name. A fix to that is to use one name for CNAME and another for NAPTR.

> I'm not opposed to compromises, but I'm still not seeing any benefit at all from more complicated proposals.

Honestly, if we have to do either "basic" or "advanced" and cannot do a compromise, I lean toward "basic".

The only thing that bugs me about the basic solution is that we are doing it in response to clients operating in a limited environment, and I'm unsure of what other limitations we are not taking into consideration.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 20 Jul 2012 18:47:09 -0400

> The reason for A/AAAA is because CNAME will not co-habitate with NAPTR or any other records on the same name. A fix to that is to use one name for CNAME and another for NAPTR.

Well, OK, but now the question is what problem NAPTR solves.  I think I 
understand what it does in an environment where there are a lot of not 
quite compatible legacy servers serving irregular parts of the name space 
with mutually hostile managers.

But there's no legacy servers here, it's all going to be shiny new WEIRDS 
all of which will take exactly the same URLs, and on the name side, 
everything is strictly delegated from the top down.  What am I missing?

> The only thing that bugs me about the basic solution is that we are 
> doing it in response to clients operating in a limited environment, and 
> I'm unsure of what other limitations we are not taking into 
> consideration.

That's a reasonable concern, but I'd rather address it by building stuff 
out of the most widely available building blocks.  There's a lot more 
client stuff that understands CNAMEs than stuff that understands NAPTR.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Fri, 20 Jul 2012 23:34:16 +0000

On Jul 20, 2012, at 6:47 PM, John R Levine wrote:

> Well, OK, but now the question is what problem NAPTR solves.  I think I understand what it does in an environment where there are a lot of not quite compatible legacy servers serving irregular parts of the name space with mutually hostile managers.
> 
> But there's no legacy servers here, it's all going to be shiny new WEIRDS all of which will take exactly the same URLs, and on the name side, everything is strictly delegated from the top down.  What am I missing?

Really only two things that I see: 1) allows for hosting the service on a non-fixed path, and 2) allows the specification of HTTPS.

I personally am not swayed by these issues. Perhaps other have better reasoning.

> That's a reasonable concern, but I'd rather address it by building stuff out of the most widely available building blocks.  There's a lot more client stuff that understands CNAMEs than stuff that understands NAPTR.

This strikes me as a reasonable argument.

-andy

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2012 01:16:10 -0000

>Really only two things that I see: 1) allows for hosting the service on a
>non-fixed path, and 2) allows the specification of HTTPS.
>

HTTPS is a sensible concern.  One possibility would be to say that all
WEIRDS servers run over HTTPS, or if people really hate that, we could
have tld.weirds.arpa for the normal server and tld.sweirds.arpa for
the secure one.  Personally, I prefer all HTTPS all the time.

R's,
John

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Fri, 20 Jul 2012 12:49:04 -0400

Hi, see inline

regards

Carlos

---

From: Chris Wright <[email-masked]>
Date: Sat, 21 Jul 2012 23:32:06 +1000

I like the idea of trying to maintain a secure path from bootstrap to
response. So with the "CNAME to well know port 80, which can then redirect
to 443 for HTTPs if the provider wants" proposal I don't like the insecure
hop in the chain (if we are to seriously think about security).

An easy fix for this is make all required to run over HTTPs instead of
HTTP, but the issues with this (asides from forcing secure) is that if I
run a registry for 100s of TLDs (which AusRegistry will be for example) I
don't want to have to get 100s of SSL certs. I would prefer to be able to
run the weirds service at something like say
"https://weirds.ausregistry.net" for all the TLDs we operate. Also I
couldn't get a wildcard cert for *.weirds.arpa because that would mean I
could pretend to be other TLDs, oh and finally, how will I get a cert at
all? What CA will give me a cert for au.weirds.arpa?

So this leads me to preferred solution

SOLUTION 2
NAPTR for TLD under weirds.arpa to a URL (DNSSEC protects the DNS query,
HTTPs (if I use it in the URL) protects the HTTP - no break in security)
and this means one SSL certificate to manage and everything is nice and
clean. It also means I can use NAPTR records with varying attributes to
support load distribution and 'failover' etc. Its a really good clean
solution that only has the one disadvantage as far as I can tell and
that¹s that it can't be used by Javascript - which firstly can be solved
by the person implementing the java script client making a call back to a
server side script (which they host) to do the DNS lookup - as others have
discussed, and secondly I am very worried that we start to look at things
like 'this can't be done in javascript' as a constraint on our protocol
design.

Thanks

Chris

---

From: Chris Wright <[email-masked]>
Date: Sat, 21 Jul 2012 23:50:25 +1000

Actually I would like to add to my preferred solution below that it also
works equally well as a well known NAPTR record in the TLD zone file
itself, and this is even better as then there is no need to get IANA
involved for changes. Though we may need to think about how this would
work for IP address lookups, although I am not sure that it is entirely
required that IP addresses and domain name lookups need the exact same
bootstrap.

IP bootstrap could be reverse resolve eg. 203.18.56.1 and look up the
203.in-addr.arap zone file for the record (and similar for IPv6).

Thanks

Chris

---

From: "John R Levine" <[email-masked]>
Date: 21 Jul 2012 11:34:36 -0400

> don't want to have to get 100s of SSL certs.

Your new TLD customers will each have paid ICANN $185,000 to apply for 
their new TLDs, and $50,000 maintenance every year.  You will I hope 
excuse us if we have limited sympathy for complaints that joining the 
gravy train might involve some extra work.

> What CA will give me a cert for au.weirds.arpa?

The obvious answer is that whoever runs weirds.arpa (most likely IANA) 
will arrange for SSL certs for the entities that register CNAMEs in it, or 
at least have agreements with a few SSL vendors to approve applications 
from the registrants.

> NAPTR ...

Didn't we just spent a week noting that a large fraction of WEIRDS clients 
will probably be unable to handle NAPTR?

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2012 16:14:34 -0000

>> would be different from a top level WEIRDS server ...

>bootstrapping the WEIRDS tree without relying on a centralized database.

It occurs to me that for people who care about security, unless there
is a single well known master helper server (which has the same
scaling problem as a top level redirect server) this enables a
gigantic man in the middle attack that no amount of DNSSEC or HTTPS
will fix.

For the umpteenth time, CNAMEs do everything a bootstrap needs to to.
Really.

R's,
John

---

From: Chris Wright <[email-masked]>
Date: Sun, 22 Jul 2012 10:46:00 +1000

Thanks John, 

I notice you have conveniently ignored responding to the keeping the chain
secure argument? What are you thoughts on that? And how would you solve it
in your proposed model?

Response to your other comments below:

>gravy train might involve some extra work.

What ever personal opinions you have about new gTLDs and the amount of
money that is or is not involved (I didn't know you were privy to any of
our back end contracts? So Im fairly confident you DO NOT know how much we
are charging for Registry services), they are not an argument for
designing a system in a way that is unnecessarily expensive to implement.

>at least have agreements with a few SSL vendors to approve applications

Operationally I do not like not being in control of my own destiny. SSL
certificates have to be 'renewed' every year, I do not want to be reliant
on someone from IANA doing this to ensure my WEIRDS service keeps
functioning correctly, further there will surely be a cost to this, to
date I am not aware of anything IANA charges for, this would be either
something IANA would have to operationally absorb, or they would have to
add 'functionality' to start charging for these things, neither of which I
believe is a good thing to be asking IANA to do (without damn good reason
- which I am sorry but I (and others it seems) disagree with you that
Javascript is a damn good reason).

>will probably be unable to handle NAPTR?

No, you spent a week saying that and I (and others) said so what? Why
should the constraints of a particular programming language dictate our
protocol specification (especially when we have shown perfect viable,
cheap and easy ways to work around those constraints). What happens if in
the next version of java script they now introduce the ability to do DNS
lookups? I am sure if it is that big of a deal for the large fraction of
implementations already out there (cmon really, later fraction of
implementations already out there for a standard that doesn't yet exist,
they are in a test bed?) then someone will add the appropriate support to
the language. Finally, the implementation at the moment is just that, an
experiment, nothing more.

I am all for considering the Javascript use case and making sure we do not
do something that will mean it is impossible to implement a client using
javascript, but that simply is not the case. As above we have shown that a
simple call back to the server (the one that served the javascript in the
first place) can do the DNS resolution, there is lots of examples of
javascript code doing this on the web already (just google it) there are
even javascript libraries with corresponding server side scripts to handle
just this case!

So I for one (and I have seen others), am yet to be convinced that the
constraint is justified - you seem to think it is, but last time I checked
IETF processes where rough consensus not dictatorship.

---

From: "John R Levine" <[email-masked]>
Date: 21 Jul 2012 20:56:14 -0400

> IETF processes where rough consensus not dictatorship.

Good point.  So before I respond to your screed, let's see if anyone else 
agrees with some of your surprising assertions.

Regards,

---

From: Chris Wright <[email-masked]>
Date: Sun, 22 Jul 2012 10:59:35 +1000

John, 

Again see below.

>gigantic man in the middle attack that no amount of DNSSEC or HTTPS

Can you please explain how a secure DNS lookup done via DNSSEC, which
returns a HTTPs URL, which is then resolved again using DNSSEC, which you
finally then connect to using SSL is vulnerable to a man in the middle
attack, and then if so how a single HTTPs starting point solves that
problem? I just don't see your point, sorry if I am too stupid to see it,
but can you help me understand.

>For the umpteenth time, CNAMEs do everything a bootstrap needs to to.

The argument is not whether CNAMES server the purpose of bootstrap, I
concede that they do, but they come with several operational concerns
which are valid:

> the fixing the port problem (granted - a minor concern)
> the do we use HTTP vs HTTPs problem (securing end to end)
> the cost of purchasing, managing and so forth large volumes of SSL
>certificates (which the number registries, if they care about ssl, will
>need to do to)
> the ability to get those certificates (having IANA in the chain and what
>that means for IANA)
> the unnecessary IP address consumption (again, may be a minor concern)

Where as NAPTR records ALSO serve the purpose of bootstrap (I haven't
heard anyone say they don't) and so far they seem to be simpler and the
only argument any one has come up with is:

> they can't be used directly in javascript

And I am sorry that I appear to be frustrating you, but at the moment I
don't really hear anyone else weighing in on the discussion one way or the
other, perhaps I am not clear in how the process is supposed to work, if I
don't agree with what you saying, Im just supposed to give up? Throw my
hands up in the air and walk away in frustration?

---

From: Warren Kumari <[email-masked]>
Date: Sun, 22 Jul 2012 21:13:59 -0400

On Jul 21, 2012, at 8:59 PM, Chris Wright wrote:

> attack,

Please sir, how does an app know that the DNS lookups were "done via DNSSEC"? In the real world? From <insert favorite language here>? (This isn't really specific to the helper discussion…)

> and then if so how a single HTTPs starting point solves that

Or a number of other languages...

> other,

Ok, I'll weigh in -- as much as I dislike agreeing with John[0], I too believe that having this easy to do in Javascript (and php and vbscript and  rexx and asp and…) is really important. 

> perhaps I am not clear in how the process is supposed to work, if I

No, but toning it down a little might be nice…

W

[0]: Just on principle...

--
What our ancestors would really be thinking, if they were alive today, is: "Why is it so dark in here?"

    -- (Terry Pratchett, Pyramids)

---

From: Chris Wright <[email-masked]>
Date: Mon, 23 Jul 2012 11:44:33 +1000

Thanks Warren

Comments below.

On 23/07/12 11:13 AM, "Warren Kumari" <[email-masked]> wrote:

>
>Please sir, how does an app know that the DNS lookups were "done via
>DNSSEC"? In the real world? From <insert favorite language here>? (This
>isn't really specific to the helper discussionŠ)

If the app is not willing to trust its local resolver then it can retrieve
the DNS records from the DNS directly itself. Yes this is problematic as
the app will need to have the root public key embedded in it, and then be
updated when it changes, but its not impossible. This begs the larger
question about whats the point of DNSSEC at all if this is really a
problem? Given that DNSSEC came from the IETF, when we are producing new
protocols we probably should be advocating the use of DNSSEC to help
encouraging adoption?

I guess its good that we can offer a client the option of putting in the
work and remaining 'secure', but it still works if they don't have to.
However as John has pointed out it is possible to achieve end to end
security by requiring that the CNAME record be accessed over HTTPs and if
we are prepared to accept that the security argument for one way or the
other comes off the table.

>
>Ok, I'll weigh in -- as much as I dislike agreeing with John[0], I too
>believe that having this easy to do in Javascript (and php and vbscript
>and  rexx and asp andŠ) is really important.

Great, thanks for weighing in, its good to see that there is more support
for one way over another (regardless of which way that is). For the record
though:

Php = dns_get_record -
http://us2.php.net/manual/en/function.dns-get-record.php
Vbscript and ASP/ASP.net can load objects using windows com object model,
there are many many com DNS objects around

>
>No, but toning it down a little might be niceŠ

Understood, I will attempt to be 'nicer' in my emails, for the record
though, nothing in my emails is meant to be attacking or negative towards
anyone in any way and I apologise if any one has taken it as such. I am
simply eager to understands others views and getting them to backup the
assertions they are making. I will look over past emails and see where I
have gone wrong here. If you could help me out by pointing out to me the
emails of concern to me would be appreciated.

---

From: Warren Kumari <[email-masked]>
Date: Sun, 22 Jul 2012 22:16:02 -0400

I started writing this as an [off-list], but then realized an on-list response is probably more appropriate...

> protocols we probably should be advocating the use of DNSSEC to help

Yes, yes we should, but at the moment, there (unfortunately) isn't a good (generic) way of apps to *know* if the response was DNSSEC validated, even if they trust their browser… There *is* work underway in various places to try fix this issue by exposing / defining a standard API...

> other comes off the table.

Ok.
> there are many many com DNS objects around

Ok, also fair 'nuff -- obviously enough I'm not a php / vbscript person (for which I thank the good lord every day!), I'm a python / c person.

> emails of concern to me would be appreciated.

Ok -- I found the bit just above where I inserted this to be snotty / passive aggressive… but then again, I was writing this while sitting on a plane with a *really* annoying seatmate who kept leaning over to look at my screen, bumping my armrest and explaining his views on politics, so it is more than possible that I was being overly sensitive… 
<we can now hug and make up>.

W

--
Life is a concentration camp.  You're stuck here and there's no way out and you can only rage impotently against your persecutors.
                -- Woody Allen

---

From: Chris Wright <[email-masked]>
Date: Mon, 23 Jul 2012 15:20:07 +1000

All,

This is my last email on this subject (applause I am sure), and I am attempting to be as clear and concise as possible. I will happily continue to discuss any of this with anyone off list should you want.

John has asserted that there will be more clients than servers and thus the principal should be to do what is better for clients rather than servers. In principal I have no issue with this sentiment.

Obviously I am speaking as a domain name Registry and we are directly affected by the bootstrapping processes. For now I am ignoring the IP address registry side of things, as if the bootstrap process for the two is not consistent I don’t think it is a big deal (and others have said as much as well).

As far as I can tell there are two potential solutions for domain name bootstrapping on the table at the moment that make sense:

weirds-server.<tld> [SRV|NATPR] XXXXXXX

or

weirds-server.<tld> [A|AAAA|CNAME|NS] XXXXXXXX

John and I have continued a discussion off list, and he has convinced me of the following:

- a secure bootstrap can be implemented in both models
- the SSL certificate per IP addresses issue is solved in principal by Server Name Indication (RFC6066) (more on this below)

So this leaves me with the following comments for others to consider:

- there is no client implementation issue with using SRV or NAPTR records:
For javascript running in the browser, the client can call back to the server where it got the javascript code to run in the first place - there is no security or any other issue with this - for those interested I can send you proof of this. For server side javascript use (which was what was bought up to me as the 'other' javascript reason why we can't do this), most if not all server-side javascript implementations are adding scripting support to other languages and thus can make calls out to that underlying language without issue. Node.js (the only standalone javascript framework I could find) has socket based APIs and DNS based APIs built into it. There is no limitation of the Javascript language that makes implementing a SRV or NAPTR lookup impossible (or even difficult).

There was an issue raised that you can't do DNS lookups in other languages, but this is also incorrect for all examples raised to date, and further to this, what is the relevance - if there was only one language where we could do DNS lookups then yes requiring a DNS lookup would be problematic, but it seems that for every major programming language out there, DNS lookups are not an issue. Writing a WEIRDS client in HASKEL or PROLOG will be difficult at best, and maybe not even possible, but if I were to suggest we bring those constraints onto our protocol development you would all, rightly so, laugh at me and tell me to sod off.

Next, if we are to consider in browser executing javascript as an issue, most of your authentication mechanisms are not going to be straight forward if possible at all. So the in browser javascript client will generally only be able to do unauthenticated lookups, which means most more than basically useful clients will need to be written in other languages anyway. Currently we are discussing making a design trade off decision about our protocol on a very limited data set (one which I'm wondering how it was collected in the first place - another conversation for off list), there is no real evidence that once WEIRDS is in widespread use that Javascript will be the language of choice for implementing a real client, I will assert that people will write clients in Java, C/C++, Perl and PHP at least.

- there is a real operational issue encountered by forcing registries responsible for operating multiple TLDs to need to support an SSL site (and corresponding certificate) for each TLD it operates
Yes arguably it is manageable, but if we have a way to not have to incur this risk then why make us? If there is a justifiable reason for me to have to do this, then so be it I will do it, but the Javascript reason is pure fiction (I have presented much evidence to this fact (contact me off list and I will send you more if required) - no one has presented any evidence proving otherwise) and this is the bases of my problem. I am all for making things better for clients and servers taking on more responsibility, however only when justified. Operationally forcing me to do this means a larger number of certificates to manage and renew (more things to go wrong) and it will be actually forcing me to move away from Java (that’s right Java) or eat lots of IPs! Currently the only java application container I can find that supports Server Name Indication (RFC6066) is the latest version of Tomcat and even then only when running on Java 7. Now there are many organisations (ours included) who won't use Java7 in production just yet until it demonstrates itself to be stable, and who have large applications (registries) that use different Java application containers that don’t support the required SNI technology yet. Granted this is our problem to solve, and I will solve it if I need to, but I am not seeing the reason yet why you are forcing me to solve it.

- the SRV/NAPTR approach is simply more flexible
 nuff said - it simply is

So that’s it, I ask you all to consider these things and speak up one way or the other, I will live with the A/AAAA/CNAME/NS solution if people truly believe it is justified, but I for one can't see how, and encourage those others on the list that will be affected by that decision to speak up.

Happy to discuss further with anyone off list.

Thanks

Chris

---

From: Andy Newton <[email-masked]>
Date: Mon, 23 Jul 2012 17:01:49 +0000

> - a secure bootstrap can be implemented in both models

I think this is true. However, I want to push back against the notion that ALL interactions have to be secured. Certainly we should support it, but if people wish to do lookups insecurely that should be their option. We've been running our service now for over two years and in that time have never received a request to do it over HTTPS.

> - there is no client implementation issue with using SRV or NAPTR records:

And there is nothing stopping us from forcing clients to implement DNSSEC or X.509 DER parsing or the necessary crypto or any of that. But just because we can does not mean we should. Reducing complexity of the clients is paramount.

> For javascript running in the browser, the client can call back to the server where it got the javascript code to run in the first place - there is no security or any other issue with this - for those interested I can send you proof of this.

This sounds reasonable to me, btw. And it maybe the difference between what has been called a centralized redirector and a helper in these threads. If you dynamically execute code from a website, then you are already dependent on that website and there is no extra security issue with trusting them for help in the bootstrap.

It should also be noted that from a client complexity point of view, a helper site means that bootstrapping is no different than simply following redirects and therefore it reduces client complexity.

> Currently the only java application container I can find that supports Server Name Indication (RFC6066) is the latest version of Tomcat and even then only when running on Java 7.

This is an aside, but I'd think using Apache httpd to front your Java containers would solve this problem.

> - the SRV/NAPTR approach is simply more flexible

I've yet to hear a reason why SRV/NAPTR is more appropriate than U-NAPTR.

-andy

---

From: "John Levine" <[email-masked]>
Date: 23 Jul 2012 18:52:20 -0000

>I've yet to hear a reason why SRV/NAPTR is more appropriate than U-NAPTR.

Given that some cruddy client libraries still don't support NAPTR, and
that most of the things people are proposing to do for bootstraps can
be done with slightly more CNAME records, I don't understand why we
need NAPTR at all.

R's,
John

PS: When designing a standard, extra flexibility is often a bug.

---

From: Byron Ellacott <[email-masked]>
Date: Tue, 24 Jul 2012 13:42:11 +1000

Hi all,

> be done with slightly more CNAME records, I don't understand why we

There's a trade-off between client complexity for NAPTR, and server complexity to support SNI or manage multiple CA certs.  Both issues are "real" in that someone would have to deal with them.  Both issues are not intractable.  I favour putting the complexity on the server side.  I favour this particularly because adding the processing required to go from a set of NAPTR records fetched, to connecting to the right server, would be as much as or more processing than is required to go from connecting to the right server to having a parsed weirds response in memory.  It would not be a doubling of complexity to support SNI on the server side, nor to manage 100 SSL certs.

I'd like to note that the ability to host web content, including javascript, is different to the ability to host web server scripts; there would be a set of users who could include a weirds script on their page, but not put a DNS resolver service on their web host.  I think this would be a less common issue than just the complexity of processing NAPTRs, but when it is an issue, it's effectively an intractable problem: changing web host providers is a non-solution, IMO.

I'm curious about how strong the perceived need is for channel security, too.  Is it something we should consider mandatory, something that should be optional at service operator discretion, or perhaps related to differential access class needs?

Also, there's a taxonomy invented by ICANN for these services, though they sadly forgot what the first "N" in ICANN stands for.  Rather than weirds.arpa, I would prefer us to use rd-ds.arpa, taking the "DNRD-DS" taxonomy and dropping the "DN" part :-)

  Byron

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 24 Jul 2012 14:19:21 +0200

> I think this is workable and strikes the right balance for the needs of the clients vs. distributed bootstrapping.

What is 'this' in the sentence above: xxx.weirds.arpa of xxx.weirdsservers.net ?

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 24 Jul 2012 14:35:28 +0200

On Jul 20, 2012, at 5:36 AM, John R Levine wrote:

> Two points.  One is that rDNS zones have never had anything in them other than NS, CNAME, and PTR.  You'd hope that nothing strange would happen if you put in other stuff, but I wouldn't want to try it without some significant testing first.

A reverse zone is just a zone with records served by normal DNS servers. The DNS doesn't care about the namespace it coughs up, recursive name servers have no clue about the fact that they query a special-purpose namespace, and applications call libraries that will turn the IP addresses into in-addr.arpa based domain names and query for PTR records.  If there is other information in the zone it will only be served when asked for.

In absence of any clear indication that there is a significant and severely corrupt implementation out there I wouldn't want to dismiss rDNS on this particular ground.

OH, and as a case in point. About a decade ago I was around when a bunch of new records got thrown into the reverse zones served at the RIPE NCC, and while DNS clients need to set a special bit in order to retrieve those records I have not seen on heard any breakage because of the DNSKEY, RRSIG, DS and NSEC RRs that were introduced way back when.

Note that I am not giving a +1, 0, or -1 to rDNS. Only a -1 to your first argument.

--Olaf (no hats)

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 24 Jul 2012 14:20:27 -0000

>From my point of view, it could equally well be either.  If we decide
to bootstrap number queries a different way (e.g., start at your
closest RIR if you don't have a local copy of the IANA table), it
could be weirds.<tld> which would likely make the administration
somewhat easier.

R's,
John

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Wed, 25 Jul 2012 09:26:57 -0400

Hi! see inline:

> I've yet to hear a reason why SRV/NAPTR is more appropriate than U-NAPTR.
In my mind I tend to group NAPTR and U-NAPTR as the same thing :-) But
you're right, U-NAPTR seems to me the perfect match here, since what we
need to specify is actually a mapping {name_resource, number_resource}
-> {uri_weirds_server}.

Cheers!

~Carlos

---

From: Ray Bellis <[email-masked]>
Date: Wed, 25 Jul 2012 13:39:38 +0000

> could be weirds.<tld> which would likely make the administration

That presupposes that weirds.<tld> hasn't already been registered by a normal
registrant.

Ray

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 25 Jul 2012 16:16:10 +0200

> need to specify is actually a mapping {name_resource, number_resource}

The URI RR might even suffice (http://tools.ietf.org/html/draft-faltstrom-uri-06)

Note that the specification of the RR is stable: the code point for the RR TYPE has been allocated already see http://www.iana.org/assignments/dns-parameters

NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 25 Jul 2012 15:33:15 -0000

>That presupposes that weirds.<tld> hasn't already been registered by a normal

Of course it has, in .com, .net, .org, and .info, but I don't think it
would be a big problem to find a name like
whois-information-server.<tld> that we can be reasonably sure is
available across all the TLDs that are likely to implement WEIRDS.

While you're here, how hard would it be to add another 2LD in .UK, with
CNAME or NS records at whois-information-server.uk (or whatever it
is)?

R's,
John

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Wed, 25 Jul 2012 17:38:11 -0300

Hello all, see inline:

> There's a trade-off between client complexity for NAPTR, and server complexity to support SNI or manage multiple CA certs.  Both issues are "real" in that someone would have to deal with them.  Bot…
Agreed!
> I'd like to note that the ability to host web content, including javascript, is different to the ability to host web server scripts; there would be a set of users who could include a weirds script…
It's of course true that you can host JS w/o the ability to run
server-side scripts. However, I'm afraid we are piling restrictions up
upon the bootstrap problem (and maybe others) without a clear direction.
I'm afraid that we could end up here choosing a worse technical solution
in the name of a restriction that ends up being incompatible with other
stuff we decide later on.

Summing it up: I think we need to get our restrictions and border
conditions clear and documented first. Note that I'm NOT taking position
here either for or against Byron's comment here, just making an
observation on the path (I think) we should follow.

IMO, U-NAPTR or URI records (see Olaf's email) plus helpers (local or
3rd party) for those JS-only implementations is a reasonable bootstrap
implementation, but again, in order to decide, we need to get a clear
picture of ALL the restrictions applied to our current problem space.

> I'm curious about how strong the perceived need is for channel security, too.  Is it something we should consider mandatory, something that should be optional at service operator discretion, or per…
IMO there should be a relationship/correspondence between access class
and channel security requirements. The highest access class levels
should probably require not only a server-side cert but a client-side
one as well (which would provide a nice way of implementing / enforcing
Bulk WHOIS agreements, something which is currently are done in kludgy ways)

Lowest access class probably could be server over plain HTTP, with a
protection level similar to current port 43 service (that is, no
protection at all :-) )
> Also, there's a taxonomy invented by ICANN for these services, though they sadly forgot what the first "N" in ICANN stands for.  Rather than weirds.arpa, I would prefer us to use rd-ds.arpa, taking…
Didn't know about that, thanks!
cheers!

~Carlos

---

From: Chris Wright <[email-masked]>
Date: Thu, 26 Jul 2012 11:04:02 +1000

I know I said I wasn’t going to comment on this anymore, but one more very important thing occurred to me last night that I think is worth sharing with all. I remembered that we already have an SRV record in the .au zone to support this very thing. There is precedent for what is being discussed already, now granted it’s not an RFC, but it is a convention that many have adopted (I haven’t searched all TLDs just checked the ones referenced in the article below).

# dig +short -t SRV _nicname._tcp.{au,at,dk,fr,de,hu,ie,li,lu,no,re,si,se,ch,uk}
0 0 43 whois.ausregistry.com.au.
10 0 43 whois.nic.at.
0 0 43 whois.dk-hostmaster.dk.
0 0 43 whois.nic.fr.
0 0 43 whois.denic.de.
0 0 43 whois.nic.hu.
10 0 43 whois.domainregistry.ie.
0 1 43 whois.nic.ch.
0 0 43 whois.dns.lu.
0 0 43 whois.norid.no.
0 0 43 whois.nic.re.
10 0 43 whois.arnes.si.
0 0 43 whois.nic-se.se.
0 1 43 whois.nic.ch.
0 0 43 whois.nic.uk.

See here for more information:

http://blog.nominet.org.uk/tech/2007/04/17/_nicname-srv-record/

So we can talk about whether it should be an SRV or a NAPTR/U-NAPTR record and the pros and cons of those, but I think it is clear that looking up the location of the WhoIs (or indeed the WhoIs replacement service) in the DNS is not unprecedented.

Thanks

c.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Carlos Martinez-Cagnazzo
Sent: Thursday, 26 July 2012 6:38 AM
To: Byron Ellacott
Cc: [email-masked]
Subject: Re: [weirds] the bootstrap problem, Redirection in the RESTful WHOIS world

Hello all, see inline:

Hi all,

nuff said - it simply is

need NAPTR at all.

I'd like to note that the ability to host web content, including javascript, is different to the ability to host web server scripts; there would be a set of users who could include a weirds script on their page, but not put a DNS resolver service on their web host.  I think this would be a less common issue than just the complexity of processing NAPTRs, but when it is an issue, it's effectively an intractable problem: changing web host providers is a non-solution, IMO.
It's of course true that you can host JS w/o the ability to run server-side scripts. However, I'm afraid we are piling restrictions up upon the bootstrap problem (and maybe others) without a clear direction. I'm afraid that we could end up here choosing a worse technical solution in the name of a restriction that ends up being incompatible with other stuff we decide later on.

Summing it up: I think we need to get our restrictions and border conditions clear and documented first. Note that I'm NOT taking position here either for or against Byron's comment here, just making an observation on the path (I think) we should follow.

IMO, U-NAPTR or URI records (see Olaf's email) plus helpers (local or 3rd party) for those JS-only implementations is a reasonable bootstrap implementation, but again, in order to decide, we need to get a clear picture of ALL the restrictions applied to our current problem space.

I'm curious about how strong the perceived need is for channel security, too.  Is it something we should consider mandatory, something that should be optional at service operator discretion, or perhaps related to differential access class needs?
IMO there should be a relationship/correspondence between access class and channel security requirements. The highest access class levels should probably require not only a server-side cert but a client-side one as well (which would provide a nice way of implementing / enforcing Bulk WHOIS agreements, something which is currently are done in kludgy ways)

Lowest access class probably could be server over plain HTTP, with a protection level similar to current port 43 service (that is, no protection at all :-) )

  Byron
cheers!

~Carlos

weirds mailing list

[email-masked]<mailto:[email-masked]>

---

From: "John Levine" <[email-masked]>
Date: 26 Jul 2012 04:01:59 -0000

Since some data is generally better than no data, I did a quick survey
of TLD SRV records.

There are currently 314 TLDs in the root.

Of those, 36 have SRV records at _nicname._tcp.<tld>.  One (.gr)
points nowhere, presumably because they don't have WHOIS, the other 35
refer to port 43 on hosts whose names look like WHOIS servers.

268 return NXDOMAIN, meaning they publish nothing at that name.

The surprising part is that 9 returned NOERROR, meaning there
is something other than a SRV record there.  Eight of those
nine (kr, mp, ph, st, sy, tk, to, ws) have an A record.

The ones with A are wildcards: kr, ph, st, sy, tk, to.  *.mp is not a
wildcard, but *.<random string>.mp is.  Go figure.

One, _nicname._tcp.mil, returns NOERROR to every query I give it,
suggesting there may be some name defined below that, but it's not
a wildcard.

The award for the most creative misuse of the DNS goes to
Vietnam:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20716
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 4

;; QUESTION SECTION:
;_nicname._tcp.vn.		IN	A

;; ANSWER SECTION:
_nicname._tcp.vn.	53	IN	CNAME	wildcard.vnnic.net.vn.
wildcard.vnnic.net.vn.	42461	IN	A	203.162.57.28

;; AUTHORITY SECTION:
vnnic.net.vn.		42461	IN	NS	dns2.vnnic.net.vn.
vnnic.net.vn.		42461	IN	NS	dns3.vnnic.net.vn.
vnnic.net.vn.		42461	IN	NS	dns4.vnnic.net.vn.

;; ADDITIONAL SECTION:
dns2.vnnic.net.vn.	2861	IN	A	203.119.8.108
dns3.vnnic.net.vn.	42461	IN	A	203.119.36.107
dns4.vnnic.net.vn.	42461	IN	A	203.119.8.70
dns4.vnnic.net.vn.	42461	IN	AAAA	2001:dc8:5::70

Turns out that there's also a wildcard at *.vn.

So SRV records aren't unused, but they aren't exactly well-established
or consistently published, either.

R's,
John

---

From: Dmitry Kohmanyuk <[email-masked]>
Date: Thu, 26 Jul 2012 11:24:01 +0300

> available across all the TLDs that are likely to implement WEIRDS.

this is not a good way to do it -- first, not all TLDs allow addition of arbitrary names just like that
(for example, some allow only third-level registrations, e.g. company.{com,org}.tld).

Moreover, even if TLD has no problem reserving such a name, there is a always (slight) possibility
of squatting the name just for purpose of exerting money.  Getting the message across to 300+ TLDs
would also be difficult (with more coming by next year if ICANN executes on their strategy.)

Therefore I proposed name with underscores in it, similar to SRV records for whois some TLDs have.

This may be not the best idea, but I suggest we do not pick any "magic" names - either reserved namespace
under .arpa.  SRV record for TLD itself would also work (or NAPTR record, or URI record.)  

> CNAME or NS records at whois-information-server.uk (or whatever it

What if <some country> government have to approve any "special" subdomain creation?

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Thu, 26 Jul 2012 12:27:52 -0300

Personally I love the idea of having all 'special purpose' or 'system'
domains kind of 'hidden' under '.arpa'. I'd rather have IANA delegate
weirds.arpa or host it themselves than us going around registering
domains under .com or any other general purpose {g,cc}TLD.

Again, thats IMO only.

cheers,

~Carlos

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 26 Jul 2012 18:36:11 +0200

Not sure on subject: "REST-pect-ful" vs "Redirection in the RESTful
WHOIS world".

On Wed 25/Jul/2012 22:38:11 +0200 Carlos Martinez-Cagnazzo wrote:
>> I'm curious about how strong the perceived need is for channel
>> security, too.  Is it something we should consider mandatory,
>> something that should be optional at service operator discretion,
>> or perhaps related to differential access class needs?
>
> one as well (which would provide a nice way of implementing /
> enforcing Bulk WHOIS agreements, something which is currently are done
> in kludgy ways)
> 

+1, TCP's triple handshake is enough of a protection.  For people
seeking an abuse-mailbox, which can often be done with a single DNS
query, it may be overkill already.

---

From: "John Levine" <[email-masked]>
Date: 26 Jul 2012 22:13:57 -0000

>(for example, some allow only third-level registrations, e.g. company.{com,org}.tld).

But it isn't a registration, it's part of a service.

>under .arpa.  SRV record for TLD itself would also work (or NAPTR record, or URI record.)  

That's not how SRV records work.  They have prefixes, it would be _nicname._tcp.<tld>.

If it's a problem to add a name for whois-information-server.<tld>, I expect the SRV name
would be just as bad.

>What if <some country> government have to approve any "special" subdomain creation?

I assume that means it might take a while before you could publish
your CNAME.  If it's a widespread problem, we could revisit
<tld>.WEIRDS.ARPA, but that has its own administrative issues.

We have over 300 TLDs managed by over 200 different entities.
Anything we do will cause some administrative problem for someone.  My
goal, at least, is to minimize the problems for WEIRDS clients, which
will vastly outnumber WEIRDS servers, and be technically
straightforward for servers to implement.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 26 Jul 2012 22:17:12 -0000

>domains under .com or any other general purpose {g,cc}TLD.

One concern is that if your WEIRDS server supports SSL, which it
probably would, then IANA would have to be involved in any request for
an SSL cert for <TLD>.WEIRDS.ARPA or whatever.  It might be just
validation requests from random SSL vendors as they go by, or it could mean
that they buy or issue the SSL certs on behalf of the TLDs.

If that were the case, do you think it would be a problem for the TLDs
you're familiar with?

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 27 Jul 2012 09:52:42 +0200

On Fri 27/Jul/2012 00:13:57 +0200 John Levine wrote:
> 
> If it's a problem to add a name for whois-information-server.<tld>,
> I expect the SRV name would be just as bad.
> 

As a prospect user of such service, I would prefer the .ARPA
alternative.  However trusty TLD operators may be, IANA is seen as the
global authority on such issues, the most trustworthy of all.

In this respect, it would be a valuable source of order if IANA signed
SSL certificates to TLD operators.  Having the CA flag set on such
certificates would enable them to certificate their clients in turn.
That is to say, it would make more sense if the entities who issue
domain names also certify them, rather than the opposite way around.

Could such activity yield the income to operate WEIRDS servers?

> Anything we do will cause some administrative problem for someone.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 27 Jul 2012 12:39:15 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alessandro Vesely
> Sent: Friday, July 27, 2012 3:53 AM
> To: [email-masked]

[snip]

> domain names also certify them, rather than the opposite way around.

Whole companies have been formed to provide CA services. It might be a stretch for IANA to do it unless the scope is limited.

Scott

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Fri, 27 Jul 2012 10:23:07 -0300

I like the idea of IANA issuing SSL certs only for limited purposes, and
with the CA bit on. I think this ties nicely with some concerns raised
earlier in this thread about the proliferation of potentially hundreds
of certs for multiple-domain registrars.

IANA already has been issuing certs for limited/specific purposes, so
this won't represent a huge leap into the unknown for them.

~Carlos

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 27 Jul 2012 09:27:25 -0400

On Fri, Jul 27, 2012 at 10:23:07AM -0300, Carlos Martinez-Cagnazzo wrote:
> with the CA bit on. 

I don't think a protocol-development working group should go so deep
into the weeds of IANA operations.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Fri, 27 Jul 2012 10:43:40 -0300

Definitely not. But we can toy with the idea and if we think it has
merit, then have it processed through the appropriate channels.

~carlos

---

From: "John Levine" <[email-masked]>
Date: 27 Jul 2012 17:48:45 -0000

>SSL certificates to TLD operators.

Since IANA's signing cert is unlikely to be in the list in anyone's
browser, this strikes me as an impressively user-hostile suggestion.

Technically, signging SSL certs is trivial.  (If you'd like your cert
signed by the extremely reputable Network Abuse Clearinghouse
authority, just ask.)  In practice, if your cert isn't in people's
browsers, it's worse than useless.

R's,
John