Found some dprive's documents related to the problem. My fault, I apologize for posting here. 06.07.18 02:31, Philippe Duke пише: > Hello, IETF folks. I still don't think that main IETF mailing list was a > good place to post this question. > > Have a little silly question about current state of the art DNS privacy. > > *) We have DNSSEC to validate DNS responses from authoritative DNS > servers for recursive queries. It works for recursive DNS resolvers you > (configure || trust) for domains that have zones signed. So we have > more-less (i should say more!) working mechanism for DNS response > authentication. > > *) At the same time last years 2016+ there are efforts to make > communication between trusted recursive resolver and client encrypted > hence secure. There is DNS-over-TLS available under RFC8310 and RFC7858. > > There is a problem. Two pieces of puzzle does not completely connect, > maybe. I realize that these efforts are developed to solve two different > sides of the same problem. One for client, other for resolver. But there > is a logical conclusion: DNS responses are consumed by clients in the > final. > > Is there a need to encrypt whole communication between recursive > resolver and authoritative servers? What if someone wish to establish > own recursive resolver in order to not trust "big guys" services and > hide the name resolution traffic at the same time? There is a problem > that it can't be easily done, I realize it from my point of view. Maybe > I am wrong. But what I know is the one thing - chicken and egg problem: > we authenticate by names. In DNS-over-TLS it is solved by simply > specifying resolver public key into trusted store. In case of TLS > encryption for DNS resolution itself, we don't have this way. > > What is your attitude? Is there a problem at all? > -- Philippe Duke Network software engineer System-level developer NetAssist LLC Ukraine Khreshchatyk Street, 10B, office 8 AS29632 http://netassist.ua Our GitHub Repository: https://github.com/netassist-ua
