DNS decides far more than which address you reach

There is a settled way of talking about the domain name system. It is worth asking how much of it survives contact with the detail.

A hierarchy of delegation

Resolving a name walks a chain: root servers point to the servers for a top-level domain, which point to the servers for the domain itself. Each step is a delegation of authority rather than a lookup in one big table, which is what allows the system to scale to hundreds of millions of names.

Your device usually asks a single recursive resolver to do this walking on its behalf and return the answer. That resolver is therefore in a position to see every domain you visit, in order, with timestamps.

Caching is everywhere and explains most confusion

Answers carry a time to live, and resolvers, operating systems, browsers and applications all keep copies until it expires. A change to a record propagates as fast as the shortest cache clears, which is why updates appear for some people and not others. Lowering the time to live before a planned change and raising it afterwards is standard practice for exactly this reason.

Some resolvers ignore short values and impose their own minimum, which is why propagation sometimes takes longer than the record says it should.

Resolution time is real latency

A cold lookup can require several round trips up the hierarchy before any connection to the site begins. A page that loads resources from a dozen different domains pays that cost repeatedly on a first visit.

This is why a slow or distant resolver makes the whole internet feel sluggish while a speed test looks perfect. It is also why browsers prefetch lookups for links they think you might follow.

Filtering happens at this layer

Blocking a domain at the resolver is the cheapest way to implement parental controls, malware blocking, ad blocking and government-mandated censorship. It is easy to configure and easy to bypass by choosing a different resolver, which is why bypass is such a persistent policy argument. Network-wide blocking at the resolver has the advantage of covering devices that cannot run software blockers, such as televisions.

It cannot block anything that is addressed directly rather than by name.

Encrypted lookups change who knows

Traditional lookups travel unencrypted, so anyone on the path can read and modify them. Encrypting them inside TLS or HTTPS hides the questions from the network and prevents tampering.

It does not hide them from the resolver you chose, so the effect is to transfer visibility from your network provider to that operator. It also breaks network-level filtering, which is why some organisations block it and some browsers make the choice configurable.

Figures here are typical rather than guaranteed — check the spec sheet for your part.

Practical choices

A resolver physically close to you and well peered generally gives the lowest lookup latency, and the closest is often your own provider. Public resolvers differ in logging policy, filtering behaviour and how well they cooperate with content delivery networks choosing a nearby server.

A resolver far from you can cause content networks to send you to a distant server, which harms performance in a way that looks unrelated. Running a local caching resolver on your own network reduces repeated lookups and gives you the logs instead of somebody else.

The takeaway

Every connection starts with a question. Choosing who answers it is a performance and a privacy decision at once.

Once you know what it is trading away, the design stops looking arbitrary.