Network Working Group E.

Gavron

Request for Comments: 1535 ACES Research Inc.

Category: Informational October 1993

A Security Problem and Proposed Correction

With Widely Deployed DNS Software

Status of this Memo

This memo provides information for the Internet community. It does

not specify an Internet standard. Distribution of this memo is

unlimited.

Abstract

This document discusses a flaw in some of the currently distributed

name resolver clients. The flaw exposes a security weakness related

to the search heuristic invoked by these same resolvers when users

provide a partial domain name, and which is easy to exploit (although

not by the masses). This document points out the flaw, a case in

point, and a solution.

Background

Current Domain Name Server clients are designed to ease the burden of

remembering IP dotted quad addresses. As such they translate human-

the translation process includes understanding and dealing with

hostnames that are not 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 typically these include the

host, domain, and type. Example: foobar.company.com or

fooschool.university.edu.

Flaw

The problem with most widely distributed resolvers based on the BSD

BIND resolver is that they attempt to resolve a partial name by

processing a search list of partial domains to be added to portions

of the specified host name until a DNS record is found. This

"feature" is disabled by default in the official BIND 4.9.2 release.

Example: A TELNET attempt by User@Machine.Tech.ACES.COM

to UnivHost.University.EDU

Gavron [Page 1]
RFC 1535 DNS Software Enhancements October 1993

The resolver client will realize that since "UnivHost.University.EDU"

does not end with a ".", it is not an absolute "rooted" FQDN. It

will then try 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.

Further, discussion reveals that specific hostnames registered in

this private subdomain, or any similarly named subdomain may be used

to spoof a host.

Example: harvard.edu.com. CNAME targethost

Thus all connects to Harvard.edu from all .com sites would end up at

targthost, a machine which could provide a Harvard.edu login banner.

This is clearly unacceptable. Further, it could only be made worse

with domains like COM.EDU, MIL.GOV, GOV.COM, etc.

The specification of the Domain Name System and the software that

implements it provides an undifferentiated hierarchy which permits

delegation of administration for subordinate portions of the name

space. Actual administration of the name space is divided between

"public" and "local" portions. Public administration pertains to all

top-level domains, such as .COM and .EDU. For some domains, it also

pertains to some number of sub-domain levels. The multi-level nature

of the public administration is most evident for 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.

Gavron [Page 2]
RFC 1535 DNS Software Enhancements October 1993

The danger of the heuristic search common in current practise is that

it it is possible to "intercept" the search by matching against an

unintended value while walking up the search list. While this is

potentially dangerous at any level, it is entirely unacceptable when

the error impacts users outside of a local administration.

When attempting to resolve a partial domain name, DNS resolvers use

the Domain Name of the searching host for deriving the search list.

Existing DNS resolvers do not distinguish the portion of that name

which is in the locally administered scope from the part that is

publically administered.

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 which 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, if the local user were trying to reach:

User@chief.admin.DESERTU.EDU from

starburst,astro.DESERTU.EDU,
 it is reasonable to permit the user to 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

has control over the assignment of names within the locally

administered domain, so the administrator can make sure that

abbreviations result in the right thing. Outside of the local

control, users are necessarily at risk.

Gavron [Page 3]
RFC 1535 DNS Software Enhancements October 1993

A more stringent mechanism is implemented in BIND 4.9.2, to respond

to this problem:

The DNS Name resolver clients narrows its IMPLICIT search list IF ANY

to 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

hosts'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.

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 making 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 return the ability for them to succeed,

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.

Gavron [Page 4]
RFC 1535 DNS Software Enhancements October 1993

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 indicates vulnerabilities with all too-forgiving DNS

clients. It points out a correction that would eliminate the future

potential of the problem.

Author's Address

Ehud Gavron

ACES Research Inc.

Tucson, AZ 85711

Phone: (602) 743-9841

EMail: gavron@aces.com

Gavron [Page 5]