Skip to main content

Response to your letter of August 4, 12 August 2004
statement-iab-2004-08-12-icann-wildcard-01

Document Type IAB Statement
Title Response to your letter of August 4, 12 August 2004
Published 2004-08-12
Metadata last updated 2023-12-14
State Active
Send notices to (None)
statement-iab-2004-08-12-icann-wildcard-01
Date: Thu, 12 Aug 2004
From: Harald Tveit Alvestrand, IAB Spokesman
To: Paul Twomey, CEO ICANN
Cc: IAB
Subject: Response to your letter of August 4

Thank you for your note of the 4th August, concerning the ICANN Security and Stability Advisory Committee’s recently completed report on the change VeriSign introduced into the COM and NET domains last September.

You have requested that the IAB verifies your interpretation of
previously published IAB comments with regard to the issues described above and correct this interpretation if necessary.

It is always difficult to summarize an already summarized position – what the summary section of the IAB commentary said was:

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 that 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.

The IAB finds it difficult to make a shorter statement that says exactly the same thing, so we would rather have ICANN formulate any public statement as “Based on the IAB’s recommendation, ICANN thinks that…” instead of “We interpret the IAB as having said that….”. Reviewing the points below should make it clear why this is our preference.

Speaking to the specific bullets in your message:

“The IAB believes that the unrestricted use of wildcards with arbitrary DNS records in arbitrary zones is unwise and should be prohibited as a policy matter.”

It should be clear from the note above that there are many instances where we do not recommend the use of wildcards. But we have not recommended any specific mechanism to make people follow our recommendations, such as a policy of prohibiting them – that is not something we chose to speak about.

If you stop the sentence after “unwise”, it is consistent with the IAB statement (for some reasonable interpretations of “arbitrary”).

“The IAB does not believe that it is necessary to replace or update the existing RFCs to clarify or document that fact.”

Strictly speaking, this is true. The IAB has so far not initiated any effort to change the existing RFCs. Future versions of the RFCs, produced by the Internet standards process, may choose to clarify this issue, but at the moment, there is no ongoing IETF activity to do so. So while we agree with your statement that it is not necessary to update the RFCs to clarify this issue, this does not mean that such updates will not happen.

“The IAB does not believe that additional guidance in this area should come from it or the IETF but that, instead, additional policy statements should come from more policy-oriented bodies, possibly reflecting the differences between TLDs and zones lower in the tree or distinctions among types of uses.”

This is, strictly speaking, incorrect.

The IAB, in making its response, provided what it believed was a response that was appropriate and within the scope of a technical consideration of the topic. We do not see any need for further input from us at this time, and recognize that it’s appropriate for the policy-oriented bodies you mention to work on policy. But further events in this area may lead to situations where the IAB believes that the IAB or the IETF could make useful contributions to the debate, and we would not want to preclude the possibility of doing so.

In closing….

The IAB works as part of the
Internet Engineering Task Force, assisting in the creation of Internet Standards and, as appropriate, promoting their adoption in service of the global Internet. Within this activity the IAB will, as appropriate, make balanced and considered comment on issues that affect the Internet, reflecting the insight that the IETF community may provide. It is often hard to define any strict demarcation between “policy” and “technology” – for instance, the IAB’s RFC 1984 on encryption was a statement about policy.

We believe that ICANN understands and respects the role IETF and the IAB plays in the continued development of the Internet, and that the relationship will continue to work well based on this understanding.

Respectfully,

Harald Alvestrand
Acting IAB spokesman


Date: Wednesday, 3 Aug, 2004
From: Paul Twomey, ICANN
To: Leslie Daigle, IAB

Dear Leslie

The ICANN Security and Stability Advisory Committee recently completed its report on the change VeriSign introduced into the COM and NET domains last September. As you know, they inserted wild card records in those domains to redirect queries of uninstantiated names. The committee made four recommendations. The first two recommendations are that wild cards – and, indeed, synthesized responses in general – not be used in “top- level domains (TLDs) or zones that serve the public, whose contents are primarily delegations and glue, and where delegations cross organizational boundaries over which the operator may have little control or influence.” (The first recommendation was to not do this in the future, and the second recommendation was to withdraw these from those few TLDs that currently use wild cards.)

The third recommendation speaks to the existing specifications:

Recommendation (3): There exist shortcomings in the specification of DNS wildcards and their usage. The defining RFCs should be examined and modified as necessary with a focus on producing two results: first, clarification of the use of synthesized responses in DNS protocols; second, provision of additional guidance on the use of synthesized responses in the DNS hierarchy.

In formulating its recommendations, the SSAC relied on input from a number of sources, including IAB’s comments. We ask that you verify our interpretation of those comments with regard to the issues described above and correct it if necessary. Specifically:

  • The IAB believes that the unrestricted use of wildcards with arbitrary DNS records in arbitrary zones is unwise and should be prohibited as a policy matter.
  • The IAB does not believe that it is necessary to replace or update the existing RFCs to clarify or document that fact.
  • The IAB does not believe that additional guidance in this area should come from it or the IETF but that, instead, additional policy statements should come from more policy-oriented bodies, possibly reflecting the differences between TLDs and zones lower in the tree or distinctions among types of uses.

ICANN will, of course, hope to have discussions with you as needed to clarify the boundary between policy issues and the fundamental technical workings of the DNS (or in other areas).

If these assertions accurately reflect IAB opinion, please confirm that fact. If it is incorrect in any way, or if we have missed anything of significance, please let us know as soon as possible.

Yours sincerely
Paul Twomey
President & CEO