Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
The Internet Data Storage It's funny.  Laugh.

Dan Kaminsky Suggests Having Fun with DNS 212

boogahsmalls writes "A few weekends ago Dan Kaminsky of scanrand fame presented some pretty cool ideas involving DNS that made plenty of heads spin at the LayerOne Technology Conference. Some of his concepts included Voice over DNS and storing Knoppix in a DNS cache. He's also apparently got a couple new tools in the pipe including a scanrand based DNS scanner and a visualization suite. Could another version of Paketto Keiretsu be in the works?" (OpenOffice.org does a great job of opening the PowerPoint slideshow.)
This discussion has been archived. No new comments can be posted.

Dan Kaminsky Suggests Having Fun with DNS

Comments Filter:
  • No thanks, (Score:5, Insightful)

    by Anonymous Coward on Monday June 21, 2004 @05:39PM (#9489510)
    I'd rather my dns just work.
  • Nice ideas (Score:5, Funny)

    by Anonymous Coward on Monday June 21, 2004 @05:40PM (#9489513)
    but who doesn't have Knoppix in the DNS cache already anyway? Welcome to the 21st century buddy.
  • by Anonymous Coward on Monday June 21, 2004 @05:42PM (#9489530)
    I'd rather read his slides in binary from IN A records than open powerpoint.
  • RTFPP? (Score:4, Funny)

    by Nethead ( 1563 ) <joe@nethead.com> on Monday June 21, 2004 @05:43PM (#9489540) Homepage Journal
    Now we have to Read The Fsckin' Power Point?
  • Great Article (Score:5, Insightful)

    by Anonymous Coward on Monday June 21, 2004 @05:44PM (#9489548)
    It's a pity most of the slashdot crowd won't understand any of its technical merits at all.
    Mark this as flamebait if you will, but come back in a while and read the comments, I promise there will be hardly any discussion of the paper.

    Dan is obviously a very smart guy, I like his ideas about using http tunnel (it's a great program), I'm going to have to give some of these ideas a work out!

    Bob
    • Re:Great Article (Score:5, Insightful)

      by wwest4 ( 183559 ) on Monday June 21, 2004 @05:50PM (#9489598)
      The presentation is intriguing, but like any typical slideshow, lacking in specifics (things like "stuff=cool" aren't terribly telling). Unless you already know the DNS pretty well, it would be hard to infer the nitty-gritty of the talk from this ppt without thinking pretty hard about it, and you shouldn't fault a diverse group of geeks from different nerd realms for not being DNS power users.

      • Re:Great Article (Score:3, Interesting)

        by Anonymous Coward
        No, I guess I shouldn't. That was kind of elitest of me and I apologise. It's just frustrating sometimes to see a really good article on slashdot, digging in to hopefully read some good comments about it, and finding people can only post "humourous" stuff or other equally lame stuff. If I don't understand an article, I don't post on it.

        You're also right about the powerpoint, it would have obviously been much better for us if we'd been there to hear his presentation. It still gives us a good insight to
        • Re:Great Article (Score:3, Insightful)

          by wwest4 ( 183559 )
          One thing that is cool about /. is that if you're willing to dig for a bit, there are some crazy-smart people who know the material. There are plenty sympathetic to your lament also.
    • Re:Great Article (Score:5, Interesting)

      by jovetoo ( 629494 ) on Monday June 21, 2004 @07:31PM (#9490253) Journal

      His techniques allow someone to set up a cryptographically secure network that most likely completely ignores firewalls. It features high bandwidth-high latency connection, low bandwidth-low latency connections and is virtually untraceable, even to both parties involved in the connection. An initial hostname and time would act as the 'phonenumber'. (By keeping a certain request alive, one can even implement a dailing service with TTL delay.) A message service is freely included.

      It is virtually impossible to shut these networks down without replacing/patching dns. Not an easy task.
      The bandwidth available to this network most likely exceeds that of most irc-botnets. Especially since the root servers are defending themselves against DDoS attacks.

      The tools he's still developing might be able to trace these things but it will still require cooperation of dns server administrators (to get their logs). You will never get them all and you'll have a LOT data to process. Accorfing to this [internetnews.com] the ICS root server continuosly handles almost 8Mbps (and can handle upto 80Mbps) of traffic. I seriously doubt they can log that... (if so, transferring the logs would continually consume a healthy percent of the servers bandwidth.)

      Pretty smart man indeed and very idealistic or shortsighted. Both the right and the wrong sort of people would pay a lot of money for that...

    • Re:Great Article (Score:3, Informative)

      by rasz ( 788512 )
      Dan is obviously a very smart guy
      .. and copied DNS [coredump.cx] and other ideas from others.
      • Re:Great Article (Score:3, Insightful)

        by Effugas ( 2378 )
        Freaking Zalewski :-) I hadn't seen this paper. Super cool, it'll help the next version of this speech greatly!

        (I directly name Zalewski in one of my apps; believe me, if I had seen this, I'd have credited him.)

        --Dan
    • Merits? The guy is proposing a system for
      conducting conference calls through firewalls
      by hijacking DNS servers, and you can use the
      term "merits"?

      Demerits maybe.
      • Re:Great Article (Score:3, Insightful)

        by Glamdrlng ( 654792 )

        Merits? The guy is proposing a system for conducting conference calls through firewalls by hijacking DNS servers, and you can use the term "merits"?

        What you're overlooking is, if Dan could have these ideas, so could someone else. By sharing his ideas publically, he's giving whitehats and blackhats a level playing field.

        Consider also, many common auditing tools were once considered blackhat programs. For example, If Mr. Kaminsky had written scanrand in the late 90's / early 2000's, back when port scannin

    • After taking a look at Paketto back when he wrote it up, and now taking a look at his work here, I think I've figured out his MO:

      1. Surround self with RFC's for core internet protocols.
      2. Ingest large quantities of something very hallucinogenic, yet not very legal.
      3. Give the RFC's the Fruit Fucker 2000 [penny-arcade.com] "rode hard and put back wet" treatment.
      4. Put together a group of proof-of-concept tools that make intelligent people who have worked in networking for years say "Shit, just when I thought I knew this stuff
  • by OzPhIsH ( 560038 ) on Monday June 21, 2004 @05:45PM (#9489557) Journal
    Gee, maybe they could make the results of any unresolved queries forward users to a handy search page, instead of returning an appropriate 'not found' response!
    • Gee, maybe they could make the results of any unresolved queries forward users to a handy search page, instead of returning an appropriate 'not found' response!

      No, this is the fun sort of DNS abuse -- things like using a DNS server as a covert communication channel, with a data rate of a few bits per minute.
  • by YouGotServed ( 790258 ) on Monday June 21, 2004 @05:45PM (#9489558)
    Microsoft Powerpoint also does a great job of opening the PowerPoint slideshow.
  • Crazy! (Score:5, Insightful)

    by chill ( 34294 ) on Monday June 21, 2004 @05:46PM (#9489563) Journal
    Most people are lucky if DNS just works without major headaches.

    I could swear BIND and its config file is considered, along with Sendmail, one of the most convoluted programs in Internetdom. It, again along with Sendmail, is historically also one of the most bug-ridden and exploited.

    And now someone is suggesting futzing around with it?! Why not just change your domain to "rootmeplease.com" and get it over with?

    -Charles
    • How can you compare bind and sendmail configuration with a straight face?!? Bind is SO much easier to setup then people say, MUCH more so then sendmail.

      If you think they are on the same level, you didn't even bother reading anything about either.
      • Re:Crazy! (Score:4, Informative)

        by Dwonis ( 52652 ) * on Monday June 21, 2004 @05:53PM (#9489610)
        It's easy. Use djbdns for a little while. BIND stars to look very sendmail-esque after that.
        • Use djbdns for a little while.

          A recent Slashdot article (or maybe it was one of the comments attached to the article) pointed out an easy cache-poisoning DoS attack on djbdns. Are you still sure you want to use it?
          • Re:Crazy! (Score:2, Informative)

            by mkettler ( 6309 )
            I'm not sure which article it was, but perhaps it was referencing this [securityfocus.com] study.

            In it someone did phase-space analysis of the PRNGs used in DNS, and combined it with a birthday paradox style attack. In it, an attack on BIND 8 was shown to be 100% likely to succeed, BIND 9 20% and DJBDNS was 30%.

            However, if you read the rest of the article, it points out that DJBDNS also uses a strongly random source port for the query, making it significantly more resistant to the attack, as the attacker would have to guess
          • A recent Slashdot article (or maybe it was one of the comments attached to the article) pointed out an easy cache-poisoning DoS attack on djbdns.

            Wrong. dnscache (from the djbdns package) is not vulnerable to poison [cr.yp.to] and never has been. You are probably thinking of previous versions of BIND.
        • Re:Crazy! (Score:3, Interesting)

          by Feyr ( 449684 ) *
          i have both a djbdns server (for a customer, 1200 domains or so) and a couple of bind ones (~400 domains).

          how the fuck can you say djbdns is easier than bind? if i want an A record in bind it's "IN A" (see, easily understood). if you want the same in djbdns it's some cryptic characters that make no sense (and is, of course, undocumented, or was last time i needed it).

          now the best part. there's MULTIPLE characters to do nearly the same thing. if i recall a + is a straight A record, and a @ (i think) is an
          • how the fuck can you say djbdns is easier than bind?

            Because I've used both, and after about a week of using djbdns, I found it to be easier to use. (Prior to that, I cringed at the thought of using tinydns-data's configuration format, but it's actually pretty easy once you get familiar with it.)

          • Firstly, djbdns provides tools such as add-host to easily add hosts to the dns list.. Also, the format has never been undocumented, there is documentation about the format right on the djbdns homepage.. As for multiple characters to do "nearly" the same thing... your saying there are multiple characters to do DIFFERENT (but similar) things.. Are you suggesting that it should use the same character to do different things? how would that work?
            • there are tools to modify the bind config file too, that's not the point. your tools won't help one bit if you want to READ the damn file and understand what it does, unless maybe by converting it to BIND format which defeats the whole purpose (also the bind format just happen to be the dns protocol format)

              the documentation might have been there, but it sure as hell wasn't clearly linked on the main page of djbdns, as i remember spending an hour or two looking for it on cr.yp.to

              as for the multiple charact
              • You can use 2 lines if you wish, your free to totally ignore the A+PTR function if you wish, noone is forcing you to use it.
        • Use djbdns for a little while. BIND stars to look very sendmail-esque after that.

          ...and djbdns starts to look very non-standards-compliant.

    • Re:Crazy! (Score:2, Funny)

      by flonker ( 526111 )
      "The sendmail.conf file looks like someone banging there head against the keyboard, after working with it for a while, I can see why."
      (Attribution forgotten, if anyone knows, please tell me.)
    • There are alternatives to BIND, though the hyperbole about its complexity is a bit extreme... and none of the BIND boxes that I've set up so far have been rooted (knock, knock).

      Someday the utility of the DNS as a distributed name resolver will probably wane. Why not toy with alternative uses and recycle all that code and/or infrastructure?
    • I could swear BIND and its config file is considered, along with Sendmail, one of the most convoluted programs in Internetdom.
      As far as potential complexity in config files go, Bind ain't bad. No worse than Apache, anyway. Comparing BIND with Sendmail is like comparing a bicycle to the Space Shuttle. :-)

      tho Sendmail got a lot easier to configure when m4 configuration became available, and lately bugs and patches have been few and far between.
  • by OverlordQ ( 264228 ) * on Monday June 21, 2004 @05:46PM (#9489564) Journal
    Enjoy [thedarkcitadel.com]

    Note: Was converted with *gasp*powerpoint so yes it is horrible :)
  • "Could another version of Paketto Keiretsu be in the works?"

    Silly poster, the article's link to Dan's website brings you to the new tools (in "prebuild three"). Can someone please get a .torrent up?

    Those are some seriously amazing gadgets in there, but I have to say I've yet to actually, you know, use one in any particular way.... yet I'm excited there are more out! I somehow want to know I could store knoppix in DNS even if I'm not likely to actually do it.
  • Conclusion
    Stuff = Cool
    More Stuff Soon


    This guy is amazing! Where does he come up with this stuff! ;)
  • by ideut ( 240078 ) on Monday June 21, 2004 @05:57PM (#9489636)
    Dan isn't the first one to suggest novel new applications for the DNS. Many will also be familiar with SPF, the "spam permitted from" framework for defining permitted email senders. Microsoft have recently taken over the standard process and are proposing for the sender permission rules to be sent in XML format over DNS!

    The open source community's response so far has been SPF+ [listbox.com], which is essentially a technique of encoding the rules in TCL, which is served over DNS and executed on the mailserver. For obvious reasons, SPF+ will probably define the future of spam control on the internet.

    • Hmmm. We've been hearing about agent technology / mobile code for years, and not only has its functionality been a bit sketchy at best, but its security is a nightmare. Note -- you can't post Javascript on Slashdot or PHP within common forums, and there's a reason.

      Putting TCL in DNS as a commonly used standard is a bit worrisome -- you'd have programmatic access to an execution context within any mail server. Not rejecting the idea outright -- but what are the functionality gains that justify such an ou
    • I can't believe that people mod this interesting.

      Read the D#$%$@#M links, people! You've been meta-trolled!

      Ideuts.

    • by jensend ( 71114 ) on Monday June 21, 2004 @10:21PM (#9491508)
      If you read the linked email and the replies to it, you will find that the linked post is a troll. For real information about SPF, visit spf.pobox.com [pobox.com].
  • by mcrbids ( 148650 ) on Monday June 21, 2004 @06:08PM (#9489702) Journal
    Forget the current legal nightmare of this proposal - just roll with me...

    This guy proposes putting content (eg Knoppix) into DNS.

    Why is DNS particularly not well suited for this kind of distribution mechanism?

    Seems to me that if the RIAA wanted to distribute their movies via broadband providers (an inevitability, I'm afraid) the biggest problem would be dealing with BANDWIDTH.

    I always figured that ISPs would have to have some way to cache content locally so their Internet pipes don't get absolutely HAMMERED by all the people viewing the latest flick...

    DNS already has a mature, stable, and lightweight caching mechanism in place. Why not use it?

    Honestly, caching content a la DNS might provide a MUCH more efficient content distribution mechanism than, say, BitTorrent.

    Where's the bad part of this idea?
    • by markov_chain ( 202465 ) on Monday June 21, 2004 @06:24PM (#9489815)
      Content would probably get cached better with BT than DNS because of the dynamically constructed network topology. The caching in DNS works as well as it does because it happens along the domain name hierarchy (duh). The default topology probably wouldn't be very efficient for content.

      Further, DNS would need to be upgraded. There is a good reason that short-term, experimental applications are better done at the ends; read the End-to-end arguments in system design [reed.com] for further insights.
    • by kryptkpr ( 180196 ) on Monday June 21, 2004 @06:33PM (#9489861) Homepage
      Where's the bad part of this idea?

      1) I think the requirement for caching sets of 4 byte IP addresses and 4 GB movies are quite different. Just because a system is good at one, doesn't mean it will automatically be good at the other. When I RTFA, the author made it quite clear that there was a 512-byte packet size limit, of which only around 50% could be useful for actual data. By the author's own estimation, it would take 35,000 DNS servers to host a single 700mb Knoppix image.

      2) DNS is already an overloaded system, and his idea uses recursion, so it would place even more load on top of it.

      If you think this is going to replace BitTorrent, you're off your rocker.
    • The problem is DNS isn't THAT distributed. Each query has one authority. Also, what kind of TTL do you put on a Knoppix CD?

      I think the single point of failure is the biggest problem with using DNS as a way of distributing large amounts of information. It really DOESN'T make sense to do this with DNS when you can design something "like DNS" only more distributed.

    • DNs is really, really, not designed for these types of payloads. You'd be far better off using a heirarchy of squid web caches than the DNS system for mass distribution of media.
    • by Bagheera ( 71311 ) on Monday June 21, 2004 @06:48PM (#9489981) Homepage Journal
      Forget the current legal nightmare of this proposal - just roll with me...

      Were that we could...

      Why is DNS particularly not well suited for this kind of distribution mechanism?

      Because DNS is designed to handle its hierarchical data, not massive amounts of content? The extra fields available in DNS are there fo, well, DNS related stuff.

      Seems to me that if the RIAA wanted to distribute their movies via broadband providers (an inevitability, I'm afraid) the biggest problem would be dealing with BANDWIDTH.

      I know you meant the MPAA, not the RIAA, but I think their biggest problem will be letting go of their deep seated need for control, rather than bandwidth. They can afford the pipe. And I, for one, would be incredibly pissed off to find the RIAA (or any other commercial service) caching their stuff on MY name server.

      I always figured that ISPs would have to have some way to cache content locally so their Internet pipes don't get absolutely HAMMERED by all the people viewing the latest flick...

      Like, say, USENET?

      DNS already has a mature, stable, and lightweight caching mechanism in place. Why not use it?

      We do. Millions of times a day. We use it every time we translate a name to an IP number. Looking up, say www.slashdot.org

      Honestly, caching content a la DNS might provide a MUCH more efficient content distribution mechanism than, say, BitTorrent.

      Highly unlikely. A highly effecient system dedicated to caching content will almost certainly be better than trying to do the same thing with DNS. It's simply not made for it.

      Where's the bad part of this idea?

      Inefficiency. Load on already stressed servers. Better existing solutions. Should I go on?

      Dan's come up with some brilliant ideas over time. Definately A Geek's Geek. But this one sounds a lot more like one of his thought experiments than an actual proposal. Like directly burning CD's over an SSH tunnel...

      • by Effugas ( 2378 ) on Monday June 21, 2004 @07:49PM (#9490368) Homepage
        It is indeed a thought experiment -- but one that's led to some interesting stuff. Voice over DNS was actually a really surprising hack -- here you have a globally deployed caching system, sometimes several levels deep, that actually has the capacity to host the minimal bitrate for a minimally compressed voice link.

        There's millions of servers out there that we can interface with -- what's the impact of that? If nothing else, it's fun to be playing with something other than TCP headers :-)

        --Dan

        P.S. A broom can be used to sweep the floor -- or to knock something out of a tree, or to scare off a wild animal, or to burn for heat. There's something to be said for separating common uses from "inherent purposes". HTTP was certainly never designed to host as much dynamic content as it does now!
        • ``HTTP was certainly never designed to host as much dynamic content as it does now!''

          Nor was it intended to do sessions (think webmail), and it doesn't do a very good job at those. RPC over HTTP (useful for interactive applications) is even worse; the HTTP headers can easily outweigh the payload. A stateful protocol (like FTP) would be a better fit for those uses.
    • by strabo ( 58457 ) on Monday June 21, 2004 @07:09PM (#9490106) Homepage
      DNS already has a mature, stable, and lightweight caching mechanism in place. Why not use it?

      What part of the word lightweight don't you understand?

  • PDF Link (Score:5, Informative)

    by kryptkpr ( 180196 ) on Monday June 21, 2004 @06:08PM (#9489704) Homepage
    PDF Conversion [mountaincable.net] of powerpoint presentation

    On my ISP's very fast webspace, but please post mirrors in case they decide to pull the plug.
    • http://freecache.org/http://www.mountaincable.net/ ~krypt/bo2004.pdf
      • Not another one of you people.

        Please read the FreeCache FAQ [archive.org]:

        We don't bother with files smaller than 5MB, as the saved bandwidth does not outweight the protocol overhead in those cases.

        I know how to make a freecache link all by myself, but the PDF is only 1mb.. that's why I asked people to mirror it. It's too small to bother with a torrent, too small for freecache, but just the right size to throw up on your ISP webspace.
  • by Have Blue ( 616 ) on Monday June 21, 2004 @06:12PM (#9489730) Homepage
    DNS is just a pervasive and well-organized caching broadcast protocol, isn't it? Right now, all it's been used to transmit is mappings of ASCII strings to IP addresses, and ancillary data related to that. Why is using it to transmit anything else particularly innovative? We didn't see this much enthusiasm when someone figured out how to send Knoppix over HTTP or Usenet.
  • by NemosomeN ( 670035 ) on Monday June 21, 2004 @06:20PM (#9489785) Journal
    Discussed YEARS ago with the possibility to sticking the source of DeCSS into a DNS cache (Among other things). I would put the source in an HTML comment here, but alas, no comment tags.
  • The PDF file [dlitz.net] (created using OpenOffice.org) is here (8.7 MB .torrent).
  • by andrewagill ( 700624 ) on Monday June 21, 2004 @06:36PM (#9489890) Homepage
    You used to be able to play a text adventure game with DNS:
    ]$
    nslookup - hastur.rlyeh.net
    > set querytype=txt
    > set domain=adventure
    > 1
    Alas, hastur has been down since around 1998, but you can still live the magic if you believe in yourself [fataldimensions.org]!
  • by Anonymous Coward
    Dan's got some interesting ideas, I'll grant you. But considering how scanrand has toasted network equipment I've run it against in the past, I don't think I'm too keen on his take on this. The tunneling angle is interesting, but when he gets to content distribution - it starts to look like a DNS stress tester more than a useful application, and considering how akamai got hosed for a bit last week, I sure hope that not many people play around with Dan's ideas unless they have a clue as to what they're doi
  • Yea baby! (Score:4, Insightful)

    by stienman ( 51024 ) <.adavis. .at. .ubasics.com.> on Monday June 21, 2004 @06:47PM (#9489975) Homepage Journal
    Ok, so let's do this:

    We've got the Kaminsky protocol connected to the
    DNS protocol
    the DNS protocol's connected to the
    UDP protocol
    The UDP protocol's connected to the
    IP protocol
    Oh hear the word of the inefficient!


    The second verse is left as an exercise for the reader. Please keep in mind that writing another verse is somewhat more productive than implementing the aforementioned Kaminsky protocol.

    -Adam
    • "There's no problem in computer science that can not be solved by using another level of indirection, except for too many levels of indirection"

      -- Unknown
    • Lets watch how the initial implementation of SSH over DNS works:

      SSH connects to HTTPtunnel's TCP proxy, which converts TCP to HTTP (another TCP protocol, but record oriented with all sorts of limitations). These HTTP packets are then captured by a DNS translator, which sends the packets out over UDP. The UDP packets route across the net, themselves encapsulated in IP, MPLS, and Ethernet, potentially bouncing off a local DNS server. They arrive, are decapsulated more times than I can count, and are event
      • Um, So?

        You talk like multiple layers of encapsulation is something new. This just reeks of yet another way to dodge The Man and hide your filesharing traffic.

        And by the way, I categorize somebody potentially using my internet facing DNS servers for covert file transfers in the "abuse", not "cool" category.

        The only good that could come out of this is to force some sort of validation of your dns cache so it's truely a name resolution cache, and not a cache of pieces of some chump's favourite dvd.

        What's n
        • Well, there are two kinds of people in the world -- those who see SOCKS over SSH over TCP over HTTP over DNS over UDP as neat, and those who don't.

          The DNS backchannel through a firewall, by abusing the heirarchy, is a real problem.

          --Dan
          • Weird bionic encapsulations are 'neat' until you're the one trying to justify the bandwidth bill.

            It's neat until you've gone into the next higher pricing bracket because someone decided to piggyback a bunch of other protocols on top of dns to your external name servers. Aside from breaking rfc, or causing a self-inflicted DOS, there isn't much you can do about it.
            (On the other hand, this is a prime example why allowing recursive DNS requests externally is a bad idea.)

            What I think is neat is stuff that's
            • I did load balancing stuff last year; created this entire system whereby a central distribution node could have its outgoing traffic actually brokered across any number of volunteering other hosts that would spoof the outgoing traffic. ACKs would come back to you, though, so you'd get K/s figures on data streams you couldn't even see.

              Turned out I had just reinvented some stuff from a few years back, Alteon did similar things with dedicated hosts. There's actually some neat load balancing stuff w/ DNS inv
  • DNS is the essential infrastructure required for almost all Internet applications to function correctly... so let's fuck with it and create some cool hacks, and use it to implement stuff that's already been done much better using other protocols! I mean, what could possibly go wrong?

Keep up the good work! But please don't ask me to help.

Working...