One of the questions we have to ask ourselves is what sort of DNS privacy solution are we aiming to provide here. Is it meant to be
A) A replacement for the DNS client-resolver protocol intended to eventually replace it. B) A scheme that allows those who want to achieve DNS privacy to do so My goal is to achieve A. However given the constraints that any clean architectural solution needs to deal with (UDP port blocking, etc) and the requirement to maintain 100% connectivity, that probably means accepting some sort of plan B as a backup. The reason this makes a difference is that there are a number of engineering approaches that are completely closed off if the objective is A. We can't expect to use a mechanism that tunnels encrypted DNS inside DNS as a long term replacement for the protocol. It also goes to the approach to scoring proposals. If we are looking to only achieve B then the simplest approach is to leverage as much existing infrastructure as possible. But if we are looking at A then we have to propose something that is the smallest possible increment on a minimal TCP+DNS stack.
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
