RFC 4027

Domain Name System Media Types

📅 published May 2005, from ietf

RFC 4027: Domain Name System Media Types 🎀

okay bestie, this one is from the Network Working Group 💅 It's Request for Comments 4027, written by S. Josefsson (that's Simon Josefsson, the author) and dated April 2005. It's Category: Informational, so it's giving "here's some info" rather than "here's a standard" 🌸 The header doesn't list anything it obsoletes or updates, so it's a lowkey solo mission 🦋

Status of This Memo ✨

This memo gives information to the Internet community. It doesn't specify an Internet standard of any kind, and distribution of it is unlimited 💖

Copyright (C) The Internet Society (2005).

Abstract 🧚

okay so this doc registers two media types, application/dns and text/dns, following RFC 2048. application/dns labels data in the detached DNS format from RFC 2540, and text/dns labels master files from RFC 1035. that's the whole plot 💜

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 ✨

okay so DNS info is traditionally stored in text files, called master files or zone files. The format is described in section 5 of RFC 1035 [2] 📝

there's also a "detached" format for DNS data, meant for archiving, and it's described in RFC 2540 [4] 🗄️

this document registers MIME media types for those two data formats, using the registration procedures from RFC 2048 [3] 🎀

2. MIME Type Registration of application/dns 💜

here's the registration template, verbatim so nothing gets lost in translation 💅

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

the vibe: the data is binary, so it has to arrive unmodified, and textual encodings are not recommended 🙈 it's detached DNS info from RFC 2540, and it might be security-relevant under RFC 2538 or secured under RFC 2535. extra securing can use stuff like OpenPGP [5] or CMS [9], but that's out of scope here, and there aren't any further security assessments yet 🔐 interop is simpler than master files because the encoding is well defined 🫶

3. MIME Type Registration of text/dns 🌸

and here's the second template, also verbatim 🦋

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

so text/dns is textual, so it should go line-oriented. non-ASCII octets are treated as opaque by DNS software, and \DDD encoding can be more reliable through gateways that re-encode characters 🧚 master files have interop concerns because of vendor-specific extensions, and the same goes for non-ASCII comments and unrecognized RR types (see section 5 of RFC 3597 [8]) 💀 security-wise, it's the same story as application/dns: RFC 1035 [2] documents the format, and the rest is outside the scope here ✨

4. Security Considerations 🔐

security considerations are covered in the security considerations clauses of the MIME registrations in sections 2 and 3 🫶

5. IANA Considerations 👑

IANA registered the MIME media types application/dns and text/dns using the registration templates in sections 2 and 3, following the procedure in RFC 2048 [3] 💖

6. Acknowledgements 🎀

thanks to D. Eastlake for suggesting text/dns 💜 thanks to Keith Moore and Alfred Hoenes for reviewing the doc 🙌 the author also acknowledges RSA Laboratories for supporting the work behind this document 🌈

A. Disclaimer and License 🦋

regarding this whole document or any part of it, the author makes no guarantees and isn't responsible for any damage from using it. the author irrevocably lets anyone use, modify, and distribute it in any way that doesn't reduce anyone else's rights to do the same, as long as redistributed derivative works don't contain misleading author or version info. derivative works don't have to 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

Copyright (C) The Internet Society (2005).

this document is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights 💜

this document and the info in it 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 on the validity or scope of any intellectual property rights that might be claimed for the technology in this document, or on whether licenses under those rights are available. it also doesn't claim to have independently looked for such rights. info on how RFC documents handle rights is in BCP 78 and BCP 79 📚

copies of IPR disclosures sent to the IETF Secretariat, assurances of licenses, and the results of attempts to get a general license for implementers or users can be found in the IETF online IPR repository at http://www.ietf.org/ipr ✨

the IETF invites anyone to point out any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💖

Acknowledgement 🫶

funding for the RFC Editor function is currently provided by the Internet Society 🎀

📦 where this page comes from