Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

foo@bar.com

bar.com

Post reply on HN
Print view View original

101–110 of 301 posts

Re: foo@bar.com

#101

Post by Jon_Lowtek »

davemtl wrote: post #54
chrismeller wrote: post #4

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 doin…

> "no, it's your server doing this"

at that point i expected the story to go "and then they sued me for stealing their documents"

Re: foo@bar.com

#102

Post by CydeWeys »

throw0101a wrote: post #93
nebulous1 wrote: post #20

Earlier quoted context omitted.

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. As mentioned above, it should have been .test

> .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 "ss…

This applies to every domain name though (at the second level too, not just the first). You'd have exactly the same problem if you were using a fake .com domain that someone then actually registered. The best practice has always been to use a real domain name that you own, and subdomains thereof. If you don't, your setup isn't working so much as it is not broken ... yet.

See https://jdebp.eu/FGA/dns-use-domain-names-that-you-own.html for more explanation.

Re: foo@bar.com

#103

Post by chrisweekly »

chrismeller wrote: post #4

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

yeah, "example.com" seems pretty sensible; it's what I've always used and recommended.

Re: foo@bar.com

#105

Post by Xylakant »

JdeBP wrote: post #95
djsumdog wrote: post #62

I always used bob@bob.bob. It's not a real TLD (although at the rate of new TLDs, it might be soon) but it still validated on most websites.

Someone whimsical will grab it, and not be happy with the ground that you've laid. Consider that dot@dotat.at exists. * https://news.ycombinator.com/item?id=21369013

Though it is substantially easier to register a domain for fun than register a TLD for fun, even though the principle remains the same: pay some money and do some DNS configuring. It’s just that for TLDs the value of “some” changes.

Re: foo@bar.com

#106

Post by Hamuko »

jeroenhd wrote: post #90
Hamuko wrote: post #55

Earlier quoted context omitted.

Can't wait for .internal to be registered so that my internal DNS breaks.

The only proper way to do internal DNS is to register a domain. Even a free one will do. 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 htt…

I do have a domain but I don't want to enter my private IP addresses on a public DNS. Hence I just have server.internal to point to the correct IP address on my local DNS server and have service1.server.com, service2.server.com, etc. all just CNAME to server.internal.

Re: foo@bar.com

#108

Post by paultopia »

lifthrasiir wrote: post #9
chrismeller wrote: post #4

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.

I usually use president@whitehouse.gov and the like...

Re: foo@bar.com

#109

Post by CydeWeys »

Hamuko wrote: post #106
jeroenhd wrote: post #90

Earlier quoted context omitted.

The only proper way to do internal DNS is to register a domain. Even a free one will do. 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 htt…

I do have a domain but I don't want to enter my private IP addresses on a public DNS. Hence I just have server.internal to point to the correct IP address on my local DNS server and have service1.server.com, service2.server.com, etc. all just CNAME to server.internal.

You can continue using /etc/resolv.conf to specify the private IP addresses even for a website that does actually exist. The point of registering the domain is to ensure that your computer/software can't ever accidentally hit anything you didn't intentionally configure that is actually under the control of someone else. You don't actually need to use publicly visible DNS to configure your internal network just because you used a real domain name.

Re: foo@bar.com

#110

Post by PowerBar »

throw0101a wrote: post #93
nebulous1 wrote: post #20

Earlier quoted context omitted.

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. As mentioned above, it should have been .test

> .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 "ss…

Which is one of the reasons I always insist our dev and prod teams use FQDNs (under domains the company owns) in all of their configurations.

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).

Post reply on HN