Before anyone wonders: No, this isn't an official TLD. The domains you register there won't resolve for anyone unless they futz with their nameserver settings.
I'm not sure what to make of this. Looks like a bunch of hackers got really bored and perhaps had a beer too many...
>Looks like a bunch of hackers got really bored and perhaps had a beer too many...
Many, many excellent projects are birthed this way.
I can only hope that one day, when I get drunk, my first instinct will be to start my own TLD. Right now, that generally isn't the foremost thing on my mind four pints in...
Just a thought: maybe that's a feature, not a bug. Seems like a quick and dirty way to put up a site that people couldn't get to unless they're already know what they're looking for (which would imply that you want them to find it). Probably not the intent, but I'm kind of intrigued by the idea of it essentially being an Internet stash house.
reading the rules from an rfc mentioned on the wiki, if XXX.XXX.XXX.42 is a valid IP address, the client should try to use that first, if not it should only then try to use DNS to resolve.
But note that the RFC assumes there will never be a numeric TLD. Furthermore, it suggests checking the string syntactically to determine if it's in dotted decimal form, remaining somewhat ambiguous about what to do if the hostname looks like IPv4, but the connection fails (it seems unwise to do a DNS lookup for every IPv4 address that's offline). Since IPv4 is relatively easy to validate, it would have made a lot more sense for a numeric TLD to select a number outside the range of 0-255, such as 4200. Then it's obvious that 1.2.3.4200 is a hostname (or harmless typo), and not an IP address.
host
The fully qualified domain name of a network host, or its IP
address as a set of four decimal digit groups separated by
".". Fully qualified domain names take the form as described
in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
[5]: a sequence of domain labels separated by ".", each domain
label starting and ending with an alphanumerical character and
possibly also containing "-" characters. The rightmost domain
label will never start with a digit, though, which
syntactically distinguishes all domain names from the IP
addresses.
A lot of parsers do support numbers outside 0-255, though, and treat them as "packed" addresses. For instance, 127.0.1, 32512.1 and 2130706433 are all sometimes treated as alternate representations of 127.0.0.1.
That certainly works, but it seems like a large part of this market would want numeric-only URLs, and so you couldn't have e.g., 1.2.3.4, or 1.1.2.3, etc.
Perhaps the 42registry should try to get openDNS to support .42, that would certainly open up a MUCH larger amount of people that its available to, its also reasonably easy to change to using openDNS servers.
The really interesting thing here is the alternate DNS root that hosts the gimmick TLD. But it's not the first (remember AlterNIC?).
Getting involved with this will teach you about DNS, and that's probably the best reason to do it --- but there are risks. (Frex, you're implicitly trusting whoever's running it to direct you back to the mainstream root servers for ".com", and not to an alternate ".com" on which selected sites are directed through password-harvesting proxies.)
> Because a numeric TLD is something new. As far as we know, it has never been tested out in the open.
> Because it means being independent from ICANN, and we believe this to be an important aspect of the experiment.
> Because we CAN. And "we" also means YOU. Technically, the experiment works. It is not officially endorsed by the powers that be, but it
Point 1 is pretty equivalent to #3 "because we can", I don't think we're running out of alphabetical TLDs so I don't get the purpose of the experiment (If it ain't broke...).
Point 2 I don't understand, why do you need a numerical TLD to be independent from ICANN? Why no go for ".foo"?
As I read it, because ICANN have apparently disallowed numeric TLDs so they don't expect they'll be allocating .42 anytime soon. Whereas ICANN might decide that .foo sounds nice and hand that out to someone, and then you wouldn't be able to figure out which registry to resolve the address against. It's not foolproof of course.
I remember in the late 90s (when I was just out of the single digits) Dutch computer hobby magazines would regularly feature articles about the "alternet" or the "dark net", where they'd explain how you could visit so many more sites beyond the "normal" internet that were secret, "illegal" and exciting.
I'll never forget the screenshot they printed of a website with a photo of a sea and "Welcome to the atlantic ocean" on it: http://atlantic.ocean.
Now you can find all of the software that used a regex on [.0-9]+ to decide if you gave them an IP or a name.
I would never have done that… on any software that is still in service, to my knowledge.
Edit: The right way is not to try to determine which it is, pass it to inet_pton() on the assumption that it is a numeric address. If that fails, then pass it in to getaddrinfo() to let DNS or whatever the host uses for names have a crack at it. gethostbyname is obsolete now.
“The answer to this is very simple. It was a joke. It had to be a number, an ordinary, smallish number, and I chose that one. Binary representations, base thirteen, Tibetan monks are all complete nonsense. I sat at my desk, stared into the garden and thought '42 will do'. I typed it out. End of story.”
Adams described his choice as 'a completely ordinary number, a number not just divisible by two but also six and seven. In fact it's the sort of number that you could without any fear introduce to your parents'
Douglas Adams' Hitchhiker's Guide comes to mind. 42 is the answer to the ultimate question of life, the universe and everything. I guess many hackers will get the reference.
Agreed, and as above, 42 is in the valid range for the 'D' part of an A.B.C.D ipv4 address. If the number were larger than 255, there would be no issue.
I'm not sure what to make of this. Looks like a bunch of hackers got really bored and perhaps had a beer too many...