Re: Many A-records

Barry Margolin <barmar@alum.mit.edu> writes:
>In article <c52vmm$1c1u$1@sf1.isc.org>, "fih" <frhak@hotmail.com>
>wrote:
>
>> Good point!
>>
>> I have been spending hours about this discussion the latest days. More and
>> more I'm convinced that how i work and always have worket is fine. But i
>> have to admit that there is no rules against having more than one A-record
>> which i always have believed.
>>
>> My current thoughts leads to questions like. Ok if they use A-records
>> instead of Cnames i wonder what they do about the PTR records. I heave read
>> that it's OK to have multiple PTR records. But for applications that uses
>> A-records and PTR-records i guess it will not work. Examples i can think of
>> is Sendmail, NFS and Backup solutions. (I could be wrong here, if a resolver
>> recieves a list of PTR records it might be so that it will check for the
>> proper one, i don't know)
>
>As long as every PTR record has a matching A record, it's OK. You don't
>have to have a PTR record for every A record. So the following is a
>good setup:
>
><name1> A 1.2.3.4
><name2> A 1.2.3.4
><name3> A 1.2.3.4
>4.3.2.1.in-addr.arpa. PTR <name1>

To expound on Barry's usual excellent posting.

Sendmail, etc, systems that do reverse lookups on clients do the
following:

Take the IP of the client (which is a feature of the IP connection,
so you always have that)
Look up the PTR record for the IP (which gets you back some hostname)
Look up the A record for that hostname (which gets you back 1+ IP
addresses)
If the original client IP doesn't appear in the list of A records that
come back, deny access or scream and yell or whatever.

Note that this works just fine with a setup like Barry's.

1.2.3.4 connects
The PTR lookup yields <name1>
The A lookup on <name1> gets you back 1.2.3.4
The addresses match.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Alan Schwartz <alansz@uic.edu>
Author of: "Managing Mailing Lists", "Stopping Spam" (Schwartz & Garfinkel),
"Practical Unix & Internet Security, 3rd Ed" (Garfinkel, Spafford, Schwartz)
Published by O'Reilly and Associates, Inc. (http://www.ora.com)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-