DNS as Dead Drop

Remember when people physically embedded USB drives in public places so strangers could swap files without talking in the early 2010s? You would find one, plug it (brave), copy files, add your own, and put it back. No contact between the people involved and the wall was the shared state.

A physical dead drop works because it removes the relationship between sender and receiver, meaning there is no session or acknowledgement. Just a shared place where state may or may not have changed.

A DNS cache dead drop is the same abstraction, translated into networking. The shared place is the cache memory inside a recursive DNS resolver. Nothing is stored in DNS records as a message, the message is encoded in whether the resolver remembers something.

Shared cache state

Recursive resolvers are built to answer questions efficiently and they do this by caching responses. Once a response is cached, subsequent lookups can be served from memory until the cached entry expires.

That cache state has two important properties:

1. It can be influenced by one party (by causing lookups to occur).
2. It can be observed by another party (by asking whether a cached entry exists).

If you can reliably create a difference between "this name is cached" and "this name is not cached", you basically have a building block for signalling. Again, this isn't about DNS as a message transport like with a TXT record, but using DNS caching as a shared memory cell instead.

RD flag

DNS queries include a set of header flags. One of them is the Recursion Desired flag (RD).

• RD=1 effectively means: if you do not know the answer, go and find it.
• RD=0 effectively means: do not go and find it, only answer if you already remember.

These two are conceptual meanings and the exact behaviour depends on the resolver implementation and its configuration, but that distinction is the idea behind the cache-based dead drop. In dead drop terms, RD=1 is the write action because it can cause new cache state to be created and RD=0 is the read action because it attempts to observe cache state without triggering new lookups.

Wildcards

A wildcard DNS zone makes it easy to generate a large number of distinct names that all produce valid answers. Each unique hostname can act like a separate cell: either it is cached or it is not. With wildcards, you can create arbitrarily many hostnames that all resolve without pre-provisioning individual records.

So the components are:

• a resolver cache (the shared memory)
• a way to make distinct names resolve (wildcards)
• a way to write cache entries (RD=1 queries)
• a way to read cache entries (RD=0 queries)

Encoding information and addressing

The simplest encoding is binary, bit 1: cause a resolver to cache a name, bit 0: do not cause caching for that name. Then, the receiver probes the same set of names and interprets 1 as an answer and 0 as a non-answer. In other words, the message is a pattern of remembered and not-remembered hostnames.

A dead drop needs a common meeting point. In this model, this is achieved by agreement in advance on which resolver is the shared drop, which set of names correspond to which bits and what time window is relevant (because caches expire). This now mirrors physical dead drops where both parties agree on the location, the method of transfer and the general time (when the drop is available).

The DNS version adds a more concrete concept of time because TTL determines the lifetime of stored state. TTL is now the retention time of the dead drop and the the validity window of a bit.

Is this practical?

Maybe, if done right, but even as theory, there are multiple failure modes that would require careful planning, because they explain why this is interesting but not generally practical:

• Caches have finite size and resolvers evict entries so the bit can disappear early.
• If a resolver is shared, other users might query the same wildcard names by chance or through scanning, which can create false positives.
• Rate limit, minimisation, and policy controls still exist and can interfere with repeated lookups.