Concise set of rules for discarding DNS responses, or portion therein

Question

Problem statement

It is possible for any name server on the internet to become "Authoritative" for legitimate, and illegitimate zones.

For example, I can add microsoft.com to my internal name server. As long as I add the required records for www, msdn, technet.microsoft.com everything will work fine. However I'm not a legitmate owner of microsoft.com (according to the .com DNS servers)

DNS has a feature where it will also include Additional records in a response for these fake "NS" of a legit name server.

When this happens, a DNS client should be smart enough to discard the Additional record, and to traverse the DNS hierarchy from the root, to the proper location. In this case, the DNS Client (recursive resolver) will look at :

1. The root servers
2. The com servers
3. Microsoft.com

Additional Background

I've been querying a variety of DNS servers and noticed a wide inconsistency in how the Additional records section is used.

Some DNS servers include A Record information (in the Additional section) for servers they aren't authoritative for.

Example:
Question: CNAME (or ALL) for host.example.com.
Answer: host.otherguy.com  (then in the additional ->  A record for host.otherguy.com is 8.8.8.7)

I would think that this would be a DNS cache poisoning attempt if the A record is cached and the NS for "otherguy.com." says the IP is 7.7.7.7.

• Is there a concise set of rules that describe the 99% percent of responders, and what to expect?

• Conversely, are there are set of rules that define when DNS queries are invalid?

Example answer

I would think that the answer I'm looking for is like this:

If the DNS server encounters a FQDN that is not equal to the current traversal location, then it must discard any additional records that are sent in the query, and traverse the DNS hierarchy from the root.

Answer 1

The problem you are talking about is well known and is a type of poison attack. Examples (1)"RFC 1034's resolution algorithm allows any server on the Internet to destroy, or take over, yahoo.com." - http://cr.yp.to/djbdns/notes.html (2) http://en.wikipedia.org/wiki/DNS_spoofing#Redirect_the_NS_record_to_another_target_domain

Basically, the solution used today is: RR sets in the additional information are ignored.

Informal evidence: "Even though the referral includes A records for "ns1.example.net" and "ns2.example.net" in the additional section of the DNS message, modern iterative resolvers ignore these records as a defense against cache poisoning." - http://verisigninc.com/en_US/products-and-services/domain-name-services/domain-information-center/frequently-asked-questions/dns-behavior-changes/index.xhtml

The "clarification" (i.e., fix) to RFC1034 is in RFC 2181 section 5.4.1:

Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query.  They may be returned as additional
information where appropriate.  Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
without cause or excuse.