undefined | Better HN

0 pointsnecovek21d ago0 comments

The examples you cite (eg. 2021 Facebook outage) have nothing to do with DNS being used for internal infrastructure.

In the other example (Amazon DynamoDB issue), the problem is with dynamically choosing from a large dynamic pool of IP addresses for a service — DNS is but one mechanism to do it. If it wasn't DNS, it could have been something else that did that job that was broken. Even /etc/hosts if it was updated with an empty record.

What I am saying is that your analysis is not defining the problem you want solved exactly, your examples are not backing up your proposal or analysis, and you are ignoring all the things DNS does both for public and private infrastructure. You seem to have some intuition about this adding complexity and thus being a risk (which is true), but you need to do a better job of connecting and analysing real risks and proposed solutions (and their comparative performance).

0 comments

6 comments · 1 top-level

louwrentius21d ago· 5 in thread

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.

necovekOP21d ago

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.

patmorgan2320d ago

Or you can just clear the cache!

monkpit20d ago

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

Melatonic19d ago

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)

JackSlateur21d ago

TTL caching

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

j / k navigate · click thread line to collapse