Subject: [weirds] For a new task: whois abuse-contacts via DNS

From: Alessandro Vesely <[email-masked]>
Date: Wed, 14 Sep 2011 18:02:49 +0200

Hi all,
I just subscribed to this list, with the purpose of putting this question.

Most RIRs are overhauling their whois databases in order to fix abuse
point of contacts.  That includes removing query limits, and possibly
provide "abuse-poc-finder" utilities.  However, they are bound to come
up with five different things, and leave the caching as is.

The question is:  why not have a global domain providing such data
over rDNS queries?  For example,

   dig +short 30.58.22.12.abuse-poc.iana.org txt

That would either return "no record" (3) or the abuse email address,
according to whois information (in ARIN, in this example.)  IANA would
delegate zones of that domain to RIRs, mirroring IP allocations.  Each
RIR would populate its zones according to abuse-mailboxes present in
their whois database, with a suitable TTL.

That would allow full automation of abuse reporting.  Simple and easy,
isn't it?

Ciao
Ale

---

From: "John Levine" <[email-masked]>
Date: 15 Sep 2011 02:45:09 -0000

>   dig +short 30.58.22.12.abuse-poc.iana.org txt

If you can get at least three RIRs to sign up to do this, that would
be great.  If not, we'd just be wasting our time.

R's,
John

---

From: Arturo Servin <[email-masked]>
Date: Thu, 15 Sep 2011 12:04:00 -0300

And probably automation to abuse the system as well.

Regards,
-as

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 15 Sep 2011 17:19:03 +0200

On 15/Sep/11 04:45, John Levine wrote:
> be great.

My Gosh, that seems one of those tasks like finding 50 Righteous in
Sodom...  Wouldn't one RIR be enough, for starting?

I have to start from one anyway.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 15 Sep 2011 17:33:48 +0200

On 15/Sep/11 17:04, Arturo Servin wrote:
>> That would allow full automation of abuse reporting.
> 

I don't think it would make much difference, since those addresses are
already published.  Most of them are red herrings, like abuse@, that
you couldn't hide anyway.

The net effect of the change is the possibility to specify algorithms
for abuse reporting, thus moving it from black art to logical empiricism.

Then, of course, we cannot say that reporting all (or most) spam will
eventually make it cease.  I think trying is the only way to know.

---

From: "Michele Neylon :: Blacknight" <[email-masked]>
Date: Thu, 15 Sep 2011 15:39:03 +0000

There's already an active discussion on abuse objects in RIPE. If that were adopted I'd be happy, as I'm really sick of people sending notifications to me directly - totally ignoring our abuse contact *sigh*

Mr. Michele Neylon
Blacknight
http://Blacknight.tel

Via iPhone so excuse typos and brevity

On 15 Sep 2011, at 17:34, "Alessandro Vesely" <[email-masked]> wrote:

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

---

From: Andy Newton <[email-masked]>
Date: Thu, 15 Sep 2011 16:03:31 +0000

>   dig +short 30.58.22.12.abuse-poc.iana.org txt

This would require RIRs to stand up zones that populate a record for every IP address under their stewardship. Think about how that would work in IPv6?
Special server software would be required that duplicates the IP search functions already found in Whois. There is also the issue of obtaining the Abuse POC for the most specific network vs any of the upstream networks, and the political implications of getting IANA to stand up another zone. Additionally, this would be complex in ERX space.

You could ask that network operators populate their zones with a TXT, but you would still have the problem that not all networks fall neatly on a label boundary.

I think this problem is best left outside of DNS.

-andy

---

From: David Conrad <[email-masked]>
Date: Thu, 15 Sep 2011 09:28:29 -0700

Hi,

On Sep 14, 2011, at 9:02 AM, Alessandro Vesely wrote:
> Most RIRs are overhauling their whois databases in order to fix abuse point of contacts.  

Your registration dollars/euros/etc. at work.

> That includes removing query limits, and possibly

Unfortunately, all too true.

>   dig +short 30.58.22.12.abuse-poc.iana.org txt

Interesting idea, but:

For one thing, I'd recommend using the RP RR, not TXT.
For another, getting the RIRs to do anything in unison appears to be a _major_ undertaking.
For another, associating it with IANA can potentially result in a really unpleasant amount of politics, both ICANN<->RIR as well as ICANN<->US Government.

> That would allow full automation of abuse reporting.  Simple and easy, isn't it?

'Simple and easy', particularly in the context of providing common interfaces to the outside world, doesn't really appear to be a goal of the RIR system.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Thu, 15 Sep 2011 09:30:25 -0700

> 	And probably automation to abuse the system as well.

What sort of abuse are you imagining?  And how would the n (n<=5) different systems based on whois the RIRs are likely going to come up with be able to avoid that abuse?

Regards,
-drc

---

From: Arturo Servin <[email-masked]>
Date: Thu, 15 Sep 2011 13:53:20 -0300

On 15 Sep 2011, at 13:30, David Conrad wrote:

> What sort of abuse are you imagining?  

	Harvesting contact information. Then SPAM, junk mail, marketing, you name it.

> And how would the n (n<=5) different systems based on whois the RIRs are likely going to come up with be able to avoid that abuse?

	So far is rate limiting. Not perfect, not really a great solution that's why we are here, isn't it?

