[ On , June 27, 2003 at 23:30:58 (+0100), Andrew - Supernews wrote: ]
> Subject: Re: [Exim] how to configure HELO/EHLO and DNS for multi-homed hosts
>
> What _isn't_ true is that you can do a PTR lookup on the IP to get the
> name in the HELO. This is not required by any language in any RFC,
> without creative re-interpretation that ignores completely the intent
> of the specification.
Sorry to spoil your litle game, but you've apparently failed to notice
that the SMTP greeting name is a host domain name, i.e. something that
resolves to at least an A RR. For Reverse DNS to be complete and
correct there _MUST_ be a PTR for every A RR and vice versa. The
Reverse DNS is useless and misleading if this is not the case. In fact
given the normal use of the Reverse DNS to authenticate hostnames, it's
impossible to tell the difference between a missing PTR and a spoofed
hostname.
If you want to connect to any of my systems, using any TCP application
protocol (not just SMTP, but not yet including HTTP), and if you or your
ISP publish Reverse DNS for your source address, then I will verify its
correctness and completeness and if that test fails I will reject your
connections. If the protocol requires your host send its hostname then
I will validate it against any available Reverse DNS as well. If you
want to use Reverse DNS then you MUST use it correctly or _you_ lose.
Note that this tried and true means of hostname validation has been
extrememly widely implemented. I believe it may have been Steve
Bellovin who first suggested it, though the most widely used
implementation is perhaps that in TCP Wrappers.
> It's also likely to be false in many common
> cases that occur in practice (two examples already given in this
> thread).
It only causes problems for people who are blind to the fact that
multiple PTRs are allowed and necessary.
> Being pedantic about the HELO parameter in SMTP is one of the clearest
> examples of this. The HELO value is purely documentary, it plays no
> part in the process of exchanging mail other than to be recorded in
> logs or Received: headers.
Sorry to blow another hole in your game. HELO is a vital part of the
SMTP protocol -- it would have been omitted if it were not necessary.
(and no, I'm not going to repeat its purposes here again -- look it up)
> No. This is why: because in at least 90% of cases where a PTR lookup
> is performed, the program doing the lookup is only interested in _a_
> name for the IP and not _all_ names.
However if you don't have the right name in the PTR RR set, how the hell
is such a program supposed to find it?
Incomplete Reverse DNS is broken -- it is worse than no Reverse DNS at all.
> If multiple PTR records are
> present, such programs will use an arbitrary one.
"use"?!?!?! What do you mean by "use"? Most programs search the
Reverse DNS for matches -- they don't "use" the values looked up for
anything but comparison against hostnames they already know. Those that
start with the address and then look up the PTR to find the name, may
then look up the name to ensure it has an A record matching the address
in question (if they care to validate the name), but not every program
starts with an address when it validates the Reverse DNS!
$ host -v -A mx1.supernews.net
Query about mx1.supernews.net for record types A
Hostname mx1.supernews.net maps to address 216.168.1.22
Hostname mx1.supernews.net maps to address 216.168.2.22
Found 2 addresses for mx1.supernews.net
Checking mx1.supernews.net address 216.168.1.22
*** mx1.supernews.net address 216.168.1.22 maps to hostname trinity.ranger.supernews.net
*** Hostname mx1.supernews.net does not belong to address 216.168.1.22
Checking mx1.supernews.net address 216.168.2.22
*** mx1.supernews.net address 216.168.2.22 maps to hostname trinity.delta.supernews.net
*** Hostname mx1.supernews.net does not belong to address 216.168.2.22
*** Not all addresses for hostname mx1.supernews.net have a matching hostname.
$ host -v -A mx2.supernews.net
Query about mx2.supernews.net for record types A
Hostname mx2.supernews.net maps to address 216.168.2.22
Hostname mx2.supernews.net maps to address 216.168.1.22
Found 2 addresses for mx2.supernews.net
Checking mx2.supernews.net address 216.168.2.22
*** mx2.supernews.net address 216.168.2.22 maps to hostname trinity.delta.supernews.net
*** Hostname mx2.supernews.net does not belong to address 216.168.2.22
Checking mx2.supernews.net address 216.168.1.22
*** mx2.supernews.net address 216.168.1.22 maps to hostname trinity.ranger.supernews.net
*** Hostname mx2.supernews.net does not belong to address 216.168.1.22
*** Not all addresses for hostname mx2.supernews.net have a matching hostname.
> Using a non-unique
> value in the PTR record as you suggest would mean that in about half
> of all cases where the rDNS name was recorded, it would be recorded in
> such a way that it did not identify the interface used, which defeats
> the whole purpose of having separate names.
Obviously you don't understand the rules of the "Received:" header.
As for "the interface used", well if you've not recorded both the
hostname used/discovered _and_ the IP address, then your logs are as
good as garbage anyway (at least for the purpose of auditing).
(and most times the PTR RR set is not rotated since most nameservers run
versions of BIND that don't do round-robin on PTRs)
(and whether you want the interface name or the service name logged
depends on your situation, but in the received header you definitely wan
the common service name logged along with the IP address in a comment)
> I mentioned your suggested scheme to a number of other experienced
> mail and DNS admins and they were unanimous in their disapproval.
Well, obviously you and they have not tried it then. It works, very
well, as it must. There are even similar examples in the RFCs.
> If that were the case I would expect it to be documented as such,
> which it is not.
It is -- RTFRFCs again! The DNS was most definitely designed to be used
this way. Use it correctly or _you_ lose _your_ interoperability. :-)
Maybe you don't understand the underlying design of the DNS deeply
enough and how the Reverse DNS fits into the picture, but to anyone who
does this is blatantly obvious.
You can be a stick in the mud w.r.t. the Reverse DNS and it won't be any
skin off my nose, but beware that people won't stop using the Reverse
DNS the way it was designed to be used despite your lacking
implementation of it.
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
