The Internet Architecture Board’s Commentary on “Architectural Concerns on the Use of DNS Wildcards” raises several points regarding implications of Verisign’s deployment of the SiteFinder services.
1. SiteFinder affects many applications other than the Web, including Email.
2. SiteFinder disables various spam filters.
3.. SiteFinder disables foreign language error screens, replacing them with the English langauge SiteFinder site.
In conclusion, we would like to propose a guideline for when wildcard records should be considered too risky to deploy, and make a few recommendations on how to proceed from here.
Proposed guideline: If you want to use wildcards in your zone and understand the risks, go ahead, but only do so with the informed consent of the entities that are delegated within your zone.
Generally, we do not recommend the use of wildcards for record types that affect more than one application protocol. At the present time, the only record types that do not affect more than one application protocol are MX records.
For zones which do delegations, we do not recommend even wildcard MX records. If they are used, the owners of zones delegated from that zone must be made aware of that policy and must be given assistance to ensure appropriate behavior for MX names within the delegated zone. In other words, the parent zone operator must not reroute mail destined for the child zone without the child zone’s permission.
We hesitate to recommend a flat prohibition against wildcards in “registry”-class zones, but strongly suggest that the burden of proof in such cases should be on the registry to demonstrate that their intended use of wildcards will not pose a threat to stable operation of the DNS or predictable behavior for applications and users.
We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity.