DNS Media Types: Domain Name System Media Types
MIME types for DNS data in binary and text formats
Josefsson, S., "Domain Name System Media Types", RFC 4027, DOI 10.17487/RFC4027, May 2005, <https://www.rfc-editor.org/info/rfc4027>.
@misc{rfc4027,
series = {Request for Comments},
number = 4027,
howpublished = {RFC 4027},
publisher = {RFC Editor},
doi = {10.17487/RFC4027},
url = {https://www.rfc-editor.org/info/rfc4027},
author = {S. Josefsson},
title = {{Domain Name System Media Types}},
pagetotal = 6,
year = 2005,
month = may,
} RFC text
Contents
Network Working Group S. Josefsson
Request for Comments: 4027 April 2005
Category: Informational
Domain Name System Media Types
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document registers the media types application/dns and text/dns
in accordance with RFC 2048. The application/dns media type is used
to identify data on the detached Domain Name System (DNS) format
described in RFC 2540. The text/dns media type is used to identify
master files as described in RFC 1035.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. MIME Type Registration of application/dns . . . . . . . . . . 2
3. MIME Type Registration of text/dns . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4
A. Disclaimer and License . . . . . . . . . . . . . . . . . . . . 5
Normative References . . . . . . . . . . . . . . . . . . . . . 5
Informative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5
Full Copyright Statements. . . . . . . . . . . . . . . . . . . 6
1. Introduction
Domain Name System (DNS) [1] information is traditionally stored in
text files, so-called master files or zone files. The format is
described in section 5 of RFC 1035 [2].
DNS data can also be stored in a "detached" format, intended for
archiving purposes, described in RFC 2540 [4].
This document registers MIME media types for the two data formats,
with the registration procedures described in RFC 2048 [3].
2. MIME Type Registration of application/dns
To: ietf-types@iana.org
Subject: Registration of MIME media type application/dns
MIME media type name: application
MIME subtype name: dns
Required parameters: None.
Optional parameters: None.
Encoding considerations: The data format is binary, and data must be
transfered unmodified. Using encodings intended for textual parts is
not recommended.
Security considerations: This media type identifies content as being
detached DNS information, as documented in RFC 2540 [4]. This data
may be security relevant as per RFC 2538 [7] or may be secured
information as per RFC 2535 [6]. Securing the content further may be
done with standard techniques, such as OpenPGP [5] or CMS [9], but
this is outside of the scope here. Further security assessments are
not available at this point.
Interoperability considerations: The encoding of detached DNS
information is, unlike textual master files, well defined. No
further interoperability considerations are known.
Published specification: The format of data that could be tagged with
this media type is documented in RFC 2540 [4].
Applications that use this media type: DNS-related software,
including software storing and using certificates stored in DNS.
Additional information:
Magic number(s): None.
File extension(s): Unknown.
Macintosh File Type Code(s): Unknown.
Person & email address to contact for further information:
Simon Josefsson simon@josefsson.org
Intended usage: LIMITED USE
Author/change controller: simon@josefsson.org
3. MIME Type Registration of text/dns
To: ietf-types@iana.org
Subject: Registration of MIME media type text/dns
MIME media type name: text
MIME subtype name: dns
Required parameters: None.
Optional parameters: None.
Encoding considerations: The data is textual and should be transfered
in a line-oriented mode. Text literals may contain CRLF within the
text. Binary transport is possible between systems that use the same
end-of-line conventions. Master files are in general ASCII, but
non-ASCII octet values may occur and are treated as opaque values by
DNS software (compare RFC 1035, section 5). The master file format
permits encoding arbitrary octet values by using the "\DDD" encoding.
The use of "\DDD" encoding can be more reliable than transporting
non-ASCII through MIME transports, if data passes through a gateway
that re-encodes the character data.
Security considerations: This media type identifies content as being
DNS information in "master file" format, as documented in RFC 1035
[2]. The DNS data may be security relevant as per to RFC 2538 [7],
or may be secured information as per to RFC 2535 [6]. Securing the
content further may be done with standard techniques, such as OpenPGP
[5] or CMS [9], but this is outside of the scope here. Further
security assessments are not available at this point.
Interoperability considerations: There are interoperability concerns
with master files, due to the widespread use of vendor-specific
extensions. Non-ASCII comments within master files may have been
encoded in locally chosen character sets, which may be difficult to
transport interoperably. Non-ASCII data in general can become
corrupted by re-encoding gateways. To achieve interoperability, one
can use the master file format described in the specification and the
"\DDD" encoding for non-ASCII octets. Further interoperability
issues with unrecognized RR types exist, which may be handled as
discussed in section 5 of RFC 3597 [8].
Published specification: The format of data that could be tagged with
this MIME type is documented in RFC 1035 [2].
Applications that use this media type: DNS-related software,
including software storing and using certificates stored in DNS.
Additional information:
Magic number(s): None.
File extension(s): 'soa' and 'zone' are known to be used.
Macintosh file type code(s): Unknown.
Person & email address to contact for further information:
Simon Josefsson simon@josefsson.org
Intended usage: LIMITED USE
Author/change controller: simon@josefsson.org
4. Security Considerations
Security considerations are discussed in the security considerations
clauses of the MIME registrations in sections 2 and 3.
5. IANA Considerations
The IANA has registered the MIME media types application/dns and
text/dns by using the registration templates in sections 2 and 3, as
per the procedure described in RFC 2048 [3].
6. Acknowledgements
Thanks to D. Eastlake for suggesting text/dns. Thanks to Keith Moore
and Alfred Hoenes for reviewing this document. The author
acknowledges the RSA Laboratories for supporting the work that led to
this document.
A. Disclaimer and License
Regarding this entire document or any portion of it, the author makes
no guarantees and is not responsible for any damage resulting from
its use. The author grants irrevocable permission to anyone to use,
modify, and distribute it in any way that does not diminish the
rights of anyone else to use, modify, and distribute it, provided
that redistributed derivative works do not contain misleading author
or version information. Derivative works need not be licensed under
similar terms.
Normative References
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[3] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", BCP
13, RFC 2048, November 1996.
[4] Eastlake 3rd, D., "Detached Domain Name System (DNS)
Information", RFC 2540, March 1999.
Informative References
[5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP
Message Format", RFC 2440, November 1998.
[6] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[7] Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates in
the Domain Name System (DNS)", RFC 2538, March 1999.
[8] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
Types", RFC 3597, September 2003.
[9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004.
Author's Address
Simon Josefsson
EMail: simon@josefsson.org
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§1DNS Data Formats
DNS information is traditionally stored in text files called master files or zone files, whose format is defined in RFC 1035. A zone file is human-readable and contains DNS records in text form, with each record on a line. However, DNS data can also be stored in a detached format, which is a binary encoding intended for archiving and other purposes, as described in RFC 2540.
The detached format encodes DNS data in its wire format, the same binary representation used when DNS queries and responses travel over the network. This format is more compact and unambiguous than the text format, but it is not human-readable. Applications that work with DNS data need to know which format they are dealing with, so they can parse it correctly. This document solves that problem by registering official MIME media types for both formats.
DNS information can be written as human-readable text (like a phone book you can read), or as binary code (like a computer's internal notes). When you send one of these files, you need to say which kind it is so the receiver knows how to read it.
§2The application/dns Media Type
The application/dns media type is registered for the detached DNS format defined in RFC 2540. This format is a binary encoding of DNS resource records, identical to the format used in DNS protocol messages. It is used when DNS data needs to be archived, exchanged, or processed in a well-defined, unambiguous way.
The registration specifies that data with this media type must be transferred without modification. The encoding is binary, so text-oriented transport encodings (like Base64 or quoted-printable) should generally not be used, as they would expand the data and lose the efficiency advantage of the binary format. Applications that use this media type include DNS software, tools that manage certificates stored in DNS (using DNS record types like CERT, TLSA, or CAA), and DNS-related management tools. The MIME type has no required or optional parameters.
application/dns is a label meaning 'this is DNS data in binary format, the same way it travels over the network.' Send it as-is, do not translate it to text.
§3The text/dns Media Type
The text/dns media type is registered for DNS master files, the human-readable text format defined in RFC 1035. A master file is a line-oriented text file where each line contains a DNS resource record. Master files are the standard format for configuring DNS servers and for exporting or importing zone data.
The registration notes that master files are generally ASCII text, but non-ASCII octet values may occur in master files and are treated as opaque by DNS software. These can be encoded using the backslash-DDD notation (for example, "\065" for the character with octet value 65). When transferring master files, the text/dns type should be used, allowing the transport mechanism to handle it as text and preserving line endings appropriately. There are interoperability concerns with master files, because many DNS server vendors support their own extensions to the format, and non-ASCII data in comments may have been encoded in locally chosen character sets. To achieve interoperability, the RFC recommends using the standard format and the backslash-DDD encoding for non-ASCII octets.
text/dns is a label meaning 'this is a DNS zone file you can read as text.' It is the format system administrators use to edit DNS records by hand.
§4Security of DNS Data
Both DNS formats can carry security-relevant data. DNS records can be signed using DNS Security Extensions (DNSSEC, RFC 2535) to provide authentication and integrity. Certificates can be stored in DNS (RFC 2538) and are themselves security-relevant. Additionally, special records like TLSA (Transport Layer Security Authentication) and CAA (Certification Authority Authorization) directly affect which certificates are trusted for a domain.
The RFC notes that DNS data may be secured further using standard techniques such as OpenPGP (RFC 2440) or the Cryptographic Message Syntax (CMS, RFC 3852), but this is outside the scope of the media type registration. The registration itself does not add security beyond what is documented in the respective RFCs for the formats. Applications that transport or process DNS data should apply appropriate security measures based on the sensitivity of the data being handled.
DNS data can contain secrets and important trust information. You should encrypt DNS files if they are sensitive, using tools like PGP. The labels themselves do not provide security; they just identify what kind of data you have.
§5IANA Registration
This RFC formally registers the two media types with IANA following the procedures defined in RFC 2048. The registrations were completed with IANA in 2005. These media types can now be used in Content-Type headers in HTTP, email, and other protocols that support MIME types. When a DNS-related tool receives a file labeled with application/dns or text/dns, it can immediately determine how to parse the content.
This memo fills out the official paperwork to make these labels official. After this, you can use them in emails and on websites to say 'this is a DNS file.'