Hacker News Reader

Comment by louwrentius | Hacker News Reader

I do state in the article that in the examples DNS isn't the root-cause, but the blast radius is very significant. Regardless of the topic of external/internal services, isn't it remarkable that a group of very smart and well-paid people create such circular dependancies?

Yet, I'm not arguing for Facebook or similar size companies to ditch DNS internally. I'm making the argument for much smaller organisations to pause and think where their own risks lie and if it would make sense to cut out DNS to reduce risk. Whatever process you used as an organisation to update DNS in a safe manner, you still use with the alternative solution, that doesn't change.

That said, even an broken update to /etc/hosts is probably easier and faster to recover from than a broken DNS service that everything is tied to and due to TTL caching, can take much longer to resolve.

View on HN

As said, I believe you are simplifying the problem significantly and thus making general claims which do not hold water.

Eg. even if you are DNS based but have direct SSH access to the system which has a query cached and root access on it (you need to manage all this too!), you can temporarily edit /etc/hosts or /etc/resolv.conf to workaround the cached value.

So my suggestion remains to keep working on a better argument and scenario by trying to understand exactly where your intuition applies — but be critical to yourself too, and think through if your alternative has any other cons too.

By doing so, you will likely find why everybody defaults to DNS for a named service registry in a sense.

Or you can just clear the cache!

> even an broken update to /etc/hosts is probably easier and faster to recover from than a broken DNS service

I fail to see how, especially if you were to accidentally break your ability to push those updates out.

I think what you are really arguing for is more people that properly understand (and implement) DNS.

A smaller organisation should have a much easier time implementing internal DNS and it should be pretty damn stable and reliable. Unfortunately a lot of people dont properly understand it (not that you need to be a complete expert - just competent) and hence we always have the mantra "Its always DNS" when something goes down.

Usually complicated beskoke systems engineered for internal use are better left for really large orgs that can hire the talent to maintain and properly implement it (and have the manpower to have enough people in the first place always on staff to maintain it when the first person gets sick or something)

TTL caching

We are talking about 300sec (=5Min), this is never an issue

Reply on news.ycombinator.com