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.

I hate video without transcripts

[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

[p0 (740290)]

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

Re:Security? It's quite simple

[ArsenneLupin (766289)]

1) Put BIND in jail.

What crime does it have committed?

Re:Security? It's quite simple

[tttonyyy (726776)]

1) Put BIND in jail.

What crime does it have committed?

I called it a name and it went all IPv6 on me.

Re:

[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:

[Crudely_Indecent (739699)]

I seem to remember reading an article [slashdot.org] recently that claimed that chroot jails were not intended for security.

Hypotheses != data

[gazbo (517111)]

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:

[Bert64 (520050)]

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

Re:

[Just Some Guy (3352)]

But going purely on vulnerabilities, we should probably all be running djbdns.

No way. djbdns doesn't even support IXFR, so instead of configuring a TSIG key for your master and slave servers and being done with it, you instead have to roll your own secure incremental filecopy implementation. Maybe you didn't want to run sshd or rsyncd on your slaves. Doesn't matter - now you have to because djbdns can't be bothered to handle it for you.

So, is djbdns more secure than BIND9 in the functionality it actually provides? Maybe. But if you want to actually use it, you have to set up

Re:

[Just Some Guy (3352)]

Your concerns are valid, but how many DNS servers lack ssh access in the real world?

How many DNS servers lack SSH set up for unattended connections to remote servers, either by using password authentication, passwordless RSA keys, or ssh-agent? Hopefully all of them. Well, except for the ones running djbdns.

Re:

[Just Some Guy (3352)]

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

Re:

[Bert64 (520050)]

Well sure djbdns is not perfect for all scenarios, i never said it was... I was responding to a poster who said msdns was more secure because it's had one exploit, i countered that based on number of exploits djbdns is more secure.
Yes number of exploits is a flawed metric, i was simply responding to the poster.
I then pointed out that other things mattered too, like what else runs on the dns server box, and how you can mitigate the damage a vulnerability could cause.

Dynamic dns clients are not a good idea, l

Re:

[Just Some Guy (3352)]

Well sure djbdns is not perfect for all scenarios, i never said it was

Noted and I see what you're saying.

Dynamic dns clients are not a good idea, letting your dhcp clients set arbitrary dns records is a horrible thing to do...

Why? In BIND9 you can write rules like "the client with this TSIG key can change this set of values". Saying that DDNS isn't good if left wide open is like saying that SMTP isn't good because of open relays. When done right, DDNS and SMTP can both be useful. :-)

As for having to use rsync/ssh, is that really necessary?

If you're doing pull-only, then DDNS moves from "maybe not a good idea" to "pretty much impossible". Also, even in the case of an SSL-ized HTTP server (which is a clever idea, BTW), that still means tha

Re:

[Just Some Guy (3352)]

Of course, djbdns could come with some special scripts to implement well-tested solutions.

Won't happen. djbdns is proprietary and hasn't been updated since 2001-02-11, so the best you can hope for is a generally agreed upon best practice.

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.

We isolate the two by creating a zone for AD to screw around with. The company has example.com, and AD controls lan.example.com. Nothing "important" is inside that subdomain so if it breaks horribly we can still get work done.

In that case, djbdns would be a good solution. Are you suggesting that we switch to BIND?

No. I am suggesting that you research djbdns's criticisms, though. For starters, it's not F/OSS so expect a fair amount of in

Re:

[dave562 (969951)]

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 d

Re:

[dave562 (969951)]

The thing is that when you run AD ontop of DNS it wants to create a whole bunch of subzones (_msdcs, _sites, etc) to store information about all the domain controllers. It also wants to allow updates to the zone file when DHCP hands out leases to the client workstations. That functionality is built into Windows DNS and it's easier to run Windows DNS to handle it as opposed to trying to hack the functionality into something like BIND.

In this day and age, a good IT team needs a bunch of competent people. T

Re:

[Just Some Guy (3352)]

They are red herrings. You obviously have a grudge against djb based on your posting history.

I don't know the guy, don't have anything against him, and wouldn't recognize him if he walked up and bit me. It's just that every time DNS, SMTP, or NTP comes up, a legion of DJB fanbois appears and rants at everyone who doesn't love his software. Maybe DJB is fine; I just can't stand his followers.

DNSSEC is dead, let's move on

[hal9000(jr) (316943)]

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:

[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:

[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:

[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].

Re:

[Russ Nelson (33911)]

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:

[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

DNSSEC is a mess and provides little value.

[tqbf (59350)]

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

From the local LDAP Finatic

[Zombie Ryushu (803103)]

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:

[Russ Nelson (33911)]

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

Re:

[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

[MadMidnightBomber (894759)]

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].

Re:

[Antique Geekmeister (740220)]

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:

[MadMidnightBomber (894759)]

No, it won't suit every site as is, but it's a useful default. You can always add people on a case-by-case basis.

Re:

[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

Re:

[MadMidnightBomber (894759)]

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:

[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:

[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:

[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:

[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...

Re:

[MadMidnightBomber (894759)]

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:

[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:

[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:

[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.

Re:

[MadMidnightBomber (894759)]

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.)

Re:

[wolrahnaes (632574)]

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.

Re:

[RollingThunder (88952)]

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.

Cricket Liu

[cerberusss (660701)]

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.

Good timing...

[tttonyyy (726776)]

...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:

[Ash-Fox (726320)]

...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 [xname.org]'s DNS service isn't that bad.

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

Re:

[tttonyyy (726776)]

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)! :)

How do I know?

[Aladrin (926209)]

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.

MyDNS owns

[pyite69 (463042)]

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.

Re:

[dintech (998802)]

I drank the worm.