Broadband

DNS: The Internet dodged a bullet, thankfully

The Internet becomes a scary place if DNS can't be trusted. Michael Kassner would like to explain why, and how a group of DNS experts recently prevented that from happening.

The Internet becomes a scary place if DNS can't be trusted. I'd like to explain why this is so and how a group of DNS experts recently prevented that from happening.

-------------------------------------------------------------------------------------------------------------------

In a recent article, "DNS: Painful Reminders of How Important It Is," I alluded to the problem uncovered by Dan Kaminsky (director of pen testing at IOActive and Doxpara Research). This past week at Black Hat 2008, Kaminsky finally revealed the actual details of the bug he discovered. The design flaw makes it a great deal easier to poison a name server's cache, voiding any trust in query results from that name server. In order to understand the magnitude of the bug, we need to be familiar with how a DNS query works, so let's start there.

Domain Name System (DNS)

Humans like to use easily remembered names (FQDN), whereas digital machines such as computers like to use numbers (IP addresses). DNS is simply the go-between, allowing us to enter a name into a Web browser's address bar or e-mail address instead of a cryptic number. For example, I want to go to www.techrepublic.com. Let's follow the steps of how my Web browser accomplishes that:

  1. I type www.techrepublic.com in the Web browser.
  2. The Web browser then asks the resolver (a background client DNS application that resolves FQDNs to IP addresses) to convert www.techrepublic.com into an IP address.
  3. The resolver first checks the host's file and the local cache to see if the FQDN/IP address combination is available. If it is, the resolver passes the IP address to my computer's network protocols to set up a connection. If not, the resolver contacts the name server at my ISP, asking it for the IP address of www.techrepublic.com.
  4. If the ISP's name server has that information in its cache, it will immediately return the IP address to the resolver, which once again sets up a connection. One important term that we need to understand is recursive name server. It's simply a name server such as my ISP's that relies on other name servers for authoritative answers.
  5. If not found, my ISP's name server takes over looking for the techrepublic.com name server by querying what are called authoritative name servers. To explain, the three components of the FQDN www.techrepublic.com determine the order of the authoritative name servers queried. Com is the top level of this particular name, so the search starts there; the next level is techrepublic, and finally www.
  6. First, my ISP's name server queries the root name server (authoritative for .com, .net, etc). The root name server returns the IP address for the appropriate .com name server to my ISP's name server.
  7. Next, my ISP's name server queries the .com name server (authoritative for name servers in the .com domain) for the IP address of the techrepublic.com name servers. The .com name server returns the appropriate IP addresses to my ISP's name server.
  8. Now my ISP's name server queries the techrepublic.com name server for the IP address associated with www.techrepublic.com. Finally, my ISP's name server has the required IP address, sending it to the resolver application on my computer so it can establish a connection.
  9. Once connected, the Web server will send the specified Web pages back for display on my Web browser.

That seems like a great deal of back and forth just to get the IP address of a Web site. Thankfully, these transactions take only milliseconds due to several features incorporated in the DNS protocol. I'd like to give a quick overview of these features as they are important to our discussion about the new DNS bug.

Caching

To help reduce the number of queries, DNS uses caching. For example, my ISP's name server may have recently communicated with the .com name server. If so, my ISP's name server stores that information in its cache, cutting out a step. The more popular a Web site is, the better chance my ISP's name server will have the Web site's IP address already stored in its cache.

Time to live (TTL)

The IT department at TechRepublic decides to change the IP address of the Web site www.techrepublic.com. When that happens, how do all the name servers around the world receive the new IP address for www.techrepublic.com? It's taken care of by a component of caching called Time to live (TTL). TTL controls how long a server will cache the FQDN/IP address information. This allows new information to propagate efficiently, keeping all DNS records in the cache accurate.

"Out of bailiwick"

