Skip to main content

Using the DNS Question to Carry Randomness - a Temporary Hack?


I read Mark Rothman's post Boiling the DNS Ocean. This lead me to a thought (just a thought), that somewhere within the existing DNS protocol, there has to be a way of introducing more randomness in the  DNS question and get that randomness back in the answer, simply to increase the probability that a resolver can trust an authoritative response. Of course having never written a resolver, I'm not qualified to analyze the problem -- but this being the blogosphere, that's not a reason to quit posting.

So at the risk of committing bloggo-suicide....Here goes......

Plan 'A' was to figure out if the unused bits in the ancount, nscount or ascount of the question could be used to send more random bits to the authoritative DNS. The ADNS would have to return those bits somewhere, and not in the same fields, because in the answer those bits are already used. Perhaps in an additional RR? It sounds hard to implement, and it would require that the ADNS and resolver both be upgraded. Try again.

Plan B is to use additional question records to send randomness from the resolver to the authoritative DNS, and figure out how to get them back.

Hmm…….How about using NXDOMAIN to carry the bits back to the resolver?

If I am a resolver, instead of asking one question (the one I want to know), I ask two questions, one that I want to know, and one that nobody knows, not even the authoritative DNS. Like perhaps asking for an A record made up of a long string of random bytes. Depending on the response, I can decide to trust or not trust the answer. Lets say that I need to know an A record for First  - I set qdcount=2, then in one request I ask's NS's two questions:

Question 1:
Question 2:

If I get a valid response for the first question and an NXDOMAIN response for the second, I know that I've got a reply from a valid ADNS rather than a spoofed reply. An attacker spoofing the valid ADNS will not know the longstringofrandombytes part of the second question and cannot reasonably guess that string. The real ADNS will reply to the second question with either an NXDOMAIN error or a valid IP. If I get the NXDOMAIN error for the same that I asked for, I'm good to go.

If the ADNS responds with a valid IP address or CNAME, I know that the DNS in question is doing NXDOMAIN re-writing or it has a wildcard. I can trust and cache that answer, annoying though it may be. If I get neither IP nor NXDOMAIN, the response is suspect.

From what I can see, which isn't very far, Plan B could be implemented by a resolver without any change to the upstream authoritative DNS. The upstream would just see a bunch of requests that it would reply to with NXDOMAIN. Heck - it probability is already seeing tons of those, with all the exploit attempts that likely are flying around. The resolver would have to either track the longstringofrandombytes that it sent for each question, or it would have to use some sort of hash/cookie to validate the bytes without storing or caching them for the duration of the round trip.

This is definitely an ugly hack, and I’m not even sure it would work.  It wouldn't make sense to use it for stub resolvers, it doesn't help man-in-the-middle attacks, and ADNS's would see increased load.  But  - there is no shared secret to manage as in TSIG, it doesn't require a top-down deployment like DNSSEC, and there is no protocol layer change (as far as I can figure out....) and there is no coordinated world wide deployment needed. Each operator can update one resolver at a time.
So am I smoking too much weed? guess is that there is something I'm missing.

A bit of searching uncovered a similar concept being discussed at ietf org.

OK - I'm not the first one to dream this up. There is a difference though. That proposal is similar, but seems to have died, and from what I can tell, would require both ends of the transaction to be aware of the 'new plan'. That requirement makes that proposed too hard to implement as a short term solution.

Obviously the topic of short and a long term fixes for the DNS issue is already being discussed in circles where discussions like this actually matter. The problem is finding a solution that can be implemented on a wide scale, and per Vixie's summary of the conversation in the above link:

a solution here would be opportunistic and pairwise deployable, requiring
no flag days; it would require no new technical expertise for end users; it
would have only graceful failure modes; it would not be subject to downgrade
attacks; and ideally, it would require no new protocol development work.

The 'pairwise deployable' part  is still a problem. There are an awful lot of nameservers our there.



  1. Not being a DNS guru in the slightest, I'm not qualified to answer, but I just wanted to say that I found this:

    Of course having never written a resolver, I'm not qualified to analyze the problem -- but this being the blogosphere, that's not a reason to quit posting.

    Very funny

  2. Who knows where to download XRumer 5.0 Palladium?
    Help, please. All recommend this program to effectively advertise on the Internet, this is the best program!


Post a Comment

Popular posts from this blog

Cargo Cult System Administration

Cargo Cult: …imitate the superficial exterior of a process or system without having any understanding of the underlying substance --Wikipedia During and after WWII, some native south pacific islanders erroneously associated the presence of war related technology with the delivery of highly desirable cargo. When the war ended and the cargo stopped showing up, they built crude facsimiles of runways, control towers, and airplanes in the belief that the presence of war technology caused the delivery of desirable cargo. From our point of view, it looks pretty amusing to see people build fake airplanes, runways and control towers  and wait for cargo to fall from the sky.
The question is, how amusing are we?We have cargo cult science[1], cargo cult management[2], cargo cult programming[3], how about cargo cult system management?Here’s some common system administration failures that might be ‘cargo cult’:
Failing to understand the difference between necessary and sufficient. A daily backup …

Ad-Hoc Versus Structured System Management

Structured system management is a concept that covers the fundamentals of building, securing, deploying, monitoring, logging, alerting, and documenting networks, servers and applications. Structured system management implies that you have those fundamentals in place, you execute them consistently, and you know all cases where you are inconsistent. The converse of structured system management is what I call ad hoc system management, where every system has it own plan, undocumented and inconsistent, and you don't know how inconsistent they are, because you've never looked.

In previous posts (here and here) I implied that structured system management was an integral part of improving system availability. Having inherited several platforms that had, at best, ad hoc system management, and having moved the platforms to something resembling structured system management, I've concluded that implementing basic structure around system management will be the best and fastest path to…

The Cloud – Provider Failure Modes

In The Cloud - Outsourcing Moved up the Stack[1] I compared the outsourcing that we do routinely (wide area networks) with the outsourcing of the higher layers of the application stack (processor, memory, storage). Conceptually they are similar:In both cases you’ve entrusted your bits to someone else, you’ve shared physical and logical resources with others, you’ve disassociated physical devices (circuits or servers) from logical devices (virtual circuits, virtual severs), and in exchange for what is hopefully better, faster, cheaper service, you give up visibility, manageability and control to a provider. There are differences though. In the case of networking, your cloud provider is only entrusted with your bits for the time it takes for those bits to cross the providers network, and the loss of a few bits is not catastrophic. For providers of higher layer services, the bits are entrusted to the provider for the life of the bits, and the loss of a few bits is a major problem. These …