Re: Question about TSIG, AD/AA, and AXFR

["Scott Rose" <[e-mail]>]

Good question - I don't think there is any way (using the current DNSSEC
spec) for a stub resolver to know that the secondary is using a secure AXFR
other than knowing the policy out-of-band.

One possible solution would be to include a SIG generated by the primary
host along with the data (over the SOA).  This would be in addition to the
zone key SIG and only included when a secure AXFR is used.  However, then
the SIG must be verified by contacting the primary host (so we loose some of
the benefits of having secondaries since resolvers are still contacting the
primary).

As Brian said - it may not be that big of an issue.  Any malicious
alterations of zone data during a transfer will be noticed if the zone is
secured.  If it is unsecured to begin with, there are multiple points of
attack to worry about.  Is this a big enough problem to justify adding to
the spec?  I'm not so sure.

> I am wondering if there is an unreported protocol problem in the
> combination of TSIG, AD/AA, and AXFR.  My concern is that a resolver may
> over trust an answer that has come TSIG-protected from a secondary who
used
> an unsecured AXFR to get its zone data.
>
> Here is the case-by-case breakdown that led me to this concern.  Assuming
a
> "stub" resolver - one that will rely on query/response security and is not
> able/willing to do full chain processing, and only looking at TSIG-covered
> answers:
>
> Case TSIG AD AA Server-type
>   1    Y   0  1 Primary        "From disk," so it can be trusted
>   2    Y   0  1 Secondary      Via AXFR, trustworthy only if AXFR is
secure
>   3    Y   1  0 Non-auth       Server validated the chain
>   4    Y   1  1 anything       Not possible as far as I can tell
>
> DNS Security is supposed to be about protecting the resolver, and here we
> have a case (#2) where the resolver can't be sure of an answer's security.
> It is fine to recommend that zone transfers use TSIG, but then you're
> putting discretion in the hands of the zone and not the resolver.  (Not to
> mention that TSIG isn't the only way to secure an AXFR.)
>
> Can there be some way to indicate that a secondary has used a secure means
> to acquire the zone data?  (Yeah, "can there be some way to indicate that
a
> *primary* has used a secure means to acquire the zone data?" is the first
> rebuttal.  But we know that a secondary had to get its data from some
other
> machine, so I think this asking about a secondary's source is valid.)



to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.