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

[Edward Lewis <[e-mail]>]

At 10:12 AM -0400 7/17/01, Roy Arends wrote:
>WRT axfr-clarify-02, situations 3 and 4 will not occur.

Case 3 will occur - that's the "nominal case."  By "non-auth" I meant to
imply a recursive server that isn't authoritative for the answer.

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

I think that relying on the AD bit alone is not sufficient.  A true
resolver should have logic that accepts AD or AA bit with TSIG as "as good
as I'm gonna get."  (This is why I want to know that the AXFR [if any]
wasn't vulnerable to a simple attack.)

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

The arguement against this is the time it takes.  But I would like to have
the option in some "strict policy" applications.

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

I wouldn't jump on the no-recursive on an authoritative bandwagon.  I think
it is reasonable to be authortitative and recurse for just the local stubs
(whether by physical interface or key).  Heck, I'd even be willing to acl
via (untrustworty) IP address in this instance.

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

I couldn't see .com's zone transfers working this way, but perhaps
super-secret.mil's transfers would like this.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: [phone]                      Email: [e-mail]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.




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