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.
foo@bar.com
121–130 of 301 posts
Re: foo@bar.com
#122Earlier 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.
Re: foo@bar.com
#123Earlier 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.
Re: foo@bar.com
#124Earlier 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…
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
#125Earlier 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.
Re: foo@bar.com
#126Earlier 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-…
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
#127Earlier 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…
Re: foo@bar.com
#128Earlier 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…
Re: foo@bar.com
#129Earlier 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…
Re: foo@bar.com
#130Earlier 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…