DNSCrypt – A protocol to improve DNS security • Hacker News Board

Re: DNSCrypt – A protocol to improve DNS security

#51

Post by _jal » Thu, Mar 30, 2017, 2:16 PM UTC

INTPenis wrote: post #40

Tepix wrote: post #38

Earlier quoted context omitted.

Bind is still a mess after all these years. It seems to me like I get an update every other week that fixes a trivial DoS that hits an unchecked assertion. bind is a software that is only 80% finished. The missing 20% that take 80% of the time will only be implemented via CVEs.

What's a good alternative open source DNS that supports views and DDNS updates?

Take a look at PowerDNS. I use it for my day job and it causes very little trouble. I can only recall one annoying bug and one security issue in about the last two years.

It also has an OK, if not great, API for integrating with, e.g., your provisioning system, inventory system, etc.

Re: DNSCrypt – A protocol to improve DNS security

#52

Post by _jal » Thu, Mar 30, 2017, 2:23 PM UTC

Tepix wrote: post #39

singularity2001 wrote: post #31

This can't be repeated often enough: If you have some ssh server somewhere (who hasn't), you can very easily create a 'VPN over ssh' by calling: sshuttle -r user@remote_host 0.0.0.0/0 --dns It works nicely together with dnscrypt

This only moves the problem slightly. You then have to trust the network surrounding your SSH box.

It does more than that. AWS or Linode are not, to my knowledge, deploying the sort of intrusive, ad-centric deep packet inspection that Comcast, for instance, is. It is also a layer of separation from your actual IP address, which is worth less than it may seem at first, but helps.

Of course, that could change if everyone starts using homebrew VPNs. That's a bit hard to imagine, but stranger things and all that.

Re: DNSCrypt – A protocol to improve DNS security

#53

Post by _jal » Thu, Mar 30, 2017, 2:26 PM UTC

tankenmate wrote: post #29

The default port of 443 is somewhat bizarre, it's almost guaranteed to conflict on a server. They could have applied to IETF / IANA for port 253 (it currently reserved / unassigned).

It is intentional. There are creepy providers out there that really want you to use their DNS so they can surveil/gaslight you, so they block or redirect traffic to well-known DNS ports.

Putting it on 443 forces a choice between letting people manage their own DNS or blocking every store on the planet.

Re: DNSCrypt – A protocol to improve DNS security

#54

Post by sGatling1788 » Thu, Mar 30, 2017, 2:44 PM UTC

LogicX wrote: post #28

gwu78 wrote: post #21

I prefer http://curvedns.on2it.net This was the original. Other than having to modify their ksh script, it is painless to set up. In my opinion, authoritative nameservers, and therefore DNSCurve forwarders like CurveDNS, are more important than recursive resolvers/caches such as OpenDNS and DNSCrypt. A recursive resolver should be authoritative for nothing. They are middlemen. Companies that offered this "service", s…

So much to respond to here. I am one of those companies running a recursive DNS service, DNSFilter.com We are not advertising driven. OpenDNS cut the ads a few years ago. We do not run open resolvers, we just have paying customers who wish to use our service. The DNS extensions you are referring to are the EDNS0 Client Subnet extension. It is in wide use by authoritative servers for major CDNs and is supported by a n…

How was OpenDNS able to cut the ads yet provide free service?

Re: DNSCrypt – A protocol to improve DNS security

#55

Post by riquito » Thu, Mar 30, 2017, 2:51 PM UTC

Is there any plan to let smartphones, both Android and iOS, tu support changing the DNS at system level without rooting the device? So that it works with cellular data and that you don't need to change it for every wifi?

Re: DNSCrypt – A protocol to improve DNS security

#56

Post by pixl97 » Thu, Mar 30, 2017, 2:51 PM UTC

MertsA wrote: post #25

0xxon wrote: post #12

Earlier quoted context omitted.

Most clients nowadays sent the "server name indication" (SNI) TLS extension though, which contains the name of the site you are connecting to. The extension is sent unencrypted, even when using TLS 1.3. So everyone sniffing the traffic can tell where you are surfing to, even without DNS.

And in order to support clients that don't support SNI, you need to have one domain per IP address so an attacker can just try and connect to that IP and then look at the SSL cert that's sent back to get the domain name.

>And in order to support clients that don't support SNI

There is little reason to support clients that do not support SNI. By supporting those clients you are likely putting your entire encrypted infrastructure at risk. SSL3 should be disabled by now. XP clients are legacy and should be taken out back and shot. Older mobile phones are enormous security risks.

