Subject: [regext] Using RDAP as a Domain Availability Service

From: Andrew Newton <[email-masked]>
Date: Fri, 16 Dec 2016 06:34:41 -0500

This topic keeps appearing over and over again, so Marcos and I
decided to address it.
As it turns out, there's not much needed to achieve this. This draft
suggests two new query parameters and re-uses the current RDAP domain
query. In other words, its a very small addition to RDAP.

-andy

A new version of I-D, draft-newton-regext-rdap-domain-availability-00.txt
has been successfully submitted by Andrew Lee Newton and posted to the
IETF repository.

Name: draft-newton-regext-rdap-domain-availability
Revision: 00
Title: Using RDAP as a Domain Availability Service
Document date: 2016-12-16
Group: Individual Submission
Pages: 6
URL:
https://www.ietf.org/internet-drafts/draft-newton-regext-rdap-domain-availability-00.txt
Status:
https://datatracker.ietf.org/doc/draft-newton-regext-rdap-domain-availability/
Htmlized:
https://tools.ietf.org/html/draft-newton-regext-rdap-domain-availability-00

Abstract:
  This document describes a minimal profile of RDAP which can be used
  to check the availability of domain names available for registration.

---

From: Michele Neylon - Blacknight <[email-masked]>
Date: Fri, 16 Dec 2016 11:40:06 +0000

Sorry, but why would RDAP be used for this?

I know that whois is used by a lot of people for this, but it really shouldn’t be. Only a direct EPP query to the registry can give a “sane” response. 

What am I missing?

Regards

Michele

--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
http://www.blacknight.host/
http://blacknight.blog/
http://www.blacknight.press - get our latest news & media coverage
http://www.technology.ie
Intl. +353 (0) 59  9183072
Direct Dial: +353 (0)59 9183090
Social: http://mneylon.social
Random Stuff: http://michele.irish 
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,R93 X265,Ireland  Company No.: 370845

On 16/12/2016, 11:34, "regext on behalf of Andrew Newton" <[email-masked] on behalf of [email-masked]> wrote:

    -andy

    Abstract:
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: Jonas Brømsø Nielsen <[email-masked]>
Date: Fri, 16 Dec 2016 11:56:26 +0000

Hello,

I do not see why RDAP should not be taken into consideration for this?

We have implemented a DAS service by request from registrars since this was pointed out to us as a de facto standard.

