Hey Robert,
"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
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?
Marek
On 2 September 2015 at 19:17, Robert Edmonds <edmonds(a)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.
Hi,
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(a)debian.org
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users