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

[Roy Arends <[e-mail]>]

On Mon, 16 Jul 2001, Edward Lewis wrote:

> 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.)

WRT axfr-clarify-02, situations 3 and 4 will not occur.

The problem is when some caching forwarder is also authoritative for a
local domain. Say that local domain is secured and applications using a
stub resolver (which forwards all to the local cache) depend on the AD
bit. The AD bit will never be set on responses containing local domain
data, since the queried server will never (!!!) check it.

If a server is willing to verify chains, why not verify the localy
configured data that happens to be in the chain, either verify data when
queried for it, or verify the data on accepting it (during disk-read,
axfr or caching).

Ofcourse having an authoritative and cache server in one might be not a
good setup, it is not strictly forbidden by a MUST NOT in any RFC.

What I'm actually saying is that there _is_ some indication that a
secondary trusts the transferred secure zone, by simply verifying the
received info, and set the AD bit on every query-response containing this
info.  In that, an axfr-response is just like any query-response in that
the response contents must be verified if possible.

Regards,

Roy



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