Hello,
I am interested in finding out what the motivation is for requiring
valid reverse address lookups before connecting to a daemon. I have
heard a number of different explanations, the majority of the responses
point to history/tradition and tcpwrappers. Is there a commonly accepted
justification for this practice? In my opinion it does not appear to
increase the validity of the connection. But I may be missing something
obvious.
Thanks in advance...
--dfc returns to lurk mode
Douglas F. Calvert
Well, my understanding is that whilst its easy to get a domain name and some dns
its usually quite difficult to put in a ptr record, these are usually controlled
by the ISP. If they dont exist or dont match then the address is a dialup or
hijacked or something not legitimate.. I think this is mainly an smtp antispam
thing tho altho I see your point is for any connection is general, I guess the
same appliers to hackers as to spammers.. ?
Steve
I am interested in both cases smtp and other services. Syr.edu only
accepts ssh connection to the public unix boxen if you come from an ip
with a valid reverse address. The majority of smtp servers on the net
require the same. What more is known about the mail sender or ssh client
just because the reverse address lookup goes through?
Anyone care to give their thoughts on the legacy aspect?
Douglas F. Calvert wrote:
<snip>
What more is known about the mail sender or ssh client
just because the reverse address lookup goes through?
You have a clue as to who their ISP thinks they are...for starters. Also its easier on the eyes in the logfiles.
Anyone care to give their thoughts on the legacy aspect?
I gather that most people here, far from viewing it as legacy, increasingly support more prejudicial treatment of those hosts without it...
if you reverse resolve, then some registry somewhere (ARIN, RIPE, APNIC, etc)
recognises that network as having 'valid' contact details and has assigned
someone reverse authority.
It stops some IP block hijackers - if you find the right peer,
you can just pop up for a bit, say "hi! I'm foo/12!", start spamming
from a few /16's worth of IPs, then drop away after an hour.
In practice, at least with IP block hijackers, they'll either
(a) hijack a smaller chunk of a registered/announced ip network, complete
with nameservers, or
(b) they'll find a registered but un-announced ip network, with the
in-addr authoritative nameservers inside said network, and just
pop up for spamming there.
I think you'll find the original reasoning rooted in past history.
A few useful side-effects, like the above, have popped up so I don't
think there's much motivation to change it.
2c,
Adrian
Douglas F. Calvert wrote:
I am interested in finding out what the motivation is for requiring
valid reverse address lookups before connecting to a daemon. I have
heard a number of different explanations, the majority of the responses
point to history/tradition and tcpwrappers. Is there a commonly accepted
justification for this practice? In my opinion it does not appear to
increase the validity of the connection. But I may be missing something
obvious.
Thanks in advance...
Well, my understanding is that whilst its easy to get a domain name and some dns
its usually quite difficult to put in a ptr record, these are usually controlled
by the ISP. If they dont exist or dont match then the address is a dialup or
hijacked or something not legitimate.. I think this is mainly an smtp antispam thing tho altho I see your point is for any connection is general, I guess the same appliers to hackers as to spammers.. ?
I am interested in both cases smtp and other services. Syr.edu only
accepts ssh connection to the public unix boxen if you come from an ip
with a valid reverse address. The majority of smtp servers on the net
require the same. What more is known about the mail sender or ssh client
just because the reverse address lookup goes through?
Anyone care to give their thoughts on the legacy aspect?
Speaking for myself only, and for the groups that I used to manage
at the time I managed them...
There is a concept of a Complete Job in doing something. In the
case of exposing a machine to a larger community, that Complete
Job includes (but is not limited to) such things as insuring
that machine is physically up to its assigned task, that its
Operating system is appropriate and at the appropriate patch
level, that the software is appropriate for the assignment, and
properly configured, that the installation is physically and
operationally secure, and that all of the paperwork (including
virtual paperwork like domain registrations and DNS minutia)
is in order.
If you are an outsider looking in at one of my installations, that
last one is the only one you can readily look at to see if you
think I am worthy of your trust.
if you reverse resolve, then some registry somewhere (ARIN,
> RIPE, APNIC, etc) recognises that network as having 'valid'
> contact details and has assigned someone reverse authority.
> It stops some IP block hijackers - if you find the right
> peer, you can just pop up for a bit, say "hi! I'm foo/12!",
> start spamming from a few /16's worth of IPs, then drop away
> after an hour.
This tactic is often bandied about - but given the number of people
and sites that track BGP changes, why does no one produce any evidence
of it actually happening?
> In practice, at least with IP block hijackers, they'll either
> (a) hijack a smaller chunk of a registered/announced ip
> network, complete with nameservers, or
> (b) they'll find a registered but un-announced ip network,
> with the in-addr authoritative nameservers inside said
> network, and just pop up for spamming there.
Most commonly, IP space hijackers start by falsely updating the
registration info at the RIR, and/or forging letters of authority
purporting to allow them to announce the block, and work from there.
It tells you that the connection is coming from a netblock managed by somebody
with enough clue and motivation to get PTR records right. If the site can't
even get that right, they're probably lacking in logging/auditing and the like
as well.
As a result, it's a pretty safe bet that if your site policy says you'll go
looking for somebody if there's a problem with the connection, you might as
well drop the connection early on, because nobody's answering the cluephone at
the remote end...
As far as SMTP goes, it's surprising (barely) how often you get "MX points to myself"
errors back from sites that don't have a valid PTR either....