One in ten DNS servers still vulnerable to poisoning

Four months after researchers warned of a nasty design flaw in the net's address lookup system, more than 10 per cent of the servers used to resolve domain names on the internet remain "trivially vulnerable" to attack, a new study concludes. That translates to about 1.3 million domain name system servers that still have not …

[Chronos]

DNSSEC

"I had hoped we would see a spike in the adoption of DNSSec, but we really didn't see much of anything," Liu told El Reg. "It says that awareness of DNSSec is not that high, and the people who do know about DNSSec are probably afraid of it."

DNSSEC is trivial in BIND 9 and we're afraid of sod-all about it. It's getting your secondary providers to support it that's difficult. Most secondary providers don't even recognise AAAA or SPF RRs, let alone RRSIGs. It's fine for those with a server in every CoLo, but for the rest of us mere mortals trying to keep our subnets separate and our secondaries globally dispersed it's hell.

Now, getting your parent zone signed, that's a whole different cooking utensil of piscene matter. I'm using lookaside (the ISC's DLV) at the moment. $DEITY alone knows when the fractious, argumentative lot in charge of the ccTLDs, gTLDs and roots will make their minds up. RIPE's DNS-WG can't even agree on the wording of their response to NTIA's proposal. I suppose semantics count for something but, guys, as polite as I can make it, THE DNS IS FALLING APART AND YOU'RE WORRIED ABOUT GRAMMAR? Get on with it, ferchrissakes!

Nice little link for anyone "afraid" of DNSSEC: http://www.nlnetlabs.nl/dnssec_howto/

[Chris C]

Short-sighted much?

"I had hoped we would see a spike in the adoption of DNSSec, but we really didn't see much of anything," Liu told El Reg. "It says that awareness of DNSSec is not that high, and the people who do know about DNSSec are probably afraid of it."

This reeks of short-sighted ignorance. Whatever your take on DNSSec, there's one blindingly simple fact: encryption costs. For every packet that is encrypted, there are four additional costs over non-encrypted packets (two at each end): the additional cost in processing cycles to encrypt/decrypt the packet's content, and the additional cost in packet size (thus bandwidth) due to the encrypted packet being larger than the non-encrypted packet. This probably isn't a big deal on the user's end because they make relatively few lookups compared to the server end. But for a server, encryption can seriously slow down the machine. That's why hosts only use SSL HTTP where they absolutely have to.

I'm not saying that the extra CPU and bandwidth costs are why people haven't adopted DNSSec, but it's ignorant to discount it as a possibility. Also, let's not overlook the "it's working well enough right now, so why spend money on it?" mindset, either.

[Joseph Helenihi]

@ Chronos

"that's a whole different cooking utensil of piscene matter"

Very nice control of the anger by lashing out with the metaphors. I feel a need to share after that.

A favorite of mine is,

"If you want to know why the company does things like this and makes it policy, picture a semi-tractor trailer loaded to capacity with steel and concrete winding its way down a mountainside of deadly switchbacks at night in a heavy rainstorm. In the cab of this truck are 13 monkeys, some of them are fighting over the steering wheel, others mess with the pedals on the floor, while the rest of them take turns screaming into the CB radio, playing with the windshield wiper controls and rummaging through the glove box. These monkeys are oblivious to the conditions outside. That is how this company works."

[Alan W. Rateliff, II]

Encryption costs? Really?

I am not buying the argument that encryption weighs too heavily on a server to be implemented in DNS. At some point one must weigh security, availability, and convenience and determine that security wins out.

Unlike in the real world, the Cyber-World has proven over and over that a trusted authority is central to secure computing. Of course, provided that the trusted authority can really be trusted. But then, that is the ultimate question, is it not: what authority do we trust? First we would have to look at those we trust already, namely domain registrars and those responsible for maintaining the TLDs. But that idea protrudes too much into the real world of centralized authorities, and we fall right back to square one.

The whole "if it ain't broke, don't fix it" crowd tend to ignore when things really are not working by setting a low threshold for determination. If it works 20% of the time, then technically it *is* working. Contrarily, the "if it works, fix it until it breaks" crowd will draw the line at 100%. I do not see things like DNSSEC and TLS over HTTP being such work-breaks, and yet both are stagnated while seemingly trivial in purpose and implementation.

Frankly, there are resources available to spare for a more secure infrastructure. And if not, then we need to make them available. Not doing so simply shifts the costs and burdens from those who maintain it to those who use it.

Paris, wanting nothing more than to be safe when using it.

[Chronos]

Re: Short-sighted much?

DNSSEC isn't encryption, at least not in the same way as TLS/SSL. It does increase zone storage sizes and yes, on a busy server it will increase load due to the larger responses, but the mechanism is in the clear just as with normal DNS. What DNSSEC does is returns extra resource records such as RRSIG to clients requesting DNSSEC (dig flag +dnssec and you might want to add +multi to that to make it readable. You'll be wanting to query a DNSSEC aware resolver). Unless you're adding or removing RRs continuously, your extra workload as a sysadmin is restricted to effecting and keeping records of key rollovers. Changing the zone data between rollovers just requires re-signing the zone with the same keys and specifying the end date.

