DNS security

This is a general DNS security thread for anyone willing to discuss, help newbies or learn more about DNS security in general.

Who among you are using DNSSEC[1][2] already? Why do you use it? What do you use it for? Have you considered TLSA (DANE[3]), SSHFP[4], OPENPGPKEY[5] resource records (RRs) yet?

Perhaps you don't like DNSSEC and instead use DNSCrypt[6] or DNSCurve[7] for encryption of your queries?

Share your thoughts!

Newbies section:
Here are some very basic, newbie friendly, introductory DNSSEC videos:
youtube.com/watch?v=lTABuMxO2AM
youtube.com/watch?v=qlto6GfZEvA

DNSSEC uses asymmetric cryptography[8] to securely sign all resource record sets (RRsets) on all authoritative name servers that support DNSSEC. Your local DNSSEC enabled resolver then validates the authenticity of your DNS queries to make sure your query has not been tampered with. This thwarts attacks trying to, for example, redirect you to malicious and compromised servers instead.

If you're thinking about registering your own domain, check if your registrar offers DNSSEC. Some registrars automatically sign your zone, which means you most likely can already add your TLSA RRs and such. Other registrars offer to upload your Delegation Signer (DS) RR, or your public zone signing key (ZSK) / public key signing key (KSK) instead. That's also nice if you wish to just host your own authoritative name server.

[1] tools.ietf.org/html/rfc4033
[2] dnssec.net/
[3] tools.ietf.org/html/rfc6698
[4] tools.ietf.org/html/rfc4255
[5] tools.ietf.org/html/rfc7929
[6] dnscrypt.org/
[7] dnscurve.org/
[8] en.wikipedia.org/wiki/Public-key_cryptography

Other urls found in this thread:

dnssec-validator.cz/
wilderssecurity.com/threads/wireshark-question.389556/
web.cs.ucla.edu/~lixia/papers/06INFOCOM.pdf
developers.google.com/speed/public-dns/privacy
namecoin.org/
twitter.com/AnonBabble

what browsers can i install on gnu/linux that support dane?

Most major browsers out there with the DNSSEC/TLSA Validator add-on[1].

[1] dnssec-validator.cz/

People in IT can barely muster making functional SPF records, do you honestly think they can even comprehend the basics of DNS security? Unless someone comes up with a way of easily implementing this, DNSSEC will remain a meme.

>Unless someone comes up with a way of easily implementing this, DNSSEC will remain a meme.
Some registrars are rolling DNSSEC for all their customers already, so sometimes it's just a matter of populating all your RRs in the zone and the registrar takes care of all the rest.

I'm a complete nood so i installed dnscrypt (the easy one) and i tried to see with wireshark if my dns requests were encrypted and they were but they use a protocol called QUIC that i couldn't find mentioned anywhere on the dnscrypt website, so is that normal or i screwed up the configuration?

wilderssecurity.com/threads/wireshark-question.389556/

So what is the purpose of this? Hiding your DNS lookups from your ISP/VPN, right? How much practical value does this actually have, given that if you're hiding from the government you will probably not be using clearnet anyway, and if you aren't they'll mostly be seeing you make lookups for innocent sites?
It's not like they can see any actual content. Should I really be worrying about them seeing the hostnames of the sites I connect to?

Encrypting your lookups is possible with DNSCrypt or DNSCurve. DNSSEC 'simply' makes sure your lookups are tamper-proof, by validating the added cryptographic signatures of each lookup.

So this isn't about hiding. It's more about making sure your queries haven't been tampered with by attackers.

I will add that DNS wasn't designed to be secure at all. It's a big misconception that DNS queries are supposed to be public anyway. And as a result, DNS has long been the most easy and widely used monitoring mechanisms to track people's online behaviour, especially when combining this with other telemetry ingress. For example when they also see that you're connecting to the resolved hostnames and such, using whichever protocol, or at what time, and how long. Metadata is sometimes all you need to deduct what a person is doing. I'll leave it to you whether or not you're worried about that.

>It's more about making sure your queries haven't been tampered with by attackers.
Ah that makes a lot of sense. I assume DNSCrypt also does that (if only by virtue of it being encrypted with a secret key)?

>they also see that you're connecting to the resolved hostnames and such, using whichever protocol, or at what time, and how long
Sorry if this makes me sound stupid, but I assumed there'd be a cache around, if not at the OS level, at least at the router level? Surely there isn't a DNS lookup happening every single time I click on a video on youtube to watch. Or is there?

Did you at least install a caching server like unbound along dnscrypt?

Be sure to enable dnssec in unbound.conf along with using a no log/dnssec enabled server from your dnscrypt-resolvers.csv

So that means that everything is ok, right? I don't see a clear answer to that OP

>Did you at least install a caching server like unbound along dnscrypt?
Ehm... No. What do i need it for? Is a dns caching server the same things as a dns cache? So it speeds up things when i request something i had already requested?
And how do i know if a server doesn't log? Now I'm using the default one called "DNSCrypt.org France"

>sorry for being so clueless

Google has dnssec implemented and they provide a dns over https server at dns.google.com.

You can use a local proxy to translate requests.

