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

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

Re:Security? It's quite simple

[Anonymous Coward]

Unlawful restraint.

Re:Security? It's quite simple

[billcopc]

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 'inferior' power users with unnecessary complexity.

Strictly speaking, if I got fed up enough with BIND, I could probably replace it with a single-page PERL script, because most people use DNS for only two things: resolve hostnames for local users/processes, and resolve their own hostnames for everyone else. Done. I don't need all the other features; in fact I'm quite happy with the defaults, and simple apps are simple to debug.

The other 90% of BIND is used by maybe 10% of users. It also causes about 90% of the security breaches because the new breed of sysadmins these days are simply copy/paste experts. They Google something, copy the proposed (and often amateurish) configs, then flame the forums if it doesn't work. As much as these guys are dumb/lazy, if the thing were simple in the first place they might be able to figure it out on their own, instead of copying some guy's half-understood configs.

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.

Re:Security? It's quite simple

[p0]

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:Security? It's quite simple

[Bert64]

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 shield you from the config, i'm sure many gui driven apps store their config in formats which are even harder to edit by hand than bind's.

The advantage of open source is that you have choice, you are not forced to use something that has verbose and anally-retentive configs. There are many alternatives for all kinds of different purposes.

When you bring up dumb/lazy staff, it is dumb/lazy people who are at fault for most things, and even if you give them something simple and intuitive they can still screw it up. Instead what we really need to do is make sure that people doing jobs where they need to run internet connected systems are suitably competent.

Re:Security? It's quite simple

[erKURITA]

You forgot the most important of all steps: ???

Re:Security? It's quite simple

[Crudely_Indecent]

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

Re:Security? It's quite simple

[stim]

$ 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:Security? It's quite simple

[Anonymous Coward]

aw. Too bad they didn't consult with you before writing bind. I guess those damned people doing enterprise-level, load-balancing DNS servers who actually know what all of the fields are for somehow got there first. You should just edit the hosts table, what more do you need?

There's no "verbose" stuff in bind config files. It all translates directly to the DNS protocols and the functions needed by the resolver software in the client. As for "somename.com = a.b.c.d" do you know how to do that simple lookup when the nameserver for somename.com is ns.somename.com? Didn't think so.

Re:Security? It's quite simple

[cstdenis]

FreeBSD's jail(8) is.

Re:Security? It's quite simple

[p0]

that's great! :)

Re:Security? It's quite simple

[cpthowdy]

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:Security? It's quite simple

[nihaopaul]

1) Put BIND in jail.

What crime does it have committed?

Its a terrorist!

Re:Security? It's quite simple

[timbrown]

DNSMasq?

Re:Security? It's quite simple

[billcopc]

This place would be so much nicer if they got rid of Mr Coward.

With my respectable knowledge of DNS, I still declare BIND to be overcomplicated and in need of a redesign. Much like all the other big Linux apps, it consists of immensely useful functionality wrapped in a baroque layer of crud. How can someone spend so much effort writing an excellent feature set, then hide it away beneath poorly-documented interfaces that even the developers don't consistently understand ? It's a cop-out.

Re:Security? It's quite simple

[gr8scot]

With my respectable knowledge of DNS, I still declare BIND to be overcomplicated and in need of a redesign. Much like all the other big Linux apps, it consists of immensely useful functionality wrapped in a baroque layer of crud. How can someone spend so much effort writing an excellent feature set, then hide it away beneath poorly-documented interfaces that even the developers don't consistently understand ? It's a cop-out.

This is just unfathomable to me. You're talking about open source software there. Do you not see the logical flaw in your complaint?

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

[Anonymous Coward]

Especially as there has been one vulnerability in the windows dns server in the past few years (even then it was an RPC vulnerability really) as opposed to the numerous bind problems. But hey, lets not let facts get in the way of microsoft bashing.

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]

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 a bunch of parallel systems that have much more dire failure modes, such as giving a cracker a shell login or accidentally exposing your whole filesystem to them via rsync. That, to me, makes it less secure in practice.

Re:Hypotheses != data

[Alex Pennace]

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

Re:Hypotheses != data

[Just Some Guy]

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

[Alex Pennace]

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

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. SSH supports binding a key to a command in .ssh/authorized_keys. Also supports IP matching too.

Well, except for the ones running djbdns. Looks like you can get djbdns to do AXFR, too.

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

[Alex Pennace]

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. Actually, both scenarios lead to the same worst case: potential root access. With both BIND and djbdns -- or pretty much any program that binds to a well-known port -- you are at the mercy of that process switching to the correct set of privileges.

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

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. 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. In that case, djbdns would be a good solution. Are you suggesting that we switch to BIND?

Re:Hypotheses != data

[Anonymous Coward]

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.

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

