[ On Thursday, June 17, 2004 at 22:49:18 (-0400), David Brodbeck wrote: ]
> Subject: RE: [Exim] AOL - SPF - and EXIM
>
> The thing is, I don't really see the point of the reverse DNS check. It
> doesn't accomplish anything.
Well it all depends on how much you trust the DNS, and even your own
caching DNS servers, etc.
I'm more the paranoid type when it comes to trusting information my
nameservers might have received from some un-protected UDP datagram that
might just happen to have a matching query-ID, etc. to some outstanding
query my nameserver was waiting for an answer to.
> Someone claimed earlier that it's a form of
> server authentication, but it isn't really,
Well actually it is a form of authentication, though obviously it's not
a cryptographically secure form of authentication.
The best use of the reverse DNS is in fact to provide an added level of
assurance that the address some hostname points to is indeed valid.
This is done by giving that hostname as the value of a PTR for its
address in the corresponding reverse DNS (in-addr.arpa) zone.
I.e. the reverse-DNS check is done for the same reasons as Steve
Bellovin et al recommended it for protocols such as RSH, and why Wietse
Venema's TCP Wrappers library has the "PARANOID" option. We don't run
RSH on the Public Internet any more, at least not if we know what's good
for us, and even TCP Wrappers seems to be less popular (though maybe
it's just become ubiquitous?), but SMTP still runs over plain TCP
circuits in the clear on the Public Internet and it still uses plain old
DNS that also usually operates over plain UDP in the clear too.
Correspondence between the reverse and forward DNS is not always as much
additional assurance as it could be of course. However if the owner(s)
of the relevant zones really want it to be stronger then it is possible
to give someone such as myself the ability to query two different zones
of authority at two separate sets of nameservers and to compare the
results to see if they match up properly. It might be relatively easy
to forge one DNS reply, but forging two, which given caching semantics
might not even have any obvious temporal relationship, is going to be
much harder. (though cache poisoning bugs which allow the insertion of
forged NS records for one zone or another or both can make the hacker's
job a lot easier -- your cache can be primed before your mailer ever
gets the connection and so it'll query the wrong nameservers for the
forged HELO name and get forged replies confirming its apparent
validity).
> because whoever controls
> reverse DNS for that IP can stick whatever they want in there.
Which is of course exactly the point.
In the ideal case where an ISP who controls the netblock and routing
also refuses to delegate the reverse DNS to its customers and instead
insists on managing those zones itself then folks such as myself have a
relatively high degree of trust in a hostname when we see that the ISP
and the customer have actually agreed on what hostname(s) is(are)
assigned to an address and vice versa.
On the other hand if the ISP says that the IP address is assigned to a
name like "CPE0080c7047f3d-CM.cpe.net.cable.rogers.com" then we can be
fairly certain that they don't expect any valid server or client-SMTP to
be operating from that address (especially if we know what their terms
of service are and what their AUP says). :-)
> For example, if I get a connection from a server that says 'HELO
> mail.whitehouse.gov', and I do a reverse lookup on its IP and find
> 'mail.whitehouse.gov', all that tells me is that the person who does rDNS
> for that netblock set that value.
Indeed, which is why it's also necessary to verify the forward DNS
correspondence as well. In a system like the DNS verifying that A
points to B is less than useless (i.e. it could even be misleading) if
you don't also verify that B points to A.
I.e. if you look up "mail.whitehouse.gov" and find out that it does not
exist (which is in fact the case), then you can be almost 100% certain
that the HELO speaker and the reverse DNS for its source address are
both lying (and are probably in cahoots with one another too!). Similar
conclusions result if the name exists but has a different address,
especially if a PTR for that different address also agrees with the name.
> But
> if I look up the A record for mail.whitehouse.gov and find the IP matches
> the server connecting to me, I have a pretty good idea that someone at
> whitehouse.gov was involved.
No, you don't really know any such thing for certain. Unless you look
up the reverse DNS for that address and compare it as well then you
don't know for sure whether you can trust that A record, as it may have
been spoofed. The DNS on the Public Internet normally runs over very
insecure protocols and even some of the DNS software still widely
deployed is full of holes like a Swiss cheese when it comes to being
susceptible to cache poisoning and reply spoofing tricks.
Now normally I personally don't insist on there being any reverse DNS
unless the HELO parameter is a literal IP address. However IFF there is
reverse DNS then I insist that it be correct and valid. Most of the
time it is, but when it isn't then I can't trust either name -- the only
thing I know for certain at that point is that the client-SMTP can
inject IP packets in the right way to at least create the illusion that
a valid TCP circuit has been set up and that they are likely at the
location on the Interent where the routing tables suggest they are at
(though of course they could be controlling a trojan on my own local
network and able to see the packets my mailer itself sends out to the
spoofed IP address :-).
Luckily the HELO name is only used for loop detection and for tagging
the IP addresses in audit trails (received headers) and logs with the
hostnames that were intended to be associated with those addresses at
the time of the transaction, so we don't really need DNSsec to help
identify spammers and miscreants -- we just neeed people to pay more
attention to fixing and maintaining their reverse DNS! :-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
