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

[Petr Špaček]

On 5.10.2017 18:50, George Michaelson wrote:
> what ratio? what % of total unique IPs seen per sample interval?

I believe that it is irrelevant, the number of RFC 8145 clients in
previous e-mail represent detail of single data point in presentation
https://indico.dns-oarc.net/event/27/session/1/contribution/11

Moreover, most of the clients here are likely not recursives but stubs.

Anyway, here are number of unique IP addresses per day:

  82409 2017-08-31
 111806 2017-09-01
  12085 2017-09-02
  48486 2017-09-03
 128731 2017-09-04
 189340 2017-09-05
 110486 2017-09-06
  12731 2017-09-07
  12393 2017-09-08
  11469 2017-09-09
  11738 2017-09-10
  12677 2017-09-11
  12677 2017-09-12
  83320 2017-09-13
 115391 2017-09-14
  23320 2017-09-15
  13264 2017-09-16
  11932 2017-09-17
  13006 2017-09-18
  28351 2017-09-19
  13048 2017-09-20
  12976 2017-09-21
  15709 2017-09-22
  12875 2017-09-23
  15717 2017-09-24
  14438 2017-09-25
  16015 2017-09-26
  15414 2017-09-27
  14075 2017-09-28
  16337 2017-09-29
  11125 2017-09-30

My hypothesis for high variations is:
DDoS attacks trying to use the resolver as amplifier.

Petr Špaček  @  CZ.NIC


> 
> On Thu, Oct 5, 2017 at 9:17 AM, 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.