"Out of bailiwick" refers to any information that doesn't pertain to the original DNS query. For example, an ISP's name server asked for information about www.techrepublic.com, instead information about www.faketechrepublic.com is returned. That information is "out of bailiwick." This problem surfaced in the early editions of DNS but is no longer an issue. It does relate to the discussion on Kaminsky's DNS bug though.

Now that we have all these terms defined and have a good idea of how a DNS query works, I'd like to delve "under-the-hood." While doing so, I'd also like to include some DNS history.

Original DNS protocol

DNS started out as a completely trusting application. As the Internet matured, it became apparent that tricks could be played on DNS, redirecting users to Internet locations they didn't ask for. At first, it was harmless, but then attackers realized they could redirect users to spoofed Web sites with the hope of stealing personal information using "DNS cache poisoning."

In the original DNS protocol, the DNS query packet contained a 16-bit number (1- 65535) called a Transaction ID (TID), which is a linear-incrementing counter. The TID's purpose was to verify the DNS query response, as the queried name server must return the same TID it received in the initial query.

Therefore, if the attacker knew the Transaction ID number used in the victim DNS server's latest query, the attacker could send malicious DNS query responses using Transaction IDs. Starting with that number, each additional query response would be incremented. It's guesswork, but the attack can be accomplished. It's also important to know that the original cache-poisoning method required the attacker to wait patiently until the victim DNS server sent out a query (TTL expired) for the domain the attacker was interested in.

Cache poisoning is only possible because DNS uses UDP, a connectionless protocol as defined by Wikipedia:

"Connectionless describes communication between two network end points in which a message can be sent from one end point to another without prior arrangement. The device at one end of the communication transmits data to the other, without first ensuring that the recipient is available and ready to receive the data. The device sending a message simply sends it addressed to the intended recipient."

Being a connectionless protocol, UDP traffic doesn't use authentication. Therefore, it's possible to send spoofed query responses with altered IP addresses and port numbers.

Next-generation DNS

In order to harden DNS, the use of random Transaction IDs created by a pseudorandom number generator became part of the protocol. This markedly increased the strength of DNS by forcing the attacker to guess a number from 65,535 choices, not just the next increment. To review: the attacker has two variables to resolve in order to successfully inject a cache-poisoning query response: the Transaction ID (now difficult) and the IP address/port combination (not so difficult).

16-bit randomization is still not secure

Several well-known DNS experts, including Dan Bernstein, have pointed out that with today's processing power,16-bit randomization afforded by the Transaction ID isn't enough. As a point of reference, Bernstein developed his own DNS application that randomizes the query port (Internet traffic requires an IP address and port number).

Up until now, DNS required a static port. Typically, port 53 for the query port, meaning the attacker had to guess only the Transaction ID. With 65,535 ports being available, Bernstein determined that query port randomization would add 16 bits of entropy to the mix, making it 65,535 times more difficult to guess the required query port and Transaction ID combination.

Sounds like a plan; but most variations of DNS don't use query port randomization, because it gets complicated. There are firewall and NAT router issues that come into play when you use port randomization. BIND, Cisco, and Microsoft DNS applications are some examples, and they only just recently implemented query port randomization.

Kaminsky's bug

