8 ms·

I'm interested to see how the implementation performs in practice, but I don't see DNS over HTTPS as better than some of the other solutions out there. Some hav

I'm interested to see how the implementation performs in practice, but I don't see DNS over HTTPS as better than some of the other solutions out there. Some have been around for a while and are well-tried but failed to gain wide adoption, like DNSSEC. Others are new kids, unproven but with lots of promise on paper, like IPFS service discovery. In no particular order, here are some alternative technologies. As always YMMV and the proof is not just in the technical implementation of the protocol, but also the policies and politics around the adoption. A good chunk of them overlap DNS's goals in what they aim to do, but only partially. * DNSSEC - https://www.icann.org/resources/pages/dnssec-qaa-2014-01-29-en https://www.icann.org/resources/pages/dnssec-qaa-2014-01-29-... Various Distributed Hash Table (DHT) based approaches: * IPNS - https://medium.com/@yaniv_g/hosting-websites-on-ipfs-with-ipns-b94659c42b52 https://medium.com/@yaniv_g/hosting-websites-on-ipfs-with-ip... * Telehash - http://telehash.org/ http://telehash.org/ Various cryptocurrency approaches: * Namecoin - https://bit.namecoin.org/ https://bit.namecoin.org/ * DomainToken - http://www.domaintoken.io/ http://www.domaintoken.io/ * Steemit - https://steemit.com/ https://steemit.com/ If you know of others, please comment with the name and a link.

georgyo 8y ago
Ipns lookups take over a minute: https://github.com/ipfs/go-ipfs/issues/3860 https://github.com/ipfs/go-ipfs/issues/3860 Dnssec is just as vulnerable to mitm attacks, because you just strip the dnssec responses and the client has no way to know if it the resolver just doesn't support DNSSEC The crypto ones don't even warrant a response, they are non compatible with anything that happens today.
- phicoh 8y ago
  The reason DNSSEC is vulnerable to that kind of MITM attack is because browsers refuse to do client side validation. For privacy reasons, DNS over TLS and DNS over HTTPS are still a good idea. So even with DNSSEC you would need one of those.
  - tptacek 8y ago
    Browsers tried to do DNSSEC validation. It didn't work. DNSSEC features in Chrome, OS X, and Firefox were rolled back. Also: it is part of the architecture of DNSSEC for clients not to do full validation, which requires that they act as their own recursive resolvers and eliminates shared caches.
    - phicoh 8y ago
      Any pointers to which browser versions did do DNSSEC validation and is there any documentation of what didn't work? My experience with running the validator plugin for a couple of years is that it just works. Obviously, in the early days of DNSSEC there were more improperly signed zones. But since Google's public resolvers do DNSSEC validation, that is mostly a thing of the past. Then there might be the rare case of middle boxes breaking DNSSEC, but as far as I can tell, that is extremely rare. There is no connection between DNSSEC validation and being a full recursive resolver. You can easily have a stub resolver that does DNSSEC validation. Or, if it is easier, have a local validation recursive resolver that forwards to another recursive resolver.
      - tptacek 8y ago
        Google [why not dane in browsers].
        phicoh 8y ago
        I'm sure you are aware that Google has different results for different people. So for me the first 10 hits: don't seem to include any reference to browser versions that did DNSSEC validation. And didn't have any reference to studies using those browser versions to see what breaks. In short, 'Just google it' often means that somebody doesn't actually have the relevant references.
- mike-cardwell 8y ago
  1. sudo apt install unbound 2. Configure network settings to use 127.0.0.1 as the resolver You now have end to end DNSSEC protected DNS (when the domain supports it. Where support is admittedly low). The best a MITM can do is block your lookups. In the same way they can also block your HTTPS connections. [edit] Of course, the above will now fail by default in Firefox, because they wont use your local system resolver. Every other app on your system will be secured though. Until they also start getting their own custom made name resolution systems too.
- Avamander 8y ago
  You can make your resolver verify the entire chain.
  - georgyo 8y ago
    There are tlds that are unsigned, and any domains that are unsigned. You can not verify the entire chain, because it is possible that the domain you are looking up is infact unsigned. You can maybe pin some of the tld keys, but you can't pin all the domains under them.
    - mike-cardwell 8y ago
      I don't know what the figures are today, but in 2016, 89% of TLDS were signed using DNSSEC - https://www.internetsociety.org/blog/2017/01/state-of-dnssec-deployment-2016-report-shows-over-89-of-top-level-domains-signed/ https://www.internetsociety.org/blog/2017/01/state-of-dnssec...
    - Avamander 8y ago
      > You can not verify the entire chain, because it is possible that the domain you are looking up is infact unsigned. Then you conclude that it's okay that the domain is unsigned. Else - hard fail.
red0point 8y ago
The point of DNS over HTTPS is enhanced privacy. Currently, DNS packets are unencrypted, but can be signed (with DNSSEC). DNSSEC does nothing to hide to content of DNS requests /responses, but makes sure that they can't be tampered with. Adoption (client side DNSSEC validation) is currently at around 14% [1], which is indeed low. There is the DNS Privacy project, which proposes some solutions to the privacy issue [2]. The alternatives you're mentioning are really not alternatives at all (except namecoin, but only for .bit). How the other solutions (e.g. Steemit) are connected to the problem at hand is beyond me. [1]: https://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g=0 https://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&... [2]: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+-+The+Solutions https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+-+The+Sol...
- Asseon 8y ago
  Right now there are no benefits though. Because the browser sends the domainname you contact unencrypted via the TLS handshake due to SNI. So someone listing in to your communication will learn the hostname anyway. I know people are working on encrypted SNI but that will take time.
  - pfg 8y ago
    > Right now there are no benefits though. In terms of privacy, I would mostly agree. Using an authenticated channel to your resolver still protects against many common MitM vectors, so there's definitely a benefit there. Unlike DNSSEC, you're not dependent on the target domain being in the small subset of DNSSEC-enabled domains, not to mention that most client resolvers won't validate DNSSEC anyway.
  - icedchai 8y ago
    Encrypted SNI will take years before it is in common usage. If you're that concerned about privacy, you better use a VPN.
    - jedisct1 8y ago
      Not necessarily. CDNs have been doing, and keep doing a great job at pushing new things forward. Fastly, Cloudflare and Akamai already have implementations and test websites.
pfg 8y ago
It's important to note that DNSSEC does not provide encryption. Additionally, very few client resolvers validate DNSSEC. In typical MitM scenarios, DNS over TLS or HTTPS provides much better protection. If the resolver happens to validate DNSSEC, you're probably adding a bit of protection for other scenarios, but overall I'd still rather not see DNSSEC succeed. The confidentiality win is not huge, most use-cases will let an attacker make a good guess at the query through the destination IP (for IPs serving only one site) or via SNI. Still, there's definitely a win for other types of queries, and it'll get more useful once we figure out how to encrypt SNI.
- jedisct1 8y ago
  Major resolvers do DNSSEC validation. The real problem is the very low number of zones that are actually signed. Which shouldn't be an excuse for not doing DNSSEC validation if only because your own zones can be signed. You know, the ones you will be constantly ssh'ing to, and blindly accept new ssh server keys from because hey, it's your zone and you trust it.
  - deleted 8y ago
    [deleted]
  - tptacek 8y ago
    A good reason not to do DNSSEC validation is that it adds significant unreliability to your network (DNSSEC deployment failures happen all the time, with what appears to be higher frequency than TLS certificate failures, and DNSSEC failures are more dramatic and disabling than TLS failures) while adding only marginally to security, and then only in the best case --- there are cases where it reduces security. The security of my SSH servers is not influenced at all by the integrity of my DNS queries. If I had a fleet of servers and a large organization of people to secure, such that I was concerned about the security of user introductions to SSH servers, I would address that concern directly with certificates, not indirectly with DNSSEC. What's more, there are other good things that fall out of adopting SSH CAs (simplified provisioning being the most noticeable, short-lived credentials being the most important). Whereas there is basically no upside at all to adopting DNSSEC, and a lot of downside. DNSSEC is bad, which is why nobody uses it.
