Stuffing Javascript into DNS names


Today seemed like a fun day to write about a really cool vector for cross-site scripting I found. In my testing, this attack is pretty specific and, in some ways, useless, but I strongly suspect that, with resources I don't have access to, this can trigger stored cross-site scripting in some pretty nasty places. But I'll get to that!

Interestingly enough, between the time that I wrote this blog/tool and published it, nCircle researchers have said almost the same thing (paper (pdf)). The major difference is, I released a tool to do it and demonstrate actual examples.


If you've installed nbtool, you may have noticed that, among other programs it comes with, one of them is called dnsxss. Take a look at the wiki page for more information, but what it does is, essentially, respond to DNS requests for CNAME, MX, TXT, and NS records with Javascript code. Unless you want some specific code, all you have to do is run it:

# dnsxss
Listening for requests on
Will response to queries with: 

Pass -h or --help for a list of arguments.

Now, an observant reader will realize that this isn't valid HTML. Unfortunately, as far as I can tell, there's no way to send a space through DNS, so you have to come up with some space-free code. The best I could find was replacing spaces with a '/', which will work on Firefox but not IE (I haven't tested anything else). If anybody can think of a better way to write HTML without spaces, let me know. The next best solution is using the TXT query, which DOES allow spaces. dnsxss will reply to TXT queries with well formed Javascript.

For what it's worth, dnsxss will answer A or AAAA requests with localhost ( or ::1) -- if somebody does a lookup, they'll get an odd answer that won't immediately lead back to you.

Let's break stuff!

So, what can you do with this?

Well, fortunately (or unfortunately? depends who you are), most sites don't echo back DNS records. But, some do. I picked the first three sites from a Google query and tested them out. All three were vulnerable. And I very much doubt that any programmers even *consider* filtering DNS responses. I mean, who expects DNS responses to contain HTML?

And, furthermore, if I can sneak HTML code into pretty much any site that looks up DNS names due to lack of filtering, how about SQL injection? If the response is inserted into the database without filtering for SQL characters, which I would bet they are on at least some sites, you now have an avenue for SQL injection! And, better yet, there's a decent chance that the requests won't be logged because a) it's coming through a backchannel so it's not going to be in their Web server logs, b) the statements containing SQL injection won't be inserted to your logging table (since they wouldn't be valid queries), and c) you can turn off the DNS server whenever you want, and no trace will be left that you were ever doing it (except short-lived caches).

As I mentioned earlier, I took the first three sites from a google query I crafted, and all three were vulnerable. I emailed the administrators of all three sites, and two of them replied thanking me. Both told me that it was a really interesting vector, and that they would fix their sites as soon as possible. The third I haven't heard back from. But the point is, on three random sites, none had even considered implementing any defenses.

Let's take a look at the examples! But first, here are some notes on them:

  • The examples use, which is the domain I use for all my testing -- if you plan on testing these yourself, you'll have to register your own domain
  • The examples use "/* */" to conceal the space, but I realized later that a single "/" works just as well

So, without further ado, here are some screenshots of the sites. I anonymized them a little, though a clever attacker could likely Google hack them.

Site 1

The form:

The result:

The source:

Site 2

The form:

The result:

The source:

Site 3

The form:

The result:

The source:

So there we go...

Three sites, none of which filter out my cross-site scripting attempts. Fun!


The problem is, this only affects a small percentage of sites -- those that will look up domains and display them for you. How can this be used against more targets?

Well, I have two ideas:

  1. As I mentioned earlier, I'd bet money that there are other forms of attacks through these avenues -- I'd be surprised if SQL injection didn't exist
  2. Can you stuff javascript into reverse DNS entries?

The second point, I suspect, is where we're going to have fun. I can think of countless security devices, from firewalls to vulnerability management tools to proxy servers, with Web interfaces that display reverse DNS records. Not to mention tools where administrators are shown reverse lookups -- forums, for example. Another avenue is logfiles, which are normally visible to administrators.

In all of these cases, if you can stuff Javascript into reverse DNS lookups, you will likely find some very interesting vulnerabilities. Plus, you can instantly see when somebody hits one, and, more often than not, you can clean up your tracks quite well.

I don't have access to any domains where I control the reverse DNS records, but if anybody does I'd love to test this out!

19 thoughts on “Stuffing Javascript into DNS names

  1. Reply


    That is very intresting,

    Thanks for your great article..!

  2. Reply


    man ... you are really crazy, but the stuff you publish and find and research: BIGGGUPPPP!!!!


  3. Reply


    Your tool should support requests :) Lots of interesting stuff with things like IDS/IPS, IDS/IPS GUI (like Acid) which resolves where the atk came from, firewall, proxy, log parsers, web-hit report generators, etc. etc. if you support gethostbyaddr() ...


  4. Reply


    thanks a lot for this interesting article..

  5. Reply

    Norbert vA

    Of course this is a very interesting way of XSS, although I really doubt the usefullness (as you point out). If it is possible to let such a DNS query run serverside code things would become a bit more interesting, since JavaScript is only clientside you could just add the JavaScript tag in your own webbrowser using a tool like FireBug...

    This does not execute the JS at an "unsuspecting" user, though I wonder what useful information you could collect (I'm not that of an expert on JavaScript :)).

    Anyway, nice article and indeed a good new vector to consider securing.

  6. Reply

    Eli Grey

    A solution that doesn't require spaces: document.body.appendChild(document.createElement("script")).src=""

  7. Reply

    Eli Grey

    Apparently the script tag was stripped from my comment. It'd be wise to mention exactly what formats comments may be in in the commenting form, as by default I assume plain text.

    1. Reply

      Ron Bowes Post author

      Sorry, blame WordPress's overzealous filtering. :)

      Thanks for the comment, though! I'll give that a shot.

  8. Reply


    @Norbert vA

    The point of XSS is not running code on you, the attacker's computer....but some unknown victim's.

    There are plenty of malicious things you can do with just JS....

    I think the reason this is not terribly useful is not so much because it runs client side...

    ...but because how unlikely it is someone will be vulnerable.

    To be vulnerable they have to do a DNS lookup on your malicious domain via a website that is vulnerable.

    That probably won't happen very often.

  9. Reply


    marry this to something like dsniff's DNS mitm tools and voila, you can XSS arbitrary names or IPs.

  10. Reply


    This does appear to work! I'm very surprised. Nice.

  11. Reply


    Good work !

    Probably that the same principle could be abused for MX records which are resolved by MTAs. For instance, depending on the victim product, it might be possible to inject line feeds and additional headers, thus changing the some aspects of the delivery.

    PTR records might be abused to attack web statistics reporting tools that parse logs and report resolved addresses. I've done that in the past by injecting ANSI codes into HTTP requests, that were logged unencoded and which turned the terminal black for the reader.

  12. Reply


    This is typically known as Inter-protocol exploitation ( and is probably most notorious for the various xss in whois lookup reports floating around. The concept has been floating around for a while, but there hasn't really been anything innovative recently.

    This is the first dns inter protocol exploitation article I've seen though. Good job!

  13. Reply


    Hi, can someone explain to me step by step how to test dnsxss ? Sorry for being nob! My server ip looks like 18*.17*.13*.86 on port 80 "Wordpress" so what should I do to test if someone can inject javascript code on my site or not ?

  14. Reply

    Robert Keyes

    You CAN stuff spaces into DNS names. You can stuff anything in there, including nulls. Just because your DNS server or resolver barfs on it, doesn't mean it can't be done. 15 years ago I wrote a DNS server for, among other things, PTR (reverse resolution) that did exactly that, and sent vt100 control codes to clear the screen and put a flashing '0wned' in the middle of the screen. I have fun with that. I could have done a fair amount of evil, though. People just don't pay attention to DNS any more, and keep on finding the same old flaws that don't get fixed, and then others think there's new discoveries (Kaminsky...nice guy, but dude, we had done that stuff YEARS before you published it). Have fun with DNS. There's lots of stuff to break. Or hire me to do it.

  15. Reply

    Robert Keyes

    Also, I have plenty of IP space, and the DNS servers for them in my control. So, if anyone is serious about doing some good work with this, let me know, perhaps we can work together. Yeah, it would be recycling old vulnerabilities, but they could be optimized exploits for programs written by programmers who don't properly understand DNS.

  16. Reply


    Did you thought about sending valid base64 encode data url


  17. Reply


    '\ ' give that a shot.

  18. Reply

    Blake Cornell

    Been stuffing XSS,CSRF,SQLi into VoIP for a few years now.

    Any protocol with a web administration portal is feasibly vulnerable.

Leave a Reply

Your email address will not be published.