Do you remember how an attacker has to wait until the TTL expired before the attacker could attempt injecting a poisoned DNS query response? Well, Kaminsky figured out how to get around that. The best way to explain would be to step through an attack. Let's say I wanted to poison my ISP's DNS record for the techrepublic.com domain. Here's what I'd do:

  1. I obtain the IP addresses of the authoritative name servers for techrepublic.com. I also get the IP address of my ISP's name server and what port it's using for DNS queries.
  2. I then send a query for a fake computer at techrepublic.com, called 11.techrepublic.com.
  3. Since there isn't a machine by that name, my ISP's name server must send a DNS query to techrepublic.com's name server.
  4. At that time, I construct a bunch of DNS query response packets that contain:

  • Spoofed source IP address (so it appears to be coming from techrepublic.com)
  • The correct query port (used by my ISP's name server in the DNS query)
  • A Transaction ID (random selection, sufficient query responses will affect a collision)
  • IP addresses of name servers of my choosing (notice this is "in bailiwick," thus accepted)

Therefore, waiting until the TTL of a domain expired is no longer required. In my example, I'm controlling when my ISP's name server is sending out a DNS query. If my query for 11.techrepublic.com didn't work, all I have to do is try 12.techrepublic.com and go through the same process until I get a collision. I'll know when that happens, because I'll get DNS information for 11 or 12.techrepublic.com from my ISP.

There are several concepts in play here that make this cache-poisoning attack vector extremely onerous, they are:

  • Since the DNS query response was "in bailiwick," my ISP's name server thinks the IP addresses that I gave it are authoritative for the whole techrepublic.com domain.
  • I can set the TTL of the FQDN/IP address information to an extremely large amount; it's a 32-bit number. That way the false DNS information will not expire.
  • I can now set up phishing Web sites that will not trip any alarms or phishing filters.
  • This design flaw is present in every recursive name server.

Cache-poisoning countermeasures

Do you recall Dan Bernstein and his idea of using random query ports? That's the fix for now. It adds a significant amount of randomness -- enough that the attack is no longer viable. The problem is getting all the ISPs and entities running recursive DNS servers to install patches. If you'd like to know if your ISP's name servers are patched, there are two Web sites that you can go to check. Kaminsky has a test application on his Web site "Doxpara.com" and one that I especially like at "DNS-ORAC.net."

If you find that your ISP's DNS servers are not randomizing the query port, I'd suggest asking the ISP when and if the DNS servers will be patched. Then immediately switch to a patched and secure DNS service like OpenDNS, until your ISP's DNS servers are upgraded. It's also important to know this attack vector doesn't work on Web sites using SSL; certificates can't be spoofed. Therefore, you're safe as long as you make sure the certificate is correct and the URL displays https.

Final thoughts

If you have gotten this far, I sincerely thank you, as the article is long. I just felt it was important to explain a DNS query and how the attack vector works. Imagine not knowing for sure if the Web site you are looking at is the one you asked for. I realize that most important sites are SSL, but some of those aren't secure until the user actually logs in. Before then the Web sites could be spoofed and you wouldn't be any the wiser.

I wanted to thank Dan Kaminsky. I feel that he handled the situation responsibly. Taking any other path could have led to serious alterations of our Internet experience. I'd also like to extend my thanks to all the ISPs that have implemented the patch, because it's not a trivial undertaking.

One final point: I wanted to link "Microsoft Patch MS08-037," the Windows 2000 and 2003 Server fix for the DNS bug. I suspect many organizations have internal DNS servers that may alternatively be acting as recursive name servers.

-------------------------------------------------------------------------------------------------------------------

Michael Kassner has been involved with wireless communications for 40 plus years, starting with amateur radio (K0PBX) and now as a network field engineer for Orange Business Services and an independent wireless consultant with MKassner Net. Current certifications include Cisco ESTQ Field Engineer, CWNA, and CWSP.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

62 comments
Michael Kassner
Michael Kassner

I can't verify this but, there's evidence being discussed that some ISPs are capturing user DNS queries and resending them to the ISP's designated name servers. I was listening to a Steve Gibson "Security Now" podcast and this was the portion that really caught my attention: "Question from a listener: Long ago I changed my static DNS entries in my Linksys home wireless to the IP addresses of OpenDNS. So during the recent discussions of DNS vulnerability I thought I had little to worry about. However, the other day I fat-fingered a web request and got a Charter Communications "not found" result page. Wait a minute. Confused by this, I began to research. My router settings had not changed, and my client machine's IP config showed DNS set to the router IP and the two IP addresses of OpenDNS. Yet when I went to the DoxPara test page I found my DNS server was vulnerable to DNS cache poisoning, with all the requests being sent out over a single port. Anyway, Whois found that the IP address identified by DoxPara is owned by Charter Communications. LEO: Well, that's - huh? That's interesting. I guess that's who's hosting his site. My questions are many. How could Charter intercept these? Oh. Maybe they don't own his site. STEVE: Exactly. LEO: How could I stop them from intercepting my DNS requests and use a security-aware DNS service? What are my options? So let me recap to make sure I understand. He's using OpenDNS, so theoretically all his DNS should go through it. But for some... STEVE: Well, let's say he's configured to use OpenDNS. LEO: For some reason Charter is intercepting these. What's going on? STEVE: This is a problem. This means that, okay, and think about it, DNS is over UDP, that is not connection oriented and that has no TCP connection. And his ISP could do anything it wants with his packets. So they are receiving DNS queries coming from his network, out of his router, with a destination IP on the packet of OpenDNS. They know that it's a DNS query because it's aimed at port 53, which is a universal DNS query port. All DNS servers are listening for incoming UDP and TCP traffic on their port 53. Charter, for whatever reason, perhaps for the purpose of intercepting and putting up their own advertising page, they're ignoring the destination IP of his DNS packets and changing them, rewriting them to their own. So that... LEO: Oh, man. STEVE: ...no matter what he does, no matter what DNS configuration he uses at home, Charter is ignoring the destination IP, rewriting his packets on the fly so that they go to their DNS server. And if he, as he says, "fat-fingered," which I think means typo... LEO: Mistyped it, yeah. STEVE: Mistyped it. Then instead of his browser being told there's nothing at that IP, he's given an IP, his browser is given an IP of a server that Charter is running that brings up their own interception page for whatever purposes they choose. LEO: Usually advertising. VeriSign did this for a while, and it was very... STEVE: And, boy, they didn't do it for long because it really upset people. LEO: A lot of ISPs do that. And they say, well, we do it as a convenience, we have a much better page. And it's true, if you don't do that, then you get that stupid Internet Explorer page saying I can't get anywhere. STEVE: Okay, well, two things. First of all, you said many ISPs do this? LEO: Yeah. STEVE: The only way to do it is rewriting DNS. LEO: Ah, interesting. Of course, yeah, of course. STEVE: So that means all the ISPs that are able to present their own page are doing so by preventing you from going to the DNS server you have asked for. And secondly you'll notice that he ran the test at DoxPara, and it said all your requests are coming from one port. So not only is his ISP screwing up his deliberately configured-for-security DNS, but they're aiming it at an insecure server. LEO: They're doing a bad job. STEVE: Exactly. They've got a spoofable server, and they're forcing all of their customers to use their misconfigured spoofable server." I thought this might be of interest to the members as some have mentioned that they were getting strange returns on the DoxPara DNS randomness test. If this is true than certain ISPs are hijacking DNS queries to known good DNS servers and forcing users to obtain query responses from insecure DNS servers that aren't even randomizing the source port.

go4thetop
go4thetop

I used to work for a PKI vendor called Baltimore Technologies. At that time we had a number of large banks and a few large corporates interested in Public Key Infrastructure projects, but it was a hard sell. I still believe that properly managed personal and company certificates are one of the key ways to ensure identity information is correct. As the Internet is used in an ever increasing fashion for e-commerce and other purposes where personal information is at risk it is critical to know who you are dealing with. Unfortunately not even certificates may work any more as it seems that in the interests of speed and "ease-of-use" the background identity checks of individuals and businesses and requirements for becoming a signing authority are constantly being diluted. With a robust, stringent infrastructure in place many of the issues relating to identity should be solved.

JCitizen
JCitizen

Michael. This problem just can't get enough publicity, as far as I'm concerned. I will have to educate myself somemore on the solutions before I dig under my ISP's skin. I want my big guns out when I face them with this.

vijaya1906
vijaya1906

Good one Michael...Look forward for somemore of these:)

