It must have been an exciting surprise for attendees.
I'm glad Snowden said DNS should be encrypted. From the tweet stream provided by @conflictmedia, that was tied for 1st for most re-tweeted, along with making the Internet for users, not spies. (It should be noted that DNSSEC is not encrypted.)
Too bad his appearance wasn't recorded, but HUGE thanks to Niels ten Oever and Rich Salz for tweeting major points!
You know, it's funny because just last week, I chatted with a friend of mine in the UK giving me some pretty crazy rundown of DNS issues he was having. I found out that BT (UK's leading ISP) hijacks DNS for parental control purposes (read: pornblock).
This is by law in the UK. A 2014 amendment to the 2003 Communications Act forces ISPs to do this. Blame the government, not the ISPs.
edit because HN won't let me post a rebuttal to the reply below:
Private corporations can be compelled and coerced by the government in other ways that aren't readily publicized. If you think these companies enjoy wasting resources on porn filter then you're crazy. Wikipedia:
"Prime Minister David Cameron made it clear in July 2013 that his aim was to ensure that by the end of 2013 all ISPs would have a filtering system in place.[13] As a result three of the four major ISPs (TalkTalk, Sky and BT[14]) began applying default filtering to new customers in 2013[15] with the fourth major ISP, Virgin, doing so in February 2014.[16] Default filtering of existing customers was implemented by all four major ISPs during 2014 with the aim of ensuring that the system applied to 95% of all households by the end of the year.[17][18]"
This timing isn't a big coincidence. Elect a better PM (or indirectly elect considering this is the UK) if you don't want such shenanigans.
1. Porn filtering is not law in the UK, that is a common misconception. It was merely encouraged by the government, but ISPs are not forced to offer it. The ISPs absolutely are the ones to blame.
2. DNS hijacking certainly is not mandated by law.
Edit: Here is a post by Adrian Kennard, CEO of Andrews & Arnold ISP in the UK, regarding porn filters:
Separate reply to your edit. [btw, you can click the timestamp in my comment if you are not presented with a reply link]
> If you think these companies enjoy wasting resources on porn filter then you're crazy
I don't know who's misleading you but BT offered parental controls, including adult content filtering, long before the 2013 governmental push. All they did was turn it on by default (it was off by default, before).
And none of this excuses hijacking DNS to offer parental controls. There are far better technical ways to achieve that.
And by the way, I don't live in the UK anymore and I don't like what you're implying with who I may or may not be voting for. I left when it got shit. Voted with my feet.
Sorry I'm a non-devops programmer ;) bad me. What are the better ways? HTTP 403 and friends? (Praying that you won't say "a .exe to fix the browser's access to porn")
Router-level blocklists/firewalling are the most common, but there are other ways. Think of how companies sanely implement their internal web access filters.
This is where I get to plug djbdns and DNSCURVE over DNSSEC. I think DJ has been ahead of the curve (no pun intended) on these things for quite some time. I am currently in the process of migrating from bind9 (and avoiding bind10 like the plague) to djbdns wherever possible. Quirks and lack of updates/extensions not withstanding, it's great so far.
I think that's a mistake. You are using abandoned software: djbdns 1.05 was released in 2001. It even has a published security flaw from 2009, for which the $1000 guarantee was paid by DJB, and yet there is still no official release to fix the issue (there is a patch available from other sources).
There is a fairly healthy ecosystem of BIND alternatives these days, but djbdns is not one of them.
This one? http://article.gmane.org/gmane.network.djbdns/13864 It is a little disappointing he didn't issue a new release with the patch included. Perhaps it can be rationalized that the original fork is abandoned, but distro-maintained forks are fine.
As someone who runs tinydns to serve a few personal domains, I'd be interested to hear of another simple, solid option, if it fixes any concrete problems a recent Ubuntu build of tinydns has.
A major issue with DNSCurve (and, to some extent, DNSSEC) is that you can't really do validation on the client.
Routers frequently redirect anything going to port 53 to a local cache and anything that doesn't look like regular, unencrypted DNS queries, will be dropped on the floor.
It's also fairly common to have routers only support some DNS records, or to be unable to return more than one record type in a response (e.g. no RRSIG records and A records together). Wi-fi access points are particularly good at making any attempt at making DNS more secure next to impossible.
I've been working on DNSSIG, a DNSCurve-like protocol that encapsulates signed responses in TXT and CNAME records, similar to what ip-over-DNS tunnels do. The end result is pretty ugly.
DNSCrypt initially used port 53, similar to DNSCurve, but it turned out to be a terrible idea, as it didn't work for the majority of home users, that had routers redirecting DNS queries.
> (Fully encrypted DNS can only fail in even more ways than dnssec.)
The main reasons DNSSEC fails frequently are:
* pre-computed signatures, rather than online signing
* a demented, overly complex protocol
* signatures that expire rapidly
Maybe tptacek can name some others.
The only DNS encryption people are currently using (DNSCurve/DNSCrypt) does per-packet encryption, with a very simple protocol involving only a single ciphersuite designed by djb, and no signatures. This makes all the difference in the world.
If encryption were so bad then people wouldn't be using TLS, SSH, etc. It's the terrible design of DNSSEC that has poisoned efforts in DNS security.
It's probably time to retire unauthenticated encryption as useless.
Now, if what you meant is that it uses AEAD, that amounts to the same thing as a signature. It has all the same failure modes, namely failure to authenticate.
DNSSEC is a clusterfuck, but if somebody can't put the right public key in the right place, I'm not convinced they'll be able to put the right public key in the right record with DNSCurve either. The exact same thing will happen, and then the solution will be "click here to disable dnscurve".
DNSCurve and DNSCrypt use authenticated encryption.
DNSCrypt is not stuck to "a single ciphersuite designed by djb". The ciphersuite is negotiated (using DNS queries + signed responses in DNSCrypt v2, and TLS in DNSCrypt v3).
Over TCP, it's not limited to "per-packet encryption" either.
The first of those is actually a very important feature. In an age where many organizations outsource their DNS hosting, it's more important than ever to sign your resource records offline.
It's pretty useless to invent a new scheme that gives Amazon and Cloudflare access to your cryptographic keys, so your favorite three letter agency could just go via them instead.
Only you can sign your data, and no one else. That is a feature we cannot compromise on if we face the sort of adversaries mentioned here.
The rapidly expiring signatures is actually a feature too. It serves to avoid the trainwreck that is TLS certificate revocation. But that is a technical problem that may have other solutions. Feel free to suggest one.
If a future DNS improvement (hopefully, blockchain based) starts providing SSL keys to reduce the latency required for an SSL connection on HTTP/2 (skipping the "Connection: Upgrade") and on HTTP/1 (when being redirected from http to https), it would provide advantages and would also encourage encrypted DNS queries.
I'm glad Snowden said DNS should be encrypted. From the tweet stream provided by @conflictmedia, that was tied for 1st for most re-tweeted, along with making the Internet for users, not spies. (It should be noted that DNSSEC is not encrypted.)
Too bad his appearance wasn't recorded, but HUGE thanks to Niels ten Oever and Rich Salz for tweeting major points!