is reverse dns required? (policy question)

Sat Dec 4 16:34:12 UTC 2004

On Sat, 4 Dec 2004, Henning Brauer wrote:

> > So if I want to check on 127.1.2.3, I first do lookup on 
> >   _srv.3.2.1.127.IN-ADDR.ARPA
> > if that does not give any answer, I'll have to do lookup on
> >   _srv.2.1.127.IN-ADDR.ARPA
> > if that does not give any answer, I'll have to do lookup on
> >   _srv.1.127.IN-ADDR.ARPA
> > And if that does not work, I still have to do lookup on
> >   _srv.127.IN-ADDR.ARPA
> 
> that is how it works.
> 
> > Is that how you expect it to work? If that is so, I do not like it
> > because it forces to do these multiple lookups.
> 
> these lookups are cheap, and with increasing deployment I expect the 
> the vast majority of lookups to have matches on /32 (1st query) or /24 
> (2nd query).

The problem is going to be for early adaptors - they have to do all
4 lookups because at the time nobody would have these records. There
are also problems because sometimes in-addr tree deligation is not
properly setup and lookups on it time out (and you have to wait for
timeout for each of those lookups).

> but anyway, these lookups are reasonably cheap.

There are some here who may disagree if they see this deployed
(like say ARIN and other RIRs...)

----------------------------------------------------------------------

Earlier this year I proposed different way of doing above, which maybe
better. It involves not checking directly in in-addr tree but instead 
checking SPF (or some other policy) record on the dns PTR name. So if
somebody does not offer proper IN-ADDR support, there is no record there
and we need not bother doing this check (and checking just PTR for SMTP
connection is going to happen anyway). If PTR record does exist then
that is checked and it may then specify that ip can or can not be an
SMTP client.

Now if somebody needs to enter this record for whole bunch of ips that are
not in use (for example 127.1.2.0/24), they can do something like this:
 *.2.1.127.in-addr.arpa.   IN   PTR   nomail.example.com.
 nomail.example.com.	   IN   SRV   TXT  "v=spf1 -all"
 nomail.example.com.	   IN	A     127.0.0.2

If they have legitimate mail server, the they would likely be wise to
enter SPF1 record for such hostname anyway, so nothing new there.
The somewhat troublesome situation is when this is a dialup/dsl ISP which 
has bunch of ips and they actually set each one of them in reverse, i.e.
 1.2.1.127.in-addr.arpa.   IN   PTR   dsl-127-1-2-1.example.com.
 2.2.1.127.in-addr.arpa.   IN   PTR   dsl-127-1-2-2.example.com.
 3.2.1.127.in-addr.arpa.   IN   PTR   dsl-127-1-2-3.example.com.
 ...
And if they have properly setup dns (or otherwise their customers will 
begin to complain that they can't use irc :), they would also have:
 dsl-127-1-2-1.example.com.  IN   A  127.1.2.1
 dsl-127-1-2-2.example.com.  IN   A  127.1.2.2
 dsl-127-1-2-3.example.com.  IN   A  127.1.2.3
 ....
Now this does mean that you no have to enter an extra record for each one
of these and as there is no way to do it with wildcards:
 dsl-127-1-2-1.example.com.  IN   A  127.1.2.1
 dsl-127-1-2-1.example.com.  IN   TXT "v=spf1 -all"
 dsl-127-1-2-2.example.com.  IN   A  127.1.2.2
 dsl-127-1-2-2.example.com.  IN   TXT "v=spf1 -all"
 dsl-127-1-2-3.example.com.  IN   A  127.1.2.3
 dsl-127-1-2-3.example.com.  IN   TXT "v=spf1 -all"
 ...
But I suspect that for most ISPs such dial/dsl zones are not generated by 
hand, but by some script and modifying such script to add such extra record
is not a big deal.

P.S. Instead of doing SPF another possibility is to use SRV, i.e. 
 dsl-127-1-2-3.example.com.  IN   A  127.1.2.3
 _client._smtp._tcp.dsl-127-1-2-3.example.com.  IN   SRV  0 0 0 .

--- 
William Leibzon
Elan Networks
william at elan.net