[Yeti DNS Discuss] Yeti back to the future
shane at biigroup.cn
Mon Oct 26 10:34:44 UTC 2015
On 2015-10-25 11:17:25+0100 (Sunday)
Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
> On Sun, Oct 25, 2015 at 10:15:54AM +0100,
> David Beck <david.beck at informnis.ch> wrote
> a message of 17 lines which said:
> > An authoritative server requires the approximately correct time for
> > TSIG
> Yes, but attacking the clock would just prevent name servers to
> synchronize. A DoS but which is quickly detected and fixed.
> And Yeti does not use TSIG (should we? With DNSSEC, is it still
As I understand it, the possible attack that TSIG would prevent would be
something like a man-in-the-middle attack between the Yeti distribution
masters (DM) and the Yeti roots. This attack should be relatively easy
to set up via BGP hijacking (for example).
The outcome of such an attack would be one or more Yeti root servers
which are serving bogus versions of the root zone.
If resolvers validate responses, then it should not matter at all,
since the root servers only serve the root zone, and that is signed. In
fact, a validating resolver should try a different server, and
ultimately get a correct answer unless all Yeti servers are compromised
in this way. In that case - which seems very unlikely - then resolvers
will start to fail.
TSIG would do no better, only the failure point would be between the DM
and the root servers. TSIG would also be a hassle to manage because we'd
ideally use a separate key between each DM and each Yeti root.
If resolvers do NOT validate responses, then having a Yeti server
provide bogus answers would basically completely compromise that
resolver. It would be nice if we could insist that resolvers validate,
but there is no provision for that in the protocol (although this is
being discussed in the context of the IANA root KSK roll).
What we *could* do is to check that the root zone is valid on each
authority server. There is no provision in any existing DNS software to
do this automatically as part of the zone transfer process, but it
could be done via scripts or as a periodic (hourly?) audit activity. It
would not provide any additional safety for validating resolvers, but it
would help non-validating resolvers a bit.
More information about the discuss