[knot-dns-users] minimal responses (was: Re: Knot DNS 2.0.1 patch release)

Robert Edmonds edmonds at debian.org
Tue Sep 15 00:34:46 CEST 2015


Marek VavruĊĦa wrote:
> "occasionally" useful, yes. As everything it's a compromise.
> RFC2181 ranks data based on trust level, but that doesn't reflect the
> correctness of the data as I've seen delegations broken in
> authoritative data and vice versa.
> A resolver has to deal with both cases unfortunately, and evaluates
> all possible options before giving up and be wary of what to accept it
> cache at the same time.
> NS in the authority section is really extra data and shouldn't be
> cached, as it gives the attacker a tool to joust valid NSs out of
> cache with spoofed ones much more easily.

I agree that resolvers could probably do better than to eagerly
overwrite a cached NS RRset with whatever just came in off the wire.
(In the non-DNSSEC case.)

But, given a Knot 2.0.1 style server that only hands out its apex NS
RRset when explicitly asked for qtype NS, that potentially makes things
even easier for an attacker, since the NS RRset being attacked has the
lowest "trustworthiness" level.

I think it would be nice to keep the pre-2.0.1 behavior as an option
(but have the 2.0.1 behavior be the default).  But it's not a must-have
option, I don't think.  Certainly not for root or TLD service :-)

> The real problem is that people want DNS to be decentralised when it
> works and centralised when they make a mistake.
> This could be solved by providing feed of "purge requests" indexed by
> time, so the resolvers could poll it and automatically flush part of
> its cache.
> It is a glaringly similar problem to RPZ feeds which were adopted
> really quickly, so I trust it's tractable.
> Do you know about any efforts going in this direction?

There are generally calls for such a mechanism to exist, usually on the
dns-operations@ list right after a compromise of some high profile
domain :-)  I don't know of any active efforts, though.

-- 
Robert Edmonds
edmonds at debian.org


More information about the knot-dns-users mailing list