[AfriNIC-rpd] abuse contact information in whois database (AFPUB-2010-GEN-002)

[Tobias Knecht]

>>>> This is not a problem of this proposal. This is a problem of the over
>>>> all situation at RIRs. We are having the problem of not having dedicated
>>>> abuse mailboxes, we are having the problem of data accuracy, we are
>>>> having the problem of complicated ways of parsing and finding abuse
>>>> contacts.
>>>>
>>> No, this is a problem of human nature, education, and experience.
>>>
>>> Human nature is that rather than follow the proper prescribed process
>>> and sending automatic abuse reports to automated-abuse-c and sending
>>> personal reports to personal-abuse-c, what usually happens instead is
>>> that both forms of abuse reports go to:
>>>
>>> admin-c
>>> tech-c
>>> every-other-c
>>> abuse-c
>>> parent-admin-c
>>> parent-tech-c
>>> parent-abuse-c
>>> parent-every-other-c
>>> parents-parent-admin-c
>>> etc.
>>
>> I think you forgot the most distinctive nature of human beings: Laziness.
>>
>> Okay look at it that way. If AfriNIC would offer a service, where I
>> could put in a ip address and get back the abuse contact e-mail address,
>> why should I start doing painful and really ugly whois queries to send
>> this stuff to more than the mentioned receiver?
>>
> whios -h whois.afrinic.net <IP>
> 
> Would work for that if we had an optional abuse-c field.
> 
> Advantage: All the automated tools are already prepared for this.
> Advantage: People already know whois is the place to look for this stuff.
> Disadvantage: It also returns the other contact data, too.
> 
>> A service that is build to solve their problems, telling them, that is
>> the only way to report abusive behavior will educate them.
>>
> Such a service is only likely to get used by those who pay attention
> to the availability of such a service. The other (uneducated) users will
> continue to query whois. Thus, I think having abuse-c appear in whois
> for those that choose to define one is the superior solution.
> 
>>> The education problem comes in the form of the majority of the people
>>> that exhibit the above behavior do so out of ignorance because they
>>> have not been taught and do not bother to educate themselves on
>>> the proper way to go about reporting abuse.
>>
>> If there are stupid people outside sending the reports to 15 people,
>> block them. Easy. Same problem today, nothing new, so not really an
>> issue of an abuse contact information proposal.
>>
> Less easy than you may think.

I think we should stop talking about the easy "frontend" things because
this will be another proposal and concentrate on the dedicated abuse
contact information.

Not that I do not like the discussion but it makes things complicated at
the moment.

>>> I do see several ways in which having an available field for an abuse
>>> contact
>>> can in part help the situation. I don't see significant benefit to making it
>>> mandatory, and, I do see a few potential downsides.
>>
>> Okay. How about that?
>>
>> We are not making it mandatory, BUT in our next proposal about an easy
>> to use query service we decide, that if there is no dedicated abuse
>> address given we use the tech-c address instead.
>>
> Yes. That would be my recommendation.
> 
>> That way we would have a chance to report stuff to a person which might
>> be responsible for the issues and probably get their attention and
>> "push" them to create one, if they do not want to receive the reports on
>> their personal accounts.
>>
> Exactly.
> 
>> Sounds more like a possible plan?
>>
> Yes. Sounds like exactly what I originally intended to suggest.

What opinions do the others have on this? Probably some more feedback
from AfriNIC members would be useful. They have to vote for it and
implement it.


>>>> The problem you described is absolutely real, but it is already today
>>>> and not a problem of this proposal. So let talk about a dedicated abuse
>>>> contact object and talk later about the other problem.
>>>>
>>> You brought up the recommendation of separate abuse contacts for
>>> automated vs. personal abuse reports. I responded to that subject.
>>
>> Yes that is exactly what I and many others would like to have, but the
>> problem you described is not linked directly with this approach. This
>> problem already exists and is nor showing up as soon as our proposal
>> will be implemented.
>>
> The problem I described would be exacerbated by having multiple
> abuse contacts, IMHO.

Why? Why would  the recommendation of separate abuse contacts for
automated vs. personal abuse reports exacerbate the problem and having
the opportunity to link one or more objects to the abuse-c not?

Did I get something wrong?

>>>> This would work. Absolutely.
>>>> If this is the solution AfriNIC members can live with, fine. I would
>>>> suggest adding the abuse mailbox field and the RIPE equivalent "whois
>>>> -b" option for short data output and unrestricted query access.
>>>>
>>> I'm not sure what you mean by adding the abuse mailbox field.  Each
>>> contact object has a required "Email" field. For example,
>>> OD19-ARIN expands to:
>>
>> RIPE for example is using a special abuse-mailbox attribute, which is
>> mentioned to be the mailbox for automatic complaints, while the e-mail
>> field is for personal contact between abuse departments.
>>
> Yeah, I think that's a suboptimal solution.