Re:Hypotheses != data

[Bert64]

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, letting your dhcp clients set arbitrary dns records is a horrible thing to do... Give all your IPs static hosts like dhcp-192.168.1.12.yourdomain.com etc.

As for having to use rsync/ssh, is that really necessary?
You can use a pull-only system, authenticated https perhaps. Compromise a leaf dns server, all you can do is steal the zone data (which you had anyway). And for many internet facing domains there are very few changes ever taking place, just a couple of hosts and an mx record.

As for incremental updates, i like the powerdns way of using sql replication.

Re:Hypotheses != data

[Just Some Guy]

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 installation pain and a small (although devout) pool of people who can help you with it. Furthermore, DJB tends to fancy himself an expert in areas where he has no experience, such as time synchronization and email system design (not to be confused with mail server writing). I'm not saying he's not smart, but he has a bad case of foot-in-mouth-philia.

I personally like BIND9 and use it on the servers I control, but PowerDNS and MaraDNS also get mentioned a lot when the subject comes up.

Re:Hypotheses != data

[Just Some Guy]

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 that you'd have to run an HTTP daemon on the nameserver. It's just one more thing that has to be gotten right.

I haven't used PowerDNS but it has enough fans that it must be doing something right. If we ever needed to migrate off BIND9 for some reason, that's probably where I'd look first.

Re:Hypotheses != data

[Just Some Guy]

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.

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.

Re:Hypotheses != data

[Alex Pennace]

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. That is precisely what we did, right down to using .local. To be fair to the Windows guys, I am not all that familiar with Active Directory and other critical Windows networking systems. I keep to the Unix systems, they keep to the Windows systems. Works wonderfully.

Re:Hypotheses != data

[dave562]

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. There are too many systems and too many things to know to rely on a single guru kind of person who knows it all. It sounds like you're working in a good shop.

Re:Hypotheses != data

[operagost]

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

Looks like that ideal went out the window:

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.

Re:Hypotheses != data

[Alex Pennace]

I was not bashing Windows, just stating that our crop of Windows admins seem to be flustered by DNS.

Re:Hypotheses != data

[leenks]

Who needs DNS when you have WINS?!

Re:Hypotheses != data

[innate]

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.

Re:Hypotheses != data

[rs79]

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

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 "

Between the rabid fanboys and the clueless MS phucks there's a middle road. And we don't run BIND. And somehow despite all hints to the contrary our dns just works and works and works and requires a lot less effort to keep it running than that bind thing.

Life goes on...

Re:Hypotheses != data

[dave562]

Between the rabid fanboys and the clueless MS phucks there's a middle road. And we don't run BIND. And somehow despite all hints to the contrary our dns just works and works and works and requires a lot less effort to keep it running than that bind thing.

And how does your DNS work? What is your DNS? Does it support Active Directory domain controllers and automatic zone updates from Windows DHCP servers?

Re:Hypotheses != data

[Bert64]

Powerdns is good because it's sql backed, which means it uses the existing sql replication facilities and makes it easy to write arbitrary frontends to it.

When i used djbdns i used HTTPS, with the data file downloaded every day... It worked on 2 stages, first downloaded a timestamp file, compared it to its locally stored timestamp and if it was different, download the full (much larger) dns datafile.
There's also no reason the HTTPS server needs to be a DNS server, it could be a completely seperate machine and it only needs to permit traffic from the leaf dns servers.

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

[AVee]

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

[Russ Nelson]

Don't hit me with those negative waves so early in the morning. Have a little faith, baby, have a little faith.

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

Re:DNSSEC is dead, let's move on

[leto]

As Morrisey's song goes, "The world is not America".
DNSSEC deployment is already happenening on Large Scale.

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 not an option, and people who whine about DNSSEC not being the right solution have done nothing for 10 years, so they have become part of the DNSSEC solution as a result. Note that no one has broken the protocol or principles behind DNSSEC. At most people say "It's too hard". That's what people said about SSL too.

DNSSEC has been deployed, and will be the protocol protecting your DNS. Get over it.

From the local LDAP Finatic

[Zombie Ryushu]

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:From the local LDAP Finatic

[Anonymous Coward]

Or someone should just hack up a new DNS server that uses LDAP as the backend and allows both transers in from other DNS servers (inserting into LDAP) and transfers zones out to other DNS servers (exporting from LDAP).

Re:From the local LDAP Finatic

[Russ Nelson]

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

Re:From the local LDAP Finatic

[raddan]

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.

Re:From the local LDAP Finatic

[Anonymous Coward]

Yes, but then you're stuck with djbdns.

Re:From the local LDAP Finatic

[Anonymous Coward]

Even better, use bind and copy your zones using ssh. ;)

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

