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 alr
Hello Andrew,
On 04/04/2017 21:31, Andrew Newton wrote:
> 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.
While that's true, we should also be aware that e.g. ICANN has been
requiring c
Thomas,
Thanks for the thoughtful response. My comments are in-line:
On Tue, Apr 4, 2017 at 11:59 AM, Thomas Corte wrote:
> Hello Andrew,
>
> On 2017-04-03 20:35, Andrew Newton wrote:
>
>> There's nothing to do about Whois in this case, but RDAP can handle
>> this easily (hence the extension).
>
Hello Andrew,
On 2017-04-03 20:35, Andrew Newton wrote:
> There's nothing to do about Whois in this case, but RDAP can handle
> 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
On Mon, Apr 3, 2017 at 1:07 PM, Thomas Corte wrote:
> 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 cli
, April 03, 2017 1:08 PM
To: regext@ietf.org
Cc: supp...@tango-rs.com
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."
&
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
>
From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Chris Cowherd
Sent: Monday, April 03, 2017 10:26 AM
To: Rubens Kuhl ; Alexander Mayrhofer
Cc: Keith Gaughan ; Registration Protocols Extensions
Subject: [EXTERNAL] Re: [regext] Using RDAP as a Domain Availability Service
Have you
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 wrote:
>
> Em 3 de abr de 2017, à(s) 10:43:000, Alexander Mayrhofer <
> alexander.mayrho...@nic.at> escreveu:
>
> Rubens Kuhl wrote:
>
> .br has
> Em 3 de abr de 2017, à(s) 10:43:000, Alexander Mayrhofer
> escreveu:
>
> 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] Interes
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 so
> Em 3 de abr de 2017, à(s) 10:26:000, Alexander Mayrhofer
> escreveu:
>
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
> >> 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 no
On 16/12/16 22:37, Francisco Obispo wrote:
> For us, RDAP has to cover both use cases. Whether a registry is
> obligated to provide an availability check or reason why the object is
> not available, should be mandated by policy and not in anyway by
> limitations of the protocol.
It might serve a
ttp://verisigninc.com/>
From: Francisco Obispo
Date: Friday, December 16, 2016 at 5:37 PM
To: James Gould
Cc: Andrew Newton , Registration Protocols Extensions
Subject: [EXTERNAL] Re: [regext] Using RDAP as a Domain Availability Service
Hi James,
From what I’ve seen, the expectation is that RDA
Hi James,
From what I’ve seen, the expectation is that RDAP will substitute port 43 WHOIS.
We (uniregistry) currently do availability checks when the domain is not
registered AND we also provide a very specific reason on why a domain is not
available.
Customers also want to know if a specific
>
> 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.
I will add that I see the same from a registry view.
Rubens
___
regext mailing list
rege
On 16/12/16 17:07, Andrew Newton wrote:
> On Fri, Dec 16, 2016 at 11:33 AM, Keith Gaughan wrote:
>>> 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
AM
To: Andrew Newton
Cc: Registration Protocols Extensions
Subject: [EXTERNAL] Re: [regext] Using RDAP as a Domain Availability Service
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
On Fri, Dec 16, 2016 at 11:33 AM, Keith Gaughan wrote:
>> 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.
A multi
On Fri, Dec 16, 2016 at 11:54 AM, Francisco Obispo
wrote:
> 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.
>
>
>
That issue is addresse
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
On 16/12/16 14:42, Andrew Newton wrote:
> On Fri, Dec 16, 2016 at 9:23 AM, Keith Gaughan wrote:
>> On 16/12/16 13:48, Andrew Newton wrote:
>>
>>> 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 co
Keith,
Yes, the DAC service looks interesting; although it would need to be made more
generic. A lightweight protocol that is focused on availability would be
preferred. It would be good to get a list of use cases to understand the need
for such a service.
—
JG
James Gould
Distinguis
On Fri, Dec 16, 2016 at 9:23 AM, Keith Gaughan wrote:
> On 16/12/16 13:48, Andrew Newton wrote:
>
>> 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 s
On 16/12/16 13:48, Andrew Newton wrote:
> 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.
That wasn't successful beca
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
On Fri, Dec 16, 2016 at 7:34 AM, Rubens Kuhl wrote:
>
>
>
> 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
>
+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 t
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 v
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 s
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 h
On Fri, Dec 16, 2016 at 6:40 AM, Michele Neylon - Blacknight
wrote:
> 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?
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-Hostmas
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
35 matches
Mail list logo
