Wampum

In a series of related threads on NANOG on the evolution of the Russian Business Network and spammers and their infrastructure, to which someone was kind enough to forward the request below, I mentioned in a footnote (yes, I footnote my technical mail) something to which Suresh commented, and I wrote the note below the below (but above its own footnotes). Here's the footnote, followed by the request, followed by this morning's mini-tutorial on shell registrars sent to NANOG.

...
[1] shell registrars exist for another exploit, to maximize race contention results for the VGRS drop pool, the acquisition of expired names which have "name" value or residual traffic monitization value. Four companies control 318 US domiciled ICANN accreditations: eNom (116), Directi/PDR (47), Dotster (51), and Snapnames (104). Source: http://www.knujon.com/registrars/

Hello,

I need servers to host botnet controller. Botnet controller is software that sends tasks to bots. Bots are hosts which send spam emails to millions of addresses. It's not direct spam but abuses on botnet contoller are received from time to time. What is your policy in case of receiving abuses and what is your policy in case of receiving a lot of abuses? What is policy about spam (not direct from your ips as I mentioned above)? Is it possible to host botnet controller in your datacenter during long-term time?

Thank you.

On 1/2/10 11:38 PM, Suresh Ramasubramanian wrote:
> ... it would be interesting if some process were developed to
> deaccredit or otherwise kill off the shell registrars

Suresh, Why?

ICANN accreditation provides the registrar with a right to attempt OT&E with registries, the Verisign operated .com registry in particular, and with that, the right to specify a range of addresses from which the .com registy EPP server must accept connections.

That is the asset.

Every day "mumble.com" is dropped by the .com registry and every day registrars "race" to register "mumble.com". For some reason "mumble.com" has value not present in "mumble.bar", where "bar" takes on some 20 values other than "com", possibly because "mumble" is a generic or hyphenated concatenation of a generic and some other string, possibly also a generic, possibly because strlen("mumble") is less than 5.

If every registrar has the right to a fixed number of connections, or "threads", at the .com registry, then the probability of acquisition of "mumble.com" is 1/N, where N is the number of registrars competing to register "mumble.com". Note that this might not be sufficient to motivate investment in a "secondary market", in the abstract, however the verisign registry, and others, identified the "secondary market" as having high value and attempted to obtain non-random distribution of secondary registrations.

Therefore, while the value of "threads" was significantly greater than the cost of ICANN accreditation (a subject of note in its own right), it was a rational economic activity to form registrar legal entities, obtain ICANN accreditation, and rent the "threads" to entities which specialized in the "secondary market", that is, in collecting "back orders" on "mumble.com" from entities seeking to become the registrant of "mumble.com", presumably ranked by value (bids at auction), and execution of registrations for "mumble.com" in a race environment.

That's auction to 3pm minus some delta, and race at 3pm minus some epsilon to 3pm plus some epsilon. So, a well-ordered sequence sensor and slots on a roulette wheel. Clearly, the more slots on the roulette wheel, the greater the likelihood of winning.

So, the root cause for shell registrars is the value of expired names, and the association of acquisition resources with accreditation.

Value arises from (a) strings which can be repurposed economically (I claim that should Qualcom forget to renew "q.com" that "q.com" can be repurposed as something other than a domain name for a communications goods and services vendor), and (b) strings which cannot be repurposed economically, but have some fungible value, aka "traffic".

Now, shell registrars are a pain in the ass, not for operational reasons, but because every time someone wants to say something stupid and get away with it they say "[some large number] of registrars".

For example, at the ICANN Seoul meeting an unidentified male (in the transcript) who I recall was Dan Halloran, ICANN's Deputy General Counsel, said, while discussing the proposed new gTLD registry agreement (note, it isn't called a contract):

"... the central idea is still there that ICANN does retain the right to modify the agreement..."

and a minute later

"... the point is there's 900 registrars and ... We don't have to go individually and negotiate bilaterally with each registrar."

Source, transcript [1].

So the number of shell registrars is offered, by ICANN's DGC, and presumably by ICANN's GC (John Jeffrey) as well, as an absolute bar to contractual distinguishment.

Registrars can be "bad" because they fail to pay ICANN (the commonest form of registrar deaccreditation) or because they aren't responsive to email or because they are claimed to be in breech of some specific term in the current accreditation agreement. Other than that, it is ICANN's consistent position of record that registrars cannot be distinguished in contract since the divestiture of Network Solutions (registrar) by Verisign (registry).

Now to me (Eric Brunner-Williams, hat=="operator of ICANN accredited registrar #439 and CTO of ICANN accredited registrar #15 and operator of the sponsored gTLD .cat and .museum" registries for their respective ICANN contracted sponsors), the inability to distinguish, in contract, between an application advanced by the RBN and the IRC is ... a pain in the ass.

CORE's "business" is socially useful, socially responsible registries, its been our business since Jon Postel and others [2] drew up the IAHC-MOU [3], forming CORE. We'd like to see a contract for .com's clones, where "policy" is completely defined by first $6 offered, and a contract for .cat's kittens, where "policy" is consistent with the language in section 3, subsection 2, of RFC 1591.

The IRC contacted CORE (thanks to the ICANN staffer who suggested us to them!) for a .red-{cross,crescent} (Latin and Arabic scripts) but because ICANN won't create contractual constructs now, having done so in the past (the initial 7-10 round was partitioned between what is now called "standard" (biz/info/name/pro) and "sponsored" (aero/coop/museum), and the 2003 round was sponsored), the IRC (and CORE, and all of CORE's other registry partners, from the Provincial Government of Quebec to the Government of the City of Paris) has to wait until ICANN's crafted an evaluation process capable of evaluating every currently imagined scheme the RBN (or any other rational economic actor) puts forward.

Oddly enough, this appears to require unbounded time, and naturally enough, someone on NANOG will opine that one or more of, particularly the last item of this list -- {dnssec, ipv6, idns for ccTLDs, new gTLDs (ADH or IDN)} is "a bad thing". As an Indian, I will simply observe that the partition of Indian Countries into "Canada", "US", ... is suboptimal, and the further partition into "native" namespaces under each of the iso3166 associated namespaces is also suboptimal. We could do better, but even if the nsn.us namespace, to pick one well-ignored example, were turned over to me personally, that wouldn't meet all the needs of two of the three tribes I have cultural and/or political association with, which exist "in" both the United States and Canada. That is, I offer the claim that at least one TLD ought to exist, a claim made to Jon prior to the Green and White Papers. I expect the time from request to delegation will be 20 years, assuming the unbounded time requirement becomes bounded in 5 or so years from the present.

Shell registrars are not, generally, the source of primary registrations of arbitrarily abusive intent. That problem lies elsewhere and is adequately documented.

> .. and the bogus
> LIRs (which is how the thread started).

This has been a tutorial on why shell registrars are not the source of operational issues that could reasonably be characterized as problems. Problematic use of the DNS exists, but the registrar association is otherwise than to shell registrars. These are different exploits.

Eric

[1] http://sel.icann.org/meetings/seoul2009/transcript-gtld-registries-constituency-1-27oct09-en.pdf at pages 32 and 33, respectively.
[2] ISOC, IANA, IAB, FNC, ITU, INTA, WIPO
[3] http://www.gtld-mou.org/