DrPhish 8y ago
Over the past year or so I've done a complete re-evaluation of my home network and online activity with an eye to privacy and safety, after having the epiphany that the cloud is just a fancy term for other people's computers. Why would I trust my modest compute needs and most personal data to someone else in this age of cheap hardware and virtualization? To concentrate purely on the DNS side, I set about re-engineering things for privacy, safety and speed (in that order). I'll only address my local resolver, and not the DNS I'm serving to the world at large for my personal domains. I run Palo-Alto's free minemeld server in order to get realtime threat lists. Any medium or higher threat level domains are fed to: an unbound caching resolver on my OpenBSD edge firewalls. These threat domains (along with adware domains from someonewhocares) are blackholed to 0.0.0.0. Any queries that are not in the cache are forwarded to: a BIND 9 server on a VM that has no direct access to the internet or the rest of my LAN. It will either answer authoritative queries for my internal LAN or forward queries that require an external authoritative answer to: Six DNSCrypt proxies in a round-robin scheme. Each proxy was chosen because it (claims it) doesn't log, and will also pass back DNSSEC failures. OpenDNS doesn't! Notes : My BIND server verifies DNSSEC. I also have a bunch of known-good/bad DNSSEC domains that my Nagios server checks constantly, verifying that DNSSEC is succeeding/failing as expected. I also have DNSSEC/TLSA/DANE for all my domains and services. Thank you letencrypt! My OpenBSD pf firewall forces ALL DNS queries to my unbound resolvers, so regardless of what server an internal client attempts to use, it ends up going thru all my security and privacy apparatus. Malware is unable to use it's own DNS servers to bypass my blackholing. I have not gone the extra step of using TOR. Although this seems like it would improve my privacy, I can't shake the feeling its an NSA honeypot and does more to mark you as a target of interest than it does to protect you. One feature I would like, which I have found impossible to implement on my own is fresh DNS cooldown, to prevent brand-new domains from resolving for x number or hours. I like the idea that malware using dynamically generated domains could be thwarted with this, but there isn't any central list/mechanism to figure this out. whois info is too unreliable and unstructured.
- mike-cardwell 8y ago
  SpamEatingMonkey offers a set of RBLs allowing you to look up domains which have been registered in the last N days with a simple DNS query (where N is one of 5, 10, 15 or 30) https://spameatingmonkey.com/services https://spameatingmonkey.com/services I've not used this myself, so I'm not recommending it. I only know that it exists.

georgyo 8y ago

Ipns lookups take over a minute: https://github.com/ipfs/go-ipfs/issues/3860 https://github.com/ipfs/go-ipfs/issues/3860 Dnssec is just as vulnerable to mitm attacks, because you just strip the dnssec responses and the client has no way to know if it the resolver just doesn't support DNSSEC The crypto ones don't even warrant a response, they are non compatible with anything that happens today.

phicoh 8y ago
The reason DNSSEC is vulnerable to that kind of MITM attack is because browsers refuse to do client side validation. For privacy reasons, DNS over TLS and DNS over HTTPS are still a good idea. So even with DNSSEC you would need one of those.
- tptacek 8y ago
  Browsers tried to do DNSSEC validation. It didn't work. DNSSEC features in Chrome, OS X, and Firefox were rolled back. Also: it is part of the architecture of DNSSEC for clients not to do full validation, which requires that they act as their own recursive resolvers and eliminates shared caches.
  - phicoh 8y ago
    Any pointers to which browser versions did do DNSSEC validation and is there any documentation of what didn't work? My experience with running the validator plugin for a couple of years is that it just works. Obviously, in the early days of DNSSEC there were more improperly signed zones. But since Google's public resolvers do DNSSEC validation, that is mostly a thing of the past. Then there might be the rare case of middle boxes breaking DNSSEC, but as far as I can tell, that is extremely rare. There is no connection between DNSSEC validation and being a full recursive resolver. You can easily have a stub resolver that does DNSSEC validation. Or, if it is easier, have a local validation recursive resolver that forwards to another recursive resolver.
    - tptacek 8y ago
      Google [why not dane in browsers].
      - phicoh 8y ago
        I'm sure you are aware that Google has different results for different people. So for me the first 10 hits: don't seem to include any reference to browser versions that did DNSSEC validation. And didn't have any reference to studies using those browser versions to see what breaks. In short, 'Just google it' often means that somebody doesn't actually have the relevant references.
