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

201–210 of 301 posts

Re: foo@bar.com

#201

Post by markdown »

jrockway wrote: post #159
captn3m0 wrote: post #128

Earlier quoted context omitted.

ICANN should never have assigned .zip, there's just too much potential for abuse, confusion giving away a common extension as a TLD.

I think it's okay. They are different namespaces and people should fix their bugs. It would be like skipping the street number "911 Foo St." because "911" is the emergency phone number and 911 Foo St. is just a regular house. I'm sorry if someone is confused but they shouldn't be confused. They're totally different things. The biggest mistake we made with DNS was the "shortcut" of implicitly adding the root domain to…

> It would be like skipping the street number "911 Foo St." because "911" is the emergency phone number and 911 Foo St. is just a regular house. I'm sorry if someone is confused but they shouldn't be confused. They're totally different things.

Floor 13.

Re: foo@bar.com

#202

Post by [deleted] »

jdxcode wrote: post #130
giantrobot wrote: post #124

Earlier quoted context omitted.

I've personally run into the .zip problem thanks to browser's omni address/search/chocolate bars. I intend to search for a zip file whose name I know but the browser "helpfully" realizes the term includes no spaces and ends in dot something and attempts to treat it as a URL. 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…

if we could go back I wonder if it would be better if we had required a leading dot in domain names ".google.com"

[deleted]

Re: foo@bar.com

#203

Post by CydeWeys »

oauea wrote: post #157
CydeWeys wrote: post #53

Earlier quoted context omitted.

It's not a huge change though. .dev was a new, never-launched TLD, so there were no existing real domain names to break with the addition of HSTS preloading. Established best practice for decades at that point was already to always use real domain names (or subdomains thereof) or specifically reserved test domains/TLDs (see RFC 2606, published in 1999) for testing/development/local networking purposes. So yes, we did…

Were you somehow unaware of the many, many, many people who used .dev in their local environments? You must've had some idea, since the initial plan was to use the .dev TLD for exactly that within Google. I've always hated Google for egoistically claiming this tld, and ICANN for letting them.

Yes. Not nearly as many people were using .dev in local environments as you seem to think. We didn't know anyone, and by the very nature of them being fake and locally-configured-only it's not something you can easily find out about. And no, our intention was not to use .dev for fake domain names.

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

Re: foo@bar.com

#204

Post by EvanAnderson »

CydeWeys wrote: post #91
yesbabyyes wrote: post #67

Earlier quoted context omitted.

Yes, you're probably thinking of corp.com, which MS used as the default for AD setups. It went up for auction this spring and MS bought it: https://krebsonsecurity.com/2020/04/microsoft-buys-corp-com-...

I used to work for a company named Foo Bar Solutions with the public website foobarsol.com, but that used foobar.com for the internal AD name for some reason (which they didn't actually own). That was ... interesting. Microsoft clearly did not do their due diligence in explaining that the domain configured in AD must absolutely, positively, 100% no bullshit, be a real domain name that you actually own and will never…

I've had to clean a number of these up. The worst is when "foobar.com" answers with a wildcard record. Booting client computers using public DNS in that scenario is like being stuck in a tar pit. The poor helpless operating system tries and tries to reach servers to query for its AD site, find Domain Controllers, apply group policy, run scripts, etc.

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.

Re: foo@bar.com

#205

Post by CydeWeys »

tony101 wrote: post #185
JoshTriplett wrote: post #167

Earlier quoted context omitted.

> If you give me your email I can send you a message from my _lastname_@ work address 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.

You could check whether the email passed SPF, DKIM, and DMARC checks. Google has certainly implemented these for their SMTP servers. If all of the tests pass, you can be pretty certain that the sender is the owner of the address.

This is what I was getting at. It's definitely not possible to fully impersonate an email from an @google.com address. We've got all the security bells and whistles turned on.

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.

Re: foo@bar.com

#206

Post by mattl »

kzrdude wrote: post #187
CydeWeys wrote: post #31

Earlier quoted context omitted.

Domain names are going for more money than ever before. The record for most expensive sale (publicly known anyway) was hit just last year. 30 million dollars for voice.com: https://domainnamewire.com/2019/06/20/yes-voice-com-is-the-m...

it's counterintuitive, with the flora of TLDs

A lot of people assume .com for whatever reason

Re: foo@bar.com

#207

Post by CydeWeys »

kzrdude wrote: post #186
srtjstjsj wrote: post #111

Earlier quoted context omitted.

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.

You could propose this to be implemented, surely?

It's already being proposed by one of my colleagues. See: https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00

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.

Re: foo@bar.com

#208

Post by CydeWeys »

themacguffinman wrote: post #189
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

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

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.

Re: foo@bar.com

#209

Post by CydeWeys »

kzrdude wrote: post #187
CydeWeys wrote: post #31

Earlier quoted context omitted.

Domain names are going for more money than ever before. The record for most expensive sale (publicly known anyway) was hit just last year. 30 million dollars for voice.com: https://domainnamewire.com/2019/06/20/yes-voice-com-is-the-m...

it's counterintuitive, with the flora of TLDs

The new gTLDs have been great for random people like you and me just wanting a domain to actually use it, but terrible for domainers. I got a nice 4-letter domain (cyde.dev, which I haven't done anything with yet) that I never in a million years would've gotten on .com.

Re: foo@bar.com

#210

Post by colejohnson66 »

tus88 wrote: post #141
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…

Why would you tell them and bring an end to the lolz?

Because, technically, opening those emails when they contain confidential information could be construed as a violation of the CFAA (it’s very broad).
Post reply on HN