Dangerous Labels in DNS and E-mail

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

4.1. Additional Risks Out of Scope

The lists of security concerns in this document cover security risks and concerns associated with interoperable use of specific labels. They do not cover every possible security concern associated with any DNS label or e-mail localpart.¶

For example, DNS labels with an existing underscore are likely by construction to be sensitive, and are registered separately in the registry defined by [RFC8552].¶

Similarly, where humans or other systems capable of transcription error are in the loop, subtle variations of the labels listed here may also have security implications, due to homomgraphic confusion ([Homograph]), but this document does not attempt to enumerate all phishing, typosquatting, or similar risks of visual confusion, nor does it exhaustively list all other potential risks associated with variant encodings. See [UTR36] for a deeper understanding of these categories of security concerns.¶

Additionally, some labels may be associated with security concerns that happen to also commonly show up as DNS labels or e-mail local parts, but their risk is not associated with their use in interoperable public forms of DNS or e-mail. For example, on some systems, a local user account named backup has full read access to the local filesytsem so that it can transfer data to the local backup system. And in some cases, the list of local user accounts is also aliased into e-mail local parts. However, permitting the registration of backup@example.net as an e-mail address is not itself an interoperable security risk -- no external third party will treat any part of the example.net domain differently because of the registration. This document does not cover any risk entirely related to internal configuration choices.¶

5.1. Dangerous DNS Labels Registry

The table of Dangerous DNS Labels (in Table 1) has three columns:¶

• DNS Label (text string)¶
• Rationale (human-readable short explanation)¶
• References (pointer or pointers to more detailed documentation)¶

Note that this table does not include anything that should be handled by the pre-existing "Underscored and Globally Scoped DNS Node Names" registry defined by [RFC8552].¶

Following the guidance in [BCP26], any new entry to this registry will be assigned using Specification Required. The IESG will assign one or more designated experts for this purpose, who will consult with the IETF DNSOP working group mailing list or its designated successor. The Designated Expert will support IANA by clearly indicating when a new DNS label should be added to this table, offering the label itself, a brief rationale, and a pointer to the permanent and readily available documentation of the security consequences of the label. Updates or deletions of of DNS Labels will follow the same process.¶

5.2. Dangerous E-mail Local Parts Registry

The table of Dangerous E-mail Local Parts (in Table 2 also has three columns:¶

• E-mail local part (text string)¶
• Rationale (human-readable short explanation)¶
• References (pointer or ponters to more detailed documentation)¶

Following the guidance in [BCP26], any new entry to this registry will be assigned using Specification Required. The IESG will assign one or more designated experts for this purpose, who will consult with the IETF EMAILCORE working group mailing list or its designated successor. The Designated Expert will support IANA by clearly indicating when a new e-mail local part should be added to this table, offering the local part itself, a brief rationale, and a pointer to the permanent and readily available documentation of the security consequences of the local part. Updates or deletions of of E-mail Local Parts will follow the same process.¶

5.3. Shared Considerations

Having to add a new security-sensitive entry to either of these tables is likely to be a bad idea, because existing DNS zones and e-mail installations may have already made an allocation of the novel label, and cannot avoid the security implications. For a new protocol that wants to include a label in either registry, there is almost always a better protocol design choice.¶

Yet, if some common practice permits any form of administrative control over a separate resource based on control over an arbitrary label, administrators need a central place to keep track of which labels are dangerous.¶

If such a practice cannot be avoided, it is better to ensure that the risk is documented clearly and referenced in the appropriate registry, rather than leaving it up to each administrator to re-discover the problem.¶

B.1. Other types of labels?

This document is limited to leftmost DNS labels and e-mail local-parts because those are the arbitrary labels There may be other types of arbitrary labels on the Internet with special values that have security implications that the author is not aware of.¶

B.2. Document History

This section is to be removed before publishing as an RFC.¶