In case you are using a an abuse-c instead of an IRT Object it is.

> I would rather see a separate CONTACT record with the alternate
> mailbox as its e-mail attribute.

And how can I decide which one is for personal contact and which one for
automatic reports?

>> whois -B -h whois.ripe.net AFI5-RIPE
>>
>> person:         Axel Fischer
>> address:        1&1 Internet AG
>> address:        Brauerstr. 48
>> address:        D-76135 Karlsruhe
>> phone:          +49 721 91374 0
>> e-mail:         axel.fischer at oneandone.net
>> nic-hdl:        AFI5-RIPE
>> notify:         ripe-role at oneandone.net
>> abuse-mailbox:  abuse at oneandone.net
>> mnt-by:         AS8560-MNT
>> changed:        axel.fischer at oneandone.net 20070813
>> changed:        ripe-role at oneandone.net 20090514
>> source:         RIPE
>>
>>>> Restrict abuse-c to one object. Instead we are running in the same
>>>> problem than RIPE a few years ago.
>>>>
>>> Again, I'm not sure what you mean by this. Do you mean a record should
>>> have exactly one abuse-c or do you mean that abuse-c should only appear
>>> in number resource records and not org records, or what?
>>
>> Each inet(6)num and as-num can only have one abuse-c. Which should be a
>> role-account, which should have the abuse-mailbox attribute and should
>> not have any further admin-c or tech-c or org stuff in there.
>>
> abuse-c should be a pointer to a CONTACT record. CONTACT records cannot
> have attributes which point to other CONTACT records to the best of my
> knowledge.
> 
> In ARIN, I believe that you can specify 0 or more abuse-c attributes for any
> ORG, NETWORK, or ASN object.
> 
> For organizations that want to have multiple abuse destinations, I would
> posit that having multiple abuse-c attributes pointing to different CONTACT
> records is the cleaner solution.

Differentiating between personal and automatic contacts?


>> That would be a good step. The only problem here is, that the
>> abuse-mailbox attribute can be part of every object (role,org,person,
>> ...) which gives the opportunity that it appears more than once and in
>> the worst case with different addresses.
>>
> Yeah, I don't like having abuse-mailbox at all.  I think we should
> stick to e-mail as an attribute of CONTACT objects and link to
>  the contact objects via *-c attributes in the ASN, NETWORK,
> and ORG objects.

And again what about the differentiation between automatic and personal
contacts?

I know you would like to forget about it, but me and some others would
mind about that.

>> Is that understandable? I'm not sure, It's 4 o'clock in the morning ;-)
>>
> I think we've pretty well come full circle to what I originally proposed,
> so, if that's the case, yes, it's understandable. ;-)

Okay. So we have now a solution here which is not having different abuse
contact for automatic and personal use. Which will never give the
opportunity to lower restrictions for queries. Which is not really
dedicated, more a reuse of as well (IRT Objects) existing ways.

And that all just to make it easy and not overburden AfriNIC members?
That is a huge trade-off especially for the fact, that we were arguing
about laziness ;-)

And on the other hand we are declining to make the query process more
easy because it might be a little bit hackish, what I absolutely decline.

Sorry if that sounds now a bit exaggerated, but it sounds like its
feeling for me after recapping all the messages of the last hours.


>>>> The problem is, that at the moment there is no easy way to query
>>>> different whois servers and get the right answer, so everybody is doing
>>>> it a little bit different and that is the problem.
>>>>
>>> OK, but, this isn't the problem of the data structure. It is a problem
>>> of the
>>> available UI to retrieve the data. You are proposing a change to the
>>> structure of the data to address a problem with the UI. I agree that
>>> there is a need for resolving your UI problem, but, I don't agree that
>>> such a change to the underlying data structure is needed, nor do I see
>>> doing so as a particularly reliable way to achieve the UI change that you
>>> seek.
>>
>> At AfriNIC it's an UI thing, that may be right. At RIPE it is a
>> structural problem, to much choices for the same thing. That is exactly
>> what I want to avoid here.
>>
> Yeah, RIPE whois seems byzantine to me. That's one of the reasons
> I held up ARIN as a better example.

ARIN is the much better example in cleanness, but I would not say it's
the better example from an hierarchical or technological point. Problem
of RIPE in my opinion is, that they had to make compromise at the
beginning, found out that they should solve the compromise later and
went into the problem we are having at the moment. They tried to make
things easy and forgot about the requirements. That caused having
several half-baked solutions.

The only solution I think, and I had another opinion one and a half
years ago, is the IRT Object. The only reason why I think the IRT Object
is half-baked too, is that it is not promoted very good. Bad
documentation and always the possibility to fiddle around with easier
but not better ways of publishing abuse contact information. e.g.
abuse-mailbox attribute, remark fields, description fields. What brings
me back to the laziness ;-)

