Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: small vent

  • From: Mark Milhollan
  • Date: Sun Jun 28 12:56:22 1998

[The original point was that the proper registry can be difficult to
find so that meaningful results can be obtained.  One poster lamented
that the whois "system" should do the right thing.  ARIN may be doing
so these days.]


"David R. Conrad" writes:
>b) someone has dummied up a prefix in a mail header or something (typical)
>c) there is a bug in the database software (happens)

I doubt B since the IP address queried was that of the TCP peer. 
Granted it could have been a spoofed session, but that would have
required a level of expertise that I've never seen used merely to
attempt delivery of a few thousand pieces of e-mail.

I suspect either C, flaky data, or C due to flaky data.


>If the prefix has been allocated, it will show up in the APNIC database
>(part of the procedure for allocation is updating the APNIC database).

Which is what seemed to have been assumed by the people that sent the
responses we received.  However they did not include the "correct"
information.

When we query the registries (which we try to avoid since its such a
slow, and imprecise mechanism) we first try the exact address, then we
back-off (class-wise) until either a non-catch-all response is
received, or an /8 is achieved.


>Might show up as the service provider instead of the end user though...

That is what we usually locate, as is who we prefer to contact.

I should clarify that we have made many queries to the various
registries, and in most cases we have received sufficiently precise
information so as to avoid a "please advise or forward" situation. 
The problem usually lays in the remaining, imprecise, cases.


>>Note:  Don't fear, APNIC isn't out-of-norm, most NSP's are doing the
>>same.
>
>APNIC isn't an NSP.

I wasn't clear enough, sorry.  What I meant to say was that, amongst
all cases where it was apparent that the database yielded contacts
that almost certainly were not the operators of the source networks
APNIC was not unique in their responses.  Specifically, we've also
sent plenty of "please advise or forward" messages to MCI, PSI,
SPRINT, and UUNET (just to name a few) that have yielded the same, or
similar, results as those sent to the registries.


>And the chances standard Unix vendors who supply sendmail (etc.) with their
>distributions will even include up to date distributions, much less up to
>date documentation or even documentation more than a man page are?  And you
>expect these folks to also translate the documentation?

I certainly do expect it of the vendors.  That they don't should not
reflect poorly on Eric.

No "service provider" specific distributions of any MTA exist of which
I am aware.  Anyone using a general distribution, or even a service
provider specific one, that did not take the time to examine the
settings for appropriateness are themselves delinquent, rather than
the package's author.  Having chosen to provide e-mail services they
should have examined the package in-hand (probably part of a general,
rather than service provider specific, OS distribution) as well as the
alternatives.  This should have resulted in them scuttling off to,
e.g., www.exim.org, www.qmail.org, www.sendmail.org, and
www.zmailer.org (to name a few).  Information is present at the
Sendmail site describing the pros and cons of the relay settings
extant, and how to change them within several service provisionings.


>>	APNIC (all):  "please send to the registered entity", none was listed.
>
>We also tell you how to determine how to find the registered entities in
>the canned response.  

We used that method to arrive at the address we used.  The mail we
sent indicated that you were receiving it due to a lack of additional
information.  Since the registries receive so many pieces of mail I
understand the need for a canned response, but one to/in which the
correct data had been appended/inserted would have been much more
helpful.


>For reference, I've personally received about 100 complaints about spam
>over the past 12 hours, about 85% demanding that APNIC disconnect "our
>dialup customer" which has resulted in the spam, and about 50% you have
>included the response from InterNIC that states "please check the APNIC
>database prior to contacting APNIC".  I don't even bother to respond any more.

I can understand, and I do sympathize -- you will never have received
such mail from us.  What are those of us that do query the registry
properly, yet still land on the registry's entry supposed to do?  It
may be that ARIN recognizes this catch-22, and has begun to act in a
fashion that helps.



What we have received from the (previously named) registries, and from
several (just named) NSP's ...

APNIC:  Usually no response, nor evidence of forwarding.  Five "please
	send to the registered entity" but no information as to who
	that would be.

MCI:  No response, nor evidence of forwarding.  In one case a voice
	call to their security department caused a message to be
	passed to the source network, which responded within an hour. 
	(By then the relay had been totally absorbed by us, so the
	useful net effect was nil.)

NORGESNETT:  Good intentioned responses to the first two messages. 
	The next three garnered no response, nor evidence of
	forwarding.  We've since had no reason to send to them as:  a)
	analysis showed that the addresses were IBM dial-up ports, and
	b) the registry database now clearly shows this anyway.

PSI:  Usually no response, nor evidence of forwarding.  Twice "please
	send to the registered entity" but no information as to who
	that would be.