tungstendiadem
tungstendiadem

How does the DNS servers resolve the different IP addresses from both the spoofed and spoofing site? And wouldn't the orignal site have a higher percentage of the IPs over the course of several days, or even several hours else the flooding of spoofed packets might appear as an unnatural spike in the requests for a particular address in a short period of time (double for probability parity).

Jaqui
Jaqui

all 4 of my dns servers have "great randomness" for both port and transactionid.

seanferd
seanferd

I'd like to think that the majority of ISPs, large institutions, and businesses have patched or are in the process of doing so. With comprehensive articles such as this one, at least the word is getting out.

Michael Kassner
Michael Kassner

Have you checked your ISP's DNS servers to see if they have patched them? If not: 1. Let them know about it. 2.Switch to secure DNS servers like those at OpenDNS until the DNS servers are patched.

Michael Kassner
Michael Kassner

I suspect that most most SOHO and SMBs use MS products and have Windows update set to automatic. That would take care of a vast majority of the issues then.

JCitizen
JCitizen

and setting up all their little fiefdoms; I'm surprised their aren't larger numbers in the negative. Even without that element I'm surprised. Perhaps most ISP, businesses, and network neophytes are more consious of security than I originally suspected.

seanferd
seanferd

Actually, I'm shocked that it is only 10%. I still wonder about businesses and institutions that have their own DNS.

