RFC 1535

A Security Problem and Proposed Correction With Widely Deployed DNS Software 🎀

Okay bestie, so this is RFC 1535 💖. It's an Informational doc from the Network Working Group, written by Ehud Gavron (E. Gavron) at ACES Research Inc., dated October 1993. Informational means it's here to share info with the Internet community, not to set a standard. Its header doesn't list anything it obsoletes or updates, so it's standing all on its own ✨.

Status of this Memo 🌸

This memo just provides information for the Internet community. It does not specify an Internet standard, so it's not one. Distribution of this memo is unlimited 💅.

Abstract ✨

This doc is about a flaw in some of the name resolver clients that are out there right now 👀. The flaw is a security weakness tied to the search heuristic those same resolvers use when a user types in a partial domain name. It's easy to exploit (although not by the masses 💀). The doc points out the flaw, walks through a case in point, and gives a solution 🔥.

Background 🧚

Current Domain Name Server clients exist to save us from memorizing IP dotted quad addresses 🙏. They translate human-readable names into addresses and other resource records. Part of that translation involves dealing with hostnames that aren't fully qualified domain names (FQDNs).

An absolute "rooted" FQDN is of the format {name}{.}. A non "rooted" domain name is of the format {name}.

A domain name may have many parts, and they typically include the host, domain, and type. Examples: foobar.company.com or fooschool.university.edu 🍓.

Flaw 🙈

The problem with most widely distributed resolvers based on the BSD BIND resolver is that they try to resolve a partial name by taking a search list of partial domains, adding them onto portions of the specified host name, until a DNS record turns up. This "feature" is disabled by default in the official BIND 4.9.2 release. Okay, that's a relief 🫶.

Here's the example. A TELNET attempt by User@Machine.Tech.ACES.COM to UnivHost.University.EDU:

Example: A TELNET attempt by    User@Machine.Tech.ACES.COM
                          to    UnivHost.University.EDU

The resolver client realizes that since "UnivHost.University.EDU" doesn't end with a ".", it isn't an absolute "rooted" FQDN. So it tries the following combinations until a resource record is found 😭:

UnivHost.University.EDU.Tech.ACES.COM.
UnivHost.University.EDU.ACES.COM.
UnivHost.University.EDU.COM.
UnivHost.University.EDU.

Security Issue 💀

After registering the EDU.COM domain, it was discovered that an unliberal application of one wildcard CNAME record would cause all connects from any .COM site to any .EDU site to terminate at one target machine in the private edu.com sub-domain. Yikes 😱.

Further, discussion reveals that specific hostnames registered in this private subdomain, or in any similarly named subdomain, may be used to spoof a host. Like this:

harvard.edu.com.        CNAME   targethost

Thus all connects to Harvard.edu from all .com sites would end up at targethost, a machine that could provide a Harvard.edu login banner 🥲.

This is clearly unacceptable 🚫. And it could only get worse with domains like COM.EDU, MIL.GOV, GOV.COM, etc. 💀

Public vs. Local Name Space Administration 👑

The specification of the Domain Name System, and the software that implements it, provides an undifferentiated hierarchy. That hierarchy allows delegation of administration for subordinate portions of the name space. In reality, administration of the name space is split between "public" and "local" portions. Public administration covers all top-level domains, like .COM and .EDU. For some domains, it also covers some number of sub-domain levels. The multi-level nature of public administration shows up most clearly in top-level domains for countries. For example, in the Fully Qualified Domain Name dbc.mtview.ca.us., the portion mtview.ca.us represents three levels of public administration. Only the left-most portion is subject to local administration 🧐.

The danger of the heuristic search common in current practise is that it is possible to "intercept" the search by matching against an unintended value while walking up the search list. This is potentially dangerous at any level, but it's totally unacceptable when the error impacts users outside of a local administration 🚨.

When trying to resolve a partial domain name, DNS resolvers use the Domain Name of the searching host to derive the search list. Existing DNS resolvers don't distinguish the part of that name that's in the locally administered scope from the part that's publicly administered. That's the tea ☕.

Solution(s) 🔧

At a minimum, DNS resolvers must honor the BOUNDARY between local and public administration, by limiting any search lists to locally-administered portions of the Domain Name space. This requires a parameter that shows the scope of the name space controlled by the local administrator. This would permit progressive searches from the most qualified to less qualified, up through the locally controlled domain, but not beyond 🦋.

For example, say the local user is trying to reach:

User@chief.admin.DESERTU.EDU from
starburst,astro.DESERTU.EDU,

It's reasonable to let the user enter just chief.admin, and for the search to cover:

chief.admin.astro.DESERTU.EDU
chief.admin.DESERTU.EDU

but not:

chief.admin.EDU

In this case, the value of "search" should be set to "DESERTU.EDU", because that's the scope of the name space controlled by the local DNS administrator 🎀.

This is more than a mere optimization hack. The local administrator controls how names get assigned within the locally administered domain, so the administrator can make sure abbreviations resolve to the right thing. Outside of local control, users are necessarily at risk 😬.

A more stringent mechanism is implemented in BIND 4.9.2 to respond to this problem. DNS Name resolver clients narrow their IMPLICIT search list IF ANY, so they only try the first and the last of the examples shown. Any additional search alternatives must be configured into the resolver EXPLICITLY 💅.

DNS Name resolver software SHOULD NOT use implicit search lists in attempts to resolve partial names into absolute FQDNs, other than the host's immediate parent domain 🙅‍♀️.

Resolvers which continue to use implicit search lists MUST limit their scope to locally administered sub-domains 🧱.

DNS Name resolver software SHOULD NOT come pre-configured with explicit search lists that perpetuate this problem 🙃.

Further, in any event where a "." exists in a specified name, it should be assumed to be a fully qualified domain name (FQDN), and SHOULD be tried as a rooted name first 🌈.

Example: given user@a.b.c.d connecting to e.f.g.h, only two tries should be attempted as a result of using an implicit search list:

e.f.g.h.  and e.f.g.h.b.c.d.

Given user@a.b.c.d. connecting to host, those same two tries would appear as:

x.b.c.d.  and x.

Some organizations make regular use of multi-part, partially qualified Domain Names. For example, host foo.loc1.org.city.state.us might be used to make references to bar.loc2 or mumble.loc3, all of which refer to whatever.locN.org.city.state.us 🧩.

The stringent implicit search rules for BIND 4.9.2 will now cause these searches to fail. To bring back the ability for them to succeed, the configuration of the client resolvers must be changed to include an explicit search rule for org.city.state.us. That is, it must contain an explicit rule for any -- and each -- portion of the locally-administered sub-domain that it wishes to have as part of the search list 🥹.

References 📚

• [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987.
• [2] Mockapetris, P., "Domain Names Implementation and Specification", STD 13, RFC 1035, USC/Information Sciences Institute, November 1987.
• [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, CSNET CIC BBN, January 1986.
• [4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller, "Common DNS Implementation Errors and Suggested Fixes", RFC 1536, USC/Information Sciences Institute, USC, October 1993.
• [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC 1537, CWI, October 1993.

Security Considerations 🔐

This memo points out vulnerabilities in all too-forgiving DNS clients. It also points out a correction that would eliminate the future potential of the problem. Please, please take this seriously 🚨😭.

Author's Address 🦋

Ehud Gavron
ACES Research Inc.
PO Box 14546
Tucson, AZ 85711

Phone: (602) 743-9841
EMail: gavron@aces.com