Subject: Re: (ngtrans) The reverse lookup issue

From: Mathias Koerber <[email-masked]>
Date: Mon, 08 Jul 2002 22:53:39 +0800

Add to that the fact that mass-WHOIS lookups are in at least some
cases frowned upon or restricted already, so that using WHOIS information
to check through only a short log of anything may not even be possible

mk

--On Monday, July 08, 2002 01:35:16 PM +0000 [email-masked] wrote:

> [ post by non-subscriber.  with the massive amount of spam, it is easy to
>   miss and therefore delete mis-posts.  so fix subscription addresses! ]
>
>
> 	and the whois data get has only one instance and is always
> 	correct...  :)
>
> 	when forward and reverse match, you have potentially -two-
> 	distinct administrative regimes that agree on the target of
> 	the delegation.  Based on the heirarchical nature of the DNS,
> 	I can follow delegation chains, increasing my confidence in
> 	the answer.
>
> 	Its not ideal, but its much stronger than a single lookup
> 	into a whois database. Of course both whois and dns depend
> 	on the integrity of the routing system. And DNS does have a
> 	defined method for checking the validity of a response (DNSSEC)
> 	while whois has no such integrity checks.
>
>
>>
>> But the problem is your [wrong] _assumption_ that when forward and
>> reverse match, you have "identified someone responsible". You haven't
>> done anything of the sort. Garbage in just matches garbage out. If you
>> have the IP address, you will be able to find out (eg from DHCP logs)
>> who was assigned that IP address at a certain time, and you'll be able
>> to find the DHCP server owner starting from whois records. If you have
>> only the reverse DNS, you have nothing.  Even if the reverse matches the
>> forward, you still have nothing.
>>
>> If your assumption were true, then reverse DNS might be warranted. But
>> your assumption is false, and it has proven very difficult to eradicate
>> that false assumption. Because of the difficulty of that eradication, and
>> the danger posed by the misplaced trust, in comparison with the minor
>> cosmetic benefits of having it, reverse DNS needs to be deprecated.
>>
>> 		--Dean
>>
>> On Sun, 7 Jul 2002, David Terrell wrote:
>>
>> > On Sun, Jul 07, 2002 at 07:10:44PM +0900, Toshi Yamasaki wrote:
>> > >
>> > > 2)  3rd party may want to identify the source of traffic to complain
>> > > about spam or abuse, not  necessarily per host but per /48. What 3rd
>> > > party want is not the FQDN but the contact (tech-c or admin-c) of
>> > > the source,  per /48. Whois db is enough to get the contact.
>> >
>> > One justification behind TCP wrappers paranoid mode (require reverse,
>> > require that reverse and forward match) is that whois data can
>> > easily become stale, but tcp wrappers will enforce that reverse DNS
>> > will at least identify someone responsible for the domain (because
>> > forward matches).
>> >
>> > I like being able to identify the source of traffic in my logfiles
>> > without having to run whois against every single entry.  This becomes
>> > more crucial with IPv6 (addresses are harder to remember and identify
>> > easily), not less.  I do not think that deprecating the reverse
>> > tree is warranted or acceptable.
>> >
>> >
>>
>>
>> --
>> to unsubscribe send a message to [email-masked] with
>> the word 'unsubscribe' in a single line as the message text body.
>> archive: <http://ops.ietf.org/lists/namedroppers/>
>>
>
>
>
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>

-- 
Mathias Koerber
[email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Jim Reid <[email-masked]>
Date: Mon, 08 Jul 2002 08:10:05 -0700

>>>>> "bill" == bmanning  <[email-masked]> writes:

    bill> 	and the whois data get has only one instance and is
    bill> always correct...  :)

Except when your ISP hasn't bothered to tell the RIR that they've
handed you some chunk of the address space that the RIR assigned to
them.