The domain is “グランピートロル.jp”, “grumpy troll .jp”.
In order to do much with this, it's necessary to get the IDN format. Yet in testing basic Perl and Python to get the IDN, I was seeing values which I knew were wrong. The desired end result is "xn--qck5b9a5eml3bze.jp". Encoding is done on a per-label basis and the "xn--" prefix is added for DNS, so the test is "can I convert グランピートロル to qck5b9a5eml3bze ?"
To get the actual value needed, I ended up using a dig(1) with an IDN-capable dig, capturing the traffic with tcpdump and shoving it to my laptop to use Wireshark with a filter of [dns.qry.name contains "jp"]. That this was the first method which worked is problematic.
The basic problem was obvious once I spotted it: the input encoding was not utf-8, so the interpreter was not accepting that the string provided was already encoded in some way.
My first attempt was with ipython, the second was with perl. Neither worked. Turns out, my Python problem was ipython, not Python itself.
The simple one:
% perl -MNet::IDN::Punycode -le '$d="グランピートロル"; print Net::IDN::Punycode::encode_punycode($d)'
% perl -Mutf8 -MNet::IDN::Punycode -le '$d="グランピートロル"; print Net::IDN::Punycode::encode_punycode($d)'
Now for Python, this is what things look like when they go well:
>>> import codecs
>>> puny = codecs.lookup('punycode')
>>> label = u'グランピートロル'
But it turns out that just creating the string, from input, was being blocked by ipython. When things encode correctly, we get: u'\u30b0\u30e9\u30f3\u30d4\u30fc\u30c8\u30ed\u30eb'
In : u'グランピートロル'
That's what I get for wanting tab-completion in my Python REPL.
End result: I wrote a tool to wrap all this for me, in future.
% puny グランピートロル.jp