[dns-operations] DNS Flush Protocol

[Bob Harold]

Even if we get faster updates to the resolvers, I see two other issues:
- the clients will still hold DNS entries in their cache.
- registrars set a ttl of 1 or 2 days on the delegation NS and glue
records, and don't give users any way to change that.

I have to wonder if the simplest and most effective solution is to
recommend that the resolvers set:

max-ncache-ttl number;
max-cache-ttl number;
(for some number like say an hour or less?)

With all the pre-fetching and bogus queries, I wonder if the increase in
traffic would really be significant or not.  Is it possible to estimate or
test?

This can be done today on resolvers, with no requirements for anything new,
and no change to auth servers or clients (at least clients that respect the
ttl, others cannot be helped no matter what we do on the DNS servers).

-- 
Bob Harold


On Fri, Mar 27, 2015 at 4:32 PM, Paul Vixie <paul at redbarn.org> wrote:

>
>
> 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
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150327/0e1b2800/attachment.html>