diff options
Diffstat (limited to 'doc/rfc/rfc4027.txt')
-rw-r--r-- | doc/rfc/rfc4027.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc4027.txt b/doc/rfc/rfc4027.txt new file mode 100644 index 0000000..84d3f65 --- /dev/null +++ b/doc/rfc/rfc4027.txt @@ -0,0 +1,339 @@ + + + + + + +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]. + + + + +Josefsson Informational [Page 1] + +RFC 4027 Domain Name System Media Types April 2005 + + + 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 + + + +Josefsson Informational [Page 2] + +RFC 4027 Domain Name System Media Types April 2005 + + + 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]. + + + + +Josefsson Informational [Page 3] + +RFC 4027 Domain Name System Media Types April 2005 + + + 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. + + + + + + + + + + + + + + + + + + +Josefsson Informational [Page 4] + +RFC 4027 Domain Name System Media Types April 2005 + + +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 + + + +Josefsson Informational [Page 5] + +RFC 4027 Domain Name System Media Types April 2005 + + +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. + + + + + + + +Josefsson Informational [Page 6] + |