3 ms·
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. DN
by 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 agoI’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 agoThe 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 agoI’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]
- teddyh 7y ago> the root 1024bit keys I was under the impression that the root key is now 2048 bits, since October 2018, over a year ago. > there’s currently not great mechanisms of signaling this to end users Not unlike SMTP, but we seem to have managed to transition to mostly TLS-encrypted mail transport.
- tptacek 7y agoThere have in fact been downgrade attacks on DNSSEC; for instance, relatively recent BIND versions would cache unsigned records in the Additional Data section of response packets. Part of the problem is that avoiding downgrade attacks is a shared responsibility between resolvers and authority servers and DNSSEC simply hasn't been fielded enough (and probably never will be) to receive the kind of sustained attention it takes to shake out these kinds of bugs; part of the problem is DNSSEC's incoherent cryptographic design (you can strip all the signatures out of a DNSSEC response and end up with a valid DNS response).