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@xxxxxxxxxx> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
