On Mar 5, 2009, at 6:30 AM, Andrew Sullivan wrote:
On Thu, Mar 05, 2009 at 01:00:55PM +0000, Tim Chown wrote:
Hi,
Just an observation, I don't know whether its been changed or
applied recently, but we had some mails to various IETF lists soft
rejected overnight due to failure of the receiving MX to perform a
successful reverse DNS lookup on the IPv6 sender address.
Note that there has been work in DNSOP suggesting that rejecting on
the failure of reverse DNS lookup is not always a good idea. So if
IETF lists are in fact doing that, perhaps the operators of the
servers want to ask for the advice of the DNSOP participants. (Be
prepared for a lot of mail.)
Agreed. Rejecting on no reverse DNS assignments within IPv4 is also
problematic for those in some countries. Rejecting on reverse DNS
might even be seen as expressing a geocentric bias. :^(
IPv6 represents an address space with the potential for exponential
growth, and becoming exceedingly difficult and expensive to manage.
Reverse DNS, especially for IPv6, results in timeouts likely to
consume resources otherwise needed to deal with the increasing
sources. Reverse DNS timeouts might be due to configuration errors,
or to providers that either neglected, or for security reasons, do not
make reverse assignments.
A fair amount of resources are saved by direct communication with
network providers who indicate which routes are permitted by their
policy to carry email, as example. A public registry, analogous to
that of reverse DNS, offering CIDR listings of permitted space would
be beneficial at conserving resources currently suffering from a
tragedy of the commons. The high overhead consumed when attempting to
make sense of what might be implied by PTR names on a per IP address
basis makes reverse DNS fairly impractical method to express this
information. Limiting a range of IP addresses permitted for specific
applications, especially within IPv6, would help conserve resources in
many ways.
-Doug
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf