Something that I’m surprised a lot of devs don’t know; there are official domains you’re supposed to use for documentation, testing, etc. They are specifically reserved by IANA for these purposes. Originally I think it was just example.com, but they now have a list of all them: https://www.iana.org/domains/reserved
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.
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
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.
Thank you, I was unaware of this. I found the relevant section in the doc that was linked from your original link:
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
* ".test" is recommended for use in testing of current or new DNS related code.
* ".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.
I learned about .invalid last year and had an immediate use for it where we needed a syntactically valid email to match a schema but didn't want it to be deliverable.
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
A lot of people learned this the hard way when Google bought and later enabled permanent HSTS for the .dev domain (prior to actually publicly releasing it) in Chrome, breaking everybody's non https local .dev environments.
The HSTS preloading fortunately ended up being an unintentional additional type of Controlled Interruption period, which was a good thing in the end. It would've been a lot worse if, one day, your fake domain names are resolving locally, and then literally the next day it's now a real domain name that's resolving remotely, with who knows what result. This at least forced people to address it well in advance of domain names potentially resolving globally.
> .dev domain (prior to actually publicly releasing it) in Chrome, breaking everybody's non https local .dev environments.
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".
Note that `foo@bar.com` is frequently used to get around the email address requirement, so it is not really for testing. I wouldn't be surprised if prominent websites block any address from example.com or so.
But people who know and use the words foo and bar are almost exclusively developers, so they should know better eveb when typing a fake address to a random form. But it’s easy to type reflexively, without thinking, so I’m not surprised people do it.
That’s really cool. Contoso (also mentioned by someone else in this thread) and Fabrikam are the only ones I remembered off the top of my head, I had no idea they used that many.
In practice, is there any difference? As long as example.com is guaranteed to be reserved, I don't see any downside in using 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.
I've used example.com in the test cases of my webscraper. When they changed the links on the page, the test cases were failing, and I complained to them, but they did not care
Not just domains but IP address ranges as well. Doesn't stop lots of people from doing things like using real US DOD ipv4 /8 sized ranges for things they shouldn't.
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.
A bit off topic, but I lament that these reserved domains are becoming less and less useful for testing web applications. I don't think you can acquire regular SSL certificates for reserved TLDs like "test.", yet an increasing number of browser features only work in "Secure Contexts" (ie. HTTPS only).
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.
Yeah, because of SSL, you really do need to own at least one real domain name that you use solely for testing. You can hang a bunch of subdomains off it and run separate applications on each one, but you are gonna want a real domain name.
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.
Yeah, but then you use that and some fool somewhere in the pipeline has decided it's an optimization to the spec to not deliver to those addresses and so you can't even test if your email sending is working.
This guy is really committed to the joke, seeing as how he could easily sell bar.com for millions of dollars.
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?
Yeah, it used to be a programming problem challenge website feeding into recruiting efforts. It was turned down though after living out its useful life and now it's just a redirect.
If Facebook was still The Facebook and for some reason hadn't thought to pick up facebook.com before now, the price on that would be only just bounded.
This reminds me of all the emails I received from roots due to putting an actual address of mine in the receiver field of a Postfix guide I wrote years ago. People will blindly copy paste whatever text you put in tutorials.
I really like the idea of setting your MX record to 127.0.0.1. I am not sure what problems this causes (the author mentions people are angry about it) but I like it.
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 really like the idea of setting your MX record to 127.0.0.1. I am not sure what problems this causes (the author mentions people are angry about it) but I like it.
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.
As an aside, I believe "foobar" is a sanitization of "fubar", which is an unofficial military acronym for "f*ucked up beyond all recognition". If you're interested in the history of fubar, a search of "history fubar" provides more history about "fubar", "snafu", and other colorful unofficial military acronyms.
Readit News
https://www.icann.org/en/system/files/files/name-collision-f...
at that point i expected the story to go "and then they sued me for stealing their documents"
2. TLDs for Testing, & Documentation Examples
To safely satisfy these needs, four domain names are reserved as listed and described below.
* ".test" is recommended for use in testing of current or new DNS related code.* ".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
https://tools.ietf.org/html/rfc2606#section-3
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
As mentioned above, it should have been .test
https://www.icann.org/resources/pages/name-collision-2013-12...
https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html
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".
https://en.m.wikipedia.org/wiki/.test
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.
[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.
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?
Seems the asking price is at least 1m USD
then pay a lot of money to ICANN
https://www.google.com/search?client=ubuntu&hs=ujt&channel=f...
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.
[1] https://tools.ietf.org/html/rfc7505
http://www.catb.org/~esr/jargon/html/F/foo.html
The emails I would get...
Let’s just say I turned off wildcard receipt of email after a week to limit my liability.