On adding a wildcard to the .travel TLD
To Lyman Chapin, Chair of ICANN's Registry Services Technical Evaluation Panel. Dear Lyman Chapin, The Internet Architecture Board has become aware of the request by the Tralliance registry to add a wildcard in the .travel TLD zone. We would like to point out that the IAB has published a statement in 2003 [1] outlining the architectural trade-offs of wild-cards in registry- class zones. The conclusions of that statement still hold. There is no indication that the behavior of MTAs and other critical applications has significantly been improved to deal with the presence of wild-cards in TLD zones. Without the intent of becoming involved in judging the merits of this particular case, we want to particularly draw your attention to the guideline and one of the recommendations from our 2003 document: "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." and "... [The IAB] strongly suggest that the burden of proof in such cases [using wildcards in "registry"-class zones] 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." These highlight that there is potential damage for third parties that the registry has contact with ---the entities that are delegated within the zone--- and third parties that the registry does not have contact with --- all Internet users and their applications. For more information please consult the original recommendation [1]. Finally, we refer you to RFC4592, a technical document. It provides a detailed description of how wildcards work. This may or may not apply to the assessment of the Tralliance request depending on the exact resource record types that are added to the wildcarded names.
--Olaf Kolkman Attachment:
PGP.sig |