[dnstap] dnstap.proto updates: "extra" field and STUB_* Message types

[Robert Edmonds]

I've just pushed two changes to the dnstap protobuf schema.  The first
is an "extra" field:

message Dnstap {
    [...]

    // Extra data for this payload.
    // This field can be used for adding an arbitrary byte-string annotation to
    // the payload. No encoding or interpretation is applied or enforced.
    optional bytes      extra = 3;

    [...]
}

This lets cooperating dnstap-using software add extra data to the
payload for which it would be inappropriate to extend the dnstap schema
to support.  General-purpose dnstap-enabled nameservers would ignore
this field.

The second change is the addition of STUB_QUERY and STUB_RESPONSE values
to the Message::Type enum.  This fills out the complete RFC 1035 section
2 diagram:

message Message {

    // There are eight types of "Message" defined that correspond to the
    // four arrows in the following diagram, slightly modified from RFC 1035
    // section 2:

    //    +---------+               +----------+           +--------+
    //    |         |     query     |          |   query   |        |
    //    | Stub    |-SQ--------CQ->| Recursive|-RQ----AQ->| Auth.  |
    //    | Resolver|               | Server   |           | Name   |
    //    |         |<-SR--------CR-|          |<-RR----AR-| Server |
    //    +---------+    response   |          |  response |        |
    //                              +----------+           +--------+

    // Each arrow has two Type values each, one for each "end" of each arrow,
    // because these are considered to be distinct events. Each end of each
    // arrow on the diagram above has been marked with a two-letter Type
    // mnemonic. Clockwise from upper left, these mnemonic values are:
    //
    //   SQ:        STUB_QUERY
    //   CQ:      CLIENT_QUERY
    //   RQ:    RESOLVER_QUERY
    //   AQ:        AUTH_QUERY
    //   AR:        AUTH_RESPONSE
    //   RR:    RESOLVER_RESPONSE
    //   CR:      CLIENT_RESPONSE
    //   SR:        STUB_RESPONSE

    [...]

    enum Type {
        [...]

        // STUB_QUERY is a DNS query message sent from a stub resolver to a DNS
        // server, from the perspective of the stub resolver.
        STUB_QUERY = 9;

        // STUB_RESPONSE is a DNS response message sent from a DNS server to a
        // stub resolver, from the perspective of the stub resolver.
        STUB_RESPONSE = 10;
    }

    [...]
}

Since this allows dnstap to support client-side query-initiating
software (dig, kdig, drill, dnsperf, etc.), I've updated references to
"DNS servers" and "nameservers" in the documentation to "DNS software".

The current version of the schema is here:
    https://github.com/dnstap/dnstap.pb/blob/master/dnstap.proto

-- 
Robert Edmonds
edmonds at isc.org