Regards,
-as

---

From: David Conrad <[email-masked]>
Date: Thu, 15 Sep 2011 10:26:26 -0700

> 	So far is rate limiting. Not perfect, not really a great solution that's why we are here, isn't it?

I thought Alessandro said the RIRs were removing rate limiting (and developing special tools) for abuse POCs.

Since abuse contacts must be published in various forms for various reasons, it would seem they are already subject to harvesting for spam.

Regards,
-drc

---

From: Warren Kumari <[email-masked]>
Date: Thu, 15 Sep 2011 16:56:01 -0400

> Since abuse contacts must be published in various forms for various reasons, it would seem they are already subject to harvesting for spam.

And it always confuses me when things like 'abuse@', 'postmaster@', 'root@' and 'spam@' end up on spam lists -- a simple regexp would remove them and seems not self reporting yourself to the abuse folk would be an obvious win...

W

---

From: David Conrad <[email-masked]>
Date: Thu, 15 Sep 2011 14:38:00 -0700

Andy,

> This would require RIRs to stand up zones that populate a record for every IP address under their stewardship. Think about how that would work in IPv6?

Seems to be feasible for in-addr.arpa and ip6.arpa.

> Special server software would be required that duplicates the IP search functions already found in Whois.

Why?  As far as I understand what is being proposed, the idea is to allow for folks to be able to look up an abuse POC given the IP address of somebody being "bad".  Why would one need a search capability?

> There is also the issue of obtaining the Abuse POC for the most specific network vs any of the upstream networks,

This could probably be dealt with by naming conventions, e.g., _parent.10.abuse.<tld> or somesuch.

> and the political implications of getting IANA to stand up another zone.

Indeed.  There are two political complications with using an "IANA zone":

1) figuring out whether it becomes part of the IANA functions contract between ICANN and the U.S. Dept. of Commerce
2) figuring out how to get the RIRs to actually play along.

At least one of these is likely intractable.  However, there are plenty of alternative domains that could be used, e.g., ABUSE-POC.<gtld> or even NRO.NET.

> Additionally, this would be complex in ERX space.

How would it be any more complicated than in-addr.arpa in the ERX space?

> You could ask that network operators populate their zones with a TXT, but you would still have the problem that not all networks fall neatly on a label boundary.

Sorry, not sure what you mean.  Are you saying an RFC 2317-like solution wouldn't work?

> I think this problem is best left outside of DNS.

Perhaps so, but I'm not fully convinced as yet.  In any event, I don't have a strong opinion as to the protocol/mechanism/data model/schema for an abuse POC system.  What I do have a strong opinion on is that we stop having N (1 < N <= 6) _different_ systems that do exactly the same thing.

Regards,
-drc

---

From: Andy Newton <[email-masked]>
Date: Fri, 16 Sep 2011 12:37:46 +0000

> Why?  As far as I understand what is being proposed, the idea is to allow for folks to be able to look up an abuse POC given the IP address of somebody being "bad".  Why would one need a search cap…

Are you suggesting we construct zones with a record for every IP address in use today? Again, how would that work in IPv6? That's why the IP address search function is needed. 

> This could probably be dealt with by naming conventions, e.g., _parent.10.abuse.<tld> or somesuch.

Again, how do you construct a name for parent/child relationship that does not occur at an rDNS label boundary, especially when you do not know where that parent/child relationship occurs?

> How would it be any more complicated than in-addr.arpa in the ERX space?

Again, if you have to formulate an RR for every IP address in use, the ERX processes become unworkable. The RIRs would need to devise a mechanism for synthesis, which is totally unlike how ERX works today.

> Perhaps so, but I'm not fully convinced as yet.  In any event, I don't have a strong opinion as to the protocol/mechanism/data model/schema for an abuse POC system.  What I do have a strong opinion…

Nobody is disagreeing with the need for a common solution. I don't know how you came to the conclusion given that two RIRs have put forward drafts on their implementations and are here to work on this problem. What does seem unworkable is to ask for a special-use mechanism for one use case only and to ignore all the other use cases, especially when that special-use mechanism is unlike all the work that has been put forth in this space. Cooperation is a multi-party endeavor.

-andy

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 16 Sep 2011 15:35:38 +0200

On 15/Sep/11 18:03, Andy Newton wrote:
> This would require RIRs to stand up zones that populate a record
> for every IP address under their stewardship. Think about how that
> would work in IPv6?

IPv6 could be done differently, as it seems less urgent.  There is a
proposal [JL] to avoid cache blasting by forcing clients to discover
the granularity of an IPv6 allocation and then query the correct
range.  That increases the number of queries, but also increases the
likelihood of cache hits.  Alternatively, it could be structured as a
whitelist, like the Dutch [WL] or other IPv6 whitelists.

[JL] http://www.irtf.org/mail-archive/web/asrg/current/msg16434.html
[WL] http://www.ipv6whitelist.eu/

> Special server software would be required that duplicates the IP
> search functions already found in Whois. There is also the issue of
> obtaining the Abuse POC for the most specific network vs any of the
> upstream networks, and the political implications of getting IANA
> to stand up another zone. Additionally, this would be complex in
> ERX space.