The service is implemented as a basic proprietary RESTful interface (https://github.com/DK-Hostmaster/das-service-specification <https://github.com/DK-Hostmaster/das-service-specification>).

The results rendered here are just the same as would be reflected if your would inquire via EPP, WHOIS or any other service we offer, the only variations are the amounts of data and the protocols.

IMHO a RDAP implementation of this would be most welcome so registrars could use a standardised protocol instead of variations like the one we implemented.

jonasbn

> On 16 Dec 2016, at 12:40, Michele Neylon - Blacknight <[email-masked]> wrote:
> 

Med venlig hilsen,

Jonas B. Nielsen
Product Manager

DK Hostmaster A/S
Kalvebod Brygge 45, 3. sal
DK-1560 København V

+45 3364 6060 • +45 3154 6056 • [email-masked] <mailto:[email-masked]> • www.dk-hostmaster.dk <http://www.dk-hostmaster.dk/>

This is an email from DIFO/ DK Hostmaster A/S. This message may contain confidential information and is intended solely for the use of the intended addressee. If you are not the intended addressee, please notify the sender immediately and delete this e-mail from your system.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 16 Dec 2016 06:58:53 -0500

> I know that whois is used by a lot of people for this, but it really shouldn’t be. Only a direct EPP query to the registry can give a “sane” response.

Not to diminish the importance of EPP, because it can be and is used
for this in many scenarios.

That said:
1. not all domain registry / registrar models fall neatly into that EPP scenario
2. not all domain registries run EPP
3. even in models where EPP is used, access to a domain availability
service is often needed outside the context of EPP for actors who do
not have access to EPP
4. this allows a domain availability service to be directly embedded
into browser-based applications, which is not possible with EPP.

This topic keeps resurfacing indicating there is a desire for it. The
original WEIRDS working group did discuss it but the working group
decided to keep the focus of the narrowly scoped to achieve delivery
of their promised milestones.

-andy

---

From: Michele Neylon - Blacknight <[email-masked]>
Date: Fri, 16 Dec 2016 12:06:56 +0000

Andrew

I can understand that it *might* suit some ccTLDs to do this, though even then I’m not 100% convinced that it’s a good idea.

The reason  behind my opposition to this  this is pretty simple. If someone has the expectation that a lookup is definitive when it actually isn’t it will cause headaches and more often than not it’s us the registrars who have to deal with the fallout.

While *some* ccTLDs have no reserved names, premium names, banned strings or any other limitations, most have. Unfortunately there is zero consistency in how this is implemented. 

And obviously in the gTLD space this is just as bad and probably worse.

My concern is that while technically a protocol might be able to do something I’d hate to see people assuming that just because it was “possible” it had been implemented fully and properly.

Regards

Michele

On 16/12/2016, 11:58, "Andrew Newton" <[email-masked]> wrote:

    
    That said:

    -andy

---

From: Rubens Kuhl <[email-masked]>
Date: Fri, 16 Dec 2016 10:34:21 -0200

Besides the concerns already mentioned by Michele, I add that using a TCP+TLS based mechanism adds latency that is not the best friend of a sales pipeline. 
When this topic last appeared I suggested considering DTLS transport and I repeat that suggestion, adding that an availability protocol should be less verbose than RDAP in order to not add network latency to the problem. 

Rubens

> On Dec 16, 2016, at 9:34 AM, Andrew Newton <[email-masked]> wrote:
>

---

From: Dave Piscitello <[email-masked]>
Date: Fri, 16 Dec 2016 12:44:28 +0000

> On Dec 16, 2016, at 6:40 AM, Michele Neylon - Blacknight <[email-masked]> wrote:
> 

Can’t anyone implement RDAP, i.e., 3rd party whois services who don’t have EPP?
> I know that whois is used by a lot of people for this, but it really shouldn’t be. Only a direct EPP query to the registry can give a “sane” response. 

Yes. 

Isn’t a possible unintended consequence of using something other than EPP that registries or registrars might see an increase in domain name front running allegations?

> What am I missing?

Hair

---

From: Elmar Knipp <[email-masked]>
Date: Fri, 16 Dec 2016 13:46:03 +0100

We should also keep in mind that the result of an availability check is in
most cases solely dependent on the label itself. But in some cases
additional parameters have to be considered. This depends on the policy
which applies to the TLD.

Let's take for example an IDN TLD which has to deal with variants. A variant
could be only available, if the applicant already has another variant
(policy to avoid consumer confusion). Or if the application is handled by
the same Registrar. See for example the Arabic script for .bazaar
(.بازار.xn--mgbab2bd).

I tend to believe that EPP is the better solution for such cases.

Just my 2 cents,
Elmar

---

From: "Gould, James" <[email-masked]>
Date: Fri, 16 Dec 2016 13:42:25 +0000

+1 

As noted in my prior post on this topic, RDAP is a lookup protocol for what exists.  Logic associated with availability is beyond the scope of a lookup protocol.   Considering that RDAP is a RESTful protocol, anything could be represented with it but the question is whether it should.   I too have heard interest in an availability service that could be discussed, but this should be separated from RDAP.  I view availability via EPP as the best channel for authorized parties to go, since it is authoritative and it includes all the availability business logic.  EPP is a standard, so registries that have chosen not to implement it may not implement another standard either.  

A public availability service would look a lot more like a DNS service than an RDAP lookup service, since it could be a larger dependency for a broader set of real-time clients and therefore needs to be focused on scalability and accuracy (complete set of availability logic) over breadth of lookup features.  It would be great to understand the use cases for a public availability service to define the need prior to making proposals on a solution.    
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com <http://verisigninc.com/> 

On 12/16/16, 6:40 AM, "regext on behalf of Michele Neylon - Blacknight" <[email-masked] on behalf of [email-masked]> wrote:

    
    What am I missing?
    
    Regards
    
    Michele

    
        
        -andy

        Abstract:

---

From: Andrew Newton <[email-masked]>
Date: Fri, 16 Dec 2016 08:48:18 -0500

> When this topic last appeared I suggested considering DTLS transport and I repeat that suggestion, adding that an availability protocol should be less verbose than RDAP in order to not add network…

Rubens,

Both I and the IETF have been down the UDP as a domain availability
service road before. See RFC 5144. Given that it rarely comes up in
these conversations is probably a good indicator that such an idea is
not successful.

While I'm not a DTLS expert by any means, my understanding is that it
is TLS modified for UDP achieved most characteristically with a record
format modified from TLS. That means it still has key exchange, and
therefore the setup is not much more lightweight than TLS itself
(there will be multiple packet exchanges before app data flows). DTLS
benefits protocols where dropped packets have a different tolerance
such as real-time audio or video streaming.

Additionally, if you look at the draft you'll see examples where octet
counts are given. A simple status check can easily fit in a single TCP
packet. Given keep-alive and the bag of tricks achievable with HTTP/2,
I think latency is not much of concern.

I'll give you that it is possible to engineer a UDP/DTLS protocol that
is more performant, but in practice it will be only marginally better
yet orders of magnitude more difficult to implement.

-andy

---

From: Keith Gaughan <[email-masked]>
Date: Fri, 16 Dec 2016 13:59:26 +0000

On 16/12/16 13:42, Gould, James wrote:

> I too have heard interest in an availability service that could be
> discussed, but this should be separated from RDAP.

Agreed. There are many, many problems with using RDAP for this, not
least of which that it's ill suited to bulk queries, which, speaking
from experience on the domain registrar side of things, is an essential
part of any DAS.

If you want a good model for a dedicated DAS protocol, the one Nominet
use[1] is sensible, and, with a few small tweaks[2], could be made
generally useful.

[1]
http://registrars.nominet.uk/namespace/uk/registration-and-domain-management/query-tools/dac/instructions

[2] A greeting to indicate a list of response headers to the client
    would be sufficient.

> I view availability via EPP as the best channel for authorized
> parties to go, since it is authoritative and it includes all the
> availability business logic.  EPP is a standard, so registries that
> have chosen not to implement it may not implement another standard
> either.

There's room for a dedicated DAS protocol. Specifically, a registrar
may wish to allow specific customers or internal services query the
availability of domains without hitting an EPP server directly. This
is what we do internally in Blacknight. A dedicated DAS can have lower
overhead than EPP too.

> A public availability service would look a lot more like a DNS
> service than an RDAP lookup service, since it could be a larger
> dependency for a broader set of real-time clients and therefore needs
> to be focused on scalability and accuracy (complete set of
> availability logic) over breadth of lookup features.  It would be
> great to understand the use cases for a public availability service
> to define the need prior to making proposals on a solution.

K.

-- 
Keith Gaughan, Development Lead; PGP/GPG key ID: D5FC9D23
Blacknight Internet Solutions Ltd. <http://blacknight.host/>
12A Barrowside Business Park, Carlow, R93 X265, Ireland
Registered in Ireland, Company No.: 370845

---

From: Keith Gaughan <[email-masked]>
Date: Fri, 16 Dec 2016 14:23:15 +0000

> these conversations is probably a good indicator that such an idea is

That wasn't successful because DCHK and IRIS aren't worth the pain to
implement, not that the idea isn't essentially sound.

Better would be something akin to Nominet's DAC protocol:

There's no need to over-engineer this stuff: use a persistent connection
and a simple wire protocol capable of pipelining requests to and
responses from the service, and a few custom request types for querying
the status of the connection and doing keep-alive.

K.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 16 Dec 2016 09:42:40 -0500

> http://registrars.nominet.uk/namespace/uk/registration-and-domain-management/query-tools/dac/instructions

Again, the IETF has been there and done that. IRIS was originally
specified using BEEP (see RFC 3983) to achieve the desire you mention
above. BEEP is a multiplexing protocol, and at the time there were a
few libraries that implemented it.

Many people complained, hence RFC 4992.

If there is a lesson to be learned here it is that you shouldn't go
around inventing your own application transports unless you have a
very large community of developers. I don't think this community
counts.

> the status of the connection and doing keep-alive.

I agree. Don't over engineer. Let's use something we know to have been
broadly accepted, and that is HTTP/REST. If you want multiplexing,
using HTTP/2. You're far more likely to find workable implementations
of HTTP/2 than your own custom app-splicing protocol.

-andy

---

From: Keith Gaughan <[email-masked]>
Date: Fri, 16 Dec 2016 16:33:32 +0000

> few libraries that implemented it.

I remember BEEP, and it had the feel of a solution looking for a
problem, even though - late-'90s, early-2000s XML fervour aside - it
was a well-designed protocol framework.

But it was a solution looking for a problem, and it didn't help that
SOAP was around at the time.

> Many people complained, hence RFC 4992.

Here's a question: was BEEP really the problem, or was the problem
really that IRIS itself never got enough traction?

Because if IRIS got any traction, we wouldn't have needed RDAP.

> very large community of developers. I don't think this community

I don't disagree, but the protocol needs to serve the needs of the
community. IRIS/DCHK didn't get traction because the various layers of
it are complex: using it to do domain availability checks was like using
a mallet to swat a fly, and all that implies.

My point is that layering a DAC on top of something like IRIS or RDAP is
overkill and introduces a layer of unnecessary complexity. This was
especially a problem with IRIS because you're dealing with XML, and
there's a good reason JSON got so much traction: XML is a pain to deal
with. In a lot of ways, RDAP is fundamentally IRIS with JSON in place
of XML.

> using HTTP/2.

In 99% of circumstances, I'd agree. This is not one of those, and,
moreover, I don't think plonking it on top of RDAP helps.

The nice thing about Nominet's protocol is that it's trivial to
implement and you get pipelining for free if you want it. While it has
its issues (a way to get a list of field names would be nice, and
headers giving request and response lengths would be preferable to
using CRLF as terminators), it fits its purposes very well.

> You're far more likely to find workable implementations

K.

---

From: "Francisco Obispo" <[email-masked]>
Date: Fri, 16 Dec 2016 08:54:49 -0800

I don’t like having to implement an RDAP client that would have to send two queries.

One to get the domain information, and if the resource does not exist, then another query to see if it’s available.

Checking for a reason on why the domain name is not available could or could not be expensive, but this should not be a reason to disallow it at the ‘presentation’ layer of the protocol.

In my opinion, we should have some OPTIONAL fields in the original negative response to signal whether the name is available or not, and if not, a way to provide a reason. If this is mandated or not by registry policy / contract, it should be a different issue.

regards

—
Francisco Obispo
Uniregistry Inc.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 16 Dec 2016 11:56:34 -0500

On Fri, Dec 16, 2016 at 11:54 AM, Francisco Obispo <[email-masked]>
wrote:

> One to get the domain information, and if the resource does not exist,
> then another query to see if it’s available.
>
>
>
That issue is addressed in the draft with alternate query parameter.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 16 Dec 2016 12:07:28 -0500

> Because if IRIS got any traction, we wouldn't have needed RDAP.

A multiplexing protocol is not trivial to implement correctly.

The problem with IRIS isn't that the XML was hard or the XPC or DCHK
were hard, but the compounded layers simply added to complexity for a
problem that was easily solved with common tools.

> using CRLF as terminators), it fits its purposes very well.

