7
Network Working Group E. Gavron
8
Request for Comments: 1535 ACES Research Inc.
9
Category: Informational October 1993
12
A Security Problem and Proposed Correction
13
With Widely Deployed DNS Software
17
This memo provides information for the Internet community. It does
18
not specify an Internet standard. Distribution of this memo is
23
This document discusses a flaw in some of the currently distributed
24
name resolver clients. The flaw exposes a security weakness related
25
to the search heuristic invoked by these same resolvers when users
26
provide a partial domain name, and which is easy to exploit (although
27
not by the masses). This document points out the flaw, a case in
28
point, and a solution.
32
Current Domain Name Server clients are designed to ease the burden of
33
remembering IP dotted quad addresses. As such they translate human-
34
readable names into addresses and other resource records. Part of
35
the translation process includes understanding and dealing with
36
hostnames that are not fully qualified domain names (FQDNs).
38
An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
39
domain name is of the format {name}
41
A domain name may have many parts and typically these include the
42
host, domain, and type. Example: foobar.company.com or
43
fooschool.university.edu.
47
The problem with most widely distributed resolvers based on the BSD
48
BIND resolver is that they attempt to resolve a partial name by
49
processing a search list of partial domains to be added to portions
50
of the specified host name until a DNS record is found. This
51
"feature" is disabled by default in the official BIND 4.9.2 release.
53
Example: A TELNET attempt by User@Machine.Tech.ACES.COM
54
to UnivHost.University.EDU
60
RFC 1535 DNS Software Enhancements October 1993
63
The resolver client will realize that since "UnivHost.University.EDU"
64
does not end with a ".", it is not an absolute "rooted" FQDN. It
65
will then try the following combinations until a resource record is
68
UnivHost.University.EDU.Tech.ACES.COM.
69
UnivHost.University.EDU.ACES.COM.
70
UnivHost.University.EDU.COM.
71
UnivHost.University.EDU.
75
After registering the EDU.COM domain, it was discovered that an
76
unliberal application of one wildcard CNAME record would cause *all*
77
connects from any .COM site to any .EDU site to terminate at one
78
target machine in the private edu.com sub-domain.
80
Further, discussion reveals that specific hostnames registered in
81
this private subdomain, or any similarly named subdomain may be used
84
Example: harvard.edu.com. CNAME targethost
86
Thus all connects to Harvard.edu from all .com sites would end up at
87
targthost, a machine which could provide a Harvard.edu login banner.
89
This is clearly unacceptable. Further, it could only be made worse
90
with domains like COM.EDU, MIL.GOV, GOV.COM, etc.
92
Public vs. Local Name Space Administration
94
The specification of the Domain Name System and the software that
95
implements it provides an undifferentiated hierarchy which permits
96
delegation of administration for subordinate portions of the name
97
space. Actual administration of the name space is divided between
98
"public" and "local" portions. Public administration pertains to all
99
top-level domains, such as .COM and .EDU. For some domains, it also
100
pertains to some number of sub-domain levels. The multi-level nature
101
of the public administration is most evident for top-level domains
102
for countries. For example in the Fully Qualified Domain Name,
103
dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels
104
of public administration. Only the left-most portion is subject to
105
local administration.
116
RFC 1535 DNS Software Enhancements October 1993
119
The danger of the heuristic search common in current practise is that
120
it it is possible to "intercept" the search by matching against an
121
unintended value while walking up the search list. While this is
122
potentially dangerous at any level, it is entirely unacceptable when
123
the error impacts users outside of a local administration.
125
When attempting to resolve a partial domain name, DNS resolvers use
126
the Domain Name of the searching host for deriving the search list.
127
Existing DNS resolvers do not distinguish the portion of that name
128
which is in the locally administered scope from the part that is
129
publically administered.
133
At a minimum, DNS resolvers must honor the BOUNDARY between local and
134
public administration, by limiting any search lists to locally-
135
administered portions of the Domain Name space. This requires a
136
parameter which shows the scope of the name space controlled by the
139
This would permit progressive searches from the most qualified to
140
less qualified up through the locally controlled domain, but not
143
For example, if the local user were trying to reach:
145
User@chief.admin.DESERTU.EDU from
146
starburst,astro.DESERTU.EDU,
148
it is reasonable to permit the user to enter just chief.admin, and
149
for the search to cover:
151
chief.admin.astro.DESERTU.EDU
152
chief.admin.DESERTU.EDU
158
In this case, the value of "search" should be set to "DESERTU.EDU"
159
because that's the scope of the name space controlled by the local
162
This is more than a mere optimization hack. The local administrator
163
has control over the assignment of names within the locally
164
administered domain, so the administrator can make sure that
165
abbreviations result in the right thing. Outside of the local
166
control, users are necessarily at risk.
172
RFC 1535 DNS Software Enhancements October 1993
175
A more stringent mechanism is implemented in BIND 4.9.2, to respond
178
The DNS Name resolver clients narrows its IMPLICIT search list IF ANY
179
to only try the first and the last of the examples shown.
181
Any additional search alternatives must be configured into the
184
DNS Name resolver software SHOULD NOT use implicit search lists in
185
attempts to resolve partial names into absolute FQDNs other than the
186
hosts's immediate parent domain.
188
Resolvers which continue to use implicit search lists MUST limit
189
their scope to locally administered sub-domains.
191
DNS Name resolver software SHOULD NOT come pre-configured with
192
explicit search lists that perpetuate this problem.
194
Further, in any event where a "." exists in a specified name it
195
should be assumed to be a fully qualified domain name (FQDN) and
196
SHOULD be tried as a rooted name first.
198
Example: Given user@a.b.c.d connecting to e.f.g.h only two tries
199
should be attempted as a result of using an implicit
202
e.f.g.h. and e.f.g.h.b.c.d.
204
Given user@a.b.c.d. connecting to host those same two
205
tries would appear as:
209
Some organizations make regular use of multi-part, partially
210
qualified Domain Names. For example, host foo.loc1.org.city.state.us
211
might be used to making references to bar.loc2, or mumble.loc3, all
212
of which refer to whatever.locN.org.city.state.us
214
The stringent implicit search rules for BIND 4.9.2 will now cause
215
these searches to fail. To return the ability for them to succeed,
216
configuration of the client resolvers must be changed to include an
217
explicit search rule for org.city.state.us. That is, it must contain
218
an explicit rule for any -- and each -- portion of the locally-
219
administered sub-domain that it wishes to have as part of the search
228
RFC 1535 DNS Software Enhancements October 1993
233
[1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
234
RFC 1034, USC/Information Sciences Institute, November 1987.
236
[2] Mockapetris, P., "Domain Names Implementation and Specification",
237
STD 13, RFC 1035, USC/Information Sciences Institute, November
240
[3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
241
974, CSNET CIC BBN, January 1986.
243
[4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
244
"Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
245
USC/Information Sciences Institute, USC, October 1993.
247
[5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
248
1537, CWI, October 1993.
250
Security Considerations
252
This memo indicates vulnerabilities with all too-forgiving DNS
253
clients. It points out a correction that would eliminate the future
254
potential of the problem.
263
Phone: (602) 743-9841
264
EMail: gavron@aces.com
added
removed
doc/rfc/rfc1535.txt
