As per Relevance of the word software, we have this rfc below:











Network Working Group E.
Request for Comments: 1535 ACES Research Inc
Category: Informational October 1993


A Security Problem and Proposed
With Widely Deployed DNS

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited



This document discusses a flaw in some of the currently
name resolver clients. The flaw exposes a security weakness
to the search heuristic invoked by these same resolvers when
provide a partial domain name, and which is easy to exploit (
not by the masses). This document points out the flaw, a case
point, and a solution



Current Domain Name Server clients are designed to ease the burden
remembering IP dotted quad addresses. As such they translate human
readable names into addresses and other resource records. Part
the translation process includes understanding and dealing
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
host, domain, and type. Example: foobar.company.com
fooschool.university.edu



The problem with most widely distributed resolvers based on the
BIND resolver is that they attempt to resolve a partial name
processing a search list of partial domains to be added to
of the specified host name until a DNS record is found.
"feature" is disabled by default in the official BIND 4.9.2 release

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



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.
will then try the following combinations until a resource record
found

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

Security

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

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

Example: harvard.edu.com. CNAME

Thus all connects to Harvard.edu from all .com sites would end up
targthost, a machine which could provide a Harvard.edu login banner

This is clearly unacceptable. Further, it could only be made
with domains like COM.EDU, MIL.GOV, GOV.COM, etc

Public vs. Local Name Space

The specification of the Domain Name System and the software
implements it provides an undifferentiated hierarchy which
delegation of administration for subordinate portions of the
space. Actual administration of the name space is divided
"public" and "local" portions. Public administration pertains to
top-level domains, such as .COM and .EDU. For some domains, it
pertains to some number of sub-domain levels. The multi-level
of the public administration is most evident for top-level
for countries. For example in the Fully Qualified Domain Name
dbc.mtview.ca.us., the portion "mtview.ca.us" represents three
of public administration. Only the left-most portion is subject
local administration








Gavron [Page 2]

RFC 1535 DNS Software Enhancements October 1993


The danger of the heuristic search common in current practise is
it it is possible to "intercept" the search by matching against
unintended value while walking up the search list. While this
potentially dangerous at any level, it is entirely unacceptable
the error impacts users outside of a local administration

When attempting to resolve a partial domain name, DNS resolvers
the Domain Name of the searching host for deriving the search list
Existing DNS resolvers do not distinguish the portion of that
which is in the locally administered scope from the part that
publically administered

Solution(s

At a minimum, DNS resolvers must honor the BOUNDARY between local
public administration, by limiting any search lists to locally
administered portions of the Domain Name space. This requires
parameter which shows the scope of the name space controlled by
local administrator

This would permit progressive searches from the most qualified
less qualified up through the locally controlled domain, but
beyond

For example, if the local user were trying to reach

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

it is reasonable to permit the user to enter just chief.admin,
for the search to cover

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

but

chief.admin.

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
DNS administrator

This is more than a mere optimization hack. The local
has control over the assignment of names within the
administered domain, so the administrator can make sure
abbreviations result in the right thing. Outside of the
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
to this problem

The DNS Name resolver clients narrows its IMPLICIT search list IF
to only try the first and the last of the examples shown

Any additional search alternatives must be configured into
resolver EXPLICITLY

DNS Name resolver software SHOULD NOT use implicit search lists
attempts to resolve partial names into absolute FQDNs other than
hosts's immediate parent domain

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

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

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

Example: Given user@a.b.c.d connecting to e.f.g.h only two
should be attempted as a result of using an
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
tries would appear as

x.b.c.d. and x

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

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





Gavron [Page 4]

RFC 1535 DNS Software Enhancements October 1993




[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,
1987.

[3] Partridge, C., "Mail Routing and the Domain System", STD 14,
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",
1537, CWI, October 1993.

Security

This memo indicates vulnerabilities with all too-forgiving
clients. It points out a correction that would eliminate the
potential of the problem

Author's

Ehud
ACES Research Inc
PO Box 14546
Tucson, AZ 85711

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

















Gavron [Page 5]







if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum