Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
The Internet Security IT

DNS Server Survey Reveals Mixed Security Picture 109

Posted by kdawson from the buddy-can-you-spare-a-zone dept.
Kurtz'sKompund writes in with word on the latest annual survey of the state of DNS on the Net. The survey, commissioned by infrastructure appliance vendor Infoblox, found that the use of Windows DNS Server in Internet-facing applications has fallen off dramatically as more users act on concerns about security. BIND 9, the latest version, gained against earlier, less secure versions. But in other dimensions, DNS practices showed little improvement from a security point of view. Hardly anyone is using DNSSEC; and 31% of nameservers allow promiscuous zone transfers, a number little changed from last year. Here's a video of an interview with Infoblox's chief architect Cricket Liu on the state of DNS.
This discussion has been archived. No new comments can be posted.

DNS Server Survey Reveals Mixed Security Picture More

DNS Server Survey Reveals Mixed Security Picture

Comments Filter:

  • I hate video without transcripts (Score:2, Interesting)

    by Anonymous Coward
    Damned videos. I want to *read* the article at my own (faster) pace, not have to listen to some doofus talk about it.

  • Security? It's quite simple (Score:5, Informative)

    by p0 ( 740290 ) on Wednesday November 21, 2007 @09:05AM (#21433713)
    1) Put BIND in jail.
    2) Put restrictions on recursive queries.
    3) Lock down box.
    4) Profit.

    • Re:Security? It's quite simple (Score:4, Funny)

      by ArsenneLupin ( 766289 ) on Wednesday November 21, 2007 @09:13AM (#21433741)

      1) Put BIND in jail.
      What crime does it have committed?
      • Dude have you ever even used BIND ?

        BIND's crime is of being yet another piece of open-source software trying to become its own operating system with extremely verbose, anal-retentive configs.

        It's nice to have extensive configurability for those unique situations, but sometimes you just want a frickin' DNS lookup. "somename.com = a.b.c.d" and be done with it. The problem is most open-source apps aren't designed to be usable, they're designed to be "geek cool" and to somehow distance us sysadmins from the '

        • Re: (Score:1)

          by p0 ( 740290 )
          actually i DO have used BIND. been using it for 4 years. had no problems whatsoever, no break-ins, no "breaches", no silly outages. BIND (or any other piece of software, is as good as how it's configured to operate). the uptime of our DNS servers is above 430 days, which i consider is more than satisfactory. i work in an ISP.

          • Re: (Score:1)

            by stim ( 732091 )
            $ uptime 12:02pm up 545 day(s), 10:26, 3 users, load average: 0.06, 0.03, 0.04 ohh snap! i got you beat! :P

            • Re: (Score:1)

              by p0 ( 740290 )
              that's great! :)
              • No, it's not really, because that means the server hasn't been rebooted in the last 500+ days in order to update the kernel with any security fixes. Think of the exploits!

                That's why it's super-cool to run TWO separate DNS servers, so a quick reboot of each one in turn to apply updates won't really be noticed by anyone who had the foresight to define both servers on their client machines.

        • Re: (Score:2)

          by Bert64 ( 520050 )
          So forget bind...
          Djbdns is a smaller much simpler DNS server with a simple config syntax (and simple ./add-host blah.com 1.2.3.4 type scripts)
          Powerdns has a smaller featureset, but lets you serve dns records from an sql database and some other neat stuff

          There was also an ultra simple dns server i saw which simply used a file format like /etc/hosts, but i forget what this program was called...

          Bind's configs are perhaps more awkward than they need to be, but there are also several frontends to bind that can s

      • Re:Security? It's quite simple (Score:5, Funny)

        by tttonyyy ( 726776 ) on Wednesday November 21, 2007 @10:33AM (#21434439) Homepage Journal

        1) Put BIND in jail.
        What crime does it have committed?
        I called it a name and it went all IPv6 on me.

      • 1) Put BIND in jail.

        What crime does it have committed?

        Its a terrorist!

    • Re: (Score:1, Funny)

      by Anonymous Coward
      I think you missed the part about zone transfers and lack of DNSSEC, although I can see how you would only do the bare minimum to maximize 4) profit.
    • I seem to remember reading an article [slashdot.org] recently that claimed that chroot jails were not intended for security.

  • Hypotheses != data (Score:3, Insightful)

    by gazbo ( 517111 ) on Wednesday November 21, 2007 @09:05AM (#21433715)
    The DATA shows certain changes in nameserver choice.

    The HYPOTHESIS is that this is motivated by security concerns.

    Conflating the two, as the summary does, is frankly retarded and exceptionally bad practice.

    • Re: (Score:2)

      by innate ( 472375 )
      Very true. Another hypothesis would be that more small- and medium- sized companies are outsourcing DNS to their domain registrar or hosting service. Small companies almost always use Windows and most registrars use BIND.

  • DNSSEC is dead, let's move on (Score:5, Informative)

    by hal9000(jr) ( 316943 ) on Wednesday November 21, 2007 @09:17AM (#21433759)
    Until TLD's start signing zones, DNSSEC won't see the light of day.
    Until registrars figure out how to securely regsister and manage keys, DNSSEC is DoA
    Until zone managers start signing zones, DNSSEC won't achieve critical mass
    Without critical mass, uneven DNSSEC deployment has no value
    Without stub resolver support, DNSSEC is meaningless
    Until all the above happen, there is no business case for DNSSEC and TLD owners won't deploy it.

    • Re: (Score:2, Informative)

      by morgan_greywolf ( 835522 )
      I think the biggest problem with DNSSEC is that it reveals all the zone data [wikipedia.org], since it has to be able to return an authenticated denial of existence.

      Implementation of DNSSEC would essentially make all zone transfers promiscuous. I think that's probably the biggest reason why there's been so much resistance to it.

      • Re: (Score:2)

        by AVee ( 557523 )
        And here is what the /. summary has to say about that:

        Hardly anyone is using DNSSEC; and 31% of nameservers allow promiscuous zone transfers, a number little changed from last year.
        Common guys, lets all stop allowing promiscuous zone transfers and then start allowing it again using a different mechanism. Way to go!

    • Re: (Score:2, Informative)

      by PsyQo ( 1020321 )
      And you need other nameservers to implement it, but the authors of at least two of those (djbdns and PowerDNS) don't think it's worth the effort.
      You can read their motivations here [cr.yp.to] and here [ds9a.nl].
    • Don't hit me with those negative waves so early in the morning. [the-ocean.com] Have a little faith, baby, have a little faith.

    • Re: (Score:2, Interesting)

      by Steve Crocker ( 1192477 )
      I wouldn't choose quite the same language, but I think the specifics are on target. We do indeed need to get the TLDs signed, we do indeed need to have registrars accept keys from registrants -- see below for a bit more -- and we do indeed need for stub (or recursive) resolvers ask for signed responses and make use of them. Here's a few details that suggest the picture is not so bleak. 1. A few TLDs are signed and more are coming. When the NSEC3 RFC is published, more TLDs will sign their zones. 2. We

    • There are few problems DNSSEC solves that SSL/TLS won't do a far better job solving. SSL/TLS deployment is almost universal. With the vast effort we've spent fighting over how to secure a tiny portion of the Internet protocol stack, we could instead have come up with a way to make verifiable SSL certificates free and easily acquired. I wrote about this at length [matasano.com] earlier this year.

      Furthermore, DNSSEC is a mess. It has taken over ten years to come up with a protocol that a plurality of operators will agree t

    • Re: (Score:2)

      by leto ( 8058 )
      As Morrisey's song goes, "The world is not America".
      DNSSEC deployment is already happenening on Large Scale [xelerance.com].

      djdns refuses to fix his code to protect against OS errors as "not his job". That makes that DNS software pretty useless.
      powerdns is fuly mysql driven, and uses a record, not a zonefile as their basic unit. DNSSEC will break that. That's why they do not like it.

      People say things will break, but things are broken already. If someone has a better fix, please step forward. Whining and doing nothing is no
  • I love Bind, but someone really should fix Bind-SDB so that it can accept Zone updates to LDAP Backends. That way, Zone transfers can travel encrypted in LDAPS.
    This is a failing of Bind.

    • Re: (Score:3, Informative)

      by Russ Nelson ( 33911 )
      Even better, use djbdns and copy your zones using ssh.

    • Re: (Score:2)

      by raddan ( 519638 )
      It's a failing of BIND that it won't talk some arbitrary competing directory protocol? Are you serious? If this is a problem for you, write a gateway program. I'm quite happy leaving fluff like that out of BIND. I want it to do DNS, period. If you haven't noticed, DNS is quite complicated enough without having to worry about everyone else's protocol-of-the-month. If it were up to me, BIND would have fewer features. E.g., secure zone transfers can be accomplished better using SSH. I/AXFR should die.

  • Promiscuous zone transfers - just say no (Score:3, Informative)

    by MadMidnightBomber ( 894759 ) on Wednesday November 21, 2007 @09:26AM (#21433813)
    allow-transfer { 127.0.0.0/8; };

    If you're server is handing out zones to anyone and everyone, you might want to check you're not offering recursion to everyone as well (see allow-recursion {}; ). http://www.oreilly.com/catalog/dns4/chapter/ch11.html [oreilly.com].

    • In a public facing network, fine. Put a chador over your head so no one can gaze over your beauty and court you. But on an internal network, it's extremely useful to allow zone transfers for gathering the list of active servers and DHCP clients for network monitoring reasons, without the pain of also managing keys.

    • Re: (Score:3, Insightful)

      by AVee ( 557523 )
      Yeah, one of those lovely best practices. Prohibit promiscuous zone transfers, because no-one will ever guess you name your webservers www1 to www8 and your database servers db1 to db6. And because it is really hard to add or substract 1 from an ip addres. Unless you are generating random hostnames and using random IPv6 adresses it is pretty naive to think prohibiting zone transfers will help you security.

      And whatever else there is to say about it, it's still nothing but security by obscurity. Most burgla
      • I used to work at a site which had around 5000 devices, maybe 50 of which were facing the public internet. Yes, it did significantly help with that site. We didn't name our db servers 1 through 6 by the way - or rather 1 through thirty-something.

        By the way, security through obscurity does work. It just shouldn't be relied on as your only defence. (e.g. changing your SSH port to other than 22/tcp will cut down on the number of people trying to brute-force their way in. I do this *as well as* insisting on

        • Re: (Score:2)

          by ivan256 ( 17499 )

          I used to work at a site which had around 5000 devices, maybe 50 of which were facing the public internet. Yes, it did significantly help with that site. We didn't name our db servers 1 through 6 by the way - or rather 1 through thirty-something.

          The 1-6 thing is a red herring... They can still be found with a ping-scan, or similar.

          I don't think anybody here was advocating allowing a zone transfer for your internal addresses. That is a bad idea, as the only thing it accomplishes is making it easier for an

        • Re: (Score:2)

          by AVee ( 557523 )
          I know security through obscurity slows things down and may even stop some script kiddies, but than again, when you have something to fear from random script kiddies you have a bigger security issue. But hey, I run ssh on different ports, simply because it keeps the log files a bit cleaner.

          So the obscurity could be usefull, sometimes, a little bit. If your fin-vms1 is not reachable from the outside world in the first place, why does it matter if someone knows about it? And by the time it does matter, e.g.

          • Re: (Score:3, Insightful)

            by MadMidnightBomber ( 894759 )
            You're right, in that you should ideally use distinct public and private views. If a machine is internal-only, it doesn't go in the public view of DNS.

            I say disable it, because a) Cricket Liu says so, and he knows what he's talking about, and b) because it's one of the first things I do when I'm performing a pen-test. There's often a heap of useful (to an attacker) info in there, that can be turned off with two minutes of your time as an admin.

      • Re: (Score:2)

        by Bert64 ( 520050 )
        It is a small step forwards...
        In the future IPv6 will be more common, and addresses are assigned based on the mac address so sequential IP scanning will become worthless.

        But sure your right that kiddies and worms just scan large ipblocks not caring about dns...
        • Well, really you should have public and private views and not include internal-only machines in the DNS view you offer to the public. That stops people doing a reverse-lookup against every IP you own.

          (And not everyone has one contiguous IP block - so the attacker has to find them all to start with.)

          • Re: (Score:2)

            by Bert64 ( 520050 )
            You can find them all quite easily...
            Search for the company name, assuming all the blocks are registered to the same company...
            Look at the routes being advertised by your AS number...

      • Re: (Score:3, Insightful)

        by rk ( 6314 )

        And whatever else there is to say about it, it's still nothing but security by obscurity. Most burglars don't know where I live, do you really believe that significantly lowers the risk someone breaks into my house?

        Allowing promiscuous zone transfers is more akin to posting the layout of your house on your front door, possibly including which picture the safe is behind. You're right that it doesn't really reduce or increase your chances of being victimized, but if you get chosen by the bad guys, why hand them a map? There's nothing wrong with security through obscurity, as long as its not your only means of defense. In any case, it's not like it's terribly difficult to secure BIND to allow transfers to authorized

    • Re: (Score:2)

      by kindbud ( 90044 )
      I never understood this one. Zone transfer merely allows access to the same data you are already publishing to the public. There is nothing an attacker can gain from a zone transfer that he also cannot gain by using a tool to scan your network and reverse-resolve your address.
      • Good question though. Can I ask in return, do you give out your organisation's phone book to people? Hackers can also build a mapping of phone numbers to people, but why make it easy for them? If you have a /16 with 5000 active IPs, why tell people where to look? (And that's ignoring TXT, HINFO etc.)
        • I use different zones for internal and external. If someone on the outside does a zone transfer, they get the equivalent of my company's Yellow Pages entry. Do the same from the inside, you get the entire corporate directory.

          If an attacker's already inside, I've got bigger concerns.
      • Except for the aliases; if the authoritative hostnames are chosen in a way to not reveal the role of the machine, the aliases usually make it clear. That's something you may not want people knowing, although if your aliases are blindingly obvious they could still probe for them with a dictionary attack.
      • I never understood this one. Zone transfer merely allows access to the same data you are already publishing to the public. There is nothing an attacker can gain from a zone transfer that he also cannot gain by using a tool to scan your network and reverse-resolve your address.

        Could it be used to do a DDoS? Or take out your DNS server due to the load?

        (It's been too long since I read all the reasons as to why to disable full zone transfers.)

        • Re: (Score:2)

          by kindbud ( 90044 )
          Could it be used to do a DDoS? Or take out your DNS server due to the load?

          I doubt performing a single zone transfer request will be more taxing on your systems than performing a scan of your entire address space, and reverse resolving each active IP that was found. Zone transfers are carried out over TCP, which involve one socket connection. But you could DDoS any host whether it runs a DNS server.

          I think the proscription against open zone transfers dates back to the bad old days when BIND was called the

  • DIY (Score:1)

    by Uzik2 ( 679490 )
    If you want it changed make it happen. Learn how to make the changes to the major applications in use today and contact each of the tech contacts listed that run that program. Make up a boiler plate email about security with a pointer to an FAQ and offer to help
    them. Or create a forum where they can all participate and ask them to join. Otherwise it won't get changed until there's a large worm outbreak that uses the vulnerability.

  • Cricket Liu (Score:5, Informative)

    by cerberusss ( 660701 ) on Wednesday November 21, 2007 @09:37AM (#21433907) Journal
    Cricket Liu is a real authority. He's one of the authors of DNS and Bind [oreilly.com] which is the must read for anyone administrating a domain server. Just following the first couple of chapters and you'll have a robust server.

    What I also like about Cricket Liu (and Paul Albitz) is that they explain the domain name system really well in an understandable way.
  • ...given that 123-reg's nameserver failure [theregister.co.uk] at the weekend left thousands of customers without a working site.

    Pretty poor redundancy - goes to show you can't even trust the big players to get it right, and probably should run your own nameservers within your domains too, just in case...

    • Re: (Score:3, Informative)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion

      • The hell? Even xname [xname.org]'s DNS service isn't that bad.

        And they're a free DNS provider that gets huge DDoS attacks.
        Oh, nice - didn't know about them. Thanks for the tip (would make good 3rd/4th choice nameservers)! :)

  • A good example of "begging the question" (Score:1, Interesting)

    by Anonymous Coward
    Are there any real-world security differences between a fully-patched Windows DNS server and a fully-patched BIND server? TFA assumes there are, but doesn't provide any examples. Since Windows DNS is a competitor to Infoblox, which runs BIND, you can see why this is the case.

    • Re: (Score:1)

      by archen ( 447353 )
      Actually I'd love to see proof that Windows DNS is less secure than BIND. I mean, seriously people this is BIND we're talking about here - only sendmail stands in this class of software with that many security holes.

      I think from a security perspective the problem isn't Windows DNS, it's the fact that it runs on Windows, with all the baggage that entails. Reality is this "survey" seems to extrapolate that people are for some reason switching away from windows DNS for security. Out of the millions of reaso
      • Which BIND? Windows DNS is probably more secure than BIND8 or BIND4. However, you shouldn't be running any of those. If you have any choice of DNS software, then you ought to consider BIND9 (of which 9.4.1 is the latest, and 9.4.2 and 9.5.0 are beginning a release process). But do not tar all versions of BIND with a single brush. They weren't created equal, and they're not equal now. (Paul Vixie, ISC)

  • How do I know? (Score:3, Interesting)

    by Aladrin ( 926209 ) on Wednesday November 21, 2007 @10:22AM (#21434319)
    How do I know if my provider is using unsafe DNS practices?

    I would like to run some checks against my domain and see if any of this applies to me. Can anyone recommend sites, utilities or linux commands to test it?

    Would have been nice to include this info in the 'article' or even the summary, instead of just saying how un-secure everything is. Again.

    Thanks.
  • Very simple, non-root, and also a good way to avoid the painful AXFR process and zone files.

    They solve the recursion problem by not supporting it; it is only for the master.

  • I sat down last week and installed djbdns. I thought it would be a big hairy project, like learning BIND was. Back in the day, before Slashdot existed, I used Cricket's book on BIND. Good book, but BIND is finicky and the book is THICK.

    Anyhow, in a couple hours I had djbdns installed and working. I had to keep checking. I couldn't believe it was that easy. But it was. djbdns doesn't allow recursive queries or zone transfers by default. djbdns has privilege separation, just like qmail. The config

  • Configuring BIND is no cakewalk, it is a challenging task and it is thus no surprise to me that many BIND servers are misconfigured and open to exploitation. IMO the first step to decreasing the number of exploitable DNS servers is to make the configuration of BIND more straightforward and easy to comprehend.
  • Wait, why would a failure to use DNSSEC matter? Doesn't DNSSEC rely on the idea that registrars will act as CAs and sign records for their respective TLDs? Isn't that something that hasn't yet happened, making DNSSEC records worse than useless at this point?

  • But in other dimensions, DNS practices showed little improvement from a security point of view. Hardly anyone is using DNSSEC; and 31% of nameservers allow promiscuous zone transfers, a number little changed from last year.

    Internet-visible DNSSEC improves security how, exactly, if the top-level domains don't support it?

    Oh, and some of us allow "promiscuous zone transfers" because the only information we make publicly available in the DNS is information that is, you know, public.

    Good security involves making sure that legitimate users don't get a false sense of security. One way to do that is to avoid providing features that look like they provide strong confidentiality or integrity without actually doing so.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close