RIPE:  Usually no response, nor evidence of forwarding.  Twice "please
	send to the registered entity" but no information as to who
	that would be.  In one of the later cases the registry had
	been updated after our message was transmitted, but the new
	information did not contain an e-mail entry.

SPRINT:  No response, nor evidence of forwarding.

UUNET:  No response, nor evidence of forwarding.



An example:

Note: ARIN is the correct NIC to query these days, at the time it was InterNIC.

	$ whois 203.30.7.44@whois.internic.net
[originally this yielded a "not found" response]

	$ whois 203.30.7.0@whois.internic.net
[originally this yielded a "not found" response]

	$ whois 203.30.0.0@whois.internic.net
[originally this yielded a "not found" response]

	$ whois 203.0.0.0@whois.internic.net
[originally this yielded the following response]
	[rs.internic.net]
	Asia Pacific Network Information Center (APNIC2)
[...]
	   Netname: APNIC-CIDR-BLK
	   Netblock: 202.0.0.0 - 203.255.255.0
	   Maintainer: AP

	   Coordinator:
	      Gampe, Paul A.  (PAG4-ARIN)  hostmaster@APNIC.NET
	      +81-3-5500-0480 (FAX) +81-3-3353-6096
[...]
	   *** please refer to whois.apnic.net for more information ***
	   *** before contacting APNIC                              ***
	   *** use whois -h whois.apnic.net <object>                ***
[...]

Okay, we know we have to parse responses for the "please refer to"
redirection -- we know what to do ...

	$ whois 203.30.7.44@whois.apnic.net
	[teckla.apnic.net]

	inetnum:     203.0.0.0 - 203.63.255.255
	netname:     AUNIC-AU
[...]
	person:      Geoff Huston
[...]
	e-mail:      gih@aarnet.edu.au
[...]

The response has no indication that AUNIC should be polled for more
information -- Geoff probably has the same problem you do as a result
of this.  Fortunately we know about the AUNIC whois server, yet ...

	$ whois 203.30.7.44@whois.aarnet.edu.au
	[nico.telstra.net]

	inetnum:     203.30.0.0 - 203.30.15.255
	netname:     AUSSIENET-AU
[...]
	admin-c:     AK600
	tech-c:      AK600
[...]

	$ whois AK600@whois.aarnet.edu.au
	[nico.telstra.net]

	No entries found for the selected source(s).

So Geoff still would have gotten the mail.


These days we also tend to try rwhois using root.rwhois.net ...

	$ rwhois whois 203.30.7.44

	Referral Whois (RWhois) spec version 1.0 (InterNIC V-1.0B9.2)

	network:Class-Name:network
	network:Auth-Area:0.0.0.0/0
	network:ID:NETBLK-AUSSIENET-AU.0.0.0.0/0
[...]
	network:Tech-Contact;I:AK600.NET
[...]

Which still isn't quite enough, so an extra pass is needed.

	$ rwhois ak600.net

	Referral Whois (RWhois) spec version 1.0 (InterNIC V-1.0B9.2)

[...]
	contact:Email:andrew@AUSSIE.NET
[...]

Finally a contact that should be near enough to be useful.  This is a
sufficiently large block that its unlikely that aussie.net is the
actual source network, but they should be close enough to be a useful
first step.  I always say that to myself, yet often nothing comes of
these messages.


And the point to it all?  I suppose I am just restating the original
poster's complaint that it is damned hard to know where to go to get
the ultimate information, as well as a responding poster's desire that
the system do the right thing so that everyone doesn't have to know
the proper incantation to avoid sending mail to people far removed
from the actual source.

It may be that ARIN recognizes this -- a run of this query today
yielded ...

	[rs.arin.net]
	Asia Pacific Network Information Center (APNIC2) APNIC-CIDR-BLK
							     202.0.0.0 - 203.255.255.0
	The Australian Internet Registry Pty Ltd (NETBLK-AUSTRALIA) AUSTRALIA-CIDR-BLK
							      203.0.0.0 - 203.63.255.0
	aussie.net Pty Limited (NETBLK-AUSSIENET-AU) AUSSIENET-AU
							    203.30.0.0 - 203.30.15.255
[...]

Our scripts would have selected NETBLK-AUSSIENET-AU for expansion ...

	[rs.arin.net]
	aussie.net Pty Limited (NETBLK-AUSSIENET-AU)
[...]
	   Coordinator:
	      Khoo, Andrew  (AK600-ARIN)  andrew@AUSSIE.NET
	      61-2-318-2341 (FAX) 61-2-310-3362
[...]

Bingo, there in two steps.  (An rwhois-based query also requires two
steps.)  The original whois trail required seven, but only yielded a
national registry address.




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.