DNS Server Survey Reveals Mixed Security Picture

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.

Comments

I hate video without transcripts

[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

[p0]

1) Put BIND in jail.
2) Put restrictions on recursive queries.
3) Lock down box.
4) Profit.

Re:Security? It's quite simple

[ArsenneLupin]

1) Put BIND in jail. What crime does it have committed?

Re:Security? It's quite simple

[tttonyyy]

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

Hypotheses != data

[gazbo]

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:Hypotheses != data

[Bert64]

True, and Bind has had many more vulnerabilities. But going purely on vulnerabilities, we should probably all be running djbdns.

But what is also important to consider is what requirements a given dns server has and assuming that there will be vulnerabilities in the dns implementation, what you can do to mitigate it.

Windows DNS requires RPC (which was the cause of the vulnerability as you point out) and requires many other default windows components, many of which are difficult/impossible to remove and have no valid reason to be on a dns server. Bind by contrast has very few other requirements, and is often found on small embedded systems.

Windows DNS only runs on windows, of which there are a relatively small number of versions (for purposes of calculating offsets when exploiting buffer overflows and the like) current versions run on only 3 (x86, x86-64, itanium) hardware platforms. Bind runs on virtually any OS, and subsequently on many different types of hardware too.

Windows DNS usually runs as SYSTEM (can it run as any other user?), Bind can be run inside of a chroot and usually runs as an unprivileged user, and this is the default on some systems.

Re:Hypotheses != data

[Just Some Guy]

I was soliciting input from people who know what they are talking about, not from today's lets-bash-x crowd.

I don't like djbdns - I've never tried to hide that - but these are factual, documented problems and not just something I'm inventing to bash on it.

SSH supports binding a key to a command in .ssh/authorized_keys. Also supports IP matching too.

But again, you the sysadmin have to set this up correctly on every machine you touch. If you're configuring BIND9 and TSIG and screw up, then the worst case scenario is that that it's buggy or you screw it up and an attacker can fiddle with your DNS data. If you're configure djbdns + SSH, then the worst case scenario is that sshd or tcpwrappers has a bug or you screw it up and that gives attackers access to your entire host, including the DNS data.

Looks like you can get djbdns to do AXFR, too.

IXFR != AXFR. IXFR (incremental transfer) is for when you have 10,000 dynamic DNS clients making changes to your zone file, and you need to propagate those changes to your slaves in realtime. Ideally, this won't require sending the whole zone file each time or wiring a trigger to fire off rsync every time an update is made. This is used very commonly in corporate setups where DHCP gives out IPs and hostnames to clients, or at least that's how we use it in conjunction with Active Directory.

Re:Hypotheses != data

[dave562]

The Windows admins I've encountered are hopeless when it comes to DNS (blaming every strange issue they encounter on DNS, for example). Best current practice over here is to never have Active Directory and public DNS interact. The Windows types can break Active Directory all they want, and the real DNS service is managed by people with a clue.

This is a very true statement. As a pretty much clueless when it comes to DNS Windows admin I would never try to host internet facing DNS with Windows DNS. What I do is setup all of the AD domains with .local and use forwarders that point to real DNS servers to resolve anything that isn't on the local network. Like everything else Microsoft related, the MS version of the technology is there to let the MS boxes talk to each other. When you want your boxes to go play in the real world, it is best to hand that responsibility over to something running *nix.

DNSSEC is dead, let's move on

[hal9000(jr)]

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:DNSSEC is dead, let's move on

[morgan_greywolf]

I think the biggest problem with DNSSEC is that it reveals all the zone data, 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:DNSSEC is dead, let's move on

[PsyQo]

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 and here.

Re:DNSSEC is dead, let's move on

[Steve Crocker]

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 are beginning to work with registrars. In addition to providing a path for enterprises to convey their keys (or fingerprints), there will also have to be support for those registrants who do not manage their own zones. That is, for the many, many registrants who depend on the registrar to manage their zones, the registrars will also have to provide DNSSEC service. I expect to see successful worked examples in six months, give or take. 3. There is work underway to have DNSSEC implemented in the major end user systems. Steve Crocker Co-chair, DNSSEC Deployment Working Group

Promiscuous zone transfers - just say no

[MadMidnightBomber]

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.

Re:Promiscuous zone transfers - just say no

[AVee]

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 burglars don't know where I live, do you really believe that significantly lowers the risk someone breaks into my house?

Re:Promiscuous zone transfers - just say no

[MadMidnightBomber]

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:Promiscuous zone transfers - just say no

[rk]

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 clients only:

acl "xfer-allowed" {
ipaddr1;
ipaddr2;
.
.
};
options {
.
.
.
allow-transfer { "xfer-allowed";};
};

And you're done. What's so objectionable about that?

Cricket Liu

[cerberusss]

Cricket Liu is a real authority. He's one of the authors of DNS and Bind 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.

Re:Good timing...

[Ash-Fox]

...given that 123-reg's nameserver failure 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...

The hell? Even xname's DNS service isn't that bad.

And they're a free DNS provider that gets huge DDoS attacks.

How do I know?

[Aladrin]

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.

Re:From the local LDAP Finatic

[Russ Nelson]

Even better, use djbdns and copy your zones using ssh.