[Antique Geekmeister]

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

[Anonymous Coward]

....network monitoring reasons

The better practice would be to add only your network management stations/networks to the allowed list instead of allowing the whole internal network.

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]

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

If your accounts server is called fin-vms1, and is only used internally, why advertise it's existence to the internet?

Re:Promiscuous zone transfers - just say no

[MadMidnightBomber]

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

[Bert64]

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

[ivan256]

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 attacker to get what they want and get out quickly should they break in.

If you have Bind9 configured correctly, it should only zone-transfer addresses that are visible on the network they are being transferred over. So your 5000 devices could do a transfer for all the addresses, and people on the internet could only transfer the addresses for the externally visible box.

If you use any type of round-robin that cycles through DNS names in a web-app, or anything like that, the only thing allowing transfers does is reduce the traffic to your nameserver by easing caching.

Re:Promiscuous zone transfers - just say no

[AVee]

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. when your network it allready compromised, does one really need to do a zone transfer do discover the existence of this machine?
And all of that is assuming you are mixing public and private machines in the same zone, which I guess is not the case for the majority of domains found on the internet. To make a rule (a holy rule for some) out of a thing which has a very limited use in a very limited number is scenarios is a useless waste of time. I have several domains for which only www. and mail. resolve, there are millions of those types of domains on the net and they gain absolutely nothing by prohibiting zone transfers.

Re:Promiscuous zone transfers - just say no

[Anonymous Coward]

Can you really expect regular hostmasters to get this, when the hostmasters of the ".int" and ".cm" TLDs (among others) don't get it?

Re:Promiscuous zone transfers - just say no

[kindbud]

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

[MadMidnightBomber]

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

[MadMidnightBomber]

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

[Bert64]

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

Re:Promiscuous zone transfers - just say no

[wolrahnaes]

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

[RollingThunder]

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.

Re:Promiscuous zone transfers - just say no

[Anonymous Coward]

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

That some people do it, nothing. That it gets toted as being a required step for a secure system, something to do before you even start thinking about securing the server itself, that's when it gets objectionable.

Like all security by obscurity, it takes time, even if just a few minutes. Time that could be better spent on real security. Like enabling mac filtering in a wireless access point, instead of enabling WPA.

Re:Promiscuous zone transfers - just say no

[WuphonsReach]

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

[kindbud]

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 Buggy Internet Name Server, and for good reason. For all I know, back then a zone transfer request could send the shadow file.

DIY

[Uzik2]

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.

Re:DIY

[ParaShoot]

Sounds like it'd be easier to write the worm.

Re:DIY

[dintech]

I drank the worm.

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:Cricket Liu

[Anonymous Coward]

Mom, is that you?
- Cricket

Good timing...

[tttonyyy]

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

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

[tttonyyy]

The hell? Even xname'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"

