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

Warren Kumari warren at kumari.net
Tue Jul 11 21:05:55 UTC 2017


On Tue, Jul 11, 2017 at 4:50 PM, Phillip Hallam-Baker
<phill at hallambaker.com> wrote:
> 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.
>

Thank you.
'twas an easy mistake to make - there is currently so much drama
around emoji and domain names that it is understandable.

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



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



More information about the dns-operations mailing list