3 ms·

"> control over delivery or content of unencrypted DNS packets And thus we are back to asking for DNSSec." DNSSEC does not encrypt DNS packets. (Nor does TLS

"> control over delivery or content of unencrypted DNS packets And thus we are back to asking for DNSSec." DNSSEC does not encrypt DNS packets. (Nor does TLS encrypt UDP DNS packets per packet. It encrypts a TCP stream.) Not interested in a debate over DNSSEC, but please note I used the word "unencrypted" for a reason. Not only can the contents of unencrypted packets be tampered with, but, if I am not mistaken, djb has suggested DNSSEC signed RRs are still vulnerable to forgery.

bluejekyll 9y ago
DNS does not only operate over UDP, it also uses TCP. > (Nor does TLS encrypt UDP DNS packets per packet. It encrypts a TCP stream.) DNS over TLS is for TCP: https://tools.ietf.org/html/rfc7858 https://tools.ietf.org/html/rfc7858 It is an encrypted private stream. For UDP encryption over DTLS: https://tools.ietf.org/html/rfc8094 https://tools.ietf.org/html/rfc8094 > Not interested in a debate over DNSSEC, but please note I used the word "unencrypted" for a reason. If you want privacy you use DNS over TLS or DNSCrypt. If you want assurance that the records can be trusted, the signatures are required. Because DNS relies on so many intermediary nodes for caching, etc, you need both. You need the RRSIG to validate that the zone actually created and manages that record. If you don't want people snooping on your queries, then you need a secure encrypted connection. You need both. > djb has suggested DNSSEC signed RRs are still vulnerable to forgery. can you find that? I know he's very much against DNSSEC, but I haven't seen comments on forgery specifically.
- aplorbust 9y ago
  "You need both." Me, personally? I do not use shared caches. I do not use local or remote caches. Wrote own nonrecursive (i.e. no RD bit ever set) stub resolver. As such, I have no use for DNSCrypt. I use trusted sources for lists of authoritative servers I need. I store IP addresses for those servers permanently and track changes in them, if any, over time. I have little interest in what ICANN certifies as a "valid" or "invalid" name. DNSSEC therefore does not appeal to me. IMO, better Web PKI could be focused on IP addresses and user-generated public keys (maybe combined with user-chosen "pet names"), something like SSH. Instead it appears to be solely focused on names issued by a third party and certificates based on those names, also issued by a third party. Probably "You need both" was a figure of speech. If so, pay no mind. "can you find that?" http://cr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-a4.pdf http://cr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-... and other DNS talks on that page Pages 11, 32.

bluejekyll 9y ago

DNS does not only operate over UDP, it also uses TCP. > (Nor does TLS encrypt UDP DNS packets per packet. It encrypts a TCP stream.) DNS over TLS is for TCP: https://tools.ietf.org/html/rfc7858 https://tools.ietf.org/html/rfc7858 It is an encrypted private stream. For UDP encryption over DTLS: https://tools.ietf.org/html/rfc8094 https://tools.ietf.org/html/rfc8094 > Not interested in a debate over DNSSEC, but please note I used the word "unencrypted" for a reason. If you want privacy you use DNS over TLS or DNSCrypt. If you want assurance that the records can be trusted, the signatures are required. Because DNS relies on so many intermediary nodes for caching, etc, you need both. You need the RRSIG to validate that the zone actually created and manages that record. If you don't want people snooping on your queries, then you need a secure encrypted connection. You need both. > djb has suggested DNSSEC signed RRs are still vulnerable to forgery. can you find that? I know he's very much against DNSSEC, but I haven't seen comments on forgery specifically.

aplorbust 9y ago
"You need both." Me, personally? I do not use shared caches. I do not use local or remote caches. Wrote own nonrecursive (i.e. no RD bit ever set) stub resolver. As such, I have no use for DNSCrypt. I use trusted sources for lists of authoritative servers I need. I store IP addresses for those servers permanently and track changes in them, if any, over time. I have little interest in what ICANN certifies as a "valid" or "invalid" name. DNSSEC therefore does not appeal to me. IMO, better Web PKI could be focused on IP addresses and user-generated public keys (maybe combined with user-chosen "pet names"), something like SSH. Instead it appears to be solely focused on names issued by a third party and certificates based on those names, also issued by a third party. Probably "You need both" was a figure of speech. If so, pay no mind. "can you find that?" http://cr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-a4.pdf http://cr.yp.to/talks/2016.12.08/slides-djb-20161208-dnssec-... and other DNS talks on that page Pages 11, 32.