Subject: Reverse IPv6 DNS checks on ietf MXs?

From: Tim Chown <[email-masked]>
Date: Thu, 5 Mar 2009 13:00:55 +0000

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.

   ----- Transcript of session follows -----
 ... while talking to mail.ietf.org.:
 >>> DATA
 <<< 450 4.7.1 Client host rejected: cannot find your reverse hostname,
 [2001:630:d0:f102:21e:c9ff:fe2e:e915]
 <[email-masked]>... Deferred: 450 4.7.1 Client host rejected: cannot find your   reverse hostname, [2001:630:d0:f102:21e:c9ff:fe2e:e915]
 <<< 554 5.5.1 Error: no valid recipients
 Warning: message still undelivered after 5 hours
 Will keep trying until message is 1 week old

This was our fault, and we now have a reverse entry for the 'offending' 
system, but we think this problem was in effect for longer than just 
last night, when we first noticed the delayed mail warnings,  hence 
we're wondering whether this is a new policy or not on the IETF lists.

It's not uncommon for IPv6 servers to be multiaddressed, so mail admins
will probably just need to be a wee bit more careful, and certainly try
to avoid using autoconf globals on servers.    In our case our server
acquired an additional global autoconf address on top of its manually
configured address, which it started sending from, and as this had no 
reverse DNS entry we encountered the Rejects.

Whether such 'authentication' is still valid for IPv6 systems is of
course another question...

-- 
Tim

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 05 Mar 2009 14:16:00 +0100

Tim Chown wrote:
[...]
> to avoid using autoconf globals on servers.

Nothing wrong with EUI-64 or autoconf, as long as you actually want them
there ;)

and otherwise on eg Linux:
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.all.accept_ra=0
other mechanisms hopefully available on your favourite OS.

As for the IETF mailservers rejecting it, clearly there was a
misconfiguration and they caught that perfectly fine. Misconfigured
boxes should not be able to send out mail, there is most often other
things also misconfigured then and/or they are not monitored and thus
just used for abuse.

> In our case our server

I suggest installing NDPMon (http://ndpmon.sourceforge.net/) next to
your arpwatch that you should have running for IPv4. Of course
protecting your L2 with 802.1x or a similar system next to that is also
a good hint.

BTW: for postfix, smtp_bind_address6 allows you to fix the outgoing
address to a certain IP (smtp_bind_address for IPv4 ;)

Greets,
 Jeroen

---

From: Dave Cridland <[email-masked]>
Date: Thu, 05 Mar 2009 14:09:37 +0000

> reverse DNS lookup on the IPv6 sender address.

That's been the case for ages, and is why I now firewall outgoing  
IPv6 connections to the IETF's mailserver. (I could go off and pay  
for IPv6 reverse DNS hosting, but I'm not *that* keen on IPv6).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Mar 2009 09:30:03 -0500

> 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.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Doug Otis <[email-masked]>
Date: Thu, 5 Mar 2009 10:32:28 -0800

On Mar 5, 2009, at 6:30 AM, Andrew Sullivan wrote:

>> 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.
>

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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 5 Mar 2009 13:40:01 -0500

On Thu, Mar 05, 2009 at 10:32:28AM -0800, Doug Otis wrote:
>> the failure of reverse DNS lookup is not always a good idea.  
>
> Agreed.  

Just to be clear: I am not sure I agree with those who think reverse
DNS should not be maintained, but there were strong currents in the WG
that led to the text of that I-D as it stands.  It isn't clear to me
where the I-D stands in its progression (if there is to be any) from
the WG, so I have no idea what the Chairs will say was consensus.  But
there was a WGLC in which at least some people suggested the text of
draft-ietf-dnsop-reverse-mapping-considerations-06.txt still contained
too much endorsement of the reverse tree.  My personal interpretation
of those remarks is that there will always be a hard core of operators
who regard the reverse tree as an insupportable burden (without
consideration for the v4/v6 differences).

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 05 Mar 2009 10:47:19 -0800

> consideration for the v4/v6 differences).