[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:A good example of "begging the question"

[archen]

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 reasons someone could go to another DNS server, they ass-u-me that it is for better security. So for better security we'll switch to BIND? Yeah right. I moved my networks to djbdns and never looked back.

Re:A good example of "begging the question"

[Anonymous Coward]

I'm usually just a reader, I have an account, but I just forgot my password... But anyway, I use djbdns as well, and have never had a problem with it ever.

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:How do I know?

[kayditty]

to get BIND version (unless it's been changed by way of the "version" directive under the options { } block in named.conf):

dig txt chaos version.bind @nameserver

to check if your name server allows zone transfers to just anyone (you might need to do this from an outside host in case they have their ACLs configured to include the network you're on):

host -l zone.name nameserver
OR
dig axfr zone.name @nameserver

You can also do that with BIND if you want. just make a slave zone and turn notifies off.

To test any of the various other things, you can do TXT SPF, KEY, SIG, and NXT resource records. As another poster said, this is a lot of hyperbole. There's no need to implement DNSSEC for public zones when the root, gTLD, and ccTLD servers don't have certificates.

Re:How do I know?

[kayditty]

Oh. I forgot recursion. Ideally, an authoritative server is going to be physically (or atleast logically) separate from a caching nameserver, but that's not always the case. You need to check from an external host to find out whether your provider is allowing outsiders to issue recursive queries:

dig anything @nameserver

With BIND, cached queries will be returned to hosts even if they aren't authorized for recursion. This known as cache snooping. To find out whether it's allowing an outsider to issue new queries and have them answered recursively, put in a domain name that you're sure isn't in cache (or flush the cache), e.g. bananorama.com

Re:How do I know?

[DRobson]

http://www.dnsstuff.com/
Though the site itself has gotten a lot more commercial than it once was the DNS report tool gives some nifty info. Other than that you'll be wanting to investigate `dig' (IIRC) and trying some various interesting commands.

Re:How do I know?

[mqatrombone]

dnsstuff.com has a "DNS Report" which can show some information, but since it is no longer as free as it was, I'm not sure it is as useful as it once was. I recommend dig + studying "DNS and BIND."

Re:How do I know?

[edgecase]

Conveniently provided by the author's company:

http://www.infoblox.com/services/dns_advisor.cfm

Re:How do I know?

[djangostiger]

You can probably use Cricket's free tool available from Infoblox:
http://www.infoblox.com/services/dns_advisor.cfm

djbdns?

[Anonymous Coward]

djbdns is not mentioned. Maybe it is lumped under "Other," but certainly suggests that Cricket is anti-djb.

MyDNS owns

[pyite69]

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.

which BIND do you mean?

[mibh]

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)

Re:which BIND do you mean?

[Anonymous Coward]

Holy shit! Paul Vixie is on slashdot. And he is using proper capitalisation for once?

Re:which BIND do you mean?

[Anonymous Coward]

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 who has to sign his /. posts because some people might not know what the l33t mibh account name means)

Instead, you should tar BIND9 separately and even more so than the previous versions. Why?

Because the commercial company that developed "BIND9" immediately turned around and wrote a better performing and more secure closed source commercial server after learning from the mistakes they made writing BIND versions X.Y-9.Z (despite what Vixie says about it being _all_ different developers for BIND9).

One of the most telling and hilariously ironic things about the better-than-BIND server written by the guys who wrote "the bestest newest" BIND server is that they use completely separate programs for authoritative and caching DNS servers - you know just like DJB was designed from the start (and BIND people have bashed incessantly) Why didn't they do that when they did the uber rewrite of BIND for v9?

Paul Vixie is Marc Fluery - he just hides it better, but be assured everything he does is about money, power and control - how about full disclosure of the money flow to/from Vixie/Nominum/ISC? Yeah, I thought not.

http://www.nominum.com/getFile.php?file=nominum_ds_cns.pdf

[these guys have balls, talking shit about code they wrote themselves on contract for ISC]

Attacks exploiting BIND's well-known weaknesses
don't affect any of Nominum's DNS servers, which
are based on completely separate source code.
With many times the throughput of BIND-based
name servers, Nominum's Foundation Caching
Name Servers are significantly more robust than
BIND servers and are able to withstand the
increased query loads generated by denial of service
attacks or virus-infected systems.
A Response Validation feature screens out
malformed or malicious DNS packets, protecting
systems from attacks directed at DNS resolver
libraries.

Nominum's Foundation Caching Name Server
operates within predefined memory constraints
regardless of the number of requests it
receives, thus eliminating a common source
of name-server outages.

Use djbdns, watch your security problems vanish

[Jonathan Walther]

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 configuration is a breeze. The file format is very robust and easy to edit. Most knobs and configuration items can be configured by using "echo" to echo values into little files in the configuration directory.

djbdns doesn't need restarting like bind does. djbdns doesn't die and restart; you can run "svc -t /service/tinydns" and it rereads the configuration instantly and starts serving it with changing its process ID.

I wish I'd installed djbdns years ago. If not for the licensing issues, it would have taken over the world and we'd have a much safer internet. djbdns even prevents cache poisoning, an old technique for hijacking domain names.

DNSSEC is a mess and provides little value.

[tqbf]

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 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 to deploy --- and that protocol hasn't even been deployed yet. Until NSEC3 (or, in the alternative, whitelies) is standardized, the result of that 10+ year effort is a protocol that publishes full zone contents to the world. And have you looked at how NSEC3 works? It's literally a Unix-style password file encoded into DNS zones. I wrote about this at length earlier this year as well.

Finally, DNSSEC will break the DNS. Everyone who takes the time to read comments on Slashdot has dealt with "expired SSL certificate" dialogs in their browser. Everyone has clicked past them. DNSSEC presents the same problem, across the entire DNS, but offers no "click-through" to deal with the situation: DNSSEC works below the API layer, and there is no chance gethostbyname is going anywhere in the near future.

Did you know that DNSSEC doesn't even secure the DNS communication between your browser and your DNS server? There's a whole other protocol --- TSIG --- that handles the "last mile" of DNS security.

Personally, I would be highly skeptical of "security" analysis from companies like Infoblox that claim DNSSEC adoption has anything to do with the security of the Internet.

Makes sense to me

[John Musbach]

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.

Re:YOU FIX IT THEN YOU CUNT

[gnarfel]

whoa dude, next time just one cup of coffee with your lines in the morning.

But... but... but...

[Grendel Drago]

But Bernstein is a jerk! Surely we can't use his software!

Why are we talking about DNSSEC?

[Grendel Drago]

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?

Hand-waving "security" theatre

[Schraegstrichpunkt]

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.