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

Tue Jul 11 20:50:03 UTC 2017

Umm sorry. I hadn't seen the DNSSEC bit.

The idea of validating punnycode in the resolver was just such a bad idea,
I really couldn't quite believe you would be doing it. But having spent
part of the day cataloging all the times someone had called me an idiot
(23) a liar (12) a paid Clinton stooge (13) a US disinformation agent (34)
for stating that the DNC attack was performed by Russia, as confirmed by
Trump Jr's email messages released today, I was probably in a frame of mind
where the stupid was the most likely explanation.

I apologize.

Incidentally, yes I am looking at how many of the 'people' making the
attacks are still posting and the answer is, about a quarter seem to have
vanished off the face of the earth, another quarter have switched to a new,
apparently unrelated singular obsession.

On Tue, Jul 11, 2017 at 2:16 PM, Warren Kumari <warren at kumari.net> wrote:

> 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/1e4f81c8/attachment.html>