[ On , June 30, 2003 at 01:16:23 (+0100), Andrew - Supernews wrote: ]
> Subject: Re: [Exim] how to configure HELO/EHLO and DNS for multi-homed hosts
>
> Speaking of which: I thought I informed you that mail from your domain
> to ours was unwelcome due to your refusal to accept responses. Please
> confine your responses to the list only.
If you wish replies to go only to the list then you will please use the
appropriate protocol feature to make that happen (as I do).
> Greg> For Reverse DNS to be complete and correct there _MUST_ be a
> Greg> PTR for every A RR and vice versa.
>
> but this requirement is only in your mind.
I'm afraid not. The full, bi-directional, correspondence between A and
PTR values is inherent in the design of the Reverse DNS and is widely
accepted as true even by those who don't understand graph theory. Those
involved in the design of the DNS and the design and implementation of
DNS related servers and tools have demonstrated their understanding of
this design in their implementations.
I have been intimately involved on a daily basis with both the DNS and
SMTP at all levels (i.e. from way up in the design levels and all the
way down to the low-level bit-bashing) for over a decade now. I really
do know what I'm talking about. You personally don't have to believe me
but you will stop simply calling me a liar without basis as you have
been doing so far.
If you feel you have a different interpretation from the rest of us then
I invite you to write a draft RFC expressing your interpretation and see
how well it is accepted by the majority of the community at large.
Perhaps if you express your view in such a way then it will come to be
the one accepted by the majority of Internet engineers, though I
seriously doubt it. I know you are not alone in your ignorance on these
issues, but those of you who have your view are far from the majority.
> It is quite normal these
> days for hosts to have thousands of A records pointing to them (I know
> of one with well over ten thousand), and no-one would seriously
> suggest that such a host should have thousands of PTR records to
> correspond.
Obviously no-one would seriously try to make use of such a configuration
with _any_ Reverse DNS in the first place.
Indeed nobody with half a clue would create such a configuration in the
first place, but that's a separate set of issues.
> (In fact when misgiuded sites do try and include an
> excessive number of PTR records it often causes considerable problems
> when the PTR lookup no longer fits in a UDP response.)
Huh? Truncated responses _REQUIRE_ retries with TCP which have a
maximum reply size of 65534 bytes. If the TCP query fails then
someone's DNS is broken far worse than just having broken Reverse DNS.
Of course that's not the bigger problem, but you'd have to know the
internals of common DNS resolver implementations to understand why.
> There are two standard cases for validating the correspondence between
> hostnames and IPs:
>
> 1) the protocol provides the hostname; the hostname is valid if an A
> record lookup returns an IP matching the connecting client. PTR
> records are not useful in this case at all.
WRONG. Reverse DNS is there to authenticate the reliability of the A
record. If the PTR set does not include the hostname then the hostname
may be invalid.
It is completely irrelivant from which direction you start. There must
always be a complete and bi-directional graph between the A RRs of the
hostnames and the PTRs of the Reverse DNS.
> while multiple PTRs are allowed, they are rarely either useful or
> necessary, certainly not in this case.
It seems you've missed some important concepts. Please go back and
study the design of the DNS in more detail and try to learn a thing or
two new about it.
> Leaving aside the use of EHLO to discover support for extensions,
> there is no justification whatsoever for your statement. Many things
> are included in SMTP which are not necessary (e.g. HELP and NOOP).
Please go back and study the design of SMTP and please try to learn a
thing or two about it before you make such false claims again. Perhaps
you need more fundamental study of the general design of communications
protocols. Not everything that's important about the implementation of
a protocol is written in its own narrow specification -- many important
concepts and rules of thumb come from the wider accepted world of all
communications protocols in general. The RFCs as protocol standards
specifications are not written to be read in a vacuum -- they must be
read and interpreted in context with everything around them.
> Greg> $ host -v -A mx1.supernews.net
>
> I do not know what utility you have on your system under the name
> "host". On my systems I have the host(1) program from one or other
> version of BIND, which does not match your usage.
Then obviously you have a very out-of-date version of 'host'. Please
upgrade.
> I understand them perfectly. (You apparently don't, since there are at
> least two SHOULD NOT violations in yours; "via" and "with" do not take
> arbitrary values.)
Welcome to the real world. You can't have it both ways. :-)
On the other hand note that what you're complaing about is BETA
software. More recent test code is already much more conformant, as
should be clearly obvious from a new example, especially if one removes
all the non-essential comments as I've done here for your viewing
pleasure:
Received: from proven.weird.com([204.92.254.15] port=59827)
by most.weird.com (port=25)
via TCP with esmtp
id <m19W0iC-000g6RC@???>
for <woods@???>;
Fri, 27 Jun 2003 17:24:52 -0400
:-)
Note that strictly speaking it is Exim which has items in the
"From-domain" section backwards. The HELO/EHLO parameter "MUST" be the
one in the clear while any PTR value and the address literal "MUST" be
the ones in the optional comment.
> Greg> Well, obviously you and they have not tried it then. It works,
> Greg> very well, as it must. There are even similar examples in the
> Greg> RFCs.
>
> where?
Can't you find them yourself? You've tried to point to enough specific
sections of specific RFCs that I assumed you had read the whole RFCs
completely and carfully and in their proper context and not just
searched them for specific references. If you have not read the related
body of RFCs in their entirety despite your claim below then perhaps
that's why you're having a problem understanding what I'm saying.
> I have read them numerous times. Neither the DNS specification RFCs
> nor the various DNS operational/configuration RFCs support your
> position in any way. In particular, when the issue of using A records
> for service names is discussed in BCP 17 (RFC 2219), there is no
> mention of adding additional PTR records.
You are taking things out of context. Please try not to do that.
Note that talking about PTRs alone is tantamount to taking things out of
context. You have to understand how they're intended to be deployed in
the IN-ADRR.ARPA domain to understand the Reverse DNS. PTRs can be used
anywhere, not just in IN-ADDR.ARPA zones. Keep in mind that at least
half of what's been recorded in RFCs about IN-ADDR.ARPA came before
their importance was realized for truly public networks.
> RFC 1917 requires a PTR
> record for each IP, not one for each A record.
Do you really mean RFC 1917, i.e. BCP 4, i.e. the document titled "An
Appeal to the Internet Community to Return Unused IP Networks (Prefixes)
to the IANA"? What does that have to do with PTRs or IN-ADDR.ARPA?
Surely you don't mean 1912, do you? It is just too far off from 1917 on
any keyboard I know to have been a typo, though visually it's just one
stroke away. If you really did mean 1912 then I strongly suggest you
read the WHOLE paragraph you are apparently paraphrasing from and note
that your sentence above is a blatantly misleading and incorrect summary
interpretation:
Make sure your PTR and A records match. For every IP address, there
should be a matching PTR record in the in-addr.arpa domain. If a
host is multi-homed, (more than one IP address) make sure that all IP
addresses have a corresponding PTR record (not just the first one).
Failure to have matching PTR and A records can cause loss of Internet
services similar to not being registered in the DNS at all. Also,
PTR records must point back to a valid A record, not a alias defined
by a CNAME. It is highly recommended that you use some software
which automates this checking, or generate your DNS data from a
database which automatically creates consistent data.
Keep in mind this advice is based on the idea that the DNS is a directed
graph data structure and that if the Reverse DNS is to be used to
validate hostnames (as Bellovin, CERT, et al have strongly recommended
that it be used to do), then it follows that there "MUST" be a matching
PTR in the IN-ADDR.ARPA zone for every A record, as well as a matching A
record for every PTR in the IN-ADDR.ARPA zone. I.e. "Make sure your PTR
and A records [both] match."
I strongly recommend use of the latest version of "host" with the "-A"
option to do that checking, and make sure you check both your hostnames
and your PTRs (i.e. check from both "directions" in the graph). Please
fix all the problems these check reveal until there's no output from
'host -A' when it is given either a hostname or an address.
Remember that the Reverse DNS isn't a protocol per se so much as it is
just a set of data structures containing values supplied by its users.
The format of the fields is specified, but the content is not. You can
build beautiful, elegant, complete, and useful data structures with your
DNS, or you can build ugly, incomplete, and useless ones. The more you
lean to the former and away from the latter the better your DNS will
serve you on the Public Interent. Or as they used to say: Garbage In,
Garbage Out.
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
