[dns-operations] DNS Flush Protocol

[Paul Vixie]

George Michaelson wrote:
> OK. thats a good motivation. Nicely stated.
>
> Models based on in-band proof(s) of possession might then in some
> sense, be better. While I hate meta-protocol usage, since we don't
> have a c&c channel that zone owners share with resolver owners, it
> might be a tool in the locker.
>
> How do you feel about state in the resolver to rendesvous on? Because
> if we can do DNS 'query knocking' with held state, we can signal both
> intentionality, and proof of possession. Obvious DoS risk of making a
> resolver hold state but its probably no worse than the Amp Attack
> risks.
>
> Or if we have held-open session, then sequences of queries can be more
> meaningful. I connect, I prove something doesn't exist with zero TTL,
> I perform state change in the zone and re-query which shows you I
> effected change for a prior query..

i put a fair amount of thought into this in 2002, and i could not come
up with a scalable secure protocol, with either push or pull, with
either subscriptions or registrations. therefore i decided that the only
thing we could do is "hold up".

in the "hold up" model, the TTL's of the above-the-zone-cut NS RRset
(so, the delegation from the ancestor zone) would control a redelegation
check in the caching resolver. essentially this NS RRset would be
cached, and when it expires, then a subsequent iterative lookup (even if
it was for an in-cache RRset) would cause the caching resolver to use
the zone's closest unexpired ancestor as the "closest enclosing NS
RRset", and to forward the query to that set of name servers. if those
name servers answer with a delegation as they must previously have done,
then the iterative lookup would be answered from cache, and the
above-the-zone-cut NS RRset would be replaced in cache with the new one
just refreshed. if on the other hand the NS RRset has changed (or is no
longer present), then all cached data at or below that name would be
purged, and the iterative lookup would be restarted without that cached
data present.

the idea here is that a 1-day TTL on all in-zone data would cause it to
be retained for 1-day just as now, but, if there was a 1-hour (or
10-minute) TTL on the ancestor's delegation NS RRset to this zone, then
there would be a delegation refresh every hour (or every ten minutes, or
whatever the TTL was set to) such that if the delegation was altered or
removed, then all cached data received from the prior set of delegated
servers, would be dropped.

if combined with a registry TTL setting of ten minutes or 30 minutes or
similar, this would allow for:

1. rapid removal of criminal DNS content from all cooperating caches,
upon DNS "takedown";
2. rapid removal of incorrect DNS content from all cooperating caches,
upon DNS "oops".

the cost of these delegation refresh checks would be minimal compared to
the incredible flood of garbage queries we see at all registry-level
authority servers today. even if we doubled the number of valid queries,
which is unlikely, it would still be noise compared to the invalid,
endlessly-repeating queries.

so, low pain, great gain, no security concerns other than predictable
timeouts (which could be randomized, if kaminsky-style attacks are a
concern), no privacy concerns, no loss of performance for cache "hot
spots", no central registration or subscription or clearinghouse.

years later (so, in 2010), i wrote this up as one of three similar
improvements, here:

http://datatracker.ietf.org/doc/draft-vixie-dnsext-resimprove/

but, i think noone understood it, so it languished. (note, it's only 4
pages long, so, an easy read.)

-- 
Paul Vixie