Indeed. I've owned `invaliddomain.com` for almost 20 years. You'll be surprised how many use it for testing. One morning I woke up to 30,000 e-mails from Sony Japan with PDFs attached of scanned hand-written part orders. Something similar with Boeing sending me backup notifications. I notified each of these companies about their configuration through their official channels, only to be told "no, it's your server doing this" then usually followed up with an e-mail a few weeks later along the lines of "sorry, our bad". So, if you're testing something and using a test domain, use the IANA reserved domains, please. Theses were the days when I was running my own servers. I don't see it as often now as my e-mail is now hosted.
.app, .dev, .prod, and .zip all had substantial volume of problematic traffic that was discovered during the Controlled Interruption period (which occurs prior to launch and consists of a wildcard DNS entry placed on the entire TLD). You would not believe some of the brokenness that was happening there. .zip may need some explanation -- apparently there are lots of library API calls out there that take a path string as input and try to load it as either a local or remote file. You can see where this is going.
There's a lot of overlap between file extensions and TLDs though. .py, .sh, and .app are some more examples (but a fully exhaustive list would be in the dozens if not hundreds). At some point you have to just treat them as the separate namespaces that they actually are (and not somehow try to block a TLD from being used as a file extension, or vice-versa).
Besides, accidentally resolving a file extension to a TLD is only one of many possible different serious errors that can result from exposing an API that can load files locally or remotely, and thus make network calls that you might not be expecting. Fundamentally you need to fix that API either way.
I think it's okay. They are different namespaces and people should fix their bugs. It would be like skipping the street number "911 Foo St." because "911" is the emergency phone number and 911 Foo St. is just a regular house. I'm sorry if someone is confused but they shouldn't be confused. They're totally different things.
The biggest mistake we made with DNS was the "shortcut" of implicitly adding the root domain to random strings treated as domain names (turning "example.com." into "example.com"). The file "foo.zip" and the website "foo.zip" wouldn't even be ambiguous if we called the website "foo.zip.". "ndots" also causes operators of DNS servers a lot of pain -- some malfunctioning program tries to resolve "example.invalid" in a tight loop and it balloons to asking for "example.invalid.", "example.invalid.local.", "example.invalid.cluster.local.", "example.invalid.svc.cluster.local.", and then DNS blows up, breaking everything.
> It would be like skipping the street number "911 Foo St." because "911" is the emergency phone number and 911 Foo St. is just a regular house. I'm sorry if someone is confused but they shouldn't be confused. They're totally different things.
We just never should have allowed filename extensions to have semantic power. Resource forks are far more elegant and you could do simple look ahead checks to verify types etc.
Back in '81 when MS-DOS came out and ascribed "magical power" fo files ending in ".com", DNS didn't exist (except possibly as experiments stuff between a handful of university or military mainframes). It was also an era where the vast majority of users of those .com files were doing so off 5 1/4" floppies (or possibly even 8" floppies), and the very idea of adding "resource forks" to your on-disk data would have been ridiculed as an outrageously profligate waste of extremely valuable disk storage resources.
It's easy to say "we should never have" in retrospect. But you're basically accusing programmers back in the late 70s of having insufficient foresight to see problems that would make their decisions seem bad almost half a decade later.
We also should never have let companies sell cigarettes. Or burn fossil fuels. Or start social networks.
The magical power of extensions actually predates MS-DOS -- both CP/M and TRSDOS did the same thing in the late 70s, and I'm pretty sure both of those were inspired by mainframe operating systems. (I was a TRS-80 kid, and didn't know until much later why our equivalent of batch files had the extension "JCL".)
Having said that, though, we could at least wish that some variant of the Mac's old idea of separate creator and document codes stored as metadata had caught on. Sure, it'd have been a few more bytes per directory entry (to be specific, five more bytes!), but it was a lot more flexible -- and if more operating systems had been built with that "document types are metadata" idea, that metadata could have been replaced with MIME types later on, like it was on BeOS.
> But you're basically accusing programmers back in the late 70s of having insufficient foresight to see problems that would make their decisions seem bad almost half a decade later.
The URL standard was published in 1994.
Sure, in a vacuum you could read view my comment as meaning in all time, but given that the parent comment is discussing ICANN domains and my comment was relevant to that, I think it’s a little uncharitable to do so.
I've personally run into the .zip problem thanks to browser's omni address/search/chocolate bars. I intend to search for a zip file whose name I know but the browser "helpfully" realizes the term includes no spaces and ends in dotsomething and attempts to treat it as a URL.
A simple workaround is to add a preceding space or something like inurl: but that's isn't an automatic behavior so whoever owns mlpdwarfporn.zip is getting a lot of unintentional hits.
Using a question make in front of the term is traditionally how some browsers trigger search. They usually have a jeybconbe to add it automatically.
For example, in firefox and chrome ctrl-l will clear the URL bar and put the cursor and focus there to take you to the location you enter, and ctrl-k will do similar but pre-fill the location bar with a preceding '?' so a search is triggered on the input.
These shortcuts have existed for quite a while. They used to just focus the respective separate input boxes, when it wasn't all done through one.
Yes, thanks. Switched to a new keyboard on my phone, and I'm getting some different typos now. Not necessarily more, I always seem to have a lot that slip through, just different...
I think that ends up as user unfriendly as requiring the dot after the TLD. I don't read up on all the gTLDs so I didn't realize zip was one for the longest time. I think ICANN just went nuts with TLDs, especially ones like .app and .zip that have long-standing associations with ubiquitous file extensions. That combined with the "smart bar" just leads to trouble.
This is the real answer here. It's widely believed that domains working the opposite way of filesystem hierarchies and even URL paths was a huge design mistake. Think of how many billions of dollars have been lost over the years from account compromises resulting from people not correctly distinguishing yourbank.com/account/foobar from yourbank.com-account.info/foobar.
1. The reason for the change is generally thought to be email: you read least specific to most specific from left to right, like non-American dates, e.g [email protected]
2. also I think ! was used rather than . for some networks at some times. Certainly I’ve heard this anecdote from some early users of the internet (or maybe other computer networks)
3. Traditionally the dot is the zero-level or extra-top level domain, a bit like / for root in the Unix file system. Indeed if you use dig you may be familiar that it writes domains like “www.google.com.” My web browser only partly seems to accept this format.
> 2. also I think ! was used rather than . for some networks at some times. Certainly I’ve heard this anecdote from some early users of the internet (or maybe other computer networks)
! was used for manual routing from the source to the destination, when messages were copied from server to server via UUCP. People would write paths like ...!ucbvax!deptserver!myname , which means "you probably know how to get messages to ucbvax; from there, here's how to reach me".
Interesting, and makes sense, seeing as how the Web didn't yet exist when domain names were first invented, but email did. It does make sense that they were thus represented in a manner catering to that use case. In hindsight I guess we'd prefer if emails were backwards too, e.g. com.gmail@cydeweys
This is ironically what’s become popular for service-specific usernames (“on twitter @dan” and “on instagram @danny”). It’s arguably more useful than the email notation because prefixing with the @ is a clear sign that a username is coming next.
You could easily just use a different symbol, or pronounce it differently. We think it makes sense the way it is now, but that's only because we've all collectively gotten used to the meaning it has in email addresses. If it had had a different meaning all along then that would make sense to us.
com.gmail.cydeweys doesn't really work because you need some way to distinguish that as an email address and not just a subdomain on com.gmail. So it really does need a different delimiter, like how you need a different delimiter in URLs when it switches from the domain to the path (and then also to the querystring and fragment).
'@' was used to mean 'at' or 'each' for a long time before email addresses. Often in pricing. '12 @ $3' means twelve units priced at $3 each. It's referred to sometimes as 'commercial at', including its Unicode name.
It wasn't remotely as familiar to a broad audience back then as it is now, though. Considering that people accept its non-idiomatic use for website user names even now (which is the same as what I'm proposing no less), I don't think this would be a problem.
Using your example with left-to-right domains and needing a delimiter, one could build a URL structure for mail that changes the protocol but not the path.
mail://com.gmail/localpart to send mail to what is currently [email protected]
Alternately, we could continue to use '@' and put the localpart first. The URL method of specifying a username or username and password does this for HTTP/HTTPS.
The domain name should definitely still be first. And there are benefits to using a different syntax for domain names than for email addresses, so you can differentiate the two when they're presented out of context (e.g. on a business card or ad).
I was mostly just making a joke about the suggestion that email addresses should look like "com.gmail/cydeweys" from upthread...
But I could _kinda_ of make an argument for it. When I open my browser, I want to go to "the homepage of the company running New Your Times, so [email protected] - or perhaps the menu from French Laundry - [email protected]
> 3. Traditionally the dot is the zero-level or extra-top level domain, a bit like / for root in the Unix file system. Indeed if you use dig you may be familiar that it writes domains like “www.google.com.” My web browser only partly seems to accept this format.
The browser actually handles it just fine, but some webservers refuse to handle it, despite it being a spec. Most famously Traefik and Caddy as webservers refuse to support these, just because their devs don’t understand the spec and think they know better (what a surprise, both are written in go after all)
This actually causes quite a bit of trouble when you have internal systems resolving pretty much everything as local domain first, and some external webservers don’t support the spec. Most famously, caddyserver.com. itself is broken
My college's online system for everything is called edukacja.cl. A lot of people type that into the address bar, expecting to be redirected to the login page. Fortunately, the person who bought that domain didn't misuse it. I can imagine someone putting a fake login page there, and getting access to a lot of sensitive student details.
I owned forexample.com for 15 years or so and saw all kinds of mail but the most persistent was a record company owner who, from time-to-time, wrote semi-deranged angry emails demanding that I turn the domain over to him. I always had grand plans for the domain but never acted and, a couple years ago, I forgot to renew and the domain is now in someone else's hands. I don't miss it, especially the record company guy.
I remember reading - long time ago - a story of a developer who used http://xxx as a placeholder for unknown domains, until at some point the browsers started resolved single-word links into www.<word>.com... :-o
Back in the days before I'd ever heard of multicast DNS or zeroconf networking, I had a local dns server set up with all our subdomain.ourdomain.com duplicated as subdomain.ourdomain.local and pointing to our local dev/staging versions of our websites. It worked wonderfully, until I think MacOS 10.2 arrived (so, like 20 years ago almost) which had mDNS support for the first time and "broke" it all on me...
I switched to using subdomain.ourdomain.staging instead and got on with life. I wonder if anyone's gonna have to deal with the fallout of that decision when someone oneway pays ICANN enough money to own the .staging TLD?
(I wonder how much "interesting" stuff would land in your mail/web/ssh/whatever log files, if you registered .staging and .dev and just logged everything that came past (or intentionally/actively honey potted everything there?)
It doesn't seem that the browsers still to the expansion things; I've tried it, and am just getting the "We’re having trouble finding that site." error message, or similar. But for some time that expansion was real.
Haha. That’s actually surprising, I mean that one takes some work to even type. I’ve mentioned previously on HN that I own doesnthaveone.com, which is constantly bombarded with random crap. I wish I had some big public customer data to see what other fake ones show up.
On the other hand, you knew what you were getting into when you decided to be the owner of a meme domain! People should use properly reserved domains, but I can't really blame them for accidentally using meme domains.
I had my.homepage.com for a while back in the early 2000s, unfortunately I wasn't allowed to monetize it, but looking at the referral logs was always interesting.
Indeed it's probably broad enough that you could likely find an ambulance chaser who'd go after people who _send_ you those emails "in excess of their authorized access" to your mail server.
You could weaponise this the same way companies use defensive patents... "Sure, I opened one of your emails, but you've connected to my mail server without authorisation <checks logs> 27,943 time so far this month. Go on, lawyer up. Bring it on!"
