Many A-records

[Alan Schwartz]

Barry Margolin  <barmar at alum.mit.edu> writes:
>In article <c52vmm$1c1u$1 at sf1.isc.org>, "fih" <frhak at 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 at 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)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-