A zone is still static in whatever backend storage method you use and the data is still requested and transferred over port 53 in the clear, so the cost of crypto argument is moot. Bandwidth, however, will increase. This is unavoidable.

As for "it's working well enough," you know it isn't. There are umpteen different ways an attacker or a badly configured resolver can inject or introduce false information into a DNS transaction with no way, until DNSSEC came along, for the client to verify the authenticity of the information it receives as the DNS is insecure by design and is about ten years overdue for a good coat of looking at.

Example of a DNSSEC transaction:

; <<>> DiG 9.4.2-P1 <<>> nlnetlabs.nl +dnssec +multi

;; global options: printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49907

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 3

[ The "ad" flag means DNSSEC has been requested and the response has been verified as trusted. Which it should be as nlnetlabs.nl is one of my trust-anchors. ]

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; udp: 4096

[ Note the EDNS, or Extension Mechanisms for DNS, defined by RFC 2671. This allows a UDP reply to be longer than 500 bytes (in this case 4kB) and is essential for DNSSEC ]

;; QUESTION SECTION:

;nlnetlabs.nl. IN A

;; ANSWER SECTION:

nlnetlabs.nl. 3600 IN A 213.154.224.1

[ Standard A record you would expect in any DNS transaction for a simple forward lookup ]

nlnetlabs.nl. 3600 IN RRSIG A 5 2 10200 20081129015003 (

[ This is the new boy. RRSIG is the result of signing the A record with the ZSK, which in turn is signed with the KSK, the public key of which is known to either the parent zone, a DLV registry or added to a client as a trust anchor, which then allows the client to make a decision on whether it trusts the reply based on "trust anchors" containing SEPs (secure entry points: This is usually the public KSK of whatever zone you use as the trust anchor) of known good zones. None of this is done "on the fly." It's all static in the authoritative server's backend and can be safely cached for the length of the TTL. The only crypto involved is on the client side while verifying the RRSIGs. All of the necessary public keys are published in the zone itself. ]

20081101015003 18182 nlnetlabs.nl.

jxNZ6Z56Nr/jLBlSfz0zOIHSG///tojuS4E6yAPAe7aJ

5XHPdgP+qSnKSti7f1fENJcXX3u+bpbIFXee7GyM4bY4

Xu/xhO34kmabKp/lYJk6uLaptOs5JtyRO/pgnc11e9JM

XlvDLiInSDyi/M0I4RDDmXU/QMTAq0svBDwKmlQ= )

;; AUTHORITY SECTION:

nlnetlabs.nl. 7200 IN NS ns7.domain-registry.nl.

nlnetlabs.nl. 7200 IN NS open.nlnetlabs.nl.

nlnetlabs.nl. 7200 IN NS omval.tednet.nl.

nlnetlabs.nl. 10200 IN RRSIG NS 5 2 10200 20081129015003 (

20081101015003 18182 nlnetlabs.nl.

YrslcGdgl+YNmJ1/c0Fh7CwDdWF4zWNroZNIvLmqoAYy

14on8MIxP88dfdi1fmbEkXrSLMHCC70hpJ0S8HhHjNRP

KlH9OveoEt+pGaAu1zywGClJrafB4vr1CoSZ59MjMZy0

s5zTI2JN3+96PH/8EO3MLYPml7r5GVaCihjy3aA= )

;; ADDITIONAL SECTION:

open.nlnetlabs.nl. 7200 IN A 213.154.224.1

open.nlnetlabs.nl. 10200 IN RRSIG A 5 3 10200 20081129015004 (

20081101015004 18182 nlnetlabs.nl.

C44JcqFHGQkXG3nKJalZ6elmiHPTvTL83BNMqm04fasz

0UsBX7HNWNAKHfBQARQnUfmSdaCAH72JW+krVY1yNLCG

8p4NudwuSZ+adbG70sZBG5RbejiaBc+pEC0o9wnwHw+U

t943mD6j7a7V9MsgLykzi+Y+/7JL0TtCC5EGHSk= )

[Chris C]

@Chronos

Thanks for the explanation. I'll be the first to admit that some of that is still over my head. My earlier comment wasn't meant to say definitively why people don't use DNSSEC or to make any statement about security vs resources; it was merely meant as a possibility of what I'm sure a lot of people/companies are saying because they don't want to spend the money or time to upgrade.

Personally, I'm surprised we're still using DNS as we know it. It doesn't take a genius to see that it's a nightmare waiting to happen. The DNS server you use literally controls your connection, especially in today's world of virtual hosts where you need to request web pages using the host name. Unless you're doing your own DNS lookups, working backwards from the root servers to the destinations' authoritative nameservers, you're always going to be susceptible to redirection.

It's not surprising considering we're still using SMTP with all of its flaws, leaving us with the impossible task of dealing with spam (and why on earth do we still have people not using SPF?!?). The current protocols (DNS, DHCP, ARP, SMTP, POP3, IMAP, HTTP, etc) were great when they were created, back when security and authentication wasn't a problem. But it's time to scrap these and design new protocols with security built in from the start. Then again, look how long IPv6 has been hanging around trying to gain traction, and it's still a long way off.