aeden

Beyond the stated changes the author believes are necessary for citizens to make: stop externalizing responsibility, stop going along with social norms that perpetuate surveillance capitalism, and indulging in anger as a substitue for action; the other actionable takeaway to me is: "Unless we have real representation in our government. Companies don’t have vested interest in protecting privacy."

I interpret this as meaning citizens need to support advocacy groups that lobby elected officials to create/improve regulations that would limit the ability to implement surveillance capitalism. This aligns with the author's own words: "Responding to National or Regional calls for safety: Calls to support initiatives, or bills to increase security at the expense of freedom, make us less safe. Trading security for freedom reduces our ability to act."

Interesting, this is the first time I've seen this project. One thing I saw that concerns me a bit is that they provide command-line options for passing your user credentials and multi-factor code. I'm not a fan of giving anything that level of access when a resource-specific access token will do, but that's me.

Our current level of granularity allows you to give read or write access to a specific zone, but it does not go down to the level of giving read or write access to a specific RRset type yet, if that's what you're looking for.

I've put a comment on the parent thread, but unless I've misunderstood what the poster said, we addressed the limitation back in 2023 with scoped access tokens.

DNSimple seemed nice but IIRC I couldn't get a different API token per zone (?).

We overhauled our account tokens a few years back: https://blog.dnsimple.com/2023/11/scoped-access-tokens/ . With account tokens you can specify fine-grained scoped access control, including specifying only one or more zones that a token has read or read/write access to.

Thanks for recommending us, I (and the rest of the team) appreciate it.

At one point we were using Cloudflare's DNS Firewall product for our entire edge network. We have since moved half of our edge network to our own infrastructure and are currently in the process of expanding our edge network further, so at this point an outage at Cloudflare should be at least partially mitigated for our customers due to our separate edge network, and eventually it should be completely independent.

Sorry to hear that you're considering leaving. Is there a specific part of our pricing that you consider expensive? From the DNS side we've aligned pricing with what AWS, Google, and MSFT are charging, and for domains we've tried to stay competitive as well without completing removing our margins. Do you use specific features that are not available on our base plan?

I really hope they get manage to recover it. I grew up surfing in Central Florida and even I knew about it and had seen pictures of it. I finally went there a few years ago and it was a blast to see people surfing it.

I'd love to see an update of this for how things look in 2024.

We run a combination of managed hardware and virtual hardware. The prices for both have indeed gone up significantly since we launched some of our earliest plans. We don't have the luxury of using a cloud provider like AWS for our Anycast DNS infrastructure, thus we are limited to our choices. Furthermore the cost for network transit has gone up, as has the cost of ancillary services we use to operate our network (such as tooling for alerting, observability, etc).

Founder and CEO of DNSimple here. I'd like to clarify a couple of things about our business that may shed some light on why we've ended certain legacy plans when we have.

There are two key parts to our business: domain registration management and authoritative DNS. These two parts have very different price models in the industry. For domains, you pay a fee for each year they are registered. For DNS, you pay for each zone and then for the DNS queries.

The price changes around domain registrations have not been coming from us, rather registry operators have been raising many of their wholesale prices repeatedly in recent years. The operator for .COM even showed up in the news recently when Senator Warren called for an investigation into Versign for the price changes around that TLD. We’ve either kept domain prices stable for as long as we could, or even reduced them, as long as we were able to retain some small margin.

The price changes around operational DNS stems from the rising prices of infrastructure as well as changes by our vendors for various services related to DNS operations. Last year we overhauled our pricing to try to remain competitive in the DNS operational space by reducing minimum requirements (you can register domains with us and use another DNS provider which is something you could not do with our previous pricing model) and by aligning to actual costs (we were not charging for queries for a long time, but we are being charged for queries for things like DDoS defense and edge caching, so we had to update our prices to reflect these changes).

Operating a business means you have to keep at least 3 groups happy: the customers, the team, and the owners. Many times I have to make a decision that will make someone unhappy, and it sucks, but I do it to ensure we can continue operating and keep providing service to those that see value in what we offer. This is one of those cases. From the operational DNS perspective, our Basic Reseller plan has been operating at a loss for the last few years, so it had to ultimately go.

To Cory and any other customer who feels we did not communicate well on the changes: I’m sorry. I assure you we have tried over and over through emails and one-on-one conversations to explain why these changes were necessary. I, and the entire DNSimple team, have always been very open with any customer that is frustrated with changes we’ve made, and we will continue to do so. If you ever want to talk to me about DNSimple, my inbox is always open.

CEO of DNSimple here. We have not changed the prices for any existing customers with active subscriptions, nor do we plan on changing them in the near future. We have adjusted our pricing for new customers and prior customers who resubscribe.

With our new plans we offer zones for $2 per month for unlimited query volume whereas Amazon charges $0.50 for each zone, plus $0.40 for the first million queries + $0.20 for each million queries thereafter. We will likely also eventually have to charge by query volume because there are real costs with operating our DNS network. One of the reasons we have not yet talked about what we will do with existing plans is because we do not know for sure what the optimal pricing will be with query volumes involved.

Cloudflare is something altogether different and frankly is hard to compete with based on price as they are subsidising their free tier with by charging business customers at a much higher amount (I can say this from experience).

In terms of where we are headed to differentiate ourselves from other domain management services, the new features we've been launching should make that clear. For example, you can now manage Route 53 zones from within DNSimple (https://blog.dnsimple.com/2023/06/manage-aws-routes-in-dnsim...) as well as CoreDNS zones for on-premise DNS, as well as see your GoDaddy domains in DNSimple as well (with management coming in the upcoming months).

