[ On Wednesday, April 3, 2002 at 09:06:42 (+0100), John Horne wrote: ]
> Subject: Re: [Exim] Exim4: helo_verify/host_lookup reverse lookups
>
> On 03-Apr-2002 at 02:33:32 Greg A. Woods wrote:
> > Nope -- PTR records are supposed to always be returned in the same order
> > they're listed in the zone file, and in most DNS resolver APIs the first
> > one is known as the "official" hostname. Ideally that'll be the name
> > the host knows of itself as (i.e. w.r.t. SMTP the one it puts in the 220
> > banner it gives to connecting SMTP clients and the one it uses as the
> > HELO/EHLO parameter when it connects to SMTP servers).
>
> I don't think so:
It is the way BIND is (at least from ~4.9.6 through to 8.2.x)
implemented..... but....
Yes, RFC 1034 originally stated generally (in several places, but this
is, I think, the canonical quote):
The order of RRs in a set is not significant, and need not be
preserved by name servers, resolvers, or other parts of the DNS.
On the other hand there are several IETF IDN draft documents (ostensibly
expired) suggesting that with I18N DNS we'll need to preserve the order
of PTR RRs so that old software which can only handle ASCII names will
always be able to find the ASCII name in the first record returned....
However I agree with your observations that it's not this way for at
least two of the nameservers for that particular zone.
Indeed I posted the following last year in another semi-related forum:
There is not really any such thing as an "official name", at least
not in the DNS, whether one is claimed to be returned by
gethostbyaddr() or not. That's an obsolete concept that only held
true in some situations *before* the days of the DNS. The layout of
"struct hostent" is done the way it's done only for purposes of
backwards compatability with pre-DNS software.
Multi-named hosts (i.e. hosts with one IP address and many canonical
hostnames that point to that IP#) are very very very common, and
they will only become more common. mail.weird.com and
most.weird.com are a perfect example! :-) (this same physical host
is also multi-homed in that it has multiple addresses too, but those
two names point to the same address and there are two associated
PTRs, one for each name)
Yes it is possible to say that the first PTR is the "official" name,
and that'll work with most DNS resolvers and servers since the PTR
RR set is supposed to be returned in the order it is given in the
master zone file. However expecting this to all hang together and
work reliably in the same way every time in every scenario is
perhaps not very realistic.
It isn't necessary to try to find an "official" hostname for the
client in any case since it's just as easy to simply scan all the
PTR RRs and to also look up all of the specified names to ascertain
their validity (see below). When using hostname-based access checks
any one rejected hostname is sufficient to reject the client (even
if another name is accepted, I would think).
As to why this particular example isn't following
$ host -t txt -c ch version.bind dns1.plymouth.ac.uk
version.bind TXT "Unknown"
!!! version.bind TXT record has zero ttl
That's suspiciously looking like a hacked version of BIND-4 or BIND-8,
or mabye it's a recent BIND-9 with a customised version configured into
it -- but IIRC the only versions that scrambled PTR records were very
early ones..... (I've not tested BIND-9 in this regard -- I'll have to
get it running on my test server again....)
The other two seem to be working OK, at least for the series of queries
I tried against them. They both always return 'mail.plymouth.ac.uk' first.
They either are not running BIND, or are running a version hacked to
ignore version queries, or are running BIND-9 and are filtering queries:
$ host -t txt -c ch version.bind dns1.cs.strath.ac.uk
Nameserver dns1.cs.strath.ac.uk not responding
version.bind TXT record in class CH not found, try again
$ host -u -t txt -c ch version.bind dns1.cs.strath.ac.uk
Nameserver dns1.cs.strath.ac.uk not responding
version.bind TXT record in class CH not found, try again
$ host -t txt -c ch version.bind dns2.cs.strath.ac.uk
Nameserver dns2.cs.strath.ac.uk not responding
version.bind TXT record in class CH not found, try again
$ host -u -t txt -c ch version.bind dns2.cs.strath.ac.uk
Nameserver dns2.cs.strath.ac.uk not responding
version.bind TXT record in class CH not found, try again
BTW, in that same posting I quote from above I also outlined a fairly
generic algorithm for managing hostname and DNS based checks for an SMTP
server:
1. check the greeting name against the approriate specified
access list (and if the list (can) contain(s) IP#s then check
the source address too)
2. look up the address(es), i.e. A RR(s) of the greeting name:
a) Optionally reject if no valid A RR(s) are returned.
b) Optionally reject if no A RR matches the source address of
the client connection.
3. look up the PTR RR(s) for the source address of the client
connection:
a) check both the source address and *all* of the names given
in the PTR RR(s) against the appropriate specified access
list.
b) Optionally reject if there are no valid PTR RR(s)
returned.
c) Optionally reject if no PTR RR(s) specify a hostname which
matchs the name given in the greeting.
4. Look up the A RR(s) for the name(s) given in the PTR RR(s):
a) Optionally reject if all of the PTR-specified hostnames
are not valid, i.e. a hostname has no valid A RR(s).
b) Optionally reject if at least one A RR from each hostname
does not match the client source address (i.e. the address
from which the PTR RR(s) were queried in #3).
For generic e-mail purposes 3.b is probably still too strict to use
by default, though I know several people (not me!) who are enforcing
it now, and they claim relative success (they are not ISPs though).
If the DNS associated with each client is 100% consistent and
RFC-conformant then the above checks will all pass just fine, and
given that I successfully receive e-mail from several hundreds of
unique remote clients every week (and simultaneously reject many
thousands of spams automatically) even after implementing and
enabling all of the remaining checks in Smail, they can all be
considered well within reason.
In fact 4.a (and 3.c assuming 2.b is met) is (/are) absolutely
required by the DNS specifications and maybe shouldn't even be an
option (provided that there are PTRs, of course, given 3.b).
4.b may be a bit too restrictive to use by default too (and goes
beyond what TCP Wrappers does -- Smail now does this check, but I
may have to add an option variable to allow it to be disabled).
Many people have tried (unsuccessfully given the evidence I've
collected over the past few years) to argue that 2.b is generically
too restrictive (and of course strictly speaking it does violate the
out- dated, poorly designed, self-contradictory, and extremely gross
mis-application of the robustness principle in the second
requirement in RFC 1123 section 5.2.5). As I say though I have not
found this check to be too restrictive in most non-ISP scenarios.
(Note that 2.a is arguably well within the 'syntax' requirements and
thus does not violate RFC 1123 #5.2.5 in any way, so perhaps need
not even be optional.)
--
Greg A. Woods
+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
