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.
[/QUOTE]
A++
PS : si tu expliquais ce que tu cherches à faire véritablement (je veux dire en détails, pour quelle type d'application) cela nous permettrais de te répondre d'une manière plus ciblée ...
[^] # Re: hmmm ...
Posté par Stephane COLIN (site web personnel) . En réponse au message Les PTR, comment ca marche ?!. Évalué à 1.
[QUOTE]
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.
[/QUOTE]
A++
PS : si tu expliquais ce que tu cherches à faire véritablement (je veux dire en détails, pour quelle type d'application) cela nous permettrais de te répondre d'une manière plus ciblée ...