[dns-operations] A quick question for my peers re: 'dnscap'

Jake Zack jake.zack at cira.ca
Fri Feb 2 19:12:40 UTC 2018

Hey all,

I'm looking to make the switch from 'tcpdump' to 'dnscap' for this years DITL.

However, because we're now hosting several TLD's and not just .CA, I need to avoid submitting data for customer TLD's.

It *looks* like this should be possible with 'dnscap', but it doesn't seem to work in practice using either version 1.0 or version 1.7.1 (latest as per DNS-OARC website).
I am in by no way ruling out that I'm doing something wrong here, and/or misinterpreting the documentation.

The DNS-OARC DITL script "capture-dnscap.sh" says:
# ** Destinations **
# If you want to select traffic directed to a specific address
# add it here

...which, when I run "capture-dnscap.sh", gives me a dnscap syntax as such:
Executing '/usr/local/bin/dnscap -t 600 -w ./col01.lhr.ca-servers.ca -m qun -i eth1 -z any.ca-servers.ca -s i -6 -T -f'

So it's utilizing the "-z" flag with my DESTINATIONS setting.  The 'dnscap' manual says:
     -z host     Capture only transactions having these responders.  Can be specified more than once to select multiple respon-
                 ders.  If a host name is used, then all of that host's addresses whether IPv4 or IPv6 are added to the recogni-
                 tion pattern.

However, when I attempt to verify that I'm not leaking customer data, I see:
[root at col01 scripts]# tcpdump -nr /tmp/col01.lhr.ca-servers.ca.20180202.185721.945211 not host and not host 2001:500:A7::2 |grep |head -5
reading from file /tmp/col01.lhr.ca-servers.ca.20180202.185721.945211, link-type RAW (Raw IP)
13:57:22.020123 IP > udp
13:57:22.058056 IP > udp
13:57:22.192434 IP > udp
13:57:22.281961 IP > udp
13:57:22.317448 IP > udp

If anyone can spot what I'm doing wrong, offer advice, and/or replicate my findings...please let me know.

Thanks all,
-Jacob Zack
DNS Architect - CIRA (.CA TLD)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180202/ddef977e/attachment.html>

More information about the dns-operations mailing list