Re: DNSCrypt – A protocol to improve DNS security

#57

Post by pixl97 » Thu, Mar 30, 2017, 2:55 PM UTC

mike-cardwell wrote: post #47

Your default setup probably involves using your ISPs DNS resolver, which leaks your DNS queries to your ISP. Your ISP can also see which IP addresses you are connecting to and which website hostnames you're visiting thanks to unencrypted HTTP, and to SNI. You could re-point your DNS resolver to one of the public DNSCrypt resolvers, but by doing so, all you're doing is making it so that another party gets to see your…

>Your default setup probably involves using your ISPs DNS resolver

You also have to make sure your ISP isn't transparently capturing your DNS packets, which they probably are.

Re: DNSCrypt – A protocol to improve DNS security

#58

Post by GTP » Thu, Mar 30, 2017, 3:10 PM UTC

LogicX wrote: post #28

gwu78 wrote: post #21

I prefer http://curvedns.on2it.net This was the original. Other than having to modify their ksh script, it is painless to set up. In my opinion, authoritative nameservers, and therefore DNSCurve forwarders like CurveDNS, are more important than recursive resolvers/caches such as OpenDNS and DNSCrypt. A recursive resolver should be authoritative for nothing. They are middlemen. Companies that offered this "service", s…

So much to respond to here. I am one of those companies running a recursive DNS service, DNSFilter.com We are not advertising driven. OpenDNS cut the ads a few years ago. We do not run open resolvers, we just have paying customers who wish to use our service. The DNS extensions you are referring to are the EDNS0 Client Subnet extension. It is in wide use by authoritative servers for major CDNs and is supported by a n…

From section 11 of the draft: "To protect users' privacy, Recursive Resolvers are strongly encouraged to conceal part of the IP address of the user by truncating IPv4 addresses to 24 bits. 56 bits are recommended for IPv6, based on [RFC6177]. ISPs should have more detailed knowledge of their own networks. That is, they might know that all 24-bit prefixes in a /20 are in the same area. In those cases, for optimal cache utilization and improved privacy, the ISP's Recursive Resolver SHOULD truncate IP addresses in this /20 to just 20 bits, instead of 24 as recommended above. Users who wish their full IP address to be hidden need to configure their client software, if possible, to include an ECS option specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of 0). As described in previous sections, this option will be forwarded across all the Recursive Resolvers supporting ECS, which MUST NOT modify it to include the network address of the client".

So it's suggested that DNS providers and ISPs use only a portion of the IP address but they aren't forced to do so (and how could they be forced anyway?). Then it says that users that don't want to send their IP address should configure their software accordingly, but again only "if possible" so again no guarantee that it would be possible. Now a question: I don't see why a DNS packet would contain the client's IP address and a (I admit too quick) look at the draft didn't provided any information. Could you please elaborate on the supposed advantages of this practice?

Re: DNSCrypt – A protocol to improve DNS security

#59

Post by bluejekyll » Thu, Mar 30, 2017, 3:13 PM UTC

MertsA wrote: post #27

gwu78 wrote: post #21

I prefer http://curvedns.on2it.net This was the original. Other than having to modify their ksh script, it is painless to set up. In my opinion, authoritative nameservers, and therefore DNSCurve forwarders like CurveDNS, are more important than recursive resolvers/caches such as OpenDNS and DNSCrypt. A recursive resolver should be authoritative for nothing. They are middlemen. Companies that offered this "service", s…

>The reason? Advertising. Or the ability to accurately direct users to the nearest POP.

Yes, for people who don't know, this is how many things like directing users to a closer TLS endpoint for HTTP such that the overall connection suffers less latency.

Re: DNSCrypt – A protocol to improve DNS security

#60

Post by bluejekyll » Thu, Mar 30, 2017, 3:19 PM UTC

sliken wrote: post #13

fukusa wrote: post #5

Earlier quoted context omitted.

As far as I understand this doesn't encrypt communication but authenticates it to ensure it hasn't been tampered with. So it's still out in the open. I also don't understand what the benefit over DNSSEC is. Edit: Nvm, DNSSEC still has to trust the validating resolver, DNSCrypt solves this.

Right, but what advantage does DNSCrypt have over a local DNSSEC aware resolver? If you can't trust the local resolver you have more serious problems than DNS.

As others have stated, DNSSec only solves for authenticity of the data, not privacy.

DNSCrypt has been designed to both authenticate, authorize and encrypt the channel.

Using both in conjunction means that you have a private connection with authenticated data coming from the upstream resolver. Now the obvious issue is you don't know what the upstream resolver does with that...