[knot-dns-users] minimal responses (was: Re: Knot DNS 2.0.1 patch release)
marek.vavrusa at nic.cz
Mon Sep 14 08:50:11 CEST 2015
"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.
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
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?
On 2 September 2015 at 19:17, Robert Edmonds <edmonds at debian.org> wrote:
> Jan Včelák wrote:
>> - We have decided to remove NS record from the Authority section for NOERROR
>> responses. We used to put these records there because BIND and NSD did it.
>> But these records are not required by any RFC and just increase the size of
>> the response.
> It looks like this code has just been deleted. I wonder if it could
> instead be made into a tunable, defaulted to off? Maybe even with the
> conditional wrapped in unlikely().
> I can certainly see how apex NS records in the authority section is not
> particularly useful for root or TLD servers, but it's occasionally
> useful for "leaf" zones to speed up the propagation of updated NS
> records, due to the trust ranking rules in RFC 2181 §5.4.1.
> I also know of at least one more DNS server (rbldnsd) that has this
> behavior as a tunable run-time option.
> Robert Edmonds
> edmonds at debian.org
> knot-dns-users mailing list
> knot-dns-users at lists.nic.cz
More information about the knot-dns-users