3 ms·

Dumb question: What does encrypted DNS really solve? Is it just that you know the DNS will be resolved by the server you chose and not modified? I understand t

Dumb question: What does encrypted DNS really solve? Is it just that you know the DNS will be resolved by the server you chose and not modified? I understand the approaches of DoT and DoH but people keep talking about privacy and tracking but it just seems like you can just run your own un-DNS server and get the same info by looking up the IP to get the DNS. You can still be monitored and controlled by IP, right?

marcosdumay 7y ago
It stops your ISP from messing with the DNS results, including from removing the DNSSEC information. It also stops them from reading all your DNS queries, even if you create a local cache you'll still need to query the network at least once on every domain you connect, encrypted DNS hides that one query from your ISP. DoH has the added benefit of hiding even the fact that you are making a query. That means your ISP can not block it and force you to use a non-encrypted algorithm. You can still be monitored by IP, but: - there isn't an exact 1 to 1 relation between IP and domain name - it still stops the ISP from messing with the results
bluejekyll 7y ago
There are two things it helps solve, but doesn't solve completely. 1) connection security, by which I mean, the DNS packets can not be actively manipulated. DNSSEC in theory helps with this too, but there's no way to distinguish in DNSSEC between a response that doesn't have any DNSSEC data vs. one that was modified to remove the DNSSEC data for nefarious purposes (i.e. allowing the response packet to have other unsigned records to be inserted in the response). DoT and DoH (and DNSCrypt before them) prevent this form of data manipulation. 2) Privacy, which you mention. This one is a little shaky, it protects you from the ISP or others monitoring the network traffic, from seeing the DNS request and response in the raw. If the next connection is TLS (for a website), until SNI is encrypted in TLS 1.3, then the name of the site is potentially disclosed in the raw on that next connection. Even so, the IP itself discloses a significant degree of information about that connection, though as more sites sit behind CDNs, the value of that information goes down. At the end of the day, with DoH and DoT, the privacy and data authenticity responsibilities are being passed off the the chosen resolver, which the article mentions as Google or Cloudflare in many cases. So now you're trusting those entities, for better or worse, with all that information.
- teddyh 7y ago
  > there's no way to distinguish in DNSSEC between a response that doesn't have any DNSSEC data vs. one that was modified to remove the DNSSEC data AFAIK, this is false. If you get a faked reply, you can see from the signatures of the parent zones that the reply should have been DNSSEC signed, and is therefore fake.
  - bluejekyll 7y ago
    I’m assuming that if you’re stripping the responses of RRSIGs you’d also deny requests for DNSKEY and DS records, returning no data and no error.
    - teddyh 7y ago
      The resolver has, hard coded, the root zone keys. If the resolver is denied the NS records from the root zone, a resolution is not possible. If the NS records are returned, they are signed and include the lower signature keys. If the NS records are stripped of keys, the signature of those responses is invalid. People have put some thought into the design of DNSSEC, you can’t simply invisibly block it and force a protocol downgrade.
      - bluejekyll 7y ago
        I’ll have to consider this in my own implementation. That is a reasonable way to detect invalid records. Thanks for the correction. I will add, though, that as you walk the tree back to the roots, downgrades in the key strength do happen as you get to the root 1024bit keys, which is unfortunate. Aside from that, if DNSSEC is detected to be blocked, or invalid, there’s currently not great mechanisms of signaling this to end users (in most software) to either opt into the security risk or notify them, beyond just failing the lookup.
        deleted 7y ago
        [deleted]
        7y ago

marcosdumay 7y ago

It stops your ISP from messing with the DNS results, including from removing the DNSSEC information. It also stops them from reading all your DNS queries, even if you create a local cache you'll still need to query the network at least once on every domain you connect, encrypted DNS hides that one query from your ISP. DoH has the added benefit of hiding even the fact that you are making a query. That means your ISP can not block it and force you to use a non-encrypted algorithm. You can still be monitored by IP, but: - there isn't an exact 1 to 1 relation between IP and domain name - it still stops the ISP from messing with the results

bluejekyll 7y ago

There are two things it helps solve, but doesn't solve completely. 1) connection security, by which I mean, the DNS packets can not be actively manipulated. DNSSEC in theory helps with this too, but there's no way to distinguish in DNSSEC between a response that doesn't have any DNSSEC data vs. one that was modified to remove the DNSSEC data for nefarious purposes (i.e. allowing the response packet to have other unsigned records to be inserted in the response). DoT and DoH (and DNSCrypt before them) prevent this form of data manipulation. 2) Privacy, which you mention. This one is a little shaky, it protects you from the ISP or others monitoring the network traffic, from seeing the DNS request and response in the raw. If the next connection is TLS (for a website), until SNI is encrypted in TLS 1.3, then the name of the site is potentially disclosed in the raw on that next connection. Even so, the IP itself discloses a significant degree of information about that connection, though as more sites sit behind CDNs, the value of that information goes down. At the end of the day, with DoH and DoT, the privacy and data authenticity responsibilities are being passed off the the chosen resolver, which the article mentions as Google or Cloudflare in many cases. So now you're trusting those entities, for better or worse, with all that information.

teddyh 7y ago
> there's no way to distinguish in DNSSEC between a response that doesn't have any DNSSEC data vs. one that was modified to remove the DNSSEC data AFAIK, this is false. If you get a faked reply, you can see from the signatures of the parent zones that the reply should have been DNSSEC signed, and is therefore fake.
- bluejekyll 7y ago
  I’m assuming that if you’re stripping the responses of RRSIGs you’d also deny requests for DNSKEY and DS records, returning no data and no error.
  - teddyh 7y ago
    The resolver has, hard coded, the root zone keys. If the resolver is denied the NS records from the root zone, a resolution is not possible. If the NS records are returned, they are signed and include the lower signature keys. If the NS records are stripped of keys, the signature of those responses is invalid. People have put some thought into the design of DNSSEC, you can’t simply invisibly block it and force a protocol downgrade.
    - bluejekyll 7y ago
      I’ll have to consider this in my own implementation. That is a reasonable way to detect invalid records. Thanks for the correction. I will add, though, that as you walk the tree back to the roots, downgrades in the key strength do happen as you get to the root 1024bit keys, which is unfortunate. Aside from that, if DNSSEC is detected to be blocked, or invalid, there’s currently not great mechanisms of signaling this to end users (in most software) to either opt into the security risk or notify them, beyond just failing the lookup.
      - deleted 7y ago
        [deleted]
      - 7y ago