I'd be willing to pay a few bucks a month for DNSSEC. Support it, please!!
8 Comments
8 Comments
Who voted for this idea
Comments
written by bill fumerola 612 days ago
Rating: 1
| Rate Comment:
if DNSSEC ever reaches anything close to momentum in the internet community, we'll move towards supporting it. until then, cryptography for the sake of cryptography doesn't make much sense.
what in particular about DNSSEC makes you consider it so valuable? what value would it add to our service that is currently lacking? has anyone intercepted and manipulated your DNS packets lately?
Well, though some of these might be specious I'll give listing reasons for a secure DNS (in general) a shot.
Reasons:
1)Since the DNS wouldn't be our ISP if an ISP decides to go network biased and restrict traffic to specific domains it would prevent the shaper from knowing *which* site on a given resolved IP I am communicating with. Of course the packet shapers will probably start inspecting the port 80 data to see what domain it's going to but that's a problem unrelated to openDNS.
2)It enables anyone on a wireless hotspot to keep the DNS requests from being logged. That obviously wouldn't stop the router just from logging port 80 traffic but at least it would reduce the amount of information the middle man can snoop in.
3)How much traffic does DNS use? If it was worth it to make a local proxy similar to giganews' accelerator a local windows service that uses openssl or some such. IIRC openssl supports compression but I don't know how much it would save in the case of miniature DNS packets.
4)I read the DNSSEC employs some sort of key based authentication of domains but for most people I suppose it's preventing someone from logging it in the middle without having to rely on a VPN tunnel to someplace else. If just a proxy to a trusted party like in reason #3 there's no concern with interoperation between ISPs.
Problems I can think of:
1)CPU time - Encryption adds this; probably in spades. I suppose if it had demand it might be a 'value-added' product one could charge for to make up for the capital cost to support it.
2)Creation time of anything entering userland to support the service across the various platforms. From googling I seem to see that bind supports DNSSEC but I don't know as you'd want users to be twiddling with bind servers all across the internet. I don't see anything other than windows server having support for it either as I've not heard of it before. Making a local proxy service for windows/linux/OSX would solve this but that adds the time/money to create said program
3)It may make ISPs with cheap filtering unhappy. This may be unwanted on the part of opendns?
4)Some ISPs are starting to throttle all encrypted traffic. Given DNS is so small a packet I suppose stenography would solve that if you *really* want to go that far.
Only partly related:
Probably overcomplex but if local proxy existed with some more doing it could trap all outgoing http header data through the encrypted stream ignoring POSTs and such. Then on receipt forge the ip of the user at their permission with complete/appropriate TCP headers. (selective forging proxy?) It should route back to the user and still be valid unless I'm mistaken. Just doing header traffic should hide the destination and involve little bandwidth. Would this circumvent the deep packet inspection noted in reason #1? I don't know enough about that kind of hardware. Obviously HTTPS wouldn't need any such thing, it's already in a tunnel.
Interesting comment (NOT mine) posted here:
If you went on to consider that OpenDNS makes money from the NXDOMAIN rewriting that would be impossible with DNSSEC deployed, OF COURSE they are going say that it's EVIL.
Now, how about those of us that want real security on the Internet (like people that need to support online commerce, banking, government transactions).
Yeah, OpenDNS shows their true colors.
I don't think this is why OpenDNS doesn't support DNSSEC, but it's a reasonable argument.
I would be interested in OpenDNS using draft-vixie-dnsext-dns0x20-00 ideas to increase its security, and/or monitor for spoofing attempts.
BTW, lil kreen doesn't know what s/he is talking about and is just speculating.
DNSSEC does NOT provide confidentiality of data, in particular, all DNSSEC responses are authenticated but not encrypted.
Arrgh. My URLs were stripped from my posts above. The comment is reachable by googling DNSSEC-Is-Dead-Stick-a-Fork-in-It and going to the eweek article. http://www.eweek.com/c/a/Security/DNSSEC-Is-Dead-Stick-a-Fork-in-It/
I'll bump this request, but say DNSSEC should be supported for all domains that have it enabled in production, not just premium custoemrs. .GOV, .SE, .ORG, and others are live now.
Premium accounts could include TSIG for stub resolves to ensure that there are no modifications from OpenDNS to the clients. OpenDNS could push NetGear/Microsoft and others to add TSIG support. It's a security/antiphishing feature.
I don't think DNSSEC is something you can just ignore. Eventually, DNSSEC may even all for the overthrough SSL Certs and put opportunistic public key encryption right in DNS. IPSECKEY and SSHFP records already exist, and it's only a matter of time.
It may not matter in the end anyway. DNSSEC stub resolvers to verify Authenticated Data may get pushed down the the clients (at least browsers as add-ons) and bypass OpenDNS altogether. It'd just be nice if OpenDNS protected its cache the way domain owners are starting to choose to have it protected with DNSSEC.
Sign in to comment or register here.
Not quite the idea of *Open*DNS. Notice that I emphasise the part "Open" with massive asterisk marks. Donating to a valuable cause such as OpenDNS would be great, but actually asking the user to pay for an Open service, it kinda defeats the purpose.