Live data from Hacker News

foo@bar.com

bar.com

121–130 of 301 posts

Re: foo@bar.com

#121
post #76
post #65

Earlier quoted context omitted.

should have used .local

Not really. .local is often tied to zeroconf/mDNS and doesn't work reliably over traditional DNS on all platforms.

mDNS is actually pretty nice on controlled networks, so if you want .local use mDNS.

Re: foo@bar.com

#122
post #106

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.

If you have a local DNS server, you can just have the service1.yourdomain.com only resolve there. Totally standard practice.

Re: foo@bar.com

#123

Earlier quoted context omitted.

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

Ask your red team about that ;)

Re: foo@bar.com

#124
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…

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 dotsomething 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 is getting a lot of unintentional hits.

Re: foo@bar.com

#125
post #122
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.

If you have a local DNS server, you can just have the service1.yourdomain.com only resolve there. Totally standard practice.

My local DNS server can't resolve certificate verifications so I need a public DNS server anyways.

Re: foo@bar.com

#126

Earlier quoted context omitted.

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

> This applies to every domain name though

Say I own "throw0101a.com", and then use "dev.throw0101a.com" and "prod.throw0101a.com". (Or you own CydeWeys.com.)

Previously, when .dev and .prod were not TLDs, it was fairly safe to type "ssh websrv01.dev" and "ssh dbsrv02.prod" because if the queries leaked onto the Internet they'd fail.

Now, with the post-Google TLD changes, if you type one of those things, and the local DNS happens to not be configured properly (i.e., the resolve.conf 'search' options is not present), then strange things can happen.

Further, if you put "websrv01.dev" in a browser now, it may go off into the Internet and try to be clever about auto-complete instead of just doing a local query.

Re: foo@bar.com

#127
post #60

Earlier quoted context omitted.

Thanks. bar.foo should really be redirecting there ... I'll look into it.

I was once reading some documentation (I think for GCP) and there was a weird artifact in the corner of the page, it moved a bit when I moused over it (??) and when I clicked it I got redirected to this site (using the .withgoogle.com TLD). The element never reappeared again. I always wondered why the element appeared on the page. Obviously because "some combination of factors" ultimately returned true - I mean speci…

I got something like that once but my ad blocker apparently screwed up the functionality and I never saw one again.

Re: foo@bar.com

#128
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…

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

Re: foo@bar.com

#129

Earlier quoted context omitted.

How do we know you are the right horse? Sorry, just watched `/the social dilemma` and now I am skeptical of all information on the internet.

If you give me your email I can send you a message from my _lastname_@ work address, which you can then match up with published media I've done under my name, e.g. https://www.youtube.com/watch?v=kBkX30Cj7Bw and https://security.googleblog.com/2017/09/broadening-hsts-to-s... Or you can look at the matching username on GitHub ( https://github.com/CydeWeys ) and see that I'm a member of the Google org and owner of the…

This is argument from authority, but an exquisite one.

Re: foo@bar.com

#130

Earlier quoted context omitted.

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

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"
Post reply on HN