[dns-operations] dnstap/duplicate query-ids?

[Jared Mauch]

> On Mar 27, 2016, at 9:29 PM, Robert Edmonds <edmonds at mycre.ws> wrote:
> 
> Jared Mauch wrote:
>> While looking at some data on a new host w/ DNSTAP w/ bind, I’ve noticed some interesting data regarding query-id recycling.
>> 
>> Has anyone done recent research on this?
>> 
>> 27-Mar-2016 20:06:56.793 AQ 78.47.119.231 UDP 40b PROTRuCK.ro/IN/AAAA
>> 27-Mar-2016 20:06:56.793 AR 78.47.119.231 UDP 40b PROTRuCK.ro/IN/AAAA
>> 27-Mar-2016 20:06:56.929 AQ 78.47.119.231 UDP 40b pROTRuck.Ro/IN/AAAA
>> 27-Mar-2016 20:06:56.929 AR 78.47.119.231 UDP 40b pROTRuck.Ro/IN/AAAA
>> 
>> Just a quick peek, I see these:
>> 
>> count   T/U query-id 
>>   4898 UDP 53b
>>   5371 UDP 43b
>>   5825 UDP 44b
>>   8342 UDP 31b
>>  11186 UDP 48b
>>  11588 UDP 45b
>>  43088 UDP 59b
>>  46178 UDP 46b
>>  90410 UDP 42b
> 
> Hi, Jared:
> 
> I think you're actually looking at the message length (e.g. 40 bytes),
> not the query ID.
> 

These tools are really poorly documented, and the unix socket support
stuff isn’t great either.. eg: dnstap{ resolve response; }; passes
named-checkconf but only logs queries.

None of the dnstap items made it to the named.conf man page but
are in the other code.

I am specifically asking because I’ve seen a situation where the
same QUERY_ID is played at a server with 3-5 packets per second
with the name QTYPE && QNAME as well from the same IP/PORT combo,
so suspected that was happening here.

We’ve also been playing with the SIE sensor stuff but that’s not been
flexible to solve the specific deployment issues we have.

I’m trying to see if I can make the DNSTAP stuff work, but it seems
to only write to a unix socket if something else creates it
and isn’t self-compatible with dnstap-read to just stream data
from the unix socket.

Trying to get less e-mail these days, but I guess I should take some
of these over to bind-users.  May be seeing zebras where they don’t
exist.

- Jared