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

Security? It's quite simple

[p0]

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

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.

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.

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.

Re:From the local LDAP Finatic

[Russ Nelson]

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

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.