[dns-operations] registry/registrar/registrant delegation checks for fun and profit

George Michaelson ggm at apnic.net
Tue Mar 1 22:24:39 UTC 2016

Running counter to this, and purely for information, It was reported some
while ago that CNNIC employed a few thousand students over a summer holiday
to contact every domain-name holder in the .CN covered namespace and
perform basic ID checks with them.

I could critique the process for its strength, or accuracy, or completeness.

I could critique the process for its social context and political endgame.

But as a proof-by-existence, It *is* actually possible for a motivated,
high scale registry to perform the kind of interactions on its "members" if
thats whats required.

If a registrar "can't do this for commercial/profit reasons" then maybe the
contract for provision of service needs a review?


On 2 March 2016 at 02:41, Jim Reid <jim at rfc1035.com> wrote:

> Mark, your comments on the thread about preventing broken delegations are
> remarkably naive and totally out of touch with the realities of the domain
> name business. What you’re saying is the equivalent of saying world poverty
> can be solved overnight just by giving everyone more money.
> Yes, from a purely technical perspective delegation checks could be done.
> And in some cases, they are done, though usually at registration or renewal
> time. [In between is another story.] However it is beyond impractical to
> expect to apply delegation checks universally.
> It’s a simple matter of economics. GoDadday (to pick one registrar at
> random) probably has a gross margin of a couple of dollars on a TLD domain
> name registration. This would be wiped out if they had to contact someone
> (anyone) to get a delegation error fixed. Even if they’ve outsourced
> customer support to minimum wage droids in Elbonia.
> Contacting the registrant could be a problem too. The end registrant could
> be at the end of a long chain of resellers. If so, good luck traversing
> that chain. Or the registrant could have provided bogus contact data. Yes,
> that sometimes happens... Or the contact data are out of date. And once
> actual contact has been established, good luck getting the registrant to
> take action assuming they even understand the problem.
> Now multiply all of that by many thousands or even millions of broken
> delegations. Then multiply again by some thosands of
> registrars/resellers/control panels, etc, etc. That’s the extent of the
> real world problem space facing your straw-man shell script.
> The technical check itself is easy. It’s just a ~5 line script. But the
> goop that goes around those sorts of checks -- procedures, roles,
> responsibilities, costs, contracts, policies, compliance, customer
> relations, support agreements, etc -- are hard and expensive. Very hard and
> very expensive. You’d know this if you had experience of working at a
> registry or registrar. Or if your day job made you attend CANN meetings.
> If you think broken delegations must be prevented and that registries or
> registrars or resellers or registrants *must* Do Something about this, free
> to submit your proposals to ICANN*. Its policy making machinery is open to
> all. *Other TLD policy-making fora are available.
> BTW the domain name portfolio for many large companies is usually managed
> by its marketing department, often in co-operation with a specialist
> registrar. That big company’s clueful DNS administrators may well have no
> influence at all over how the delegation of example.TLD is handled at the
> registry or how the company’s DNS provider(s) handles the NS RRsets for the
> domain(s).
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160302/e3d24d9f/attachment.html>

More information about the dns-operations mailing list