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

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 3 Apr 2017 13:26:19 +0000

> >> Better would be something akin to Nominet's DAC protocol:
> >>
> >> http://registrars.nominet.uk/namespace/uk/registration-and-domain-
> management/query-tools/dac/instructions
> >

For what it's worth, we (.at) use the "finger" protocol (RFC1288) for a domain availability check:

$ finger [email-masked]
nosuchdomain.at NO domain data found (1)
$ finger [email-masked]
nic.at IS NOT available (1)

Many registrars use it for bulk / near-real-time queries. We don't do a full syntax/policy check, which is the reason for the carefully worded "NO domain data found" response. 

We haver never investigated a UDP based protocol for carrying that information, though COAP comes to my mind as an interesting candidate :)

best,
Ales

---

From: Rubens Kuhl <[email-masked]>
Date: Mon, 3 Apr 2017 10:36:25 -0300

> Em 3 de abr de 2017, à(s) 10:26:000, Alexander Mayrhofer <[email-masked]> escreveu:
> 

.br has run such an UDP-based protocol for almost 10 years... it's called isavail, uses UDP port 43 and implements a session cookie mechanism in order to enforce rate limits. 

Rubens

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 3 Apr 2017 13:43:45 +0000

Rubens Kuhl wrote:
> .br has run such an UDP-based protocol for almost 10 years... it's called
> isavail, uses UDP port 43 and implements a session cookie mechanism in
> order to enforce rate limits.

[OT] Interesting! Do you have a protocol specification available somewhere? I can see there is some code in various languages  at ftp://ftp.registro.br/pub/isavail/ , but it doesn't seem to include a formal spec?

thanks,
Alex

---

From: Rubens Kuhl <[email-masked]>
Date: Mon, 3 Apr 2017 10:47:26 -0300

> Em 3 de abr de 2017, à(s) 10:43:000, Alexander Mayrhofer <[email-masked]> escreveu:
> 
> Rubens Kuhl wrote:

It's described here in an alien language known as Portuguese. ;-)
https://registro.br/tecnologia/Protocolo-ISAVAILv1.txt <https://registro.br/tecnologia/Protocolo-ISAVAILv1.txt>

I don't think it has been described as an I-D. 

Rubens

---

From: Chris Cowherd <[email-masked]>
Date: Mon, 03 Apr 2017 14:25:47 +0000

Have you seen this: https://gist.github.com/case/b979575e2feb1c3810d1

Donuts is considering implementing it
On Mon, Apr 3, 2017 at 6:47 AM Rubens Kuhl <[email-masked]> wrote:

> [OT] Interesting! Do you have a protocol specification available
> somewhere? I can see there is some code in various languages  at
> ftp://ftp.registro.br/pub/isavail/ , but it doesn't seem to include a
> formal spec?
>
>
>
> https://registro.br/tecnologia/Protocolo-ISAVAILv1.txt
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>
-- 
Chris Cowherd, CTO Donuts Inc.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 3 Apr 2017 15:20:21 +0000

From: regext [mailto:[email-masked]] On Behalf Of Chris Cowherd
Sent: Monday, April 03, 2017 10:26 AM
To: Rubens Kuhl <[email-masked]>; Alexander Mayrhofer <[email-masked]>
Cc: Keith Gaughan <[email-masked]>; Registration Protocols Extensions <[email-masked]>
Subject: [EXTERNAL] Re: [regext] Using RDAP as a Domain Availability Service

“However, EPP wasn't designed for high-volume, lightweight availability checking.”

That statement is patently false. It may be that some server implementers constrain clients, but that’s not a protocol limitation. The whole reason the <check> command exists is so that clients can perform high volume, light weight availability checks.

Scott

---

From: Thomas Corte <[email-masked]>
Date: Mon, 3 Apr 2017 20:07:50 +0200

Hello,

On 03/04/2017 17:20, Hollenbeck, Scott wrote:

> That statement is patently false. It may be that some server implementers
> constrain clients, but that’s not a protocol limitation. The whole reason
> the <check> command exists is so that clients can perform high volume,
> light weight availability checks.

Agreed, which is we've consistently advised registrars and customers to
use EPP <domain:check> (rather than the Whois) to implement availability
checks.

The general problem with services such as the Whois or RDAP in this
context is that these services are only suitable for telling which
domains are definitely *unavailable*, but not which ones are available.
There are plenty of cases in which a <domain:check> correctly yields
avail="false" but Whois or RDAP services return "not found" results,
which are easily misinterpreted as "domain available".

Whois/RDAP are services for obtaining information about existing domains,
not about availability. I believe that any attempt to add availability
check capability to these services violates the "separation of concerns"
principle.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: [email-masked]
Germany

---

From: Jody Kolker <[email-masked]>
Date: Mon, 3 Apr 2017 18:29:58 +0000

+1

Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall ([email-masked]) with any feedback.

This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of Thomas Corte
Sent: Monday, April 03, 2017 1:08 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [regext] Using RDAP as a Domain Availability Service

Hello,

On 03/04/2017 17:20, Hollenbeck, Scott wrote:

