Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
I think you expect answer to your request (or NSs that lead to answer), and you can always reject anything which is not authoritative (except of necessary glues for NS) –  Sandman4 Feb 14 '12 at 19:19
    
Guess answers you get may normally vary depending on what additional info available (possibly just from cache) on the responding server. –  Sandman4 Feb 14 '12 at 19:21
    
@sandman4 - Updated.. its it more clear now? –  makerofthings7 Feb 14 '12 at 21:24

1 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.
share|improve this answer
    
That is right along the lines I'm thinking, but think there are additional points of exploit such as SOA, extra CNAMES when querying for an A, stuff that doesn't make complete sense. I'm looking for a rule book of sorts.. so when client requests record of type X they get response of type Y and "always", "sometimes" Z or "never" Z. Substitute your DNS record of choice for each variable (A, CNAME, TXT, SOA, SRV, DNSSec Related...) etc. –  makerofthings7 Feb 15 '12 at 4:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.