15 Zář
2015
15 Zář
'15
0:34
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(a)debian.org