<div dir="ltr"><div class="gmail_default" style="font-size:small">On Tue, Jul 11, 2017 at 9:54 AM, Warren Kumari <span dir="ltr"><<a href="mailto:warren@kumari.net" target="_blank">warren@kumari.net</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Because the DNSSEC for that domain is broken....<br>
<a href="http://dnsviz.net/d/xn--e5h.com/dnssec/" rel="noreferrer" target="_blank">http://dnsviz.net/d/xn--e5h.co<wbr>m/dnssec/</a><br>
<br>
The other resolvers that you tried presumably do not validate....<br>
<br>
Working as intended, will not fix :-),</blockquote><div><br></div><div class="gmail_default" style="font-size:small">​It might be as you intend but you are violating the protocol and your resolver is causing systems to break.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Intermediary servers performing unwanted validation have long been the bane of the Internet. They break the end to end protocol and in a bad way. I will probably be raising this in the plenary in Prague because I think there are good and bad uses of intelligence in the middle and you have a bad one. And I think that it illustrates a much more general problem that we need to get to grips with.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Back in the distant past, a lot of people realized that you could put 'intelligence' in the mail server. Why put code to wrap lines of text in every app when you could put it in the mail server. So we ended up with a crappy unreliable mail system because some folk took a shortcut.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">A lot of the problems with transitioning the DNS to new uses in the past has come from built in assumptions such as requests only being for a limited number of queries. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This check is unnecessary. <a href="http://xn--e5h.com" target="_blank">xn--e5h.com</a> is a perfectly legal DNS address according to the protocol. It might be illegitimate as far as the application layer goes but that is not part of the protocol. So one part of the problem here is that we have a layering violation. We have a transport layer intermediary attempting to enforce application layer concerns.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">History tells us that your validation hack will not be properly maintained and that over time we will find it is still blocking sites after the rules have been changed. You have created a source of confusion and entropy. Stop it.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So what sort of intervention would be appropriate, what if the domain was Microsoft with a Cyrillic s or the like?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Here we do have the start of a concern but we also have a slippery slope. What kind of slope? Should we try to go down slowly or on skis?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">A DNS resolver is potentially a control point that can be used to provide a huge degree of protection to the systems using it to resolve. Consider the forms in which most blacklists of bad sites are provided today - bad IP addresses, bad DNS addresses. I can block access to 90% of the badness on the Internet in one cut just by blackholing requests that would lead there.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But Google really must not go there because the primary brand for 8.8.8.8 is anti-censorship.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">A while back, I proposed a one stop shop for resolution of services. I still think that is the right idea.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If you are going to start putting any sort of intelligence into the network core, you have to get full consent from the use for all the purposes. And consent means choice.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My vision for omnibroker was always that there would be <a href="http://free.omnibroker.comodo.com">free.omnibroker.comodo.com</a> and <a href="http://premium.omnibroker.comodo.com">premium.omnibroker.comodo.com</a>. I was not going to be censoring anyone if they weren't asking for just that.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The principle of using the resolution service as a policy enforcement point is good. But if we are going to mess up consumer's experience it should be to protect them from criminals. Not to enforce pointless syntax rules.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"> </div></div></div></div>