[dns-operations] Emoji "Female" symbol fails to resolve at Google's 8.8.8.8 & 8.8.4.4

[Phillip Hallam-Baker]

On Tue, Jul 11, 2017 at 9:54 AM, Warren Kumari <warren at kumari.net> wrote:

> Because the DNSSEC for that domain is broken....
> http://dnsviz.net/d/xn--e5h.com/dnssec/
>
> The other resolvers that you tried presumably do not validate....
>
> Working as intended, will not fix :-),


​It might be as you intend but you are violating the protocol and your
resolver is causing systems to break.

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.


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.

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.

This check is unnecessary. xn--e5h.com 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.

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.


So what sort of intervention would be appropriate, what if the domain was
Microsoft with a Cyrillic s or the like?

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?


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.

But Google really must not go there because the primary brand for 8.8.8.8
is anti-censorship.

A while back, I proposed a one stop shop for resolution of services. I
still think that is the right idea.

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.


My vision for omnibroker was always that there would be
free.omnibroker.comodo.com and premium.omnibroker.comodo.com. I was not
going to be censoring anyone if they weren't asking for just that.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170711/485f27a0/attachment.html>