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@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 hostdoesn'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.