On Fri, Feb 03, 2012 at 08:02:32AM -0600, Les Mikesell wrote: > On Fri, Feb 3, 2012 at 7:01 AM, Stephen Harris <lists at spuddy.org> wrote: > > a forward lookup matches. ?It is commonly considered "broken" for rDNS > > to return a value that doesn't match forward DNS. > > If you say something is "broken", you should quote the RFC with the > MUST requirement that it breaks. I don't think there is one for this. RFC 1912 section 2.1 http://tools.ietf.org/html/rfc1912 which says explicitly "Make sure your PTR and A records match." Which leads to things like RFC 5451 section 2.4.3 ("iprev") http://tools.ietf.org/html/rfc5451#section-2.4.3 Regardless of what the RFCs may or may not say, rDNS is _untrusted_ without a forward lookup validation. > The forward and reverse naming control is delegated 2 different ways > and may not be under the same person's control. It is also Irrelevant. If I make my hosts rDNS claim it is "mail.google.com" then no one should believe me 'cos the A record for that domain points totally elsewhere. rDNS without forward DNS validation is _untrusted_ data, and if you're performing security checks without validating the data then you're doing it wrong. This is ancient knowledge; as I said, Sun patched Solaris NFS server to fix this gap over 15 years ago. > relatively common to have multi-homed hosts with the same name for > multiple interfaces, Not a problem; rDNS and A record matching can still occur in this case. > or connections that go through NAT where the host > doesn't even know what source address will appear on its connections. Not a problem; here it's the NAT address that matters and that needs working rDNS and A record matching. I'd agree that expecting HELO to match the IP address is wrong, but I'm not asserting that. I don't care about packet _contents_, I merely care that DNS is configured in a manner that makes it trustable. -- rgds Stephen