JCitizen
JCitizen

is chasing the cockroaches out of the wood pile! In more ways that one! Good work Michael, excellent reporting! Shoot you might as well publish this as another story; course I'm sure you will! Follow up is one of the finest arts in journalism in my opinion.

seanferd
seanferd

If you commit a typo that results in a non-extant domain name while using OpenDNS, you should get an OpenDNS search page (although yoou may be able to turn that feature off). Thanks for the update, Michael. edit: So, possibly DNS vuln + DPI. I don't think their priorities are straight. (Not straight if they haven't patched, anyway.)

santeewelding
santeewelding

Maybe you're right. Maybe morality is embedded in technics. Maybe with sufficiently fine-grained exploration of the technical, determining the only correct decision tree, we will understand morality. If it's the other way around -- technics embedded in morality -- then the decision tree is fearsome. I understand how you want nothing to do with it.

Michael Kassner
Michael Kassner

I wish I was more clear on what you meant by spoofing and spoofed site. My definitions would be as follows: Spoofing site: Is the IP address of the inserted and malicious DNS server Spoofed site: Is the IP address of the web server that is hosting the attackers malicious web sites If those are the right definitions, the ISP's DNS server will consider the spoofing site as as the authoritative name server, so it doesn't consider it anything other than a normal relationship. That same rational applies to the spoofed site as well. Whether it's malicious or not pretty much depends user intervention learning that the web page isn't quite right. The flooding is not quite as you understand it. The flood of query responses are only coming from one IP address as far as the attacked DNS server knows. That's due to the initial nature of DNS. Remember a querying DNS server will accept query responses only from a source that publishes the correct IP address and port number. So, it wouldn't appear as a normal flood and the DNS server can't block traffic from what it considers an authoritative name server.

Michael Kassner
Michael Kassner

Are the name servers under your control or your ISPs? I respect your opinion and it sounds like you feel this is important. Could I recruit you to pass this information along to other? It's that important.

Michael Kassner
Michael Kassner

If the source is accurate the number of un-patched DNS servers is less than 50% now.

rkuhn040172
rkuhn040172

I use Time Warner, AT&T and OpenDNS thru work, home, etc and all were A-OK.

The Scummy One
The Scummy One

I am alive :^0 :^0 NP, as per usual, very informative and well written. Keep it up Michael!

smason
smason

Russian hacker Evgeniy Polyakov has found a way around the patch. Yes, it takes longer (a few hours, instead of seconds) but it's still very vulnerable. DNS needs some major re-writing, and SOON.

-Q-240248
-Q-240248

