[dnstap] dnstap with auth/recursive servers

Evan Hunt each at isc.org
Fri Sep 11 20:37:14 UTC 2015


Greetings,

I'm working on a BIND implementation of dnstap (targeted for BIND 9.11.0,
early 2016), and have run into a problem.  How should I differentiate
between AUTH_{QUERY,RESPONSE} and CLIENT_{QUERY,RESPONSE} when the server
is configured to be both authoritative and recursive?

If a query arrives with RD=1, I can log it as a CQ, but then it might
be answered authoritatively, in which case I might log it as AR, but it
seems strange for the query and response to be unbalanced like that.

I could postpone logging the query until I've determined whether we have
an authoritative answer, but by that time I'd already be sending a
response, and AQ and AR messages would be emitted almost simultaneously.

It seems the best solution is would be to log all RD=1 queries as CQ and
their responses as CR, and all RD=0 queries as AQ and their responses as
AR, and to extend the CR message to indicate whether the response was
authoritative.

A suggestion was already made in
http://lists.redbarn.org/pipermail/dnstap/2015-February/000017.html
to extend the CR message to differentiate between cache hits and misses.
I'd like to piggyback on that suggestion, and propose this, to be added
as an optional field in the Message type.

        enum DataSource {
                // all data used to generate this response
                // are from local authoritative sources.
                AUTH_DATA = 1;

                // this response was generated from a 
                // cache of previously-sent whole DNS responses.
                MESSAGE_CACHE = 2;

                // this response was generated by consulting
                // a cache of DNS records, but without sending
                // iterative queries
                RECORD_CACHE = 3;

                // at least one iterative query was sent in
                // the construction of this response
                RECURSION = 4;
        };

Thoughts?

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


More information about the dnstap mailing list