> "However, EPP wasn't designed for high-volume, lightweight 
> availability checking."
> 
> That statement is patently false. It may be that some server 
> implementers constrain clients, but that's not a protocol limitation. 
> The whole reason the <check> command exists is so that clients can 
> perform high volume, light weight availability checks.

Agreed, which is we've consistently advised registrars and customers to use EPP <domain:check> (rather than the Whois) to implement availability checks.

The general problem with services such as the Whois or RDAP in this context is that these services are only suitable for telling which domains are definitely *unavailable*, but not which ones are available.
There are plenty of cases in which a <domain:check> correctly yields avail="false" but Whois or RDAP services return "not found" results, which are easily misinterpreted as "domain available".

Whois/RDAP are services for obtaining information about existing domains, not about availability. I believe that any attempt to add availability check capability to these services violates the "separation of concerns"
principle.

Best regards,

Thomas

---

From: Andrew Newton <[email-masked]>
Date: Mon, 3 Apr 2017 13:35:47 -0500

> use EPP <domain:check> (rather than the Whois) to implement availability

There aren't certainly use cases where EPP is the right solution here,
especially in registry/registrar models where the registrar has a
piece of the information influencing availability.

> which are easily misinterpreted as "domain available".

There's nothing to do about Whois in this case, but RDAP can handle
this easily (hence the extension).

> check capability to these services violates the "separation of concerns"

Availability is information about the domain, so it falls neatly in the concern.

-andy

---

From: Thomas Corte <[email-masked]>
Date: Tue, 4 Apr 2017 18:59:50 +0200

Hello Andrew,

> this easily (hence the extension).

While the extension can be briefly specified, its implementation seems
excessively costly to me. To make the availability check work as
described, the RDAP server would have to be equipped with access to the
same (potentially complex) rule/policy engine that governs the principal
availability of domains in the SRS. Such an engine is usually not just
defined by a static configuration, but by a dynamic system involving
database content (such as reserved names list), launch phase setups etc.

I'd assume that many registry systems are designed with Whois/RDAP
servers being standalone applications, with their own database,
connected to the main SRS via a lightweight feed mechanism transporting
information about existing objects. Implementing the availability check
in such a setup would require that feed not only to carry repository
objects, but also all data making up the SRS's rule/policy engine.

That's a lot of effort to add a functionality that (at least in my point
of view) is out of scope of RDAP.

Best regards,

Thomas

---

From: Andrew Newton <[email-masked]>
Date: Tue, 4 Apr 2017 14:31:42 -0500

Thomas,

Thanks for the thoughtful response. My comments are in-line:

> database content (such as reserved names list), launch phase setups etc.

I appreciate the complexity some domain registry models may incur, but
all of the issues you mentioned above appear to be extra-protocol. In
other words, those complications would be incurred regardless of EPP
bits on the wire, RDAP bits on the wire, or some other protocol.

I think it is also worth noting that not all TLDs are the same, and
many do not suffer from these issues and hence should not be held back
in this regard.

> of view) is out of scope of RDAP.

Not all registries are architected the same way. There are at least 3
ccTLDs that I am aware of that do have HTTP REST services for domain
availability. I see no reason why they should be forbidden from
seeking a standardized mechanism, even if gTLDs have more complicated
matters.

Additionally, all of the solutions about UDP, EPP, etc... do not have
the ability to be embedded in a web browser. Such an example is what
you can find with https://registro.br . At the top of their page is an
embedded domain check driven by HTTP REST. These are JSON endpoints
such as https://registro.br/ajax/avail/xyz223.com.br and
https://registro.br/ajax/avail/uol.com.br

Standardizing this mechanism would help web page developers, such as
those at resellers and associates,  re-use common libraries and design
patterns. In the end, more domains are sold so one would think those
in the domain selling business would be happy about that.

Finally, I'd like to point out that the same mechanism can be used by
registrars with their resellers where they can offer the RDAP
end-point and tunnel that into EPP to the registry. While that won't
be as efficient as TLDs offering the service directly, as stated
previously such setups may be unavoidable.

-andy

---

From: Thomas Corte <[email-masked]>
Date: Wed, 5 Apr 2017 11:17:00 +0200

Hello Andrew,

> many do not suffer from these issues and hence should not be held back

While that's true, we should also be aware that e.g. ICANN has been
requiring certain RFCs to be implemented by all gTLD operators, and will
probably continue to do so going forward. So it may not be up to the
registry operator whether or not to implement this.
Also, a standard isn't very useful if only a fraction of operators are
likely to implement it.

Best regards,

Thomas

---

From: Jothan Frakes <[email-masked]>
Date: Fri, 7 Apr 2017 16:12:11 -0700

While I would push people towards epp check, having domain availability in
an anycasted zone for DNS queries is so much more lightweight.

We did this in .cc back in 1998

The registry loses the ability to measure which domains are getting looked
up or measure volumes accurately, but registrars already use zonefiles or
cached results and look to alternatives to epp check to speed the process
of responding to customers in order to not lose sales, so that data on
checks is not 100% no matter what.

Check commands are read-only, so this increases resilience and speed.

Smart move, Chris!

-jothan