[dns-operations] RFC 8145 section 5 queries hidden behind CZ.NIC public resolver

[Petr Špaček]

Oh well, what a trivial mistake!

I'm now runnning
tcpdump -nn -tt -r ... | fgrep -i '_ta-' | fgrep -i -v dlv > ta.log
but it will take dozen hours or so to generate the new log, the PCAP is
about 0.5 TB big.

Stay tuned.

-- 
Petr Špaček  @  CZ.NIC

On 5.10.2017 19:04, Roy Arends wrote:
> use ‘—ignore-case’ or ‘-i’ with fgrep please
> 
> Roy
> 
>> On 5 Oct 2017, at 17:17, Petr Špaček <petr.spacek at nic.cz> wrote:
>>
>> Hello list,
>>
>> during ICANN Root KSK Roll Discussion at DNS-OARC 27 meeting there was
>> an idea to look into data from resolvers to see how many clients is
>> hidden behind a particular resolver.
>>
>> This motivated me to look into anonymized PCAPs from CZ.NICs public
>> resolver running at IPs 217.31.204.130 and 2001:1488:800:400::130 to see
>> how many clients with RFC 8145 support is hidden behind this resolver.
>>
>> It turns out that not very much, and that all captured RFC 8145 section
>> 5 queries contain *both* root key ids (old + new).
>>
>> Here are number of unique IP addresses querying in any given day.
>>
>> 2017-08-31	2
>> 2017-09-01	3
>> 2017-09-02	1
>> 2017-09-03	5
>> 2017-09-04	5
>> 2017-09-05	6
>> 2017-09-06	4
>> 2017-09-07	6
>> 2017-09-08	4
>> 2017-09-09	4
>> 2017-09-10	3
>> 2017-09-11	1
>> 2017-09-12	5
>> 2017-09-13	6
>> 2017-09-14	5
>> 2017-09-15	8
>> 2017-09-16	4
>> 2017-09-17	6
>> 2017-09-18	4
>> 2017-09-19	4
>> 2017-09-20	7
>> 2017-09-21	5
>> 2017-09-22	5
>> 2017-09-23	4
>> 2017-09-24	2
>> 2017-09-25	5
>> 2017-09-26	3
>> 2017-09-27	4
>> 2017-09-28	3
>> 2017-09-29	5
>> 2017-09-30	6
>>
>> To generate this, I used following command:
>> tcpdump -nn -tt -r pcap | fgrep '_ta-' | fgrep -v dlv > ta.csv
>>
>> For postprocesing I decided to use LibreOffice which made easy to
>> convert UNIX timestamps to readable dates and then group results by date.
>>
>> Hints:
>> =<TIMESTAMP>/86400+25569 will give you number which can be directly
>> formated as date
>>
>> I hope this will encourage other operators to look into their data and
>> publish results as well.
>>
>> -- 
>> Petr Špaček  @  CZ.NIC
>>
>> P.S. I told to few people privately that there were none such queries
>> behind the resolver. This statement was incorrect because of a mistake
>> in data processing.