https://www.icann.org/en/system/files/files/name-collision-f...
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.
Typing `?bla.py` in the omnibar will perform a search for `bla.py` on both Firefox and Chrome
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.
http//com.google.www.
vs
http//com.google.www./file.zip
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.
https://en.wikipedia.org/wiki/UUCP#Bang_path
! 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".
https://en.wikipedia.org/wiki/UUCP#/media/File:UUCP_Email_Ad...
So com.gmail/cydeweys maybe?
Or it could be just an object in a global namespace (accesses through a protocol specific facade). So com.gmail.cydeweys
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).
https://en.wikipedia.org/wiki/At_sign
It was used as 'at' in computing in Algol 68 where it was a shorthand for a keyword 'at'. It has a different application as 'at' in Dyalog APL.
https://com.google. for the main page
https://com.google.mail for gmail
https://com.google.mail/localpart for one's own gmail account
mail://com.gmail/localpart to send mail to what is currently localpart@gmail.com
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.
http://username:password@com.site/login
And currently we use mailto:localpart@example.com but we could use mailsend:localpart@com.example instead.
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 homepage@com.newyorktimes - or perhaps the menu from French Laundry - menu@com.frenchlaundry
The other nice thing about this system, is that you can drop the domain when the communication is internal.
And if you really wanted to, you could force the communication protocol xmpp//com.twitter@dan vs smtp//com.twitter@dan
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
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.
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.
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.
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.
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.
Floor 13.
When I read reddit (before it jumped the shark imo) there was something similar in a non-tech way called /r/idontworkherelady
at that point i expected the story to go "and then they sued me for stealing their documents"
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!"
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?)
2. TLDs for Testing, & Documentation Examples
To safely satisfy these needs, four domain names are reserved as listed and described below.
.test
.example
.invalid
.localhost
* ".example" is recommended for use in documentation or as examples.
* ".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid.
* The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use.
https://tools.ietf.org/html/rfc2606#section-2
3. Reserved Example Second Level Domain Names
* example.com
* example.net
* example.org
I discovered quickly that some other systems wouldn't accept the placeholder emails such as notused@email.invalid. Too many systems try to be too smart about the syntax of emails (+ subaddressing is another minefield).
Had to go back to using something like notused@invalid.toplevel.com
I'm still not sure if this is because the developers are incompetent and don't understand that they can just used an established standard instead of rolling their own janky parser, or if it's because they just don't want to let the user tell who had their databases leaked or sold their email to a spam list.
I used to think the former because there's so many different solutions to the latter that don't involve actively annoying the people you're trying to extract money from, but I'm starting to think that it's a little from column A and a little from column B.
As mentioned above, it should have been .test
https://www.icann.org/resources/pages/name-collision-2013-12...
— We bought .dev, now what we do with all those people in the wild misusing it?
— Well, most of them misuse it with our browser, let's break at least their hacks early and loudly.
Source: The horse's mouth. I'm the guy who came up with the idea of launching .dev and .app as HTTPS-only TLDs, and I'm the one who had them added to the HSTS preload list.
It’s a huge change that surely warranted special attention before making it happen?
So yes, we didn't anticipate how many people weren't following the best practices, but that would have been hard to determine prior to doing the thing anyway. There were also lots of people who had the mindset of "We won't change anything until it stops working", so in some sense a lot of it was unavoidable. See e.g.: https://github.com/laravel/valet/issues/204 https://github.com/laravel/valet/issues/294 https://github.com/laravel/valet/issues/431 (note that Laravel users were responsible for a non-trivial fraction of the total problems experienced, and that we only discovered all this post-HSTS-preloading). The problem was repeatedly pointed out and the maintainers refused to fix it until it actually broke. So, inevitably, it broke, and then they fixed it.
I've always hated Google for egoistically claiming this tld, and ICANN for letting them.
It enables zero config local development configuration, whereby at the time it would make your locally running dev server available on .dev
So instead of having to spin up a local server and then visiting say 127.0.0.1:3000,
I could instead just visit myappname.dev and it would show me what would previously show on localhost or it would spin up a server first for that app then show it to me.
They switched to .test in response to google’s change.
Official site: https://pow.cx
Thread on change from .dev to .test https://github.com/basecamp/pow/issues/386
Visit http://pow.cx
Also, just because someone is using a fake domain doesn't preclude that from being created as a real domain name farther down the line. That's why you shouldn't use fake domain names. This problem has been known since at least the 90s and is not a good habit to get into. Them now being real makes them actually more useful (and not reliant on potentially unsynced local-only config).
I mean, I THINK this is "properly configured", but it also isn't a huge deal to avoid. Just was annoying when it started happening. Didn't FEEL like I was misconfigured. :-)
In this particular case it sounds like your resolver was set up to try an external resolution first and then append an internal domain if the external resolution failed. And as you say, this clearly worked just fine for a long, long time. Then it suddenly started failing one day, for reasons unrelated to anything you changed.
At this point, most people would find it reasonable to blame the external change for breaking their fully functional, correctly working, "properly configured" setup. Some, perhaps contrarian or perhaps more cautious, would note that the "properly configured" approach only worked so long as external systems played ball. I think it might be the case that you were bitten by this assumption that seemed safe at the time, leading to the awkward and uncomfortable conclusion that your systems were indeed misconfigured.
I would argue that, of the two options, option B is the less onerous one, and less restrictive on the future growth of the Internet. It's not that hard to set up some aliases to be able to SSH quickly into the right hosts without having to manually type out longer paths.
Or you can look at the matching username on GitHub ( https://github.com/CydeWeys ) and see that I'm a member of the Google org and owner of the Nomulus repo ( https://github.com/google/nomulus/graphs/contributors ), the software running our TLD registry and which was announced here: https://opensource.googleblog.com/2016/10/introducing-nomulu...
Or I could just dig out my GPG key and sign a message.
So I respect your healthy skepticism, but I promise I'm really me, and not just someone pretending to be me! And I'll also note that, in all my time on HN, I've never once seen someone pretending to be anyone they weren't, at least not on seasoned accounts like mine. You can go back through my 5 years of comments on here, and every time I say I'm a specific person out there in the real world, it's always the same consistent person.
Not disputing your account in any way, but please don't propagate the widespread myth that only people who own an email address can send from that email address. If you wanted to use your well-known email address as authentication, you'd need to offer to reply to a mail sent to that address.
Though, admittedly, it would be easier for a layman to verify ability to reply to an email than to verify all those features, so point taken.
The more people follow decent practices at home, the fewer businesses will accidentally break because on of the admins thought it'd be alright because it works for them at home. If you set your DNS domain correctly you can also save yourself some typing effort because DNS will automatically append the network name (so you can http://test instead of http://test.internal or http://test.hamu.co). As an added bonus, you can get valid TLS certificates for your internal network devices without messing with a certificate authority of your own!
For example, if you buy "example.com", just set your public DNS (assuming your registrar provides one) to resolv it to 127.0.0.1, then add your internal hostnames and IP addresses to your internal DNS. If you do it that way, "my-server.example.com" will simply fail to resolve unless you're on your internal network and you don't have to worry about any issues with using the reserved *.internal domain.
For example if you have a home network and a testing network, you could have one on home.example.com and the other at lab.example.com, in which case your servers would be server.home.example.com and server.lab.example.com. If you use DHCP on those networks, you simply set the domain and search-domain options and you can just enter "server/" on the devices that moves between them.
You only need to register example.com with a registrar, then you can use whatever subdomains you want wherever you want.
Good grief, usually it's because of a hairpin nat. People do that to themselves. They damage their own L3 networking and then decide that they need to damage also their entire DNS as a workaround.
It's a regular mind virus, because it's easy to implement split-horizon DNS but enormously expensive to remove it. People get used to it on one company and go and spread it on another company.
Just do a snat+dnat. These networking boxes are so expensive because they are meant to handle it, so let them do their job already. Or go IPv6 and get rid of DNAT altogether.
Why not?
.test doesn't quite cut it.
It does seem much, much more likely that .internal will be definitely reserved for this purpose than that it will ever be delegated as an actual real TLD. If you have to pick a fake TLD to use that isn't one of the 4 mentioned in RFC 2606 that has the best chance of actually being reserved for this purpose in the future, then .internal is it.
Now, there has actually been an int TLD for a long time, but you probably don't visit sites in that TLD very often because it is for international organisations like the UN.
So if your configuration blocks all those actual sites well, too bad right?
However, back that long ago the trusted Public CAs were not actually forbidden from issuing certificates for names that don't belong to anybody on the public Internet. This was a bad idea, but it was not yet (at that time) forbidden. So you could pay Thawte a pile of money and get a certificate for "exchange2" your backup MS Exchange server or maybe "linux.build" your Linux build server.
And since people were using this for internal names, you'd get people asking their CA for certificates like "exchange2.int" - for the internal backups MS Exchange server right?
Obviously there can't be any effective way to demonstrate control over internal names, since you do not in fact have control over them, you've just hijacked them.
And so the end result is that there were actual publicly trusted CAs issuing certificates for names in a real public TLD without checks, because they assumed it was internal when it was actually not.
These days the CAs are required to issue only for names in the actual Internet DNS hierarchy (plus TOR) and only after seeing one of the accepted proofs of control nicknamed the Ten Blessed Methods.
Meanwhile: There is only one namespace, do not try to hijack little pieces for yourself that don't belong to you. If you want to reserve some names so that your DNS doesn't "break" then you can buy names like anybody else.
Yeah, except it broke more than that.
A lot of folks use/d ".dev" and and ".prod" as internal sub-domains in their actually-owned domain (dev.example.com, prod.example.net).
For convenience you could however use the resolve.conf's "search" option to simply things, so at the CLI one could type "ssh webserv01.dev" and the resolver would would then append the company's domain to get the FQDN for the query.
Except once Google made their changes "webserv01.dev" now could go out to the Internet—especially if you had it in a browser and it tried to be "clever".
See https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html for more explanation.
Say I own "throw0101a.com", and then use "dev.throw0101a.com" and "prod.throw0101a.com". (Or you own CydeWeys.com.)
Previously, when .dev and .prod were not TLDs, it was fairly safe to type "ssh websrv01.dev" and "ssh dbsrv02.prod" because if the queries leaked onto the Internet they'd fail.
Now, with the post-Google TLD changes, if you type one of those things, and the local DNS happens to not be configured properly (i.e., the resolve.conf 'search' options is not present), then strange things can happen.
Further, if you put "websrv01.dev" in a browser now, it may go off into the Internet and try to be clever about auto-complete instead of just doing a local query.
Relying on DNS search lists to find the right host is a bad security practice that has caused security incidents even outside the context of the creation of new TLDs. It's best to always use fully-qualified domain names. A lot of people responsible for implementing DNS search lists in the first place now regret having ever created them.
More info at https://www.icann.org/en/system/files/files/sac-064-en.pdf (particularly section 4.1.3 and the preceding logic leading up to it).
In more dynamic environments, the config may have the domain as its own setting and each service as just the hostname, but the software must combine them before use, or better yet combine them in the config if variable expansion is possible in the config language they are using (ex: db_server="db-01.${domain}" with domain being defined near the top).
Check out the MX record for meowcats.fun, for example. It points to suremail.info, which points to mailinator. I have never had that domain rejected by a form.
Shhh, don't tell anyone ;)
Impersonating federal agents is shockingly illegal and the authorities who enforce this have absolutely no sense of humor.
The risk is low but why take it?
https://krebsonsecurity.com/2020/04/microsoft-buys-corp-com-...
And to be clear, Foo Bar is a placeholder here, not the actual name.
Microsoft's official training curriculum for "MCP" and "MCSE" back in '99 was pretty clear about it (I was an instructor at a community college for a Microsoft certification program), but other Microsoft docs and especially third-party docs weren't as clear. Thr whole ".local" debocle with Windows Small Business Server lays at the feet of Microsoft, though.
Not using .test was a big problem for tools like Pow a while ago, but that's because they were using .dev, which had no official recognition as being reserved or special-purposed.
For e-mail addresses in particular, I could easily see a situation where your domain logic prevents you from using an invalid TLD (like .test), and it would be a shame to special-case something strictly for testing purposes.
These days invalid TLDs don't really exist. New ones are getting released all the time. The only problem you'd run into is if the system you're using is treating .test differently for some reason, but that's likely not the case, for obscurity reasons if nothing else.
RFC 6761 says that there is a difference when I actually resolve these names. The example.com, example.net, etc. will resolve normally to an existent IP. Moreover they resolve the same way on every DNS cache.
The xxx.test will resolve as non-existent by default, unless you configure your own DNS specifically for them.
or use horrible ISPs that redirect everything that isn't valid (and intercept DNS if you try to use an alternate DNS).
[1] https://tools.ietf.org/html/rfc5737 [2] https://tools.ietf.org/html/rfc3849 [3] https://tools.ietf.org/html/rfc5398
This also seems to be unknown even to some university professors, who I've seen set up lab exercises using actual CloudFlare ASNs and IPs on a simulator connected to the open Internet. Not exactly dangerous as it would obviously get filtered, but still really bad form.
That's the link that qualifies special behavior for anything ending in ".test", ".localhost", ".invalid", and the set of "example.???" domains.
Copy-pasting the RFC into a comment would be a bit spammy (it's three pages of hyper-specificity), so just go read that. It's quite accessible and the mechanics are useful to be aware of.
Chrome treats "localhost." as a Secure Context by default, a nice convenience, but for the other reserved TLDs you have to either self-sign (a fairly complex and laborious process that doesn't necessarily work on locked down devices) or register a non-reserved domain with a regular SSL certificate that points to a test IP.
Fortunately domains are super cheap all things considered. A .dev domain (my preference, but admittedly I'm biased) is a buck a month. If you really want to penny-pinch there's much cheaper still.