one thing to note is that when the server is authoritative for more than one zone, a cname that crosses from one such zone to another is allowed by 1035 to be chased. however, the resolver has no reason to accept out-of-zone records, since it cannot be sure that a new query in the bailiwick of the second zone would be answered the same way (or by the same server.) after kashpureff, we ignore the out-of-zone data and re-fetch it. this strongly calls for an update to 1035, since akamai and other CDN's are sending multi-zone cname chains, and they need to know that they should not do that, and also, resolver implementers need to know that they should be stripping any answer from the response whose owner name is not in-bailiwick with their QNAME.

DNSOP mailing list

Reply via email to