Multiple PTR''s

Re: Multiple PTR''s

From:

Date:

Time:

At 2:22 PM -0600 12/3/99, Steve Dannaway wrote:
>Hello,
>
>I'm running into something interesting on the reverse domain. I have
>several clients who have purchased multiple addresses (domain.com and
>domain.org). They want to use a domain and top level domain as their
>web address only (i.e. domain.com rather than www.domain.com). So in
>order to do this and stay within DNS guidelines, I have domain.com set
>as an A record in each of their domains (with the corresponding FQDN
>CNAME'd over to it).
>
>What happens in the reverse is a PTR record is created for the .com and
>not the .org. I can't go in and add a PTR for the .org domain and stay
>within the guidelines (if I've read them correctly). If I don't have a
>PTR for the .org, DNS Expert flashes an error message.
>
>Is there any way I can resolve this without changing what my clients
>want or modifying the DNS Expert settings, or is this just a smile and
>nod when someone tells me I've got things set wrong?

DNS Expert is a little overzealous with PTR record errors. So long as you have one valid PTR record for every address in use, everything's fine.

A "valid" PTR record is one which resolves to a name which resolves back to the address. For this reason, your PTR records shouldn't use names that resolve back to multiple addresses.

Reasoning behind all this (read on only if you care):

There's no rule in the RFC's saying that there must be a PTR record for every A record, though it is listed as a design goal. It also never says that you can't have multiple PTR records for a given address; unfortunately, doing so creates havoc. The reason for this is the way that records are reported and recognized.

Suppose you have multiple PTR records for a given address. Then this happens:

1) A request is made for PTR records for the address, by something trying to verify one of the hostnames.

2) The server treats the set of PTR records in round-robin, "load sharing" the results. In effect, it reorders the records in an essentially random permutation, and reports them all.

3) The requester sees a stack of records, but only reads the first one. The rest are assumed to be supporting records (NS records, etc.). Thus the result is a randomly-chosen record from the set of PTR records.

4) There is little chance that the resulting name matches the name that was started with.

A similar problem occurs if the name given in the PTR record resolves back to multiple addresses. This would occur if, for example, Netscape's download manager, in trying to verify eligibility to download 128-bit encryption versions of their software, attempts to break through fake PTR records by verifying that the name then resolves back to the address.

The only effective way to achieve the design goal of a one-to-one correlation between A records and PTR records is to never have more than one A record per address. This means that you can't have both company.com and company.org resolve to the same address (because neither can be a CNAME alias), meaning that if they are to have the same website, you need to have some mechanism that puts them together despite being on separate addresses.

This practice is part of what lead to the current shortage of addresses, which is what prompted the W3C to endorse the WebSTAR-style virtual hosting system as the preferred method of putting multiple websites on one server.
____________________________________________________________________
Chris Buxton cbuxton@menandmice.com
Men & Mice http://www.menandmice.com
Makers of: QuickDNS Pro

Sales:
888/4-DPOINT

Support:
858/452-3696