Skip to main content

Architectural Concerns on the synthesis of non-existent names in DNS.

Document Type Expired Internet-Draft (iab)
Expired & archived
Author Olaf Kolkman
Last updated 2007-04-16
RFC stream Internet Architecture Board (IAB)
Intended RFC status (None)
Stream IAB state (None)
Consensus boilerplate Unknown
IAB shepherd (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


There are many architectural assumptions regarding DNS behavior that are not specified in the IETF standards documents describing DNS, but which are deeply embedded in the behavior as expected by Internet protocols and applications. These assumptions are inherent parts of the network architecture of which the DNS is one component. It has long been known that it is possible to use DNS wildcards in ways that violate these assumptions. More recently there have been deployments of middleboxes -- in most cases recursive nameservers or DNS proxies at the ISP level -- that synthesize answers in ways that not only violate these assumptions but also violate the DNS architecture. Experience with DNS synthesis in the DNS infrastructure have show that the cost of violating these assumptions is significant. In this document we provide an explanation of how DNS wildcards function, and many examples of how their injudicious use negatively impacts both individual Internet applications and indeed the Internet architecture itself. We also explain that similar problems arise with the synthesis of DNS responses by middleboxes. We recommend that DNS wildcards should not be used in a zone unless the zone operator has a clear understanding of the risks, and that they should not be used without the informed consent of those entities which have been delegated below the zone. In addition we recommend that middleboxes do not perform DNS query synthesis unless (1)there are informed consents of those that use the forwarding name server, and (2)there exists an opt-out mechanism that allows them to receive the original DNS answers.


Olaf Kolkman

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)