[ On Friday, February 7, 2003 at 12:01:24 (-0500), James P. Roberts wrote: ]
> Subject: Re: [Exim] Address rewriting vs. CNAME records?
>
> Don't rush on the in-addr.arpa PTR records.
No, he really _MUST_ "rush" on the PTR records. Their correctness and
COMPLETENESS is critical for interaction with other servers using TCP
Wrappers style DNS consistency checks. CRITICAL. His connections will
be denied by some servers if his forward and reverse DNS is not 100%
consistent and complete.
> As far as I know, you need
> only one, and it should point to the canonical hostname for that IP.
Before you give such bad advice you should really do some basic simple
research.
For example you will find in RFC 2181 Section 10.2:
10.2. PTR records
Confusion about canonical names has lead to a belief that a PTR
record should have exactly one RR in its RRSet. This is incorrect,
the relevant section of RFC1034 (section 3.6.2) indicates that the
value of a PTR record should be a canonical name. That is, it should
not be an alias. There is no implication in that section that only
one PTR record is permitted for a name. No such restriction should
be inferred.
> Additional PTR records for reverse lookups don't buy much, other than
> extra book-keeping for you, and confusion for anyone looking up.
If that's what you think then you've missed out on a major facet of how
and why we have PTR records in the first place. A primary reason for
their existence demands that there be one for every A RR that points to
a given address -- without this requirement they would be useless for
inferring any kind of trust about hostnames. The DNS has no real
security and only by careful and complete consistency checking can we
assume anything about a hostname can be trusted.
> Some
> DNS servers will return only a subset of PTR records, in a random order,
> for a given typical reverse-lookup query, in order to avoid sending very
> large answers (i.e. to avoid triggering a TCP response when a UDP
> response will do).
That's completely and totally bogus.
All standards compliant DNS servers will always return all records or
IFF the resolver is using UDP and all records will not fit in a UDP
response then they will set the truncated bit and the resolver is
required to retry using TCP to get a complete answer. Again from RFC
2181:
5.1. Sending RRs from an RRSet
A query for a specific (or non-specific) label, class, and type, will
always return all records in the associated RRSet - whether that be
one or more RRs. The response must be marked as "truncated" if the
entire RRSet will not fit in the response.
9. The TC (truncated) header bit
The TC bit should be set in responses only when an RRSet is required
as a part of the response, but could not be included in its entirety.
The TC bit should not be set merely because some extra information
could have been included, but there was insufficient room. This
includes the results of additional section processing. In such cases
the entire RRSet that will not fit in the response should be omitted,
and the reply sent as is, with the TC bit clear. If the recipient of
the reply needs the omitted data, it can construct a query for that
data and send that separately.
Where TC is set, the partial RRSet that would not completely fit may
be left in the response. When a DNS client receives a reply with TC
set, it should ignore that response, and query again, using a
mechanism, such as a TCP connection, that will permit larger replies.
> The vast bulk of reverse lookups are used to verify only that "at least
> one" record exists.
No, that's not true. You're still missing out on one of the two main
reasons for the existance of PTRs.
(The only other reason for PTRs is to be able to find a hostname for an
address, i.e. when the hostname is not known -- one would still need to
do consistency checks though, i.e. make sure the hostname found does
indeed have a matching address.)
> It would be impractical to sort through what could
> be hundreds or even thousands of reverse lookup records for the same IP
> (for example, from a large virtual domain server), especially when you
> aren't guaranteed to get the full set with a single query.
Well, it's certainly not imparactical -- it's easy and obvious. I've
now written code which does the right thing quite a few times in several
different languages, and it was always very easy to do -- there are no
complex algorithms involved, just simple one-to-one comparisons in both
directions.
While it may be time consuming to look through large PTR RR sets, it's
not the fault of the server doing the checking, but rather the fault of
the idiot who is not using the DNS appropriately.
Virtual domains really should not ever be using A records. They really
should be using MX (for mail domains) _or_ CNAME records (for FTP, HTTP,
etc.). This is one of the main reasons why people use separate names
for separate service (because you MUST NOT have any other records in the
same node with a CNAME). If you have many hostnames all pointing to the
same address, and if you have impartial PTRs for those hostnames, then I
can guarantee 100% that you will have trouble interoperating with other
services.
Remember too that the resolver client is allowed to re-order the answers
in an RRset to suite its own needs.
> And the
> order of multiple records returned for a PTR query is typically
> randomized!
Well, no, that's not right. Normally the DNS does not preserve the
order of RRs. However that's not normally true for PTRs. (It's not
true for any BIND-based nameserver supporting the "rrset-order" option
either.)
However it is VERY important to remember that 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 similar interfaces or
not. That idea of an "official hostname" is an obsolete concept that
only held true in some situations *before* the days of the DNS. The
layout of "struct hostent", for example, 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)
> So you really only need or want the one.
Nope, that's wrong. You need and want one PTR for every A RR with the
same target address. 100% forwards and backwards consistency is
necessary to avoid tripping over DNS consistency checks which can result
in your connections being denied.
> By the way, this is also why it is not practical to demand that a
> reverse IP lookup return the same hostname as a forward lookup that
> returns the given IP (say, for example, when doing reverse lookups at
> SMTP time).
Wrong yet again. If a server is doing any DNS consistency checks then
if there is one or more PTRs, then they MUST all be consistent if you're
to trust any of them. Note this isn't an RFC mandate per se. This is
what TCP Wrappers and other similar DNS consistency checkers do in order
to give some modicum of trust to a hostname for a connected peer, and
thus it has much more weight than a "mere" RFC -- it has a direct impact
on the ability of a host to successfully connect to another host.
If you don't want to use multiple PTRs, then you MUST NOT use any PTRs
if you hope to successfully connect to any site or service doing any DNS
consistency checking on its peers. I.e. it's better to have no PTRs at
all than to have incomplete (or incorrect) PTRs.
> As was pointed out, the same host may have multiple names,
> and there is NO WAY to ensure that a given reverse lookup will return
> the "right" one, and almost certainly not as the first record in the
> response (if there were multiple in-addr.arpa PTR records for a given
> IP).
You're still wrong. It's trivial and easy and is done many times every
day by many servers the world over.
Unfortunately you're not alone in your misunderstanding of PTRs.
Hopefully I can help set you and other straight on this issue.
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
