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

Warren Kumari warren at kumari.net
Tue Jul 11 18:16:53 UTC 2017

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

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


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

> 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
> 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. (,, 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. (,, 2607:f208:206::30,
   2607:f208:302::30, UDP_0_EDNS0_32768_4096, UDP_0_EDNS0_32768_512)


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

More information about the dns-operations mailing list