As David suggested, IPv4 can strictly mirror the structure of
in-addr.arpa, but getting the TXT record from whois.

> You could ask that network operators populate their zones with a
> TXT, but you would still have the problem that not all networks
> fall neatly on a label boundary.

No, differently than in-addr.arpa, this new zone shouldn't be further
delegated.  This way, one can be sure it faithfully adheres to whois
data.  Manual investigations would continue to use the full, richer
database served by whois, e.g. to check who is the record maintainer,
what is the last update, and the like.

> I think this problem is best left outside of DNS.

As John said, we'd better wait for some RIRs to sign up to (possibly)
do this if we want to talk reality.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 16 Sep 2011 15:46:22 +0200

> For one thing, I'd recommend using the RP RR, not TXT.

RP has a problem with "@".  TXT seems to be the de-facto standard for
this kind of use.

> For another, getting the RIRs to do anything in unison appears to be a _major_ undertaking.

Yes, I'd say _the_ major undertaking.  All practical stuff has to be
done there.

> For another, associating it with IANA can potentially result in a
> really unpleasant amount of politics, both ICANN<->RIR as well as
> ICANN<->US Government.

I thought about IANA because it already coordinates the global IP
number space, besides doing IETF specific assignments.  It would make
sense that they serve directly non-public addresses, like they do for
similar .arpa zones.

>> Simple and easy, isn't it?
> 
> 'Simple and easy', particularly in the context of providing common
> interfaces to the outside world, doesn't really appear to be a goal
> of the RIR system.

I wonder if the NRO is --or should be-- providing any coordination on
this topic.

---

From: Andy Newton <[email-masked]>
Date: Fri, 16 Sep 2011 13:23:01 -0400

On Sep 16, 2011, at 9:35 AM, Alessandro Vesely wrote:

> IPv6 could be done differently, as it seems less urgent.

Finding a solution that works equally well with both IPv4 and IPv6 is preferred.

> what is the last update, and the like.

This would require the synthesis of records for every IP address allocated.
Given that multiple contacts can be attached to a network registration, that could mean multiple records per IP address. (Additionally, the RP record does not help clarify between a contact with multiple email addresses and multiple contacts, nor does it account for phone numbers.)
So even in IPv4 that synthesis could balloon into a large number of unmanageable records.
Again, special DNS server software would be required.

> do this if we want to talk reality.

This problem could be applied simply to the RESTful interfaces that are documented in the drafts that have been circulated on this list.

Using the ARIN interface as an example (but not to suggest that it be a final way), the IP lookups could provide the feature:

  http://whois.arin.net/rest/ip/192.168.0.1/pocs

or more specifically for Abuse contacts

  http://whois.arin.net/rest/ip/192.168.0.1/pocs/abuse

Does that sounds workable?

-andy

---

From: Arturo Servin <[email-masked]>
Date: Fri, 16 Sep 2011 15:14:48 -0300

I think our efforts (at least as individual RIRs and speaking as one) are to work in RESTful services rather than DNS.

	Regarding RESTfull whois I personally see the need for a single or common interface instead of 5. Whether we will come up with one solution or five time will tell.

.as

---

From: "John Levine" <[email-masked]>
Date: 17 Sep 2011 04:16:13 -0000

>Does that sounds workable?

If ARIN were willing to do that, it'd be fine.

I doubt that anyone needs to look up abuse contacts as briskly
as they consult DNSBLs.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 17 Sep 2011 13:10:40 +0200

On 16/Sep/11 14:37, Andy Newton wrote:
> What does seem unworkable is to ask for a special-use mechanism for
> one use case only and to ignore all the other use cases, especially
> when that special-use mechanism is unlike all the work that has
> been put forth in this space.

One aspect where this mechanism differs from other proposals that have
been discussed is its simplicity.  The moment everybody agrees, we can
order any additional hardware right away, gather the software while we
wait for it to arrive, and tah dah!

However, this proposal is not meant to replace any previous work, and
it is not totally unlike it.  The most conspicuous similarity being
the amount of synergism required.  Indeed, as synergy is about /all/
that is required to go, we could regard such DNS way as an acid test
to measure whether this global community is able to cooperate.

RESTful interfaces are being designed to do some more than retrieving
an abuse-poc.  However, we don't think that abuse-poc addresses will
be heavily looked up, as it may not even be worth to fully automate
spam-reporting.  This sounds contradictory to me, what am I missing?

Both interfaces, RESTful and rDNS, are only useful as long as we want
to automate something.  I'm so single-minded to assume that what we
want to automate is related to the spam problem.  Hence, the sooner we
launch automated spam-reporting, the sooner we'll know what else
exactly do we need to do to cope with that.  Right?

The single abuse@ address datum needs to be available free of access
hindrances.  Where policies state that certain occurrences may flag
that datum as non-public, looking it up will return "no such domain".
 Making such a statement would be a relevant leap forward, albeit not
a technical change[*], and may allow to proceed more firmly with the REST.