mike-cardwell 8y ago
1. sudo apt install unbound 2. Configure network settings to use 127.0.0.1 as the resolver You now have end to end DNSSEC protected DNS (when the domain supports it. Where support is admittedly low). The best a MITM can do is block your lookups. In the same way they can also block your HTTPS connections. [edit] Of course, the above will now fail by default in Firefox, because they wont use your local system resolver. Every other app on your system will be secured though. Until they also start getting their own custom made name resolution systems too.
Avamander 8y ago
You can make your resolver verify the entire chain.
- georgyo 8y ago
  There are tlds that are unsigned, and any domains that are unsigned. You can not verify the entire chain, because it is possible that the domain you are looking up is infact unsigned. You can maybe pin some of the tld keys, but you can't pin all the domains under them.
  - mike-cardwell 8y ago
    I don't know what the figures are today, but in 2016, 89% of TLDS were signed using DNSSEC - https://www.internetsociety.org/blog/2017/01/state-of-dnssec-deployment-2016-report-shows-over-89-of-top-level-domains-signed/ https://www.internetsociety.org/blog/2017/01/state-of-dnssec...
  - Avamander 8y ago
    > You can not verify the entire chain, because it is possible that the domain you are looking up is infact unsigned. Then you conclude that it's okay that the domain is unsigned. Else - hard fail.

red0point 8y ago

The point of DNS over HTTPS is enhanced privacy. Currently, DNS packets are unencrypted, but can be signed (with DNSSEC). DNSSEC does nothing to hide to content of DNS requests /responses, but makes sure that they can't be tampered with. Adoption (client side DNSSEC validation) is currently at around 14% [1], which is indeed low. There is the DNS Privacy project, which proposes some solutions to the privacy issue [2]. The alternatives you're mentioning are really not alternatives at all (except namecoin, but only for .bit). How the other solutions (e.g. Steemit) are connected to the problem at hand is beyond me. [1]: https://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&g=0 https://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=7&... [2]: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+-+The+Solutions https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+-+The+Sol...

Asseon 8y ago
Right now there are no benefits though. Because the browser sends the domainname you contact unencrypted via the TLS handshake due to SNI. So someone listing in to your communication will learn the hostname anyway. I know people are working on encrypted SNI but that will take time.
- pfg 8y ago
  > Right now there are no benefits though. In terms of privacy, I would mostly agree. Using an authenticated channel to your resolver still protects against many common MitM vectors, so there's definitely a benefit there. Unlike DNSSEC, you're not dependent on the target domain being in the small subset of DNSSEC-enabled domains, not to mention that most client resolvers won't validate DNSSEC anyway.
- icedchai 8y ago
  Encrypted SNI will take years before it is in common usage. If you're that concerned about privacy, you better use a VPN.
  - jedisct1 8y ago
    Not necessarily. CDNs have been doing, and keep doing a great job at pushing new things forward. Fastly, Cloudflare and Akamai already have implementations and test websites.

pfg 8y ago

