Two different numbers, no? The resignation posts specifies 110 customer meetings, the blog post you linked to about meetings during odd hours does not.
Yeah, different numbers, 110 customer meetings, the other post tracked 1-6am meetings. I'm glad I tracked 1-6am meetings since I've shared that number when people think that remote workers aren't making an effort.
Those 1-6am meetings are crazy. I’ve been fully remote for over 16 years now and my only 1-6am meetings are incident response, if I’m on call.
And I’m a nobody; that you have to do that makes it feel even crazier to me.
I admit I was a bit more flexible with that in the past, but once I had a heart attack at 40 it dawned on me any company would just replace me and keep on going while my family was going to have a much tougher time (and no help from whatever company would be employing me at the time).
I hate that this is the only option available. I want to follow my connections, for their own posts, if any. What I don't want is to see everything they like, share, and comment on -- but LinkedIn won't let you turn that part off.
The ACME provider makes a query to the DNS server to validate the record exists and contains the right "funny string". Parent's question was whether that query is/can be made via DoH.
You want to build a DNS server into nginx so you can respond to DoH query's for the domain you are hosting on that nginx server?
Let's ignore that DoH is a client oriented protocol and there's no same way to only run a DoH server without an underlying DNS server. How do you plan to get the first certificate so the query to the DoH server doesn't get rejected for invalid certificate?
At that point you might as well use the HTTP-01 challenge. I think the whole utility of DNS-01 is that you can use it if you don't want to expose the HTTP server to the internet.
- wildcard certs. DNS-01 is a strict requirement here.
- certs for a service whose TLS is terminated by multiple servers (e.g. load balancers). DNS-01 is a practical requirement here because only one of the terminating servers would be able to respond during an HTTP or ALPN challenge.
But then you have to redistribute the cert from that single server to all the others. Which, yes, can be done. But then you've gotta write that glue yourself. What's more, you've now chosen a special snowflake server on whom renewals depend.
In other words, no, it's not just as easy as setting up DNS-01. Different operational characteristics, and a need for bespoke glue code.
> But then you have to redistribute the cert from that single server to all the others.
Wouldn't you have to do that anyway? Or is the idea that each server requests and renews a separate cert for itself? That sounds as if you'd have to watch out for multiple servers stepping on each other's toes during the DNS-01 challenge, if there is ever a situation where two or more servers want to renew their cert at the same time.
Afaiu, that's only a problem for trying to _delegate_ to multiple clients. But routine operation with multiple clients works just fine in my experience (doing multi-region load balancing). Multiple TXT records are created, I think (speaking off the top of my head).
I wanted to quickly double-check my (albeit limited) experience against docs. The RFC[0] implies the possibility of what I described (provided a well-behaved ACME client that doesn't clobber other TXT records):
2. Query for TXT records for the validation domain name
3. Verify that the contents of one of the TXT records match the
digest value
And then the certbot docs[2] show how it's a well-behaved client that wouldn't clobber TXT records from concurrent instances:
> You can have multiple TXT records in place for the same name. For instance, this might happen if you are validating a challenge for a wildcard and a non-wildcard certificate at the same time. However, you should make sure to clean up old TXT records, because if the response size gets too big Let’s Encrypt will start rejecting it.
> ...
> It works well even if you have multiple web servers.
That bit about "multiple webservers" is a little ambiguous, but I think the preceding line indicates clearly enough how everything is supposed to work.
Never heard of MarkMonitor before. Not a great start.
I had Google Domains for years, until they abruptly and bizarrely abandoned it, then I left for Porkbun. Never had a problem with either of them. I get yearly auto-renewal notices. Everything works, and it’s very boring, which is precisely what I want from a registrar.
I worked at a company that used MM and was involved in some of the domain work.
One of the really nice things about the service is they handle a lot of the general business continuity and security stuff that can really suck with traditional registrars. One of their main lines of work is they’ll work with you to resolve tld-squatting and typo-squatting by working directly with the registrars.
Even before an infinite number of vanity or scammy tlds started showing up it would be pretty difficult to find <your-growing-unicorn-startup>.biz to add to your portfolio of domains since the owner may just have forgotten to update their email in their registrar and were coasting on a 10 year registration. Maybe the squat was intentional and it’s now a 1:1 replica of your homepage with a phishing or other credit card scam going. Stuff like that really sucks to do yourself while handling your other responsibilities. MM was pretty successful at getting in touch with the owners in the first place and having the registrar yank and transfer in the latter case. YMMV of course.
Once a lot of tlds started showing up, and especially the porn related ones, they worked with the new registrars directly (like GoDaddy in the .us case here) in the “sunrise period” to make sure something like google.xxx doesn’t become a front page article about an actual porn site (in case you’re wondering, that one doesn’t go anywhere at all). Your other options are to work directly with each registrar or ICANN.
Oh, I didn't know they'd been around since '99. They called me on behalf of a Hollywood titan about one of my hobby domains, which happened to partially coincide at a dictionary word with one of their client's trademarks, some time around 2006. I don't recall that the approximate paralegal I spoke with actually identified the company; I never forgot the call, but hadn't thought to check who manages the studio's own domain. Go figure.
I found them surprisingly easy to deal with, and happy to have me on record that my toy domain had nothing to do with either their client or any money. I assumed as long as that remained the case I would never hear from them again, and for the decade or so longer I kept the domain, that was exactly how things went.
I may be wrong but I think I saw MarkMonitor changing hands a year or two ago so the MarkMonitor of today might not be at the same level and quality of service as before.
Yeah, in 2022 acquired by some kind of sketchy rollup of lots of legacy/web-1.0 firms or what remained of them, it looks like.
Oh, well. It's been a long time since I was so naïve as not to do a quick informal trademark/brand search before I register a new domain, so I don't really expect to hear from them again any time soon, either.
I'd argue the ability of a private company to exert control over all TLDs on the behalf of their clients is indicative of a problem in the domain registrar system. Not a "service"
That’s because you are maybe not in the market for MarkMonitor. If you check the whois for any global brands chances are they are held by MarkMonitor. Just like you don’t use EY as your tax advisor.
The are supposed to also filter things like complaints. If somebody complains I'm sending spam and I only pay $20/year then my registrar might lock my domain and then I have to work to get it back online.
Mark Monitor will apply a lot more filtering to complaints.
Ironically this is allegedly what happened in this case, a complaint about the domain got it taken offline.
They generally do full service brand monitoring to protect IP and maintain continuity. You would outsource monitoring for trademark infringement to them, and be certain that domain renewals are done perfectly for a portfolio of high value domains.
Which is why this outage is so weird: the entire point of paying MarkMonitor is ensuring that absolutely nothing goes wrong with a very fraught process, and they seem to have just taken down one of the biggest brands they support.
Precisely. You pay a company like this the nosebleed-inducing fees they charge so that this exact event never happens. That assurance, and not the mechanics of domain registration or canned web searches or whatever else, is their product.
It's like, as I'm sure I'm paraphrasing from something I read God alone knows how many years ago, if your publicist lets you walk into a press event with a giant blob of snot hanging out of your nose. There surely is a reason why that error occurred, and it probably is at least a pretty good reason. But no one is very surprised to see the intro invite from your new publicist.
It isn't a relationship you blow up on a whim, but Zoom that can't route call traffic is Zoom that's not generating revenue, and while the reputational impact is negligible if it happens once, it had really better happen only once. Zoom is the incumbent; no one remembers they were revolutionary once, now everyone only notices the parts they don't like. (Being a skilled but politically naïve sysadmin is much the same.)
Basically, this is why Ma Bell - which had about the only stronger possible "uptime" expectation, in that no one uses Zoom for 911 - was so uptight you couldn't even plug in a modem until about five minutes before divestiture, and specified everything down to the number of turns in the splices their technicians made. There was a fad among programmers, when I was a child, to consider such practices stodgy.
Like others said, uptime for a registrar barely matters. For an important domain, I don't want anything to change, and if the registrar is down, nothing will change, so that's good.
What MarkMonitor can provide is things like facilitating RegistryLock, which makes it even harder for changes to be made. And account reps that know what's going on. I hate working with account reps, but if they're knowledgable and easy to work with, it's ok.
They do some trademark monitoring (thus the name), if you want to get your own related app taken down from Google Play :p (I'm not bitter, it was amusing). And presence services if you need to hold a domain in a weird location that wants a presence, they can probably arrange it, which is handy at times.
I'd love to know more details on this incident, MarkMonitor had a bulletproof reputation as a registrar that won't fuck up. Godaddy doesn't, but then I didn't realize they had taken over the contract for .us
They can offer humans in the loop, and those cost a lot. Like, a real live human will contact you and ask if you really want to transfer microsoft.com to Shady Shell Company (Bermuda) Ltd. Porkbun's pricing model is less attractive when your domains are worth billions to you.
MarkMonitor has been around forever. It's used by many of the largest companies. I remember quite a few Google outages that could be tracked down to MM issues.
Wow, that edit is something. Post something inflammatory that will garner engagement, then turn it into your own "I'm hiring" post once it's on the front page.
You can't just be in your codebase and start doin' technical debt like that.
1a. Technical debt is when you...
1b. Okay, wait. Technical debt is when you write code but, like, the kind of code that you know Future You is gonna hate.
1c. Let me try this again.
1c-a. It's when you're coding and you think, "I'll fix this later," but then later turns into never. And now there’s spaghetti code in a project that was supposed to be a sleek pipeline.
1c-b. Like, imagine you're about to refactor something, but you go, "You know what? The deadline's tight, so I’m just gonna... not." That’s technical debt.
1c-b(1). If you're writing code and you think, "Wow, I hope no one sees this commit message," congratulations, you’ve accrued technical debt.
1c-b(2). It’s like leaving a TODO comment, except the TODO becomes, “Oops, it’s been in production for three years.”
1c-b(2)-a. You can write a clever workaround here, but the workaround has to work around the workaround of the workaround from three sprints ago.
1c-b(2)-b. Also, don't forget to include an inline comment that says, "This should be fine for now," which is developer code for “This is the next intern’s problem.”
1c-b(2)-b(i). Fun fact: the "for now" phase lasts forever, and the fix will never be fine.
1c-b(3). Seriously though. Technical debt is when your code does the thing but not in the way anyone would ever want it to. And if your app suddenly catches fire during peak traffic, that’s just the interest being collected.
> service providers who are willing host/facilitate illegal activities
At least for NFL pirate streams, it seems they tend to use "burner" tenants from Azure and AWS. Of course they get shut down, but how hard is it to spin up another one?
> And they end up repeating slots of content in all the rows in their UI, so I end up seeing the same suggestions everywhere rather than much that's new
All of the streaming services do this and I hate it. Netflix is the worst of the bunch, in my experience. I already scrolled past a movie, I don't want to watch it, don't show it to me six more times.
Imagine walking through a Blockbuster where every aisle was the same movies over and over again.
How were they selling a dollar for 80 cents? The actual food is more expensive on grubhub than ordering through the restaurant, and then there are multiple fees on top of that.
Tons of marketing/advertising. The free GrubHub+ subscription through prime probably burned through a lot of cash. I doubt Amazon was paying them very much (if anything) to Grubhub. Then you have all of the corporate staff (around 3k based on google search) who are highly paid.
And the competition from UberEats and Doordash, who also are constantly promoting discounts, free orders, etc. so there's almost no way they can recoup actual costs let alone turn a profit.
But there is the cost of hosting, developers, drivers, etc.
And that's all cost that is not borne by the restaurant.
And there is a limit to how much people would pay to get something delivered. So they're probably pricing the delivery, etc less than they've actually paid.
We've seen this before and we'll see it again. There are lots of people who will pay for things below cost. Sometimes that cost comes down but a lot of the time it does not especially in relatively affluent countries. I don't have a personal driver or chef like I might have in some places. I do have some other house/yard services but very occasionally and I consider them luxuries.
Is there any evidence for this?
reply