-- 
[*] `dig +short 30.58.22.12.abuse-contacts.abusix.org txt' can already
be queried (BTW, that's where I'd expect you'll receive this message
from.)

---

From: SM <[email-masked]>
Date: Sat, 17 Sep 2011 10:05:11 -0700

Hi Alessandro,
>wait for it to arrive, and tah dah!

Your requirement is for abuse contact information.  The mechanism you 
proposed looks simple.  draft-kucherawy-weirds-requirements-01 lists 
other data which people find useful.  Your mechanism would not 
support that.  Should the data provider, in this case RIRs, order 
additional hardware and software for each use case?  That seems like 
a waste of resources to me.

There are currently three I-Ds:

   draft-fiorelli-weirds-rws-00
   draft-newton-weirds-arin-whoisrws-00
   draft-sheng-weirds-icann-rws-dnrd-00

ARIN has been taking in some flak as some people prefer legacy Whois 
instead of the REST API.  The vendors, in this case, ARIN, ICANN and 
RIPE, are working on REST mechanisms.  You are proposing a mechanism 
based on DNS.  Standardization is also about solving all that by 
coming up with a common approach.

Regards,
-sm

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 17 Sep 2011 23:50:56 +0200

On 17 September 2011 19:05, SM wrote:

> ARIN has been taking in some flak as some people prefer legacy
> Whois instead of the REST API.  The vendors, in this case, ARIN,
> ICANN and RIPE, are working on REST mechanisms.  You are
> proposing a mechanism based on DNS.

> Standardization is also about solving all that by coming up with
> a common approach.

The whois protocol is ideal for simple scripts.  As long as it
exists I'll use whois.abuse.net for the purposes of my script;
the alternative "capture nslookup output" isn't very attractive.

In other unrelated scripts sending a HTTP GET is simple enough,
but parsing the answer is slightly more convoluted, e.g., if the
server insists on HTTP/1.1 chunking instead of HTTP/1.0 replies.

That would be my € 0,01.  For the second cent, nothing is wrong
with two interfaces (REST + whois) for the same public database;
folks implementing clients can pick whatever they like better.

-Frank

---

From: Andy Newton <[email-masked]>
Date: Sun, 18 Sep 2011 14:02:14 +0000

> If ARIN were willing to do that, it'd be fine.

I'll see what I can do about addressing this.

In the meantime, we need to keep this in mind for a standardized interface.

-andy

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 18 Sep 2011 19:22:24 +0200

On 17/Sep/11 19:05, SM wrote:
>> The moment everybody agrees, we can order any additional hardware
>> right away, gather the software while we wait for it to arrive,
>> and tah dah!
> 
> Your requirement is for abuse contact information.

Yes

> The mechanism you proposed looks simple.

Indeed, it is.  Only the legal aspects of publishing the required
datum might result in some head-scratching, but then that has to be
done anyway.

> draft-kucherawy-weirds-requirements-01 lists other data which
> people find useful.  Your mechanism would not support that.

No, it wouldn't.  You should consider this mechanism just an appetizer
before the main course.

> Should the data provider, in this case RIRs, order additional 
> hardware and software for each use case?

Frankly, I don't know if RIPE, for example, would need an additional
disk, cpu, or both.  Certainly, each added service bears additional costs.

> That seems like a waste of resources to me.

You mean the hardware or the software?

>   draft-sheng-weirds-icann-rws-dnrd-00

Yeah, I had a look at them last spring.  I appreciate that work, but
it didn't really grip me, so I didn't subscribe at the time.  I
changed my mind when I realized that part of its functionality is
requisite for specifying abuse reporting.

> coming up with a common approach.

Discussions about XML vs REST, caches, and access rights don't tend to
give the impression that implementations are arriving any time soon.

Standardization is also solving problems timely, and I don't think it
would hurt to provide this single datum in advance.  We are already
more than a decade late in abuse reporting, if you consider the
automation achievements struck by the other side.

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 18 Sep 2011 19:59:36 +0200

> the alternative "capture nslookup output" isn't very attractive.

Yet, DNS is the one exemplified at http://www.abuse.net/using.phtml

> server insists on HTTP/1.1 chunking instead of HTTP/1.0 replies.

Curl or wget should take care of chunking.  HTTP can also provide for
some caching, via a local proxy.  That's discussed in Andy's draft
http://tools.ietf.org/html/draft-newton-weirds-arin-whoisrws-00#section-5

However, if more specific behavior is needed, it wouldn't be a bad
idea to provide a command line reference client, e.g. implemented
using libcurl.  It could also take care of known differences among
servers.  Moreover, it could take care of locating the right server.

BTW, what is the rationale for having ARIN supply the latter info?
Given that it is not the alphabetical order, it must be either the
physical distance or an historical idiosyncrasy.   Isn't it time to
have IANA do that?

jm2c

---

From: "John Levine" <[email-masked]>
Date: 18 Sep 2011 18:44:36 -0000

>the alternative "capture nslookup output" isn't very attractive.

That's just lousy tools, which isn't the fault of the protocol.  If
you had dnstxt from the djbdns package, it'd give you just the contact
addresses with no junk to strip off.

But for something like contact addresses, I'm less concerned about the
details of the protocol than finding something that there is some
chance that the RIRs will implement.

R's,
John

---

From: SM <[email-masked]>
Date: Sun, 18 Sep 2011 12:30:52 -0700

Hi Alessandro,
>You mean the hardware or the software?

It also requires people and money.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 18 Sep 2011 23:00:45 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Frank Ellermann
> Sent: Saturday, September 17, 2011 2:51 PM
> To: SM
> Cc: [email-masked]
> Subject: Re: [weirds] For a new task: whois abuse-contacts via DNS
> 

Interesting.  I have the opposite perspective: DNS payloads follow a standard format where WHOIS payloads do not.  Thus, I'd rather code to the former than the latter, even if I can rely on whois.abuse.net to give me something in a format I'd expect.  It's not an interoperable solution, because I can't point that client at another WHOIS server and be sure to get the same service.
 
> folks implementing clients can pick whatever they like better.

Except, of course, ongoing costs to the service provider of keeping both up.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 19 Sep 2011 10:56:38 +0200

> It also requires people and money.

So does running a WG.  Assume an acid test provides the ability to
determine the effectiveness of a WG --I mean the practicality of its
specs-- at the price of a couple of disks and a few days programming.
 How would you rate such possibility?

---

From: "Michele Neylon :: Blacknight" <[email-masked]>
Date: Mon, 19 Sep 2011 09:01:40 +0000

On 19 Sep 2011, at 09:56, Alessandro Vesely wrote:

> So does running a WG.  

They're not the same costs and don't have the same expectations

Mr Michele Neylon
Blacknight Solutions ♞
Hosting & Colocation, Brand Protection
ICANN Accredited Registrar
http://www.blacknight.com/
http://blog.blacknight.com/
http://blacknight.biz
http://mneylon.tel
Intl. +353 (0) 59  9183072
US: 213-233-1612 
UK: 0844 484 9361
Locall: 1850 929 929
Direct Dial: +353 (0)59 9183090
Facebook: http://fb.me/blacknight
Twitter: http://twitter.com/mneylon
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow,Ireland  Company No.: 370845

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 19 Sep 2011 14:23:56 +0200

> Interesting.  I have the opposite perspective: DNS payloads follow
> a standard format where WHOIS payloads do not.  Thus, I'd rather
> code to the former than the latter, even if I can rely on
> whois.abuse.net to give me something in a format I'd expect.

Yes, using DNS would be nice in scripting languages supporting it.
That is not directly the case for REXX.  In theory I could create
an "extension" (= DLL) based on exisisting work, but then I'd end
up with a "works for me on NT" solution not working for others
using REXX on various Linux and IBM (incl. OS/2) platforms.

For folks not knowing it:  REXX is in the (former) IBM-community
roughly what perl/awk is in *NIX communities, or what VB/PS is in
the NT community -- maybe, I never tried the new PS = powershell".

I could also try to parse DNS on a binary sockets level directly
in REXX, but when I seriously considered this years ago I found
that it would be an interesting but not a "simple" job.  BTW, the
same script has no trouble to parse DNSBL answers, all the hard
work is hidden in its "get IP" socket interface.  (No IPv6 yet,
but I'm confident that somebody will tackle it sooner or later.
IPv6 and DNSBLs is anyway more on the research side of RFC 5782
and I-D.irtf-asrg-bcp-blacklists.)

>> nothing is wrong with two interfaces (REST + whois) for the
>> same public database; folks implementing clients can pick
>> whatever they like better.

> Except, of course, ongoing costs to the service provider of

"Whois" is also relatively simple on the server side.  As long
it ends up on the MUST-side I have yet no preferences what else
goes into additional SHOULDs.  It would be also fine if the RIRs
and IANA offer 5+1 whois servers based on a "smarter" interface,
where "smarter" means "does not work for all plausible clients".

-Frank

---

From: SM <[email-masked]>
Date: Tue, 20 Sep 2011 01:32:13 -0700

Hi Alessandro,
>  How would you rate such possibility?

I'll pick zero.  WG effectiveness depends on whether everyone derives 
a benefit from the work.  At the moment, the benefit is one sided.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 20 Sep 2011 13:36:04 +0200

> They're not the same costs and don't have the same expectations

A WG consumes a number of man-hours of highly qualified participants,
so I'd guess it costs a lot, while running a DNS server is quite cheap.

As for the expectations, I have no (other) ideas on how to evaluate
the risk that a WG could pause or gradually diminish the amount and
fervor of discussions, and eventually just fade away, leaving
unfinished documents to oblivion.

Indeed, this mailing list was silent for about one month after it had
been surmised that the semantic content of the data is none of IETF's
business.  I plead for the opposite position, that an abuse-contact
email address shall correspond to the mailbox of an abuse team.  We
can also crisply specify what domain names are allowed to appear in
the domain-part of the addresses, what confirmations may be carried
out by the maintainer of the datum, and what periodic checks may be
carried out by the RIR.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Sep 2011 11:17:48 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Tuesday, September 20, 2011 4:36 AM
> To: [email-masked]

The IETF can specify whatever it wants, but there exists no stick that will compel RIRs or anyone to adhere.  It only costs them {money, person-hours} to provide the service to spec, or indeed provide it at all; they get nothing out of it and it doesn't interfere with their ability to operate.  This, in addition to constraining itself from layers eight and nine, is why the IETF likes to stick to protocol rather than stipulating policy: We have no enforcement power.  And at least in my view, ICANN has a very weak track record of being tough on anyone about anything, so they're unlikely to do so either.

The only stick I can think of is the idea that security service companies like anti-{spam, virus, phishing} vendors will default to not trusting domains or networks about which complete WHOIS data is available, and apparently correct.  That will lead to reputation about WHOIS providers (see also the REPUTE WG).  This might compel compliance even in the absence of policy from ICANN.

---

From: "John Levine" <[email-masked]>
Date: 20 Sep 2011 19:09:15 -0000

>  At least in my view, ICANN has a very weak track record of being
>tough on anyone about anything, so they're unlikely to do so either.

ICANN actually has a common WHOIS format for domain registries that's
widely used.  But they have no say at all over the RIRs, so I agree
with you that this whole argument is basically pointless.

R's,
John

---

From: "Michele Neylon :: Blacknight" <[email-masked]>
Date: Tue, 20 Sep 2011 19:19:01 +0000

It only applies to thick registries. There is no standard format for thin - and thin constitutes the lions share of gtlds

Mr. Michele Neylon
Blacknight
http://Blacknight.tel

---

From: "John R. Levine" <[email-masked]>
Date: 20 Sep 2011 15:23:44 -0400

> It only applies to thick registries. There is no standard format for thin - and thin constitutes the lions share of gtlds

You're right, but I gather that Verisign is supposed to transition to 
thick at some point.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Sep 2011 12:24:08 -0700

> From: John Levine [mailto:[email-masked]]
> Sent: Tuesday, September 20, 2011 12:09 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy

Are there penalties for domain registrars not sticking to the common format?

What are the chances of them getting tougher on the RIRs?

---

From: Steve Sheng <[email-masked]>
Date: Tue, 20 Sep 2011 12:25:50 -0700

Hi John, I would like to qualify your points a bit. I think all of these
points Jay Daley and Michele has already raised.

Regarding data formats:
 
- For existing gTLD registries, ICANN specifies the format in registry
agreements somewhat (see appendix 5 of various registry agreements
http://www.icann.org/en/registries/agreements.htm).

- For existing gTLD registrars, ICANN only specify the data elements (see
RAA 3.3.1, http://www.icann.org/en/registrars/ra-agreement-17may01.htm#3),
how those date elements are represented and displayed is up to each
registrar to decide.

- For ccTLD registries, each ccTLD operator sets its own policy regarding
what to display and how to display them in WHOIS.

- For new gTLDs, ICANN require thick registry as well as a common data
format.

Kind regards, 
Steve

---

From: "Michele Neylon :: Blacknight" <[email-masked]>
Date: Tue, 20 Sep 2011 19:27:31 +0000

John

While that might happen they've denied it when asked 

M

Mr. Michele Neylon
Blacknight
http://Blacknight.tel

On 20 Sep 2011, at 21:24, "John R. Levine" <[email-masked]> wrote:

> You're right, but I gather that Verisign is supposed to transition to thick at some point.
> 
> R's,
> John

---

From: "John R. Levine" <[email-masked]>
Date: 20 Sep 2011 15:31:31 -0400

> Are there penalties for domain registrars not sticking to the common format?

Just the standard sanctions for RRA violations, but the thick registries 
all implement the WHOIS format perfectly well so it's never been an issue. 
There's the usual problem that registrants lie, but that's separate from 
the WHOIS format.

> What are the chances of them getting tougher on the RIRs?

Zero.  ICANN has no authority over the RIRs.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 20 Sep 2011 21:34:23 +0200

widely used.

Not really.  There are some common used formats but they differ
wildy by registry (operator), see below the whois output for
example.net and example.org.

To have a common WHOIS format is a desire in ICANN circles.

	jaap

==========================

whois example.net:

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: EXAMPLE.NET
   Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY
   Whois Server: whois.iana.org
   Referral URL: http://res-dom.iana.org
   Name Server: A.IANA-SERVERS.NET
   Name Server: B.IANA-SERVERS.NET
   Status: clientDeleteProhibited
   Status: clientTransferProhibited
   Status: clientUpdateProhibited
   Updated Date: 31-aug-2011
   Creation Date: 31-aug-1995
   Expiration Date: 30-aug-2012

>>> Last update of whois database: Tue, 20 Sep 2011 19:26:53 UTC <<<

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar.  Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.

TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability.  VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

domain:       EXAMPLE.NET

organisation: Internet Assigned Numbers Authority

created:      1992-01-01
source:       IANA

==========================

whois example.org

NOTICE: Access to .ORG WHOIS information is provided to assist persons in
determining the contents of a domain name registration record in the Public Interest Registry
registry database. The data in this record is provided by Public Interest Registry
for informational purposes only, and Public Interest Registry does not guarantee its
accuracy.  This service is intended only for query-based access.  You agree
that you will use this data only for lawful purposes and that, under no
circumstances will you use this data to: (a) allow, enable, or otherwise
support the transmission by e-mail, telephone, or facsimile of mass
unsolicited, commercial advertising or solicitations to entities other than
the data recipient's own existing customers; or (b) enable high volume,
automated, electronic processes that send queries or data to the systems of
Registry Operator or any ICANN-Accredited Registrar, except as reasonably
necessary to register domain names or modify existing registrations.  All
rights reserved. Public Interest Registry reserves the right to modify these terms at any
time. By submitting this query, you agree to abide by this policy.

Domain ID:D2328855-LROR
Domain Name:EXAMPLE.ORG
Created On:31-Aug-1995 04:00:00 UTC
Last Updated On:27-Jul-2010 20:57:51 UTC
Expiration Date:30-Aug-2010 04:00:00 UTC
Sponsoring Registrar:Internet Assigned Numbers Authority (IANA) (R193-LROR)
Status:DELETE PROHIBITED
Status:RENEW PROHIBITED
Status:TRANSFER PROHIBITED
Status:UPDATE PROHIBITED
Registrant ID:IANA
Registrant Name:Internet Assigned Numbers Authority
Registrant Organization:Internet Assigned Numbers Authority (IANA)
Registrant Street1:4676 Admiralty Way
Registrant Street2:Suite 330
Registrant Street3:
Registrant City:Marina del Rey
Registrant State/Province:CA
Registrant Postal Code:92092
Registrant Country:US
Registrant Phone:+1.3108239358
Registrant Phone Ext.:
Registrant FAX:+1.3108238649
Registrant FAX Ext.:
Registrant Email:[email-masked]
Admin ID:IANA
Admin Name:Internet Assigned Numbers Authority
Admin Organization:Internet Assigned Numbers Authority (IANA)
Admin Street1:4676 Admiralty Way
Admin Street2:Suite 330
Admin Street3:
Admin City:Marina del Rey
Admin State/Province:CA
Admin Postal Code:92092
Admin Country:US
Admin Phone:+1.3108239358
Admin Phone Ext.:
Admin FAX:+1.3108238649
Admin FAX Ext.:
Admin Email:[email-masked]
Tech ID:IANA
Tech Name:Internet Assigned Numbers Authority
Tech Organization:Internet Assigned Numbers Authority (IANA)
Tech Street1:4676 Admiralty Way
Tech Street2:Suite 330
Tech Street3:
Tech City:Marina del Rey
Tech State/Province:CA
Tech Postal Code:92092
Tech Country:US
Tech Phone:+1.3108239358
Tech Phone Ext.:
Tech FAX:+1.3108238649
Tech FAX Ext.:
Tech Email:[email-masked]
Name Server:A.IANA-SERVERS.NET
Name Server:B.IANA-SERVERS.NET
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
Name Server:
DNSSEC:Signed
DS Created 1:27-Jul-2010 20:57:22 UTC
DS Maximum Signature Life 1:3456000 seconds
DS Key Tag 1:31589
Algorithm 1:8
Digest Type 1:1
Digest 1:7b8370002875dda781390a8e586c31493847d9bc
DS Created 2:27-Jul-2010 20:57:36 UTC
DS Maximum Signature Life 2:3456000 seconds
DS Key Tag 2:31589
Algorithm 2:8
Digest Type 2:2
Digest 2:3fdc4c11fa3ad3535ea8c1ce3eaf7bfa5ca9ae8a834d98fee10085cfaeb625aa

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Sep 2011 12:47:02 -0700

> From: John R. Levine [mailto:[email-masked]]
> Sent: Tuesday, September 20, 2011 12:32 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: RE: [weirds] For a new task: whois abuse-contacts via DNS
> 

Who does?

---

From: SM <[email-masked]>
Date: Tue, 20 Sep 2011 14:10:36 -0700

Hi Murray,
>Who does?

The short answer is nobody. :-)

You could get this done through the respective RIR communities if you 
think that it is worth the effort.

Regards,
-sm

P.S. I am from Missouri

---

From: "John R. Levine" <[email-masked]>
Date: 20 Sep 2011 18:35:34 -0400

> example.net and example.org.

The old thin registries for .COM and .NET are different for each 
registrar.  All the other registries have a thick WHOIS, and they're all 
the same.

I realize that there's more names in .COM than anywhere else and, really, 
I understand how painful it is to parse.  I have a 2600 line perl module 
that gets maybe 80% of them.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 20 Sep 2011 18:36:44 -0400

>> Zero.  ICANN has no authority over the RIRs.

Their members.  I suppose in theory the various governments, although I 
don't know of any that have engaged with them much.

The RIRs are not totally evil.  Within the past year or so several have 
tightened the rules about abuse contacts.

Regards,

---

From: Tobias Knecht <[email-masked]>
Date: Wed, 21 Sep 2011 10:26:42 +0200

Hello,

> tightened the rules about abuse contacts.

Right.
APNIC introduced a mandatory IRT Object in November 2010.
AfriNIC decided to have an so far not-mandatory abuse-c and is working
on that at the moment.
RIPE is having a Task-Force and will come up with a proposal until end
of October for RIPE 63.
ARIN decided to make an abuse contact mandatory in future.

All these changes are initiated by policy proposals. Everybody is
allowed to bring in such proposals, discuss it with the community and
try to get consensus.

Thanks,

Tobias

(wearing my RIPE Anti Abuse Co-Chair hat)

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 21 Sep 2011 11:08:27 +0200

(johnl)
    The old thin registries for .COM and .NET are different for
    each registrar.  All the other registries have a thick WHOIS,
    and they're all the same.

If you limit yourself to gTLD registers. With ccTLDs, the mess gets
bigger (in case there is a whois service available--sometimes there
isn't at all, sometimes it is only via a web form--some have non-ascii
answers thrown in for code measures etc. etc).

    (johnl)
    I realize that there's more names in .COM than anywhere else
    and, really, I understand how painful it is to parse.  I have
    a 2600 line perl module that gets maybe 80% of them.

Before I get back into lurking mode let me make one observation:
Most time when I hear  people talking about "the whois problem"
they often mean gTLD registries and if you listen closely, they
often really mean only the .COM registry. If they mean address
registries most times they are mentioned separately.

Anyway, this discussion shows to me that there is a real need for
decent structured information from a "whois type of service" and
that a quick fix using DNS (which started this discussion) is not
going to fly.

	jaap

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 21 Sep 2011 10:04:41 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tobias Knecht
> Sent: Wednesday, September 21, 2011 1:27 AM
> To: [email-masked]

It's undoubtedly great that they're taking these steps, but I think what we're after from this side is uniformity.  How hard do you think that would be to achieve?

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Sep 2011 12:07:22 -0700

Jaap,

On Sep 21, 2011, at 2:08 AM, Jaap Akkerhuis wrote:
> decent structured information from a "whois type of service"

Yes, but this is neither a surprise nor a problem for which multiple solutions haven't already been proposed and ignored in the past.

> and

The advantage of a "quick fix using DNS" is that it greatly decreases the degrees of freedom in order to solve an extremely limited problem in a way that would be easy to deploy on existing infrastructure.  There would be _one_ solution that people all over the Internet trying to find abuse contacts regardless of the resource type could rely upon.

Instead, I fear we're going down the exact same road whois++, rwhois, and crisp/iris have gone down.  A solution will undoubtedly be proposed to meet a politically distinct subset of the Internet resulting in _different_ solutions to the _exact same problem_ for no reason other than "Not Invented Here Syndrome" (unless someone can successfully argue that the needs for an abuse contact in the ccTLD space is different than the need for an abuse contact in the RIR space).

I keep hoping folks will remember that despite all the political interest groups, there is _one_ Internet and that the folks who need to make use of registration-related data don't bloody well care the political affiliation of the registering body.  I also keep hoping for world peace, with the same likelihood of having that hope met.

As I said, your registration dollars/euros/etc. at work.

</rant>

Regards,
-drc

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 21 Sep 2011 23:46:01 +0200

David,

    The advantage of a "quick fix using DNS" is that it greatly
    decreases the degrees of freedom in order to solve an extremely
    limited problem in a way that would be easy to deploy on existing
    infrastructure.  There would be _one_solution that people all
    over the Internet trying to find abuse contacts regardless of
    the resource type could rely upon.

To me it seems that the use of a text record in DNS is similar as
the original ask-a-question, get an-unstructured-blob-as-answer
whois (port 43) protocol. (And I was thinking on the general case,
not just abuse contacts).

    Instead, I fear we're going down the exact same road whois++,
    rwhois, and crisp/iris have gone down.  A solution will undoubtedly
    be proposed to meet a politically distinct subset of the Internet
    resulting in _different_ solutions to the _exact same problem_
    for no reason other than "Not Invented Here Syndrome" (unless
    someone can successfully argue that the needs for an abuse
    contact in the ccTLD space is different than the need for an
    abuse contact in the RIR space).

Was the NIH syndrome the reason of the crisp/iris failure? I'm
afraid I didn't follow the debate closely. However if people want
to try this out using DNS for a limited whois-type service, all the
better. And yes, I agree, world peace is a nice idea as well.

    </rant>

Syntax error: </rant> found before matching <rant> (*)

	jaap

(*) Add smileys to taste

---

From: David Conrad <[email-masked]>
Date: Wed, 21 Sep 2011 15:48:43 -0700

On Sep 21, 2011, at 2:46 PM, Jaap Akkerhuis wrote:
> whois (port 43) protocol.

I've suggested using RP for exactly this reason -- the answer is explicitly structured.

> (And I was thinking on the general case, not just abuse contacts).

I'm fairly certain the general case is unsolvable (for non-technical reasons).

> Was the NIH syndrome the reason of the crisp/iris failure?

Point taken. There also was no business reason for most to spend money/develop/deploy crisp/iris (or whois++ or rwhois), either client or server.  There is probably a lesson there somewhere.

In any event, I'll go back to lurking mode. It is clear to me that minds are made up.

Regards,
-drc

---

From: Tobias Knecht <[email-masked]>
Date: Thu, 22 Sep 2011 11:12:03 +0200

>> allowed to bring in such proposals, discuss it with the community
>> and try to get consensus.
> 
> It's undoubtedly great that they're taking these steps, but I think
> what we're after from this side is uniformity.  How hard do you think
> that would be to achieve?

That is a really good question. Imho this will be really tricky since
the RIRs (AfriNIC, APNIC, ARIN, LACNIC, RIPE) are different and the
communities are really different as well. From technical and cultural
perspective.

If you want to have a unified system, you have to bring in the same
proposals to all 5 RIRs and get it ratified by the community and hope
that the RIR will be able to put things in practice.

This is somehing that will probably not happen in 2012 ;-)

Thanks,

Tobias