Until you need protocol versioning, extensibility because no two
registries have the same problem, Unicode support, and security...
etc. etc. etc... And pretty soon you've re-invented the wheel.

-andy

---

From: Keith Gaughan <[email-masked]>
Date: Fri, 16 Dec 2016 19:44:13 +0000

> A multiplexing protocol is not trivial to implement correctly.

That's true, but we don't need a multiplexing protocol in this case,
just pipelining. It's a simpler problem.

> problem that was easily solved with common tools.

Agreed, which is the point is was trying to make.

> etc. etc. etc... And pretty soon you've re-invented the wheel.

Not all protocols need all those things. Layering a DAC on top of RDAP
makes the same mistake as layering DCHK on top of IRIS. The use case
here is to check the availability of a domain and do it as quickly as
possible. The constraints of a protocol like that differ from those of
a directory access protocol like RDAP.

The biggest two omissions are that the DAC protocol lacks any kind of
error response, and there needs to be a way for the client to discover
the response field mapping, whether that be that the responses be
self-describing (such as line-delimited JSON documents) or a greeting,
which includes the version and a description of the response. Those are
just two options.

There are other things that need to be covered, such as how fee
information is transmitted and how this interacts with
draft-ietf-regext-epp-fees.

I'm not saying there aren't tonnes of potential issues with Nominet's
DAC protocol, but it's a closer match to the needs of registrars than
RDAP is.

---

From: Rubens Kuhl <[email-masked]>
Date: Fri, 16 Dec 2016 17:49:40 -0200

> DAC protocol, but it's a closer match to the needs of registrars than

I will add that I see the same from a registry view. 

Rubens