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
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.
foo@bar.com
291–300 of 301 posts
Re: foo@bar.com
#292Something 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
[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.
Re: foo@bar.com
#293Earlier quoted context omitted.
Then of course the web would similarly use http://homepage.html@org.example
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).
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
Re: foo@bar.com
#294Earlier quoted context omitted.
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…
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.
Re: foo@bar.com
#295Earlier quoted context omitted.
If CF is still using that abomination "hCaptcha", you can get an accessibility cookie for it which doesn't stop the captcha from appearing but does cause it to actually work when you click on the "I am a human" widget, unlike the normal broken flow
Hi, founder of hCaptcha here. Happy to learn more about your problems with hCaptcha. I'd like to see what we can do to make it better for you.
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
Re: foo@bar.com
#296Earlier quoted context omitted.
I'll be honest, even I do this when it's a form that has an email requirement but that I don't otherwise care about at all. I'm not gonna sign myself up for spam. Sometimes example.com and whatever other testing TLD that comes to mind is blocked because they want something that could plausibly be a real email address, so I give them something that could plausibly be a real email address, like asfgjklahsfgjklh@asdfogh…
I've been using a@b.com just because it's quick & easy to type. I just looked it up, and it seems all the single-letter .com domains are reserved, so it should be fine.
Re: foo@bar.com
#297It'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.
Re: foo@bar.com
#298the 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...
Re: foo@bar.com
#299Earlier quoted context omitted.
You don't need to disclose anything on the public DNS. Just register the domain, then use it internally. 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…
I need to have the public DNS anyways so I find this way to be easier. I'd have to use CNAMEs anyways since the .internal addresses have to resolve to different IP addresses depending on the context.
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.
Re: foo@bar.com
#300Earlier quoted context omitted.
I need to have the public DNS anyways so I find this way to be easier. I'd have to use CNAMEs anyways since the .internal addresses have to resolve to different IP addresses depending on the context.
Why would your A records change depending on context? Do you have separate networks where "server.localdomain" has different IPs? The typical way to solve that is to use different sub-domains for each one. 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.exam…
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.