Jacob, I am sorry, I just skipped answering your messages directly. Because I thought the ongoing discussion with Andrew would/will cover many other questions.
The other problem is that I am only one person and flooded with many messages....(so quick answering messages to not forget what is it in my mind... led to poor English messages or not understandable messages so that people had different interpretations. since it was only like quick thoughts without having time to expand them :-) ) In any case if the discussion did not cover your answer, I will directly answer your two(?) messages. Only briefly I answer a few of them that I think I did not cover... Best, Hosnieh > This is false. Sniffers are not always on the same path as injectors. > A sniffer is not a resolver. A resolver may be malicious. The network > may try to impersonate my resolver. In the second case, I'd like a way > to detect that someone is trying to impersonate (eg: authentication via > DANE record, etc) my resolver. In the first case, I'll use a resolver > that I trust. As you are yourself a DNS expert, DNS is application layer and not only related to local links, so the place of injectors can be anywhere in the network. If the DNS port on network devices, inbound and outbound are open then the location of injectors are not important. > > Then who are you afraid to retrieve your data?? > > I'm not sure that I understand your quesiton? I meant the people who are interested in your traffic. > > In other words, encryption help if there is continuous data exchange > > for a certain time (but not only 2 messages) that might allow > unwanted > > person to eavesdrop. > > If I configure my stub to trust my recursive resolver from the start, I > should have zero unencrypted connections. If I am a locally verifying, > DNSSEC enabled recursive resolver, I would like the traffic to look > identical (per connection) as if it was from an encrypted stub resolver. No, if the approach you use supports encryption and authentication. Then you have a complete case like item 4 of Andrew's message. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