For any existing customer that wants to switch to the new plan, we've made that easy to do (for example if you have one zone it'll be cheaper in the Solo plan). For customers that resubscribe and need to select a new plan, they are always welcome to reach out to us at support at dnsimple dot com and we will be happy to work with them to find a solution that works for them.

CEO of DNSimple here. We have indeed rolled out new plans for new customers. Anyone on an existing plan will be able to keep there current plan for now, although we will likely migrate everyone to the new plan sets within 12 to 18 months from now.

Our goal with the DNS zone pricing is to bring it in line with what folks are paying for similar service at the major cloud providers. When it comes to authoritative DNS, our operational environment has changed for us in the last couple of years, and what was once a reasonable fixed price is no longer. We're paying for DDoS defense by query volume, and as such we need to move towards a pricing model that covers that. By making the pricing the same across all of our plans, we can also focus on making our DNS better for everyone, not just for our higher tier plans.

Hopefully this helps clarify a bit on why we are introducing new plans. We still have a few more changes to make before the year is out, which is one of the reasons why we have not introduced any timeline for phasing out our old plans, allowing customers who are on them to continue with their current pricing for the time being.

Feel free to reach out to support at dnsimple dot com if you have any other questions, we're happy to answer.

Yes, yes, yes! We've wanted to build a connector for them for a while now, but so far, there's no API to pull the appropriate DNS records to automate setup of DKIM.

FWIW, we have ToTP 2FA at DNSimple, and we're prepping launch of FIDO support as well (feature is dark launched internally).

DNSimple | Software Engineering | Remote (world-wide) | Full-time

DNSimple was founded as a fully remote company in 2010 with the goal of making DNS and domain management simple for everyone. We offer a customer friendly user interface, a simple to use API, and operate critical infrastructure for our customers to provide reliable, trustworthy services. Our team continuously innovates, enhances, and releases new features for our customers to make their domain management effortless.

Open positions:

Software Engineer in Feature Engineering (https://apply.workable.com/dnsimple/j/36AE622A87/) Develop and release customer-facing features. Senior Software Engineer in Registrar Operations (https://apply.workable.com/dnsimple/j/F17DAD5B37/) Help us to improve how our customers manage domains. Software Engineer in Application Operations (https://apply.workable.com/dnsimple/j/510AFA1359/): Continuously enhance and maintain DNSimple's applications to fulfill short-term and long-term needs.

I wonder if they are using tooling that doesn't properly retain DNSKEY records for DS that recently removed? This is one of the reasons we perform controlled automated key rotation and removal in DNSimple, so that we can ensure we retain the keys in the authoritative zone on each key rollover giving the DS records time to expire from caches.

I think the post is suggesting running your own local resolver instead of using a public resolver or an ISP resolver.

"I wrote a name server"

Thank you, I feel exactly the same. I assume at this point any use of subscriptions in Stripe means we are using Stripe Billing, but the messaging is very unclear.

Without knowing the inside story, it seems like an overreaction for OVH to take down an entire service based on law enforcement requests, unless there's more to the story, which there probably is.

FWIW, DNSimple was blocked by an entire country because we adhere to our local laws in the US and we didn't take down a site that was illegal in their country. This is the Internet we have today.

Often the local governments (whether that's the town, the department, the region, or all of the above), along with some funds from the nation. This is usually thanks to one or more residents of the town who get together to try to save the structure by getting public funds allocated for it.

Added.

Could you provide some details so we can look into this. Specifically what browser and OS you are using, and any customizations you've made in your browser.

FWIW, the site is hosted on Cloudfront using an Amazon issued certificate. Here's some debug output I show using curl which shows successful negotiation:

  *   Trying 13.227.219.41...
  * TCP_NODELAY set
  * Connected to howhttps.works (13.227.219.41) port 443 (#0)
  * ALPN, offering h2
  * ALPN, offering http/1.1
  * successfully set certificate verify locations:
  *   CAfile: /etc/ssl/cert.pem
    CApath: none
  * TLSv1.2 (OUT), TLS handshake, Client hello (1):
  * TLSv1.2 (IN), TLS handshake, Server hello (2):
  * TLSv1.2 (IN), TLS handshake, Certificate (11):
  * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
  * TLSv1.2 (IN), TLS handshake, Server finished (14):
  * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
  * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
  * TLSv1.2 (OUT), TLS handshake, Finished (20):
  * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
  * TLSv1.2 (IN), TLS handshake, Finished (20):
  * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
  * ALPN, server accepted to use h2
  * Server certificate:
  *  subject: CN=howhttps.works
  *  start date: Feb 14 00:00:00 2020 GMT
  *  expire date: Mar 14 12:00:00 2021 GMT
  *  subjectAltName: host "howhttps.works" matched cert's "howhttps.works"
  *  issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
  *  SSL certificate verify ok.

Thanks for pointing that out, we'll put a link to howhttps.works in the footer on dnsimple today.

Looks like there are some issues to resolve with the signup process and billing. I've contacted you via your support channel so we'll see how this works out. :-)

PMF = Product Market Fit

I am honestly curious why, when you learned lesson 1 (Lesson: Don’t quit your job too early), did you not apply it? Find a company in a completely different space, carve out your business in your contract, and work your job while you hone your product. In 3 to 5 years you may very well have a solid growing product, or not, but at least you won't be broke.

If the authoritative is using Anycast (which they should) then you run into similar problems that you get with Anycast resolvers, which is to say you might get different results depending on distribution of data. Due to this we currently provide an API for checking distribution of zone changes with our authoritative name servers: (https://developer.dnsimple.com/v2/zones/#checkZoneDistributi...).