Any DNSvNext protocol MUST work in 100% of network situations where DNS works or else it has 0% of being adopted.
There is only one difficult technical issue and that is developing a protocol that is acceptable to the people who decide whether it goes in the machines. At this point that requirement isn't even acknowledged by this group. What people think should be the basis for decision is irrelevant. If you want to make the Internet more secure you have no choice but to work through the gatekeepers and those gatekeepers care about performance and reliability above all. Google is currently working on HTTP over UDP to shave a second of page load times. This group is working is proposing to move the most latency critical interaction from UDP to TLS. The disconnect is quite astonishing. On Thu, May 14, 2015 at 7:13 PM, Mark Andrews <[email protected]> wrote: > > In message <[email protected]>, Simon Josefsson writes: > > The document says "Protocol changes proposed here must consider > > potential interactions with middle boxes." and then goes on to introduce > > the two concepts of upgrade-based and port-based DNS-over-TLS. To me > > this looks as if behaviour of middle boxes were allowed to significantly > > influence the design of the protocol. What I'm questioning is whether > > this has lead to too high complexity that can harm rate of adoption. > > > > /Simon > > If a middle box does not respond it is broken. We need to stop > pandering to broken middle boxes. Most of them will pass stuff > especially the dumb proxies. If a middle box does not like the > query it can send back FORMERR / NOTIMP. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
