Where a name gets resolved, and why the log matters

When something on the network will not load, the first instinct is to blame the site. Half the time it is a name that resolved to nothing, and the difference between "the site is broken" and "the name was answered with a refusal" is visible from one side and invisible from the other.

The one place every device goes through

Every address lookup starts at a resolver, and whatever the resolver answers is what everything downstream believes. That is why a decision made there applies to the phone, the laptop, the television and the console without any of them being configured.

It is also why the interesting material is not about blocking but about the other answers a resolver can give: the record that points at a name instead of an address, and the record that says the name does not exist at all.

disable.page documents those layers, split by DNS, security and tooling instead of one long page nobody reads, at https://disable.page.

The list that does not need editing

There is a difference between a list you maintain and a list you wrote once. The second kind is a record of a decision, which means it does not need a review cycle and does not need a policy about when to change your mind.

LockFilter is that kind of list, with a public URL per filter that a resolver can load, at https://lockfilter.com.

The part that is worth the most

The most useful feature of any resolver is not the blocking. It is the log of what was asked and what was answered.

Because a blocked name and a broken name look identical from the client, the log is the only place where you can tell them apart. Once you can tell them apart, the fix stops being archaeology.