On Fri, Jan 11, 2002 at 11:52:15AM +0100, Christian Kurz wrote: > 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? Everything that is possible is not necessarily a good idea. However, I must admit I was talking from memory; I'm travelling at the moment and don't have time to read the RFCs, but I am sure you won't find the statement there. I am sure I read it somewhere, perhaps Cricket Liu's book, I don't remember. it made a strong impression on me as a "Best Practice". If you are offended by such a categorization ... The point is though, it's common sense that in most cases, you want a PTR to resolve to a unique A record. There is an exception which I should have thought of before I sent my email since I employed the tactic: if you've been assigned a large netblock (we had an /18) you may want to set up PTR records for IPs that are not in use or have not been assigned to customers to resolve to something funky. Thus several hundred IPs resolved to "nobody.domain.com" (replace domain.com with the domain where I worked :); the idea being if someone spoofed an address from our domain and chose one that wasn't being used, they'd get a an unresolvable A record from a PTR lookup. Otherwise, in all cases, I used subdomains to ensure that PTR records would always resolve, no matter what A records were added later. Very few customers asked for in-addr.arpa delegation, a select few asked specifically for RFC2317 in-addr.arpa which I was happy to grant. Regards, -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Ltd. | than a perfect plan tomorrow. mailto:nnorman@micromuse.com | -- Patton
Attachment:
pgp8NBYcQWQp8.pgp
Description: PGP signature