foo@bar.com
bar.com
bar.com
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?
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).
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).
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.
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.
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.
[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.
Note also that there is a .bar gTLD, and there is a foo.bar domain as of 2014 (though it doesn't seem to be hosting any content). I run the .foo gTLD, and bar.foo is a real domain (though admittedly not as good as foo.bar). There is no .baz; next round maybe?
then pay a lot of money to ICANN
The element never reappeared again.
I always wondered why the element appeared on the page. Obviously because "some combination of factors" ultimately returned true - I mean specifically why :)
And mastodon instances are rather new, and exist on a massive amount of different tlds, of course on .social but also others. Probably the age of the service plays a big role! We'll see more TLD diversity as things get much older.
com org uk gov blog us nyc io to edu
(I do have a lot of tabs.)
Seems the asking price is at least 1m USD
PS. This behavior is quite prominent in real estate prices, they're so slow to fall down. For example the US real estate market bottomed only in 2011. You have to be very patient if you want to buy the dip in such "I will only sell for the right price!!" markets.
If I had a good portfolio of potential $1M+ domain names I too would hold onto them and wait for the right buyer to come along. I'm in no desperate need of money right now.
Here are some notable expensive domain name sales:
Uber.com 2% of the company's equity in 2010 (!!)
Sex.com $13M
Hotels.com $11M
Tesla.com $11M
Porn.com $9.5M
Fb.com $8.5M
Note it also lists LasVegas.com for $90 million (in instalments) from 2005.
https://www.forbes.com/sites/forbestechcouncil/2018/08/07/ex...
https://www.google.com/search?client=ubuntu&hs=ujt&channel=f...
$ dig +short -t mx contoso.com
10 contoso-com.mail.protection.outlook.com.Note that odds are probably low today of anything listening on port 25 if no mx record is set up, I'm guessing (I'm guessing most people that setup an smtp server also sets up mx and a handful of records in dns).
By the time Tim built his toy hypermedia system ("the World Wide Web"), DNS had a sensible mechanism which could have been used to deploy it cleanly. But that wasn't done. So, first HTTP means "just look up the A record for the name and connect on TCP port 80" and then HTTPS meant "look up the A record, connect TCP 443". Today you also need to check AAAA (for IPv6) and you need to use ALPN to say what kind of HTTPS you speak, but otherwise things remain much the same.
However we have a pile of things we want to do in the near future that don't fit this model very well. HTTP/3 support (ie HTTP over QUIC) would ideally be discovered as early as possible for best performance, and Encrypted Client Hello (technology to a void revealing the names of sites you're visiting to an eavesdropper) really wants to fetch from DNS quite a lot of information too.
So there will likely be a new DNS record for basically "I want to connect over HTTPS to this DNS name" the same way the MX record means "I want to send email to this DNS name".
Ordinarily this would be a huge deployment nightmare, because we know crap DNS implementations can't do new DNS features. The specification for DNS is clear that if somebody asks "What's the WONKABAR for some.name you control?" and you've got no idea what a WONKABAR is you say there isn't one. But lots of bad software has been written that will break out, and either crash, silently drop the question or reply by reporting that there was a server error, none of which is correct.
However, fortunately the DNS privacy protocols give us a chance to reset expectations. Comcast's deal to get their DoH servers used in Chrome (for Comcast customers obviously) requires that they implement DNS properly, not half-arse it. So that's millions of customers brought on board by contractual obligation just for one example.
This makes me realize that DNS is slightly flawed in that you can prove "the owner of example.com wants to accept email at X.Y.Z.A" but not "the owner of X.Y.Z.A wants to accept email for example.com". (My experience using a managed load balancer on Amazon was that I got a ton of traffic for websites that weren't mine. Some DNS record must have been out there pointing towards our IP, which I guess is bound to happen when you only have 2^32 of them to share among all of humanity. Someone should do something about that...)
I imagine it could cause annoying loops with some mail server configurations.
RFC 7505[1] defines null MX records. This might be a good alternative, depending on what your intention is.
The emails I would get...
Let’s just say I turned off wildcard receipt of email after a week to limit my liability.
Bill said it was so that some uucp address would be
crash!boom
length of access using this method varies but it's usually enough time to cache and consume their precious content
it's impossible to verify a valid email address without sending a verification link. one half measure is to ping for an MX entry on the user-provided domain, but even that isn't bulletproof
if they go to such unnecessary lengths to hide their content then it simply isn't worth viewing. scoff, close tab, forget
Lots of lucifer at helvetet.com etc :) I sometimes reply with an mp3 with a few seconds from Diamanda Galas' "The Litanies of Satan". https://www.youtube.com/watch?v=OBeTXiTZbCc
https://westinghouse.com/ seemed to have a test environment that sent me emails with invoices as well. I asked about delivery options :S
The Foo reminds me of a whole bunch of British children’s TV shows with characters that gave me many nightmares. Some sort of body horror, I believe.
reCAPTCHA was a brief interruption, occasionally; contact with hcaptcha is "well, there goes 10 minutes of my life I'll never get back ... I should just close the tab cause I didn't want to know that bad anyway"
I recognize that's not an answer to what you can do about hcaptcha, but since hcaptcha's goal is to make the web harder to use, I guess from a certain perspective there's nothing wrong with it
the New York Times included him in a story back in 2001...
https://www.nytimes.com/2001/05/03/technology/fleeing-spam-s...
by the way, i also was the caretaker of Microsofts corp.com domain for quite a while. they wisely decided i wasn't the best person for the job.
https://krebsonsecurity.com/2020/02/dangerous-domain-corp-co...
https://www.theregister.com/2018/02/12/icann_corp_home_mail_... https://www.icann.org/en/system/files/files/sac-062-en.pdf
The shortest bar joke is missing here (or I missed it) - Man walks into a bar. ... Ouch!
$ dig -t MX bar.com +short
$https://tools.ietf.org/html/rfc5321#section-5.1
> If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
That said, it doesn't look like there's an SMTP server running for bar.com.
It's always interesting to get those test accounts for new services and try them out early.
Whats not so fun is "testing" all the draft newsletters people send to foo@bar.io.
It's a bit old and requires jquery, but it's fairly easy to gut the library and just use the email logic. It even uses your example of "gnail.com" in the README.
Or if I need to see the email sent to me, I’d use something like tempmail
This domain would be the perfect basis for such a business.