>> That was the reason for the IRT and the mandatory abuse-mailbox in the
>> IRT. With usual objects we are getting into the problem of having
>> different abuse-mailbox attributes in different objects.
>>
> Yeah, but, that's a whole other UI problem in my opinion which I think
> is meeting resistance because it requires substantial additional overhead
> for the maintainers of the objects and yet another object they need to keep
> track of and keep updated.

If you want to handle your incoming complaints right, you have to add an
object. No matter if you use the IRT or any kind of abuse-c. If you use
an existing person object which contains a personal email address which
uses spamfilters this is not a really serious approach. So there must be
a extra object.

The data accuracy part is absolutely true, but this has again nothing to
do with this proposal. Keeping the data accurate is a complete different
problem. And again, trustful members will keep it up2date and will use a
special object and will do everything right, and the others will be
"punished" by the internet users.

And there will be a following proposal from us, facing the data accuracy
problem. So please let us not mix up all the problems of RIRs and whois
and so on and try to get them all fixed with this proposal, or decline
in my opinion a technological better approach by saying this will not
fix all the problems.

Sorry if I misunderstood that, but I had this discussion at APNIC before
and I made the mistake to follow the discussion which was getting really
scary.


> Having abuse-c on the ORG record, to me, seems the cleanest and easiest
> solution all around.

If we wanna live with all these exceptions, yes it is.


>> Not storing. Store everything in the whois database. That is perfect and
>> offer a way to query it via whois. No question about that. The DNS based
>> query system is just the easy to use "frontend".
>>
> Hmmm... Not sure about that. I suppose it could be done, but, seems rather
> hack-ish to me and I'm not sure what the real benefit would be.

At the end it is not about DNS based or RBLDNSD, its about easy.
But again, different proposal, different discussion.

>> Additional create a file once a day, which looks like this:
>>
>> <cidr-range>:<a-record>:<txt-record>
>> 212.227.0.0/16:127.0.0.1:abuse at oneandone.net
>> [...]
>>
>> http://www.corpit.ru/mjt/rbldnsd.html
>>
>> And offer this as an rbldnsd on maybe 2 dedicated servers at every RIR.
>>
>>
>> Reporter could use it like this:
>>
>> $ host -t any 5.126.227.212.abuse-contacts.abusix.org
>> 5.126.227.212.abuse-contacts.abusix.org has address 127.0.0.2
>> 5.126.227.212.abuse-contacts.abusix.org descriptive text
>> "abuse at oneandone.net"
>>
> What's the point of the A record?

A DNS always needs an A-Record. You can leave it out and use it, or you
can package up different information. That is waht blacklists usually doing.

127.0.0.1 APNIC
127.0.0.2 ARIN
127.0.0.3 AfriNIC
127.0.0.4 RIPE
...

127.0.35.4 RIPE Germany
127.0.36.4 RIPE Austria
...

Just as an explanation, not as an idea of what is needed.

>> Easy, isn't it?
>>
> Depends on perspective, I guess. Easy to query? Yeah, sort of.

Easier than doing a whois query and parse content.

> Easy to implement on the DNS server? not so much.

3 and a half minutes to set it up. ;-)
RBLDNSD is a debian package with no dependencies.
Copy the generated file to the right place.
Configure it with 3 lines of configuration.

Stable, robust, scales like nothing else, can be loadbalanced by the
real dns, just let the A-Record point to more than one IP.

Really, really easy.

> Easy to set up the code to generate the files? not so much, but, probably
> not too hard.

Easier than building the abuse-finder.

> DNS is particularly bad at CIDR queries in my experience.

RBLDNSD is build for that.
It is doing nothing else than serving A and TXT Records.
And it is ipv4, ipv6 and even domain compatible.

And its free, I'm not the Director of Marketing ;-)

>> RBLDNSD is scalable, reliable, robust and used bullet proof for years by
>> nearly every blacklist provider.
>>
>> Merging different zones, without putting them into one file would help
>> to solve the issue with a few RIRs having their own file.
>>
> I'll take your word for this. I'm not familiar with RBLDNSD.

We are doing exactly this.

>>>> That would make things easy and stops thousands of different ways to
>>>> do it.
>>>>
>>> Now, you are dreaming. It _MIGHT_ provide one consistent way you can
>>> depend on, but, others will continue to use other methods.
>>
>> That way is that easy, that most of the people will use it. It is easy
>> for RIRs to implement. It is easy to deploy and publish and it is easy
>> to query.
>>
> Again, I am not convinced.

Now? ;-) Just kidding.
I will not replace whois queries, but I want to have a easier way to get
data. That's all. I think RBLDNSD would be the perfect fit.


Thanks,

Tobias



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20100617/e6f141fb/attachment.sig>