Re: Suggestion: Add contact entry to whois
OK, perhaps, then, we should consider two contacts: Complaints contact (the destination for complaints about SPAMMERS and such) (SPAM) Enforcement contact (the destination for people who can respond to real-time hacking concerns) (SMURF, FLOOD, HACKING) Tech contact would still be my bet for Bad BGP, as this is usually accidental and not malicious. Bottom line, the Tech. contact for alot of these providers is an address that gets reviewed once a day or such and doesn't provide anything more effective than a secretary putting a post-it on the door. The Admin contact is supposed to be just that, and usually is. The billing contact, as I see it would only be used by InterNIC and possibly people who want to seek reparations for SPAM. I don't pretend that the names I chose above are necessarily the best terms that can be applied, and I am flexible about what to call them. However, I do think they are needed at this point. Owen
Owen DeLong wrote:
We already have Admin, Tech, and Billing. Would it be possible to consider the addition of an Abuse contact in whois?
The existing contacts serve that function. If someone at some place is smurfing you, you don't want to talk to some secretary who is going to stick a post-it on some manager's door about it. You want the NOC and you want the person in the NOC who can initiate immediate investigation and correct the problem. Well, at least I do.
Define "abuse". It comes in a lot of categories, anyway. Which category do you think an abuse contact should be getting them for? Smurf? Flood? Spam? Bad BGP? Hacking?
-- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* phil at intur.net * --
On Fri, 26 Feb 1999, Owen DeLong wrote:
OK, perhaps, then, we should consider two contacts: Complaints contact (the destination for complaints about SPAMMERS and such) (SPAM)
Abuse contact.
Enforcement contact (the destination for people who can respond to real-time hacking concerns) (SMURF, FLOOD, HACKING)
Security contact. -Dan
On Fri, Feb 26, 1999 at 01:33:33PM -0800, Dan Hollis wrote:
Abuse contact. Security contact.
Exactly the choices I would have made. Cheers, - -jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Buy copies of The New Hackers Dictionary. The Suncoast Freenet Give them to all your friends. Tampa Bay, Florida http://www.ccil.org/jargon/ +1 813 790 7592
On 02/26/99, Owen DeLong <owen@dixon.DeLong.SJ.CA.US> wrote:
OK, perhaps, then, we should consider two contacts:
Unfortunately, "we" is not the same body of people that can actually make the changes to WHOIS. Luckily, "we" don't have to -- we could just follow RFC 2142. http://www.geektools.com/rfc/rfc2142.txt -- J.D. Falk <jdfalk@cp.net> "We don't want our customers Special Agent In Charge (Abuse Issues) to lose their marbles." Critical Path, Inc. -- Dave Rand, AboveNet
On Fri, 26 Feb 1999, J.D. Falk wrote:
On 02/26/99, Owen DeLong <owen@dixon.DeLong.SJ.CA.US> wrote:
OK, perhaps, then, we should consider two contacts: Unfortunately, "we" is not the same body of people that can actually make the changes to WHOIS. Luckily, "we" don't have to -- we could just follow RFC 2142. http://www.geektools.com/rfc/rfc2142.txt
rfc2142 only deals with email addresses, what if the host is conducting a denial of service attack and you need to call someone. email addresses are rather less useful then. a quick whois and ring up is usually more effective in getting an attack shut down. -Dan
On Fri, 26 Feb 1999, Dan Hollis wrote:
rfc2142 only deals with email addresses, what if the host is conducting a denial of service attack and you need to call someone. email addresses are rather less useful then. a quick whois and ring up is usually more effective in getting an attack shut down.
May I humbly suggest that we extend RFC2142 in the following fashion: All domain names should include a host named LDAP at which an LDAP server is operational which will answer queries for specific contact information for that domain. For example, if the domain name is example.com then the host named ldap.example.com would have a publicly accessible LDAP server available. The intent is for this server to make available up to date contact information for network operations people that deal with various types of emergency and non-emergency operational issues. An ongoing SMURF attack would be an example of an emergency issue whereas a peering request would be an example of a non-emergency issue. The contact information that is made available is intended only for use by operations people at other network providers. Because the servers are publicly accessible, the information may be shielded by suppling contact info for a "dispatch" person who acts as a gatekeeper for the real information. However this dispatcher must be able to promptly forward calls on a 24/7 basis in order to properly handle emergency issues. The LDAP server will make available the following objects: index security abuse peering smurf ... (and the list goes on) At a minimum, each emergency contact must contain an internationally accessible phone number including area/city codes and country code. And each non-emergency contact must include at least an email address. It is expected that man network operators will use a backend server that supports dynamic information so that contact info can be easily changed to reflect shift schedules, etc. P.S. This is pretty rough but I think you get the idea. Obviously it relies on having a working network connection to retrieve the information but because the info is published in a standard format, it wouldn't be too hard for some people (DRA?) to suck in copies from everyone with an AS number and make that available along with a few mirrors for robustness. -- Michael Dillon - E-mail: michael@memra.com Check the website for my Internet World articles - http://www.memra.com
participants (5)
-
Dan Hollis -
J.D. Falk -
Jay R. Ashworth -
Michael Dillon -
owen＠dixon.DeLong.SJ.CA.US