[dnstap] dnstap with auth/recursive servers

[Evan Hunt]

On Fri, Sep 11, 2015 at 09:21:51PM -0400, Robert Edmonds wrote:
> There isn't a really good reason to enforce that the query and its
> corresponding response be "paired" in terms of Message.Type values
> (other than symmetry, I guess).  Adopting Joe's "message_tag" proposal
> might make it slightly easier to locate a query/response pair from a
> dnstap log.

Fair point, but if I've configured dnstap to log AUTH traffic but not
CLIENT, or vice versa, then we might end up logging some AUTH responses
and leaving out the corresponding queries, which seems nonoptimal.

Hmmm.  On the other hand, I *could* make this problem go away by not
allowing such a configuration.  If logging CLIENT automatically
includes AUTH, I doubt very many people would be disappointed.
(I suspect the same would be true if I had RESOLVER automatically
include FORWARDER, for that matter...)

> How "malleable" is the runtime configuration of BIND with regard to
> whether authoritative, recursive, or mixed mode service is being
> provided?  (IIRC, weren't there some rndc "addzone" and "delzone"
> commands added at some point?)

Yes. And even without addzone/delzone, a server could be reconfigured
to add zones any time.

> Your hypothetical here is a server that's been configured for mixed-mode
> service.  What about the other two cases, where a server is configured
> only for recursive service, or only for authoritative service?  Is there
> a global variable that indicates whether the server has been configured
> for recursive-only vs authoritative-only service?  (That is, is it
> straight forward for BIND to make good use of the AUTH_QUERY and
> CLIENT_QUERY values when it's not running in mixed mode?)

Basically, you can't trust a recursive server not to have any authoritative
data -- if nothing else, most of them have built-in empty zones for RFC1918
reverse lookups.

However, you can configure a server to refuse recursion and cache lookups,
in which case all traffic (except as permitted by the relevant ACLs) would
be authoritative, and AUTH_QUERY would always be appropriate.

> I think we should try to accurately classify the response messages (AR
> vs QR) according to how they're actually processed in the server, and
> not based on what the query header bits look like.  So I think I'm
> leaning towards recommending postponing AQ/CQ logging until you know A
> vs C, or possibly introducing an indeterminate "QUERY" type that just
> represents a generic query received by a responder.

Hm, that's promising. There's no difference in content (other than
message type) between AUTH QUERY and CLIENT QUERY anyway, is there?

Another thought, though, is that the AUTH_RESPONSE could have the
same DataSource enum I suggested for CLIENT_RESPONSE, and then we'd
be able to see if an RD=0 query was answered via cache snooping.

> Is that a replacement for the original CacheStatus enum in the message
> you reference?  Where did the "cache miss" value go?

I renamed it "recursion" because "cache miss" isn't a data source.

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.