It's important to note that DNSSEC does not provide encryption. Additionally, very few client resolvers validate DNSSEC. In typical MitM scenarios, DNS over TLS or HTTPS provides much better protection. If the resolver happens to validate DNSSEC, you're probably adding a bit of protection for other scenarios, but overall I'd still rather not see DNSSEC succeed. The confidentiality win is not huge, most use-cases will let an attacker make a good guess at the query through the destination IP (for IPs serving only one site) or via SNI. Still, there's definitely a win for other types of queries, and it'll get more useful once we figure out how to encrypt SNI.

jedisct1 8y ago
Major resolvers do DNSSEC validation. The real problem is the very low number of zones that are actually signed. Which shouldn't be an excuse for not doing DNSSEC validation if only because your own zones can be signed. You know, the ones you will be constantly ssh'ing to, and blindly accept new ssh server keys from because hey, it's your zone and you trust it.
- deleted 8y ago
  [deleted]
- tptacek 8y ago
  A good reason not to do DNSSEC validation is that it adds significant unreliability to your network (DNSSEC deployment failures happen all the time, with what appears to be higher frequency than TLS certificate failures, and DNSSEC failures are more dramatic and disabling than TLS failures) while adding only marginally to security, and then only in the best case --- there are cases where it reduces security. The security of my SSH servers is not influenced at all by the integrity of my DNS queries. If I had a fleet of servers and a large organization of people to secure, such that I was concerned about the security of user introductions to SSH servers, I would address that concern directly with certificates, not indirectly with DNSSEC. What's more, there are other good things that fall out of adopting SSH CAs (simplified provisioning being the most noticeable, short-lived credentials being the most important). Whereas there is basically no upside at all to adopting DNSSEC, and a lot of downside. DNSSEC is bad, which is why nobody uses it.

DrPhish 8y ago

Over the past year or so I've done a complete re-evaluation of my home network and online activity with an eye to privacy and safety, after having the epiphany that the cloud is just a fancy term for other people's computers. Why would I trust my modest compute needs and most personal data to someone else in this age of cheap hardware and virtualization? To concentrate purely on the DNS side, I set about re-engineering things for privacy, safety and speed (in that order). I'll only address my local resolver, and not the DNS I'm serving to the world at large for my personal domains. I run Palo-Alto's free minemeld server in order to get realtime threat lists. Any medium or higher threat level domains are fed to: an unbound caching resolver on my OpenBSD edge firewalls. These threat domains (along with adware domains from someonewhocares) are blackholed to 0.0.0.0. Any queries that are not in the cache are forwarded to: a BIND 9 server on a VM that has no direct access to the internet or the rest of my LAN. It will either answer authoritative queries for my internal LAN or forward queries that require an external authoritative answer to: Six DNSCrypt proxies in a round-robin scheme. Each proxy was chosen because it (claims it) doesn't log, and will also pass back DNSSEC failures. OpenDNS doesn't! Notes : My BIND server verifies DNSSEC. I also have a bunch of known-good/bad DNSSEC domains that my Nagios server checks constantly, verifying that DNSSEC is succeeding/failing as expected. I also have DNSSEC/TLSA/DANE for all my domains and services. Thank you letencrypt! My OpenBSD pf firewall forces ALL DNS queries to my unbound resolvers, so regardless of what server an internal client attempts to use, it ends up going thru all my security and privacy apparatus. Malware is unable to use it's own DNS servers to bypass my blackholing. I have not gone the extra step of using TOR. Although this seems like it would improve my privacy, I can't shake the feeling its an NSA honeypot and does more to mark you as a target of interest than it does to protect you. One feature I would like, which I have found impossible to implement on my own is fresh DNS cooldown, to prevent brand-new domains from resolving for x number or hours. I like the idea that malware using dynamically generated domains could be thwarted with this, but there isn't any central list/mechanism to figure this out. whois info is too unreliable and unstructured.

mike-cardwell 8y ago
SpamEatingMonkey offers a set of RBLs allowing you to look up domains which have been registered in the last N days with a simple DNS query (where N is one of 5, 10, 15 or 30) https://spameatingmonkey.com/services https://spameatingmonkey.com/services I've not used this myself, so I'm not recommending it. I only know that it exists.