Domain Name System Uniform Resource Identifiers
Extracted elements (16)
Default values for authority, class, and type (locally known authority, IN class, A type) are chosen to match the most typical DNS usage — looking up addresses for host names — so common cases can be expressed with minimal URI syntax.
The DNS URI scheme is intentionally designed not to specify DNS protocol fields, so that the URI may be used in contexts where the DNS protocol is not used directly (e.g., zone file editors, DNS configuration files). A more detailed URI syntax mapping closely to DNS protocol parameters is considered out of scope.
DNS URIs may be resolved by protocols other than DNS (e.g., multicast DNS); use of the DNS protocol is expected but not required. Data referenced by this URI scheme might be transferred by protocols that are not URI-aware.
Interaction of DNS URIs with Binary Labels (RFC 2673) or other extended label types has not been analyzed. Binary labels appear to be infrequently used in practice.
Interoperability problems may occur if one implementation understands a new DNS class or type mnemonic that another does not. To guarantee interoperability, implementations can use integers for all mnemonics not defined in RFC 1035.
A client MAY check that it understands the dnsclassval and dnstypeval before sending a query, to ensure it can interpret the response. A proxy treating the response as opaque data would not need to perform such a check.
Each of the CLASS and TYPE clauses in a dnsqueryelement MUST NOT be used more than once. For example, 'dns:example?TYPE=A;TYPE=TXT' is invalid.
Relative dnsname values (those not ending with '.') are assumed to be relative to the root, so 'dns:host.example' and 'dns:host.example.' refer to the same owner name. An empty dnsname is interpreted as the root ('.').
The digit representation of DNS types and classes MAY be used when a mnemonic is not well known, but SHOULD NOT be used for types and classes defined in the DNS specification (RFC 1035). All implementations MUST recognize the mnemonics defined in RFC 1035.
Character encoding in DNS URIs follows RFC 3986. The dnsname field is treated as an internationalized domain name (IDN) unaware domain name slot. The '.' character serves as the DNS label separator, and any literal '.' within a label must be escaped using the RFC 1035 mechanism (e.g., '%5c.') since backslash must itself be percent-encoded in URIs.
The DNS URI scheme uses the syntax 'dns:[//dnsauthority/]dnsname[?dnsquery]', where dnsauthority is an optional host:port, dnsname is a sequence of pchars (relative or absolute domain name), and dnsquery is a semicolon-delimited list of CLASS= and TYPE= elements.
IANA has registered the 'dns' URI scheme using the template provided in Section 3 of this document, in accordance with RFC 2717 (Registration Procedures for URL Scheme Names).
Applications that accept unknown dnsqueryelement values (e.g., 'dns:www.example.org?secret=value') without understanding their meaning may enable a covert channel for information leakage. Applications should understand the implications of accepting unknown query elements.
DNS URIs referencing the public Internet DNS expose both the URI and the referenced data as public information. For security-sensitive data (e.g., certificates stored in DNS), implementations may need to employ Secure DNS (DNSSEC), CMS, or OpenPGP to protect data during transport.
Slight variations in the dnsname field — such as differences in letter case — can be used as a covert channel to leak information.
The dnsquery component is composed of dnsqueryelements of the form 'CLASS=dnsclassval' or 'TYPE=dnstypeval', separated by semicolons. dnsclassval accepts digits or mnemonics (IN, CH, or any IANA-registered class); dnstypeval accepts digits or mnemonics (A, NS, MD, or any IANA-registered type).