I think it's hard to argue that it isn't a greater burden in ipv6,
whether it is insupportable is a question of degree... obviously one can
simply use wildcards in zones to generate responses whether tha produces
a level of congruence between forward and reverse or even any actual
meaning that's useful is another question entirely.

---

From: Doug Otis <[email-masked]>
Date: Fri, 6 Mar 2009 16:42:29 -0800

On Mar 5, 2009, at 10:40 AM, Andrew Sullivan wrote:

>>> Note that there has been work in DNSOP suggesting that rejecting  
>>> on the failure of reverse DNS lookup is not always a good idea.
>>
>> Agreed.
>
> DNS should not be maintained, but there were strong currents in the  
> WG that led to the text of that I-D as it stands.  It isn't clear to  
> me where the I-D stands in its progression (if there is to be any)  
> from the WG, so I have no idea what the Chairs will say was  
> consensus.  But there was a WGLC in which at least some people  
> suggested the text of draft-ietf-dnsop-reverse-mapping- 
> considerations-06.txt still contained too much endorsement of the  
> reverse tree.  My personal interpretation of those remarks is that  
> there will always be a hard core of operators who regard the reverse  
> tree as an insupportable burden (without consideration for the v4/v6  
> differences).

When there is to be reverse namespace, it should be ensured to work.   
In reality, this is not always the case.

Whether the reverse namespace becomes an expensive luxury for  
countries adopting IPv6 seems to be an open question.  This namespace  
can be frail, and often is not properly configured which reduces  
reliability.  To sustain the delays reverse transactions create,  
additional servers might be required to handle the same amount of  
traffic possible when reverse namespace is ignored.

Reverse namespace is often used to determine, by the nature of the PTR  
labels, whether an IP address might be dynamically assigned before  
deciding to accept email from a specific IP address.  Will resolving  
labels for specific IP addresses make sense for IPv6?

Could network policy be listed using HTTPS instead?  Say for example:

A DNS query of b.a. 
9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.ARPA.

becomes:

https://2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.DOA.IP6.ARPA.

that redirects to the registered network owner's https servers.   The  
page returned would contain CIDR lists and policy assertions within an  
encapsulation, such as XHTML.

Finer grain resolutions could be obtained from a network domain of  
authority or NDOA.<referenced-domain> contained within the CIDR lists  
and policy page, CLAPP.  :^)

-Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Mar 2009 13:12:54 -0400

On Fri, Mar 06, 2009 at 04:42:29PM -0800, Doug Otis wrote:
>
> When there is to be reverse namespace, it should be ensured to work.  In 
> reality, this is not always the case.

That is either an impossible goal, or else a meaningless requirement.

In some sense, the reverse tree always works: you send a query in, and
you get the answer that the global distributed database can give you
(one of which is, "dunno -- I didn't get an answer in time, so I gave
up").

What you might asking for with "ensured to work" is what the
reverse-mapping-considerations draft calls "existing reverse data".
The idea is roughly that, for any address-type answer from a forward
zone, if you query that address in the reverse zone you get some
positive answer (e.g. you get a PTR record).

What I suspect you're asking for with "ensured to work" is what the
reverse-mapping-considerations draft calls "matching reverse data".
The idea here is roughly that the PTR record you eventually get
corresponds to the name you originally queried.

Regardless of which of the latter two you want, however, the fact is
that the reverse tree is only ever going to be as operative as the
operators of those reverse trees make it.  Since we have plenty of
examples of bizarrely broken behaviour in a forward zone, there's no
reason to imagine that the reverse is somehow special and more likely
to work.  Therefore, I say the goal is impossible.

> deciding to accept email from a specific IP address.  

That very practice is one of the more contentious pieces around the
draft.  If you want to discuss this further, I encourage you to take
the discussion to DNSOP, where the draft was last considered, since
that's the WG that will have to be persuaded to send the document
along if it is to go anywhere.

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.