On 10/01/02, Nathan E Norman wrote: > On Fri, Jan 11, 2002 at 01:29:08AM +0100, martin f krafft wrote: > > first, the IP is taken and reverse-resolved to a domain name. then the > > domain name is resolved to an IP. if that IP doesn't match, it'll DENY.
> > now if 1.2.3.4 were to point to mail.madduck.net, but mail.madduck.net
> > points to 1.2.3.5, then that's obviously a problem, or indication of an
> > error status, or a hint at a hack/spoof attack... until you realize what
> > BIND and others do with simply RR load-balancing:
> > zone IN 3.2.1.in-addr.ARPA:
> > 4 IN PTR mail.madduck.net
> > 5 IN PTR mail.madduck.net
> > zone IN madduck.net
> > mail.madduck.net IN A 1.2.3.4
> > IN A 1.2.3.5
> > now repeated queries for the A record of mail.madduck.net will return
> > both IPs alternatingly. now think about why this would cause a problem.
> Congratulations ... you just set up your DNS incorrectly. Every PTR
> entry should resolve to a _unique_ name, and that name should resolve
> to a _unique_ IP. That doesn't mean you can't have additional A
> records doing load balancing.
Pardon? Would you please cite that paragraph of the RfCs that states
that "every PTR entry should resolve to a _unique_ name"? The last time
I read in the RfC and in another book about DNS both didn't mention
that. And according to my knowledge it's possible to have such a zone
entry as Martin described it above. If I'm not mistaken even some
examples in the RfCs 1034 and 1035 show this. So would you please show
some evidence?
Christian
--
Debian Developer (http://www.debian.org)
1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853
msg04807/pgp00000.pgp
Description: PGP signature
