>>>>> "Greg" == Greg A Woods <woods@???> writes:
Greg> I'm afraid not. The full, bi-directional, correspondence
Greg> between A and PTR values is inherent in the design of the
Greg> Reverse DNS and is widely accepted as true even by those who
Greg> don't understand graph theory. Those involved in the design of
Greg> the DNS and the design and implementation of DNS related
Greg> servers and tools have demonstrated their understanding of this
Greg> design in their implementations.
Funny; I know of a number of DNS tools (from both sides of the DNS
religious divide: e.g. tinydns itself, and from the BIND camp the h2n
script that used to be part of the BIND distribution) that actively
encourage the creation of A records without corresponding PTRs. Of
course, you will now retort that those tools are broken; which of
course will leave everyone wondering which tools you consider
non-broken (unless you break with all your previous habits and
actually specify them).
Greg> I have been intimately involved on a daily basis with both the
Greg> DNS and SMTP at all levels (i.e. from way up in the design
Greg> levels and all the way down to the low-level bit-bashing) for
Greg> over a decade now.
Am I supposed to be impressed? (hint: I'm not)
Greg> If you feel you have a different interpretation from the rest
Greg> of us then I invite you to write a draft RFC expressing your
Greg> interpretation and see how well it is accepted by the majority
Greg> of the community at large.
I see no reason to do this, since your viewpoint on this issue is not,
despite your unsupported assertions to the contrary, the majority
view. This is amply shown by such impartial evidence as our outgoing
mail log, in addition to the feedback I've had from discussing your
ideas with others. In fact the majority opinion I've encountered is
that you are a loon best ignored rather than argued with, and I'm
rather inclined to start respecting this point of view. (arguably I
should have done so several messages ago)
>> 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.
Greg> Obviously no-one would seriously try to make use of such a
Greg> configuration with _any_ Reverse DNS in the first place.
why not?
The most extreme example is the host futuresite.register.com, which as
of earlier this year had something like a million A records pointing
to it _solely_ from <domain>.{com,net,org} or www.<domain>.{com,net,org}.
The reverse lookup for that host provides useful information in itself;
there is no logical or operational reason to omit the PTR record for it.
Greg> Indeed nobody with half a clue would create such a
Greg> configuration in the first place, but that's a separate set of
Greg> issues.
do enlighten us on your proposed alternative.
>> 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.
Greg> WRONG. Reverse DNS is there to authenticate the reliability of
Greg> the A record. If the PTR set does not include the hostname
Greg> then the hostname may be invalid.
You will notice that when I pointed out exim's incorrect handling of
multiple PTRs I detailed exactly why it was incorrect by showing an
example.
If a client IP asserts an association with some hostname, then it is
sufficient for validation purposes to confirm that the hostname
forward-resolves to the client IP. The loop between hostname and IP
can be closed _either_ by a PTR record _or_ by the connecting IP
providing the hostname via the protocol.
On the other hand, if I'm wrong and you're right, you will have no
problem coming up with a counterexample, surely?
Greg> It is completely irrelivant from which direction you start.
Greg> There must always be a complete and bi-directional graph
Greg> between the A RRs of the hostnames and the PTRs of the Reverse
Greg> DNS.
argument by repeated assertion; dismissed
>> 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).
Greg> Please go back and study the design of SMTP and please try to
Greg> learn a thing or two about it before you make such false claims
Greg> again.
more unsupported assertion
Greg> Perhaps you need more fundamental study of the general design
Greg> of communications protocols.
I have been working professionally in the communications field for far
longer than your own claimed experience.
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.
Greg> Then obviously you have a very out-of-date version of 'host'.
Greg> Please upgrade.
I see from the comments of others that you are maintaining what you
consider to be the up-to-date version. Obviously, I would therefore
expect it to reflect your own biases in this matter and therefore it
is irrelevent to the argument.
>> 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.)
Greg> Welcome to the real world. You can't have it both ways. :-)
you seem to want to...
Greg> On the other hand note that what you're complaing about is BETA
Greg> software. More recent test code is already much more
Greg> conformant, as should be clearly obvious from a new example,
such as this one from the headers of the message to which I am
responding?
Received: from localhost (11261 bytes) by proven.weird.com
via sendmail with STDIO
(sender: <woods>)
(ident <woods> using UNIX)
id <m19Wowa-000B40C@???>
for <exim-users@???>;
(dest:remote)(R=bind_hosts)(T=inet_zone_bind_smtp)
Sun, 29 Jun 2003 23:03:04 -0400 (EDT)
(Smail-3.2.0.116-Pre 2003-Jun-18 #9 built 2003-Jun-29)
[multiple PTRs]
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?
Greg> Can't you find them yourself?
Your definition of "similar" is obviously different to mine; that
makes it impossible for me to divine precisely what you are referring
to. Rather than resort to guesswork, I ask you for a specific
reference, and you evade rather than responding; hardly a compelling
argument.
Greg> You've tried to point to enough specific sections of specific
Greg> RFCs that I assumed you had read the whole RFCs completely and
Greg> carfully and in their proper context
which indeed I have, though not all of them in the last few days
>> 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.
Greg> You are taking things out of context. Please try not to do that.
It's a specific citation of a point at which those PTR records
_should_ have been mentioned if exact one-to-one correspondence was as
significant as you claim.
Greg> Note that talking about PTRs alone is tantamount to taking
Greg> things out of context. You have to understand how they're
Greg> intended to be deployed in the IN-ADRR.ARPA domain to
Greg> understand the Reverse DNS. PTRs can be used anywhere, not
Greg> just in IN-ADDR.ARPA zones. Keep in mind that at least half of
Greg> what's been recorded in RFCs about IN-ADDR.ARPA came before
Greg> their importance was realized for truly public networks.
Then, surely, once that importance was realized there would be mention
of it in at least some documentation, if not in the RFCs then at least
in the operations guides, FAQs, etc. for popular DNS server software?
(hint: none of this documentation supports your position either)
>> RFC 1917 requires a PTR record for each IP, not one for each A
>> record.
Greg> Do you really mean RFC 1917
no, I meant RFC 1912 of course
[snip paragraph from that RFC]
Greg> Keep in mind this advice is based on the idea that the DNS is a
Greg> directed graph data structure and that if the Reverse DNS is to
Greg> be used to validate hostnames (as Bellovin, CERT, et al have
Greg> strongly recommended that it be used to do),
I took a quick scan through Bellovin's papers to see what he actually
recommended; so far, I have found nothing whatsoever that suggests the
use of rDNS to validate hostnames. The paper "Using the Domain Name
System for System Break-Ins", the most obviously relevent, does
address the use of _forward_ (A record) lookups to validate the
reverse lookup (a technique it rightly describes as "mandatory", while
nevertheless showing how even that could be penetrated given the state
of the DNS at that time, using poisoning techniques). A couple of the
other papers refer in passing to this same issue.
So, please cite a specific source for your "strongly recommended"
statement above.
Greg> then it follows that there "MUST" be a matching PTR in the
Greg> IN-ADDR.ARPA zone for every A record, as well as a matching A
Greg> record for every PTR in the IN-ADDR.ARPA zone. I.e. "Make sure
Greg> your PTR and A records [both] match."
But here you are deliberately changing the meaning by inserting your
own assumptions as a precondition. The paragraph as written, without
assuming your conclusions, merely requires a PTR for each IP in use
and a matching A record for each PTR. This does not imply your
conclusion and therefore your argument is faulty.
--
Andrew, Supernews
