Comment by chrismorgan | Hacker News Reader

Comment by chrismorgan | Hacker News Reader

I must quibble on points of technical precision (because otherwise the article is both amusing and interesting): the title is pretty much entirely incorrect.

I’ll pick on the FQDN part first, because it’s the (only) part that is unequivocally wrong. FQDN is a very specific technical term in the domain name system. A fully qualified domain name includes a trailing dot, so Ⅷ.ﬁ. would be four characters, even if Ⅷ and ﬁ were the actual labels. But they’re not: DNS is strictly ASCII-only, so this normalisation is happening at a higher level (as the OP notes in another response here, tools are applying IDNA2008, per RFC5895). The FQDN is viii.fi., which is eight characters long.

Next I deny the claim that it’s a single-character domain. Perhaps I’m getting petty here, but even if people do colloquially speak of example.com as a six-letter domain, counting only the label at the level you register the domain, so that I would grudgingly allow Ⅷ.ﬁ to be considered a single character domain (per proletariat vernacular), the domain name that was “bought” was not that, but viii.fi, which is a four-letter domain. Hair splitting is fun.

But my pettiness knows no bounds. Domain names aren’t bought, they’re registered for such-and-such an amount per annum. And I bet it wasn’t exactly £15.00 that was paid.

:-)

———

I went thinking about other TLDs that would work, and ℡ (TEL → .tel) and № (No → .no) occurred to me off the top of my head. Haven’t seen a .tel domain name in yonks. I never did quite see the point of .tel.

I appreciate your pettiness! I have edent.tel

I also have a list of tld which can be shortened by this process. https://shkspr.mobi/blog/2018/11/domain-hacks-with-unusual-u...

And, yes, £15.30. But let's not quibble :-)

Huh! That’s probably the most serious use of .tel that I’ve ever seen. Well done. :-)

The explanation in your blog post isn't quite correct. The conversion of "Ⅷ" to "VIII" happens when Unicode text is normalized using a "compatibility" mapping, that is normalization forms NFKC or NFKD, not when text is lowercased. While IDNA2003 required a custom mapping based on NFKC, IDNA2008 doesn't specify a mapping phase. It does allow custom mappings, though, and it seems that browsers apply NFKC at some point in the process. See https://unicode.org/reports/tr46/#Mapping

> example.com as a six-letter domain

If we're being pedantic, "example" has seven letters!

:-)

Sigh. I predicted as I wrote my comment that there would be some point in my comment that someone would contest; I just didn’t expect it to be such an elementary error! Cue sad OBOE (more apt than sad trombone).

:-) indeed.

Looks like another instance of Muphry's Law: https://en.wikipedia.org/wiki/Muphry%27s_law

Lol I thought you misspelled Murphy’s Law until I clicked the link. Good to know. :)

> A fully qualified domain name includes a trailing dot

The term is ambiguous, and many uses don't include the trailing dot. See IETF RFC 8499 section 2.

> DNS is strictly ASCII-only

DNS is not strictly ascii. At the protocol level labels are octet strings. You may be thinking of the LDH convention.

Correct. The ASCII constraint is for hostnames and domainnames, but not for all labels.

Thanks for the corrections.

• Hmm, I wasn’t aware of that admission of ambiguity. Allowing that fuzziness in terminology puzzles me, because if you don’t have the trailing dot, then what you have fundamentally isn’t fully qualified. Sure, some resolvers may treat it as though it were, but some won’t, and are perfectly correct not to. (I haven’t the foggiest idea what the balance of implementation behaviours might be. I know enough DNS to be dangerous, but I don’t live and breathe the stuff.)

• I should have said DNS hostnames are ASCII-only, which I believe to be true. (And yeah, this still depends on conventional rather than rigorously defined terminology.)

The trailing-dot-to-anchor thing is hidden away from the user by probably a majority of tools now for managing DNS records. If anything, this has probably made the situation a bit worse by allowing a lot of people to spend years managing DNS records without even knowing about it. Then they edit a BIND text file or something that doesn't assume it and it all goes wrong.

As far as client-side tools... no one ever uses the trailing dot and that can lead to some interesting situations if you have a search path set and use a resolver that resolves wildcard. Use of the search path at all is fairly unusual for "client-ish" setups though. You could also view the common non-use of the trailing dot as one of the causes of the ICANN recommendation against top-level domains resolving, as the search-vs-hostname-vs-fqdn ambiguity would be less common (but still present) if people commonly used the trailing dot.

Plus, if some site were using length limits as a security check, would they be counting Unicode glyphs, Unicode codepoints, code units, or bytes? Cause the one thing TFA's domain doesn't do is take up 4 bytes even without the trailing period (which isn't needed for the XSS anyways). No, it takes 7 bytes using UTF-8 and, naturally, precomposition. So TFA's 15-character XSS is actually an 18-byte XSS (in UTF-8).

:)

http://jonpos.tel would agree with you.

>I’ll pick on the FQDN part first, because it’s the (only) part that is unequivocally wrong.

Technically correct is best correct.

>Hair splitting is fun.

Surely it just can't get any better than this. We're done here.

>But my pettiness knows no bounds.

I'm dead. Wrap me up.

Reply on news.ycombinator.com