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

111–120 of 301 posts

Re: foo@bar.com

#111

Post by srtjstjsj »

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…

It's terrible that the spec doesn't reserve something like .localdomain that is unregisterable so that DNS servers can use it for internal use.

.test doesn't quite cut it.

Re: foo@bar.com

#112

Post by srtjstjsj »

paultopia wrote: post #108
lifthrasiir wrote: post #9

Earlier quoted context omitted.

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

That risks getting you in trouble with Secret Service.

Re: foo@bar.com

#113

Post by monadic2 »

CydeWeys wrote: post #80
davemtl wrote: post #54

Earlier quoted context omitted.

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…

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

Ruby's `open` accepts urls. I can't say I've ever used this functionality.

Re: foo@bar.com

#114

Post by PowerBar »

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 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 and you don't have to worry about any issues with using the reserved *.internal domain.

Re: foo@bar.com

#115

Post by srtjstjsj »

darkerside wrote: post #17
ryanbrunner wrote: post #13

Earlier quoted context omitted.

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

Probably not, but it's always nice to follow intended designs, since others will do so as well and this allows systems to evolve in compatible ways. There may be no difference today, but there could be tomorrow. 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…

.invalid is guaranteed invalid by spec.

Re: foo@bar.com

#117

Post by Hamuko »

PowerBar wrote: post #114
Hamuko wrote: post #106

Earlier quoted context omitted.

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

Re: foo@bar.com

#118

Post by nitrogen »

ludamad wrote: post #57
jbrooksuk wrote: post #42

Earlier quoted context omitted.

Out of interest, how did this happen without any investigation into possible consequences etc? It’s a huge change that surely warranted special attention before making it happen?

I don't think fresh launches, even with bold new parameters, are always considered 'huge changes' in that sense. The fact that it could break local environment's was probably not even documented in those specific environments

There was a time when the creation of a new TLD was unthinkable, so it seemed safe to use a domain syntax internally that was never going to become a public TLD. Then the TLD money grab happened and what was assumed to be safely isolated wilderness was sold out from under everyone.

Re: foo@bar.com

#119

Post by renewiltord »

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

Re: foo@bar.com

#120

Post by aloukissas »

A friend of mine in Greece owns the null.gr domain. He's gotten a ton of automated email from misconfigured systems over the years, some of them with serious security implications :)
Post reply on HN