The problem with these bozo schemes is that Kamaneski or whatever his name is would never actually pull off an elaborate hack such as the one he describes. It assumes they can sniff and intercept host to DNS server requests, which requires physical access at major ISPs, for one thing. That's just a start. Why, if you were able to even get that far, why wouldn't you just install your own DNS server and make it authoritative for everything on the 'net? You could just take over the root servers! But let's continue to point out how vulnerable we are and continue with the mass hysteria. I think it's more funner that way....

boxfiddler
boxfiddler

and the testing sites. My ISP passed both with flying colors. I have to admit to some surprise at that. Charter is not exactly high on my 'trust them to do the right thing' list.

Michael Kassner
Michael Kassner

If I can find enough validated information, I'll try to update the members as to what's happening.

Michael Kassner
Michael Kassner

Sorry, Sean I commented on the other DNS post. I see what your thoughts are. It's not what I would consider proper. I guess we all need to check our EULAs and SLAs to see just what the ISP can do and can't do.

Jaqui
Jaqui

both mine and my isp's. :D yup I had already been passing this on. DNS spoofing is a fairly serious security issue, since when it is done, it enables all criminal activities that are site based. This is the type of activity where the site's injected will have malicious clientside code on them. [ you know, those Javascript and flash things I say shouldn't be used anyway. ;) ]

Michael Kassner
Michael Kassner

You asked a very pertinent question, but it's not one easily answered. It involves all sorts of upfront topics that need to be understood. I'd love to take it on. Except it would result in one or more inanely long articles, like this one and I don't want to bore everyone to tears. If you and the members would like to take that topic on, please let me know. It's important and I live for this stuff.

Michael Kassner
Michael Kassner

OpenDNS is huge in my book. They have always done it right.

Michael Kassner
Michael Kassner

Thank you Scummy One. I respect your opinion and your comment makes all the work very worthwhile.

Michael Kassner
Michael Kassner

DNSSec will remove the vulnerability, but as I understand, it's a bear to implement. The powers that be are well aware though and moving in that direction. http://www.dnssec.net/

smason
smason

Sorry, Evgeniy is a physicist, not a hacker. Well officially anyway :)

-Q-240248
-Q-240248

There is no danger of this ever happening. A mass dns cache poisoning could not actually occur in the real world.

Michael Kassner
Michael Kassner

Thanks Q, I like your comments, you keep me honest. I hope I can answer your questions to your satisfaction. There are several variants of the exploit out in the wild already. I assume that you have heard of "The Metasploit Project"? If not it's probably the premier hacker tool in existence. The developer has already added the necessary components to accomplish the new cache poisoning attack. Ironically his ISP AT&T was party to the exploit, the only reason he found out about it was because Google didn't look just right. If you are doubtful, please feel free to download the tool and attempt the attack yourself. http://www.metasploit.com/ Your next question is a valid one: "It assumes they can sniff and intercept host to DNS server requests, which requires physical access at major ISPs, for one thing." First, it may help for you to check out Dan Kaminsky's ppt presentation: www.doxpara.com/DMK_BO2K8.ppt Essentially it's a race, who ever gets the query reply back to the name server wins. That's because it uses UDP, which doesn't authenticate the other end of the connection. The two elements required to spoof a DNS query reply are: 1. Transaction ID 2. IP address and query port After that you can inject any kind of DNS payload you want. The real problem is when the payload contains additional information in the glue. Typically this is where the spoof occurs as the false name server IP addrs are injected here. Next you ask: "Why, if you were able to even get that far, why wouldn't you just install your own DNS server and make it authoritative for everything on the 'net?" It's much more subtle and efficient to poison the cache of official DNS servers. The only way that the people in charge of the recursive name servers will know something is wrong is when people start complaining. Wow, Q, I would have thought that you would have been aware of Paul Vixie. He is one smart guy, the authors of BIND, founded ISC, and is very well respected for his grasp of DNS and the inner-workings of the Internet. Please don't take my word, check out this link, it's a CERT note that both Kaminsky and Vixie were involved with: http://www.kb.cert.org/vuls/id/800113 I hope this information will be of help, if not please let me know and we can delve deeper into the components of the attack vector.

smason
smason

You've heard of him right? He has a rough understading of networking :) A quote from one of his blog entries: "Please do the following. First, take the advisory seriously?we're not just a bunch of n00b alarmists, if we tell you your DNS house is on fire, and we hand you a fire hose, take it. Second, take Secure DNS seriously, even though there are intractable problems in its business and governance model?deploy it locally and push on your vendors for the tools and services you need. Third, stop complaining, we've all got a lot of work to do by August 7 and it's a little silly to spend any time arguing when we need to be patching."

Michael Kassner
Michael Kassner

If you read my article about behavioral targeting, you'd be proud of Charter. They were going to use NebuAd and then changed their mind.

boxfiddler
boxfiddler

A couple of odd glitchy things have surfaced - I think I mentioned them in my addendum to my question re: U-Verse. A related rant is available, but unnecessary since it hasn't anything to do with U-Verse. ;) :0 I do not have fat fingers!

seanferd
seanferd

One more reason, eh? edit: Fat finger. :0

rkuhn040172
rkuhn040172

I'd love to see them add the ability to block specific sites and not just by category. Heck, I'd even pay money for it.

Michael Kassner
Michael Kassner

Query port randomization is only a short-term fix, Sean. DNSSec is the real answer and the powers that be know that. It's just very tough to implement. http://www.dnssec.net/ I can't even begin explain the horsepower that is involved with this design flaw. I consider myself fortunate to even remotely understand the details. I wasn't kidding when I said that DNS could be the downfall of our Internet experience as we know it. Why would all of the big names play nice if that wasn't the case?

boxfiddler
boxfiddler

check his/her location. Other side of the dateline. Makes things interesting sometimes! ;)

cameron.duffy
cameron.duffy

I find it highly suspicious your reply appeared at exactly 11:11 Mr. Q. I will insist you cease your meddling in humans affairs.

Michael Kassner
Michael Kassner

First, DNS queries are not packet-size intense, but they can potentially involve a large number of packets. That's why UDP is only the real choice. SSL requires using TCP/IP and that adds 6 packets to every DNS transaction. I've heard it mentioned by smarter people than me, that porting DNS transactions to use TCP/IP would pretty much stall the Internet, there's is just not enough bandwidth for that.

-Q-240248
-Q-240248

DNS is UDP, first of all. Secondly, encrypting packet contents wouldn't solve anything.

ed34222
ed34222

We could call it SDNS; and, SDNS servers could simply prefer each other when passing queries along.

-Q-240248
-Q-240248

You will have to excuse me, I am very bad with names, and not very good with authors. In fact, there are very few names I remember on the publishing side, Radia Perlman being one of the few. I loved her "Interconnections" book. Thanks for the link as well, I hadn't read the whole thing before (107 slides?) but I get the gist of it. BTW, the guy writes like a 12-year-old.

Michael Kassner
Michael Kassner

That's the whole point of Kaminsky's bug. The attacker doesn't have to guess it correctly the first time. If the Transaction ID is incorrect, all the attacker has to do is tell the name server to resolve another fake FQDN in the domain under attack.

-Q-240248
-Q-240248

Where? It seems highly unlikely since guessing a number between 1 and 65,535, in less time than it takes the real DNS server to reply, would be pretty near impossible.

seanferd
seanferd

I suggest you find out who Paul Vixie is, among others.

-Q-240248
-Q-240248

Sounds alarmist to me. Is the risk to the DNS infrastructure high enough to warrant immediate re-engineering of the DNS infrastructure? Short answer: No. Q says so, and Q probably has more experience than Paul Vixie.

Editor's Picks