Addressing the security flaw described in RFC 1535 regarding non-FQDN domain name searching.

Publication Summary

Disclosed is a solution to 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 name resolvers. The problem can be identified when the client name resolvers are supplied with a non-FQDN (Fully Qualified Domain Name) query. There is a chance for the search to end in an unintended value, which can prove to be a cause of concern for many clients. The major drawback is it allows spoofing for hosts.

Country
Language	English (United States)

---

Continue to Text Preview →

Page 1 of 5

Addressing the security flaw described in RFC 1535 regarding non-FQDN domain name searching.

Present Implementation:

When a non-FQDN is supplied as the search query, the present implementation of client name server resolvers will allow a search to terminate only after applying all the domains of the search list. The danger of the heuristic search common in current practice is that it is possible to "intercept" the search by matching against an unintended value while walking up the search list. Therefore by chance the search may end up in some other domain. This may provide hackers a chance to spoof a host.

Example:

To UnivHost.University.EDU

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.

UnivHost.University.EDU.

UnivHost.University.EDU.COM.

UnivHost.University.EDU.

The domain name is called ambiguous when it is formed by two top-level domain (TLD) names. (For e.g. .edu.com is formed by .edu and .com top level domains)

After registering the EDU.COM domain, it was discovered that an un-liberal 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.

Present Solution:

To describe the problem with name resolution one has to look at how the resolver works when it is supplied with a non-FQDN.

ndots:n Specifies that for a domain name with n or more periods ( . ) in it, the resolver should try to look up the domain name "as is" before applying the search list.

With ndots = 2

# cat

nameserver 9.184.192.240
options ndots:2
domain in.ibm.com
search in.ibm.com ibm.com com

Query with absolute FQDN, it will only search in 'as is' type.
# nslookup -debug google.edu. -->> a FQDN
Query Order:
> google.edu -->> Search termination at this domain.

A

A

CES.COM

TELNET attempt by User@Machine.Tech.

ACES.COM.

ACES.COM.

/etc

/resolv.conf

1

Page 2 of 5

A non-FQDN query on google*.edu, the search ends up in a different host.
# nslookup -debug google.edu -->> a non-FQDN
Query Order:
> google.edu.in.ibm.com
> google.edu.ibm.com
> google.edu.com -->> Search successful at this domain. This is unintended.

In the forthcoming query the invention has satisfied the ndots parameter by supplying 2 dots but the search ends up in a different host

# nslookup -debug www.google.edu -->> Non FQDN but with 2 (.)

periods

nameserver 9.184.192.240
domain in.ibm.com
options ndots:1
search in.ibm.com ibm.com com

With ndots =1 the invention can reduce the chance of the potential insecure search. The search will end in the correct node provided the search

query supplied is valid and at least there is one dot in the search query satisfying the ndots criteria.

# nslookup -debug google.com -->> a non-FQDN
Query Order:
> google.com -->> Search termination...

Download This Document →

Back to Overview