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

[Warren Kumari]

On Tue, Jul 11, 2017 at 1:11 PM Phillip Hallam-Baker <phill at hallambaker.com>
wrote:

> 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.
>


Please re-read the original. You appear to be working from an incorrect
assumption. This is not a syntax check; there is a DS at the parent, but no
matching signature in the zone.

The domain fails DNSSEC validation, nothing to do with the  label itself --
if this had been example.com the exact same thing would have happened...


> 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.
>

Nod.

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.
>

Stop what? DNSSEC validation?
Again - nothing to do with the string itself, this was a regular DNSSEC
failure.


>
> 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.
>

Yup. Exactly.


> 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.
>
>
>
Nor to accuse people of performing checks which they aren't - the domain
fails regular DNSSEC validation:


   - No valid RRSIGs made by a key corresponding to a DS RR were found
   covering the DNSKEY RRset, resulting in no secure entry point (SEP) into
   the zone. (208.109.255.48, 216.69.185.48, 2607:f208:206::30,
   2607:f208:302::30, UDP_0_EDNS0_32768_4096, UDP_0_EDNS0_32768_512)
   - The DS RRset for the zone included algorithm 7 (RSASHA1NSEC3SHA1), but
   no DS RR matched a DNSKEY with algorithm 7 that signs the zone's DNSKEY
   RRset. (208.109.255.48, 216.69.185.48, 2607:f208:206::30,
   2607:f208:302::30, UDP_0_EDNS0_32768_4096, UDP_0_EDNS0_32768_512)


W

> --
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20170711/75267ba1/attachment.html>