Aaron Wolfe wrote:
> On Sun, Jun 28, 2009 at 8:15 PM, Edgar Lovecraft<exim-list@???> wrote:
>> On Sun, 28 Jun 2009 12:23:38 -0400 Aaron Wolfe <aawolfe@???> wrote:
>> ..<snip snip>...
>>> Last I checked into this issue, the RFCs do not explicitly allow or
>>> disallow multiple PTRs. This translated to inconsistent behavior in
>>> the real world as some resolvers can understand them and some can't.
>>> Unless things have changed, I don't think quite legal or less common is
>>> really the correct term for this, more like good luck and say a prayer.
>>> But maybe something new has happened?
>>>
>>>
>> Actualy, the RFCs are very clear that multiple PTR records are allowed for
>> single IP addresses.
>>
>> Refernces:
>> RFC 2181 Section 10.2
>>
>> RFC 1034 Section 5.2.1 sub-section 2
>> "A type PTR query is used to get the RR with the primary name of
>> the host. For example, a request for the host name
>> corresponding to IP address 1.2.3.4 looks for PTR RRs for
>> domain name "4.3.2.1.IN-ADDR.ARPA"."
>>
>> Please take note of the "looks for the PTR RRs", 'resouce records', not
>> just 'resource record'.
>>
>
> Yes, I remember this and this is the part that isnt clear, isn't it?
> Not trying to restart any kind of debate, but doesn't this reference
> also mention "the RR" with "the primary name", both singular? English
> can be unclear. Consider the phrase, "I'm driving down the street
> looking for houses with the address 123", which maybe isn't a great
> example but hey i'm not a cunning linguist.
>
> Regardless, the important thing, and what I was interested in most was
> whether the behavior was now more consistent. This is what matters
> if you're going to use them. Can we trust that multiple PTRs will
> mostly work on most platforms now? As in the resolvers will return
> multiple results, and most software will sift through many results
> instead of just taking the first one? This did not seem to be the case
> a couple years ago.
>
> -Aaron
>
>
>> ..<snip snip>...
>>
>> --
>>
>> --EAL--
>>
>> --
>>
Agree it *was not* the [general] case until fairly recently, where '..recently'
seesm to be about 2 or 3 years.
Though Exim has had the code to build lists etc for far, far, longer, a simple
'host [IP number]' on one I run with 3 domain.tld pointed to used to return a
different one - but only - one - at each go. For about two years now it has
returned all three.
What has changed? Well - first off, I'm at FreeBSD 6.X or 7.X, no longer at
4.11, so the 'host' utility code is probably different. Secondly, my upstream.
where the records are stored, has at least twice upgraded their DNS software,
though I know not from what or to what.
Pure speculation here, but one of the drivers MAY have been hangover from the
dot-com 'bust'.
Going into it, it was a clear bet that 'the world' would soon exhaust IPV4
address space - yet IPV6 which would (among other things) once again provide
plentiful IP addresses was nowhere near gaining universal acceptance, and still
is not.
Further - plentiful or not, larger IP blocks were not going to be 'free' at the
end-point of distribution - ISP/Co-Loc or other IP-block holder who want at
least admin fees for putting them into their all-important router tables even if
one has registered for a block of their own.
Result?
Globally, folks seem to have paid attention to more flexible NAT, routing, and
DNS improvements to make better use of such IPV4 address space as was already
in-hand. 'belt tightening' so to speak.
As said - speculative.
But the reality IS largely in-place, and not just within Exim.
We have yet to be rejected on PTR RR or HELO mismatch. Though - to be fair,
while favorite filtering tools of *ours*, many others would seem to pefer to
take onboard all-comers, even from dynamic-IP blocks, then concentrate on
content scanning.
Conversely, we've been running w/o SA or such *at all* on a test server, (still
have ClamAV) and may soon be able to drop SA (hence perl) entirely.
Not that it isn't useful or accurate - but because the remaining traffic it
blocks has become vanishingly small and the absence would mean going from one
sequestered spam per user per every third day to two or three a day, worst-case
- either number being well within the tolerance range of the Mark One eyeball.
Differences in user-community can be as great as any other factor, so 'YMMV'
Bill