>Ah that makes a lot of sense. I assume DNSCrypt also does that (if only by virtue of it being encrypted with a secret key)?
Indeed, it uses asymmetric cryptography for encrypting the data as well.
>Sorry if this makes me sound stupid, but I assumed there'd be a cache around, if not at the OS level, at least at the router level?
A cache of what exactly? There's your web browser's cache of course. Other applications may as well.
>Surely there isn't a DNS lookup happening every single time I click on a video on youtube to watch. Or is there?
Not for every Web request on the same host, no. There's no point in resolving something that's already resolved, that's why we have a cache. But when you flush your cache, you need to resolve the hostname again, of course.

Another stupid question: can't your ISP (or whoever reads your traffic) just read the destination IP anyway, and then make their own DNS lookup if they want to? Wouldn't that make dnscrypt et al useless? Is that why you're recommending dnssec instead?

dnssec is just security to prevent shit like dns poisoning, it doesn't really help you unless the domain you are visiting and the dns server you are using both support it.

If you want an additional layer of privacy i.e. no plaintext domain names in your requests because they are all encrypted, then you want to use something like dns.google.com

so we set up an internet proxy to go through dns.google.com and now the only company that has all our data is Google? great..

>
>dnssec is just security to prevent shit like dns poisoning, it doesn't really help you unless the domain you are visiting and the dns server you are using both support it.
True, which is a good thing.
>If you want an additional layer of privacy i.e. no plaintext domain names in your requests because they are all encrypted, then you want to use something like dns.google.com
This may add encryption, yes, but at what cost? Google knows enough of you, no need to help it further, I say. Besides, we got DNSCrypt for that, which you can use to connect to a system you actually trust or own.

I'm really tired of scrolling past this thread

Right, but this doesn't answer my question (which I admit is a stupid one, but I'd still like an answer if possible).

Say I set up DNSCrypt and connect to some openNIC server that also implements it. Then I make encrypted DNS lookups, and say I only browse using https. How much does/can my ISP (or anyone else who has access to my traffic) know about what I'm actually doing? How much is dnscrypt actually helping in this situation?

Confirmed. IT janitor here. I didn't even know about SPF until a few months ago.

What exactly is the point of this?
If someone is on the same network is mitming you, he can intercept and modify traffic without having to rewrite any IP addresses

Not him and I don't know much about this, but at the very least your ISP would still know the actual IPs you connect to, how long your session takes and how much data you transfer.

...and then they can just make a DNS lookup themselves to find out the domain you're connecting to. That's what I thought.

So what is the point of dnscrypt then (over something like dnssec that doesn't encrypt the lookup)? Is there no point at all?

Better Google with anonymized data than your ISP.

It's an interesting question, and from the ISPs point of view, they could resolve the hostname themselves, that's correct. The only thing I can think of is that sometimes an IP address may not be enough to pinpoint what you exactly connected to. For example, a lot of businesses use third party hosting companies. One IP address to such a large hosting company still doesn't tell you to which specific website you connected to, for example.

But I see what you mean, this is not perfect. If you want to obfuscate the destination IP address as well you're probably better off with something like Tor to being with.

Alright, thanks. So really encrypting your DNS lookups doesn't offer much value.

I'll still look into it to prevent dns poisoning or whatever though.

The point is to make modifications impossible to DNS traffic. Other traffic is out of scope here. If the attacker forges his or her own DNS answer to your query, then he or she would also need to calculate an exact hash collision of the signature. This is practically impossible with strong cryptographic algorithms.

And then better your own system or a system you trust than Google's, IMHO.

Have to trust someone, thats how dns works.

how do ou know its "anonymized"

Because Google says it is.

web.cs.ucla.edu/~lixia/papers/06INFOCOM.pdf

pros/cons of a dht based dns system

...

Google Public DNS stores two sets of logs: temporary and permanent. The temporary logs store the full IP address of the machine you're using. We have to do this so that we can spot potentially bad things like DDoS attacks and so we can fix problems, such as particular domains not showing up for specific users.

We delete these temporary logs within 24 to 48 hours.

In the permanent logs, we don't keep personally identifiable information or IP information. We do keep some location information (at the city/metro level) so that we can conduct debugging, analyze abuse phenomena. After keeping this data for two weeks, we randomly sample a small subset for permanent storage.

We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services.

developers.google.com/speed/public-dns/privacy

tl;dr they delete your IP within 48 hours.

45ms for an uncached response from Google's dns over https server via local dns proxy.

In case anyone is concerned with the unpredictable speed or availability of opendns crap and just wants a good secure anonymous dns.

Namecoin [1] is an example of such a P2P resilient system.

[1] namecoin.org/

Reminder that such a latency measure differs for everyone.

I do admit it probably won't be that fast for anyone else. I already get 5ms responses from google dns without the proxy.

They log your IP, therefore it's not anonymous. Especially if you use it on a daily basis.

They delete personally identifying information and its only stored temporarily.

Whether or not you believe them its better than nothing.

Google says they only delete personally identifiable information from the permanent logs, not from the temporary logs. There's also no guarantee you or Google can give us whether someone's traffic ends up either in the temporary or permanent logs. They don't notify you, they don't tell you why or even what triggered permanent log storage, et cetera. It's a complete black box you only trust by their very short onepager.

They literally tell you exactly how they handle the information, you are retarded.

If you can answer where your data eventually ends up and how it's processed you're welcome to share, friend.

It doesn't matter because its anonymized.

It's OK to admit you don't know, man. Nobody does anyway, except Google it seems. If you're personally fine with that, great, use it. But don't advertise this black box as the solution to anonymous DNS, because it clearly is not. Anyone can deduct this from that privacy onepager.