Re: [Exim] how to configure HELO/EHLO and DNS for multi-home…

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Exim Users Mailing List
Fecha:  
A: Andrew - Supernews
Cc: Exim Users Mailing List
Asunto: Re: [Exim] how to configure HELO/EHLO and DNS for multi-homed hosts
[ On , June 30, 2003 at 12:42:35 (+0100), Andrew - Supernews wrote: ]
> Subject: Re: [Exim] how to configure HELO/EHLO and DNS for multi-homed hosts
>
> 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.


Well you can partly blame yourself and people like you for that problem.

If folks like you who would just as well have an ugly, incomplete,
disconnected, inelegant, and almost useless Reverse DNS continue to
spout your viewpoint loud enough and in enough places then there will
continue to be people who continue to follow your lead and implement
half-baked tools.

(Of course there's also the problem of people who just jump in feet
first and with their eyes and minds closed and don't care about how
things are supposed to work. They just make their tools work any old
way that suits them. Examples of these type abound -- there are several
high-priced fancy virtual domain management systems that insist on using
CNAMEs in NS and/or MX targets.)

> 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}.


I see you're really stretching. Using broken and bogus configurations
to justify your postion does not help your cause.

> 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.


I and many others have demonstrated the proper approach many times in
the past. Go do your own research.

> On the other hand, if I'm wrong and you're right, you will have no
> problem coming up with a counterexample, surely?


Why do I have to keep repeating myself?

$ host -A trinity.supernews.net
*** trinity.supernews.net address 216.168.2.22 maps to hostname trinity.delta.supernews.net
*** Hostname trinity.supernews.net does not belong to address 216.168.2.22
*** trinity.supernews.net address 216.168.1.22 maps to hostname trinity.ranger.supernews.net
*** Hostname trinity.supernews.net does not belong to address 216.168.1.22
*** Not all addresses for hostname trinity.supernews.net have a matching hostname.


> 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.


Oddly the way 'host' works is not my invention -- I've just improved the
error messages.


> 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.


No, it is an out-of-context refernce. You can play these stupid
citation games all you want -- they won't get you anywhere but
downhill. If you ignore the proper context and you will most certainly
end up mis-interpreting the implications of the details, and that is
exactly what you continue to do.

> 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.


I changed no meaning whatsoever -- I simply paraphrased using the
greater context provided by related documentation.

So far all we've learned is that you would rather argue the case for the
ugly, the incomplete, and the inelegant; at least when it comes to the
Reverse DNS. I prefer to be much more positive approach myself.

--
                                Greg A. Woods


+1 416 218-0098;            <g.a.woods@???>;           <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>