A longitudinal study of DNS traffic: Understanding current ... Zyl 2015 Msc.pdf · A thesis submitted in fulfilment of the requirements for the degree of MASTERS IN COMPUTER SCIENCE

A longitudinal study of DNS traffic: Understanding currentDNS practice and abuse

A thesis submitted in fulfilment of the requirements for the degree of

MASTERS IN COMPUTER SCIENCEof

RHODES UNIVERSITYby

Ignus van Zyl

December 2015

Abstract

This thesis examines a dataset spanning 21 months, containing 3,5 billion DNS packets. Traffic on TCP and UDP port 53, was captured on a production /24 IP block. The purpose of this thesis is twofold. The first is to create an understanding of current practice and behavior within the DNS infrastructure, the second to explore current threats faced by the DNS and the various systems that implement it. This is achieved by drawing on analysis and observations from the captured data. Aspects of the operation of DNS on the greater Internet are considered in this research with reference to the observed trends in the dataset, A thorough analysis of current DNS TTL implementation is made with respect to all response traffic, as well as sections looking at observed DNS TTL values for ,za domain replies and NX DOMAIN flagged replies. This thesis found that TTL values implemented are much lower than has been recommended in previous years, and that the TTL decrease is prevalent in most, but not all EE TTL implementation. With respect to the nature of DNS operations, this thesis also concerns itself with an analysis of the geoloeation of authoritative servers for local (,za) domains, and offers further observations towards the latency generated by the choice of authoritative server location for a given ,za domain. It was found that the majority of ,za domain authoritative servers are international, which results in latency generation that is multiple times greater than observed latencies for local authoritative servers. Further analysis is done with respect to NX DOM AIN behavior captured across the dataset. These findings outlined the cost of DNS miseonfiguration as well as highlighting instances of NXDOMAIN generation through malicious practice.

With respect to DNS abuses, original research with respect to long-term scanning generated as a result of amplification attack activity on the greater Internet is presented. Many instances of amplification domain scans were captured during the packet capture, and an attempt is made to correlate that activity temporally with known amplification attack reports. The final area that this thesis deals with is the relatively new field of Bitflipping and Bitsquatting, delivering results on bitflip detection and evaluation over the course of the entire dataset. The detection methodology is outlined, and the final results are compared to findings given in recent bitflip literature.

Acknowledgements

I would like to acknowledge the people and organizations that helped me realize the completion of this paper. My heartfelt thanks to Professor Barry Irwin for his guidance and support throughout the year, without which none of this would be possible, I would also like to acknowledge the staff of the Computer Science Department at Rhodes University for their support,

I thank my family for their support and love during my time at university, as it has allowed me to turn my full attention to my studies.

Many thanks to my colleagues, Kieren Hunt, Lauren Rudman, Alan Herbert and Sean Pennefather for their advice and insight given throughout the year.

Gratitude is also due to ISACA, whose scholarship allowed me to pursue my further studies.

Finally, my thanks go to Gareth Dwyer, whose love of Python is eclipsed only by his love of beer, memes and Dota 2, He has been a stalwart companion and true friend, and without him this thesis would not have been completed or proofread timeouslv.

This research makes use of GeoLite data created by Max.Mind.

1

Contents

1 Introduction 1

1.1 Problem S ta tem en t........................................................................................................... 1

1.1.1 Significance of Research ...................................................................................... 2

1.2 Research G o a ls .................................................................................................................. 3

1.2.1 O pera tion ............................................................................................................... 3

1.2.2 A b u s e ..................................................................................................................... 3

1.3 Research S c o p e .................................................................................................................. 4

1.3.1 Limits of R esea rch ............................................................................................... 4

1.4 Document Conventions..................................................................................................... 5

1.5 Document Structure ........................................................................................................ 5

2 Background and Literature Review 72.1 Technical C oncepts........................................................................................................... 7

2.1.1 Peap files ............................................................................................................... 7

2.1.2 Authoritative and Caching servers....................................................................... 8

2.1.3 DNS Time-to-live v a lu e s ...................................................................................... 8

2.1.4 Resource records .................................................................................................. 8

2.1.5 Network latency..................................................................................................... 8

2.1.6 Open resolvers ..................................................................................................... 9

2.1.7 DNS Blaekhole L i s t s ............................................................................................ 9

2.1.8 Bitflipping............................................................................................................... 9

2.2 DNS Threats ..................................................................................................................... 10

2.2.1 Historical DNS th re a ts ......................................................................................... 10

2.2.2 Cache poisoning..................................................................................................... 11

2.2.3 Amplification a ttack s............................................................................................ 11

ii

2.2.4 Fast-flux b o tn e ts .................................................................................................. 11

2.2.5 Bitsquatting............................................................................................................ 12

2.3 Related R esearch ............................................................................................................... 12

2.3.1 DNS Operations and P ra c tic e ............................................................................. 12

2.3.2 DNS Threats and A b u se ...................................................................................... 15

2.4 Chapter Summary ............................................................................................................ 19

3 Data and Data Processing 20

3.1 Data Collection..................................................................................................................... 20

3.2 Description of Tools............................................................................................................... 21

3.2.1 L ib tins........................................................................................................................ 21

3.2.2 Python ........................................................................................................................ 21

3.2.3 Maxmind Geoloeate D atabase .................................................................................22

3.2.4 IPv4 heatm ap ............................................................................................................ 22

3.2.5 fp in g ............................................................................................................................22

3.2.6 W ireshark.................................................................................................................. 22

3.3 Preprocessing.........................................................................................................................23

3.4 Overview of Dataset ............................................................................................................ 25

3.5 Observations of packet behavior across d a ta se t................................................................. 27

3.5.1 Traffic spike observed 10 February 2014.................................................................. 28

3.5.2 Shift in authoritative and caching packet presence for May - July 2015 . . . 28

3.6 Overview of Authoritative Dataset ....................................................................................30

3.7 Overview of Cache D ataset................................................................................................... 32

3.8 Overview of Amplification Dataset ....................................................................................35

3.9 Overview of NXdomain d a ta s e t ..........................................................................................36

3.10 Chapter Summary ............................................................................................................... 36

4 DNS Operations 38

4,1 Breakdown of DNS response TTLs .................................................................................... 38

4.1.1 Observed TTL frequency..........................................................................................38

4.1.2 Normalised TTL frequency.......................................................................................41

4.1.3 Normalised TTL frequency for resource records ..................................................42

4.1.4 0 TTL presence an a ly sis ..........................................................................................45

iii

4.1.4.1 Disposable Dom ains:.................................................................................45

4.1.4.2 Non-disposable 0 TTL presence................................................................ 45

4.2 Analysis on authoritative servers for ,za domains .............................................................47

4.2.1 Geoloeation of ,za authoritative servers................................................................. 47

4.2.2 Topology of ,za d o m ain s..........................................................................................49

4.2.3 Latency seen for ,za domains....................................................................................50

4.2.4 Domain breakdown...................................................................................................53

4.3 NX domain analysis............................................................................................................... 62

4.3.1 Observed NX TTLs and EEs .................................................................................62

4.3.2 Top Cache NX traffic................................................................................................64

4.3.2.1 Eesponses from 146,231,128,1 .............................................................. 65

4.3.2.2 Eesponse c lu s te r ....................................................................................... 66

4.3.2.3 Unexpected NX DOMAIN traffic seen at caching servers ..................... 67

4.3.3 Other NX traffic ...................................................................................................... 68

4.3.3.1 196 .x .x .l62 .................................................................................................68

4.3.3.2 ,su eeTLD tra ff ic ....................................................................................... 69

4.4 Chapter Summary ............................................................................................................... 70

5 DNS Abuse 725.1 DNS post-attack amplification scanning...............................................................................72

5.1.1 Eeported a t ta c k s ...................................................................................................... 73

5.1.2 Characteristics of captured s c a n s .......................................................................... 74

5.1.3 Temporal relation between scans and attacks......................................................... 75

5.1.4 Target spoofing......................................................................................................... 76

5.1.5 Case stud ies............................................................................................................... 77

5.1.5.1 October 2 0 1 3 ............................................................................................. 77

5.1.5.2 www.jrdga.info.......................................................................................... 78

5.1.5.3 defeon.org................................................................................................... 80

5.1.6 Bandwidth amplification factors of domain queries...............................................81

5.2 Bitflip analysis ...................................................................................................................... 82

5.2.1 Bitflip identification approach .................................................................................82

5.2.2 False positives and filtering ....................................................................................84

5.2.2.1 Domain n a m e s .......................................................................................... 84

IV

5.2.2.2 Use of DNS infrastructure....................................................................... 84

5.2.2.3 PTE queries .........................................................................................84

5.2.2.4 Further filtering........................................................................................... 85

5.3 Bitflip findings ..................................................................................................................... 85

5.3.1 Case insensitive nature of DNS ............................................................................. 85

5.3.2 Recorded IN-ADDR.ARPA flip s............................................................................. 86

5.3.2.1 Example Flips ........................................................................................... 86

5.3.2.2 Frequency of flips for IN-ADDR.ARPA queries ....................................87

5.3.3 Recorded b itf l ip s ...................................................................................................... 88

5.3.3.1 Possible T v p o s ........................................................................................... 88

5.3.3.2 Definite Bitflips........................................................................................... 89

5.3.4 Possible Bitsquats...................................................................................................... 89

5.4 Chapter Summary ............................................................................................................... 90

6 Conclusion 926.1 Reflection on g o a ls ............................................................................................................... 92

6.2 Key F in d in g s .........................................................................................................................93

6.2.1 Latency and its cost .........................................................................................93

6.2.2 Temporal relationship between amplification attacks and scan s...........................94

6.2.3 Confirmation of other Bitsquatting re se a rc h ......................................................... 94

6.3 Future w o rk ............................................................................................................................ 94

References 96

Appendices 102

V

List of Figures

2.1 Bitflip d ia g ra m .................................................................................................................. 10

2.2 Cumulative Distribution of TTL vlues for Random and Hot Servers (Wills andShang, 2000) ..................................................................................................................... 13

2.3 The cumulative distribution of TTLs of NS record returned by root servers, andthree record types, A, AAAA and NS, returned by other servers, (Gao et al, 2013) 14

3.1 Configuration of /24 IP block from which data was co llected .........................................21

3.2 Preprocessing method to create datasets for analysis........................................................ 233.3 Corrupted packet o u tp u t ...................................................................................................... 243.4 IPv4 Hilbert Curve of IP addresses in d a ta s e t ................................................................. 26

3.5 Time series of packets from 1 October 2013 to 31 August 2 0 1 5 ......................................273.6 Timeseries of packets captured for February 2 0 1 4 ........................................................... 283.7 IPv4 Hilbert Curve of client IP addresses in d a ta se t........................................................ 31

3.8 IPv4 Hilbert Curve of IP addresses in d a ta s e t ................................................................. 34

4.1 Top TTL changes over observed p e rio d ............................................................................. 394.2 Queries for se,ra.rules.mailshell.net domains during September 2 0 1 4 ..............................404.3 Geographic heatmap of authoritative server presence for February 2 0 1 5 ...................... 49

4.4 Geographic distribution observed for authoritative servers of .eo.za............................... 544.5 Geographic distribution observed for authoritative servers of .o rg .za ............................ 564.6 Geographic distribution observed for authoritative servers of .gov.za............................ 57

4.7 Geographic distribution observed for authoritative servers of .ae.za............................... 604.8 Geographic distribution observed for authoritative servers of other ,za domains . . . 61

5.1 Architecture of a distributed DNS s c a n ............................................................................. 735.2 Timeseries for October 2013 scans by domain ................................................................. 77

5.3 Timeseries of www.jrdga.info packets captured during March 2 0 1 4 ............................... 79

vi

List of Tables

2.1 Explanation of EEs (van Zyl et al, 2015) 8

2.2 Observed average amplification f a c to r s .......................................................................... 17

3.1 High level view of processed d a t a .......................................................................................25

3.2 Top 10 source IP blocks seen for April 2015 authoritative and caching datasets , , 29

3.3 Top 10 source IP blocks seen for May 2015 authoritative and caching datasets , , , 29

3.4 High level view of processed Authoritative d a t a .............................................................. 30

3.5 Top 10 source IP blocks seen for authoritative datasets July 2 0 1 4 ........................... 32

3.6 High level view of collected d a ta .................................................................................... 33



4.1 Normalised TTL frequency................................................................................................... 41

4.2 Normalised TTL frequency by resource record by month ...............................................43

4.3 Top 10 normalized frequent 0 TTL d o m a in s .................................................................... 46

4.4 Distribution of unique IP responses for ,za d o m ain s........................................................48

4.5 Top 5 /16 network topology seen in ,za dataset .............................................................. 50

4.6 Average latency observed for top geographical responders (m s ) ......................................51

4.7 Top 5 observed TTL and EEs for .eo.za .......................................................................... 55

4.8 Top 5 observed TTL and EEs for .o rg .za .......................................................................... 56

4.9 .gov.za domains using non-loeal authoritative servers .....................................................58

4.10 Top 5 observed TTL and EEs for .gov.za.......................................................................... 59

4.11 Top 5 observed TTL and EEs for .ae.za .......................................................................... 60

4.12 Top 5 observed TTL and EEs for other ,za dom ains........................................................62



vii

4.15 Domain extensions seen in DNSBL NX DOMAIN responses............................................65

4.16 Packet breakdown of 146,231,128,1 NX DOM AIN tra ffic ..................................................65

4.17 Packet clustering seen in February 2015..............................................................................66

4.18 Packet breakdown of ,su eeTLD cache tra ffic .................................................................... 67

4.19 Packet breakdown of 196,x,x,162 N.XDO.MAIN tra ff ic .....................................................69

4.20 Packet breakdown of ,su eeTLD traffic from other servers...............................................70

5.1 Captured amplification scans................................................................................................74

5.2 Seans recorded the day after attack was reported ........................................................... 75

5.3 Top monthly spoofed IP b eh av io u r....................................................................................76

5.4 IP characteristics of www.jrdga.info scans ....................................................................... 79

5.5 Number of packets received for defeon.org ....................................................................... 80

5.6 IP addresses scanning defeon.org domains ....................................................................... 81

5.7 Bandwidth amplification factor of queried domains ........................................................ 81

5.8 Permutations of PTE query domain extensions August 2 0 1 5 .........................................86

5.9 Flip frequency for IN-ADDR.ARPA p a c k e ts .................................................................... 87

5.10 Bitflipped domains as a result of ty p o s ............................................................................. 88

5.11 Bitflipped d o m ain s ............................................................................................................... 89

5.12 Bitflip seen in Bitsquatted dom ains....................................................................................90

A.l Dataset TTL frequency....................................................................................................... 104

A,2 Top 5 geoloeation distribution for .eo.za domains ......................................................... 104

A,3 Observed TTL and RRs for .eo.za dom ains......................................................................105

A,4 Top 5 geoloeation distribution for .org.za dom ains......................................................... 105

A,5 Observed TTL and RRs for .org.za d o m a in s .................................................................. 106

A,6 Top 5 geoloeation distribution for .gov.za dom ains......................................................... 106

A,7 Observed TTL and RRs for .gov.za d o m ain s.................................................................. 107

A,8 Top 5 geoloeation distribution for .ae.za domains ......................................................... 107

A,9 Observed TTL and RRs for .ae.za dom ains......................................................................108

A,10 Top 5 geoloeation distribution for .other za dom ains...................................................... 108

A, 11 Observed TTL and RRs for other .za dom ains............................................................... 109

A,12 Temporal relationship between attacks and scans October 2013....................................109

A,13 Temporal relationship between attacks and scans November 2013 110

viii

A. 14 Temporal relationship between attacks

A,15 Temporal relationship between attacks


A.17 Temporal relationship between attacks
















and scans December 2013

and scans January 2014 ,

and scans February 2014

and scans March 2014 , ,

and scans June 2014 , ,

and scans July 2014 , , ,

and scans August 2014 ,

and scans September 2014

and scans October 2014 ,

and scans November 2014

and scans December 2014

and scans January 2015 ,

and scans February 2015

and scans March 2015 , ,

and scans April 2015 , ,

and scans May 2015 , , ,

and scans June 2015 , ,

and scans July 2015 , , ,

and scans August 2015 ,

110

111

111

111

111

112

112

112

112

113

113

113

113

113

114

114

114

114

110

IX

Chapter 1

Introduction

This research focuses on data gathered around the usage and implementation of different aspects of the Domain Name System (DNS), with respect to current activity on the greater Internet, It will look at both legitimate and malicious usage of the Domain Name System within the scope of the collected and analyzed data. The data was collected using an IPv4 address block used for production purposes, and as such reflects interactions between existing end-hosts and the Domain Name System as implemented on the greater Internet,

This first chapter serves as an introduction to the thesis, as well as the research herein. The problems that resulted in the instantiation of the research will be discussed, as well as the perceived significance of the research. The goals of the research will be outlined, following which the scope and limitations of the research will be considered. The last area deals with the layout of the sections that are to follow, which will comprise the main body of the thesis.

1.1 Problem Statem ent

The following text outlines the problems that prompted this research, as well as a motivation for the significance of this research in the current field of Computer Seienee,

The development of the Domain Name System came about as a result of previously existing name resolution services not being able to meet the needs of the growing network infrastructure that has developed into the modern Internet (Aitehison, 2005), DNS, as a result of its relationship with the Internet, is a dynamic system. The system experiences implementation changes and developments, as well as revisions to the aforementioned, as the requirements and functionality of the Internet and its connected end-hosts evolve. The various DNS infrastructures and capabilities of the current era are far removed in both scope and ability from the domain name system that was created to replace the Name Servers that came before them. Unfortunately, many of the principle documents outlining DNS infrastructure and implementation are archaic (Lottor, 1987;

1

Mockapetris, 1987a,b), yet still form the core of DNS documentation despite revisions. This would suggest that while there have been reactive actions taken to improve and utilize DNS in the modern era, there has been less consideration than necessary on how it will be affected by current Internet usage and implementation.

The distributed and fluctuating nature of the Internet and its end-hosts has enshrined DNS as an indispensable tool for network maintenance and usability (Moore and Edelman, 2010), With DNS becoming an integral part of the functioning of the Internet, it sees both legitimate and malicious usage on a large scale, in many different forms. This creates multiple opportunities for research within the field of Information Security, each of which touches on multiple disciplines within the field.

1.1.1 Significance of Research

The Domain Name System is one of the commonly used infrastructures that allow for the existence of the Internet as we know it (Agten et al, 2015), Research in this area touches on multiple aspects, including but not limited to: Network configuration and usage, Network and server optimization, Network and end-host security, End-user experience, as well as different implementations of DNS and the threats generated by those implementations. The fact that research in this area contributes to so many disciplines is important with respect to the advancement of research within those disciplines, as well as Computer Science as a whole.

There is of course a plethora of research with respect to aspects of DNS, most notably in the fields of system optimization from a computational perspective, and also previous and existing threats that come about as a result of DNS implementation, configuration or usage. This research, however, also endeavors to analyze legitimate traffic and DNS configurations, of which there is a surprising lack. That is not to say that there is no work on current observable DNS traffic, merely that there is not much research that gives consideration to the normal DNS traffic that is generated through Internet usage. This research also delivers findings on the relatively new research platform of Bitflipping (Dinaburg, 2011), in the hope that it contributes to the sparse but growing collection of research on the subject.

This research will also attempt to give a South African perspective on certain aspects of DNS infrastructure and its configuration, in an attempt to make the findings of this thesis more relevant to local researchers and organizations.

Earlier findings on DNS TTL analysis using this dataset were published in the SATNAC 2015 proceedings (van Zyl et al, 2015), which indicates that there is interest in this area of research.

2

1.2 Research Goals

There are two key aims of this research,

1.2.1 Operation

The first is to understand the ways that legitimate network entities are using the DNS infrastructure and its capabilities. This allows us to see how normal users are interacting with the infrastructure, as well as allowing us to understand how the expectations of end-users have changed with respect to DNS over the years. The two main focuses of this area will be:

• DNS TTL analysis

• DNS authoritative server geoloeation and latency for .za domains

These areas will hopefully give the reader an understanding of some of the DNS implementation and configuration choices made by entities on the Internet, as well as shedding some light on current DNS practices,

1.2.2 Abuse

The second is to observe instances where DNS is being used outside of the scope of legitimate traffic, in order to better understand threats that are generated through the use and abuse of DNS and its sub-protocols. These fall into the following two categories, which were observed in the captured dataset:

• Post-attack DNS amplification scanning

• DNS NXDOMAIN analysis

The NXDOMAIN analysis, section 4,3, is interesting as it touches on both the fields of DNS operations/praetiee as well as possible malicious DNS use/abuse. The Post-attack scanning study, section 5,1, deals solely with DNS abuse, but makes reference to the specific infrastructures unique to DNS that make this abuse possible.

The final area of research combines the above two areas, as it has significant research value for both the legitimate and malicious spheres of DNS usage, and will be comprised of:

• Bitflipping and Bitsquatting presence in DNS

Section 5,2 explores the presence of bitflips as well as bitsquats captured in the dataset. It offers analysis on a new field of computer science, and looks specifically at examples of abuse through Bitsquatting,

3

1.3 Research Scope

The scope of this thesis is defined here to give a more definite context for the research presented in the following chapters. It is an important factor in not only understanding what research was possible, but also why some avenues of research were considered over others.

The dataset was made available under the condition that the source of the data was not revealed. This means that certain analysis could not be reported upon, as doing so would enable the identification of the source of the data. An example of this is NXDOMAIN analysis conducted on packets seen at the authoritative server, which were later removed from the thesis.

Malformed or mangled DNS packets were filtered out. The thesis does not concern itself with packet preservation or mangling, and as such this was considered out of scope,

A number of known miseonhguration errors were also filtered out of the dataset, as they generated millions of identical packets which did not offer opportunities for further analysis.

The scope of the research is also limited by the actual packets that were captured by the network monitor. As such there are many avenues of DNS related network activity that could not be reported on, for example amplification attacks, more specifically response packet baekseatter; this was simply because there were no packets of that nature captured in the dataset,

1.3.1 Limits of Research

The first and most important limit of this research is the nature of the IPv4 block from which the data is gathered. Analysis on domains, TTLs, observed server latencies etc, will only be on domains or IPs that have interacted with the authoritative and caching servers as a result of their common usage within the IP block. As such, this thesis will not be able to deliver a holistic interpretation of current DNS activity and implementation, and can only concern itself with the traffic that made itself known to the IP block during the time of data-gathering. This is not to say that there is a lack of data from which research can be generated, but only that the research will not be able to give a representation of DNS activity for certain spheres of the Internet, For instance, since this IP block is geographically located in South Africa, it is more likely that captured traffic will be in English, and target common western and ,za domains. This also means that there will be little to no captured traffic for domains specific to Malaysia, for example. It also means that the likelihood of capturing packets using other character sets (e.g. Traditional Chinese) is also very low. It is also difficult to obtain data of this nature, creating another limitation with respect to research.

Another limit of this research is the fact that, while the dataset captured scans for possible DNS amplification attacks, there was no actual DDoS attack captured on the dataset, as none of the 256 IP addresses were the target of such a DDoS attack (Eossow, 2014), As such the research

4

relies on a third party1, which reports DNS amplification attacks observed by an open resolver, as a validation of post-attack scanning behavior observed in the dataset,

1.4 Docum ent Conventions

This section introduces some of the formatting and presentation conventions followed throughout the document, and seen in subsequent chapters.

Footnotes are used to indicate where tools used in this research can be accessed or downloaded.

All decimal values have been rounded to the 3rd decimal point.

All numbers split after every three digits for legibility.

All domain names italicized. All organization names in bold font.

All countries given in ISO 3166-1 alpha-2 format unless whole name is given; e.g, UK, ZA, US,

The minus symbol (-) appearing in tables indicates that there was no relevant data captured during that period.

Where figures or tables have not been referenced, they were created by the researchers themselves.

1.5 Docum ent Structure

The document consists of six chapters, of which this is the first. Chapters two and three serve the purpose of contextualizing the findings of the thesis. Chapters four and five report on the analysis and findings of the thesis itself, while chapter six holds concluding remarks. The remainder of this document is structured as follows:

Chapter 2 gives an introduction to the technical concepts covered in the paper, discuss threats to DNS systems, as well as present a review of the relevant literature in the areas pertaining to this thesis.

Chapter 3 discusses the origin and processing of the dataset itself, as well as supplying heuristics on the data captured.

Chapter 4 focuses on DNS Operations, and delivers analysis on three areas, observed DNS TTL values; observed DNS latency and geoloeation for authoritative servers of .za domains; and an analysis of NXDOMAIN traffic,

1 http://dnsamplificationattacks. blogspot. eo.za

5

http://dnsamplificationattacks

Chapter 5 looks at DNS abuse, with sections on captured amplification scanning traffic; and gives an architecture for possible bitflip detection and the results of bitflipping and bitsquatting analysis.

Chapter 6 forms the conclusion of the thesis, and gives suggestions for future work in the area of DNS analysis.

6

Chapter 2

Background and Literature Review

This chapter is split into multiple sections, all of which are meant to familiarize the reader with the concepts present in the held of DNS analysis, as well as give the reader a broader understanding of the terms and concepts that will appear throughout the paper. Section 2,1 deals with some of the DNS specific jargon that will appear throughout the thesis. Section 2,2 discusses the various threats to DNS infrastructure and stability. Of these, two are covered extensively in the thesis. Past and current research is presented in section 2,3, Interesting concepts or analysis identified in specific sub-Helds of DNS research are discussed in order to give the reader a more complete understanding of past and current research.

2.1 Technical Concepts

This section gives a simple explanation of some of the jargon that is seen throughout the thesis, and discusses how these concepts relate to the thesis itself,

2.1.1 Pcap files

Packet capture (pcap) hies are datasets created by recording packet information across a connection using a passive network monitor (Williamson, 2001), The network monitor reads, or ’sniffs’, packets that travel through the connection it is monitoring, but the monitor does not create or alter packets in any way (Williamson, 2001) - it merely reads and records them. The initial datasets of the thesis, before processing, were in pcap1 format,

1http://www. tcpdump.org/

7

http://www

2.1.2 Authoritative and Caching servers

Authoritative servers are servers that only provide responses for zones for which the server is either a zone master or a zone slave, and does not allow for recursive queries (Aitehison, 2005), Apart from the zone records for which they are responsible, they do not store or communicate any other records. Caching servers are name servers that provide recursive query support to end-hosts and save responses in the local DNS cache memory (Aitehison, 2005),

2.1.3 DNS Time-to-live values

Records stored in the caching resolver memory have a 32 bit unsigned integer value called the time-to-live (TTL) value (van Zyl et al, 2015), Each resource record has a TTL value set by the administrator of the DNS domain, which tells the caching resolver how long the cached record should remain in memory, in seconds (van Zyl et al, 2015), Once the TTL expires, the caching server will stop replying to queries with the cached response and query the authoritative server for an updated record (Aitehison, 2005),

2.1.4 Resource records

Resource records (RR) define certain characteristics or properties contained within the domain (Aitehison, 2005), Table 2,1 describes the functions of RRs that appear throughout the thesis.

Table 2,1: Explanation of RRs (van Zyl et al, 2015)

Resource record DescriptionA record Returns the IPv4 address for a host of the domain

PTR record Returns reverse-mapped domain name of IP addressCNAME record Returns an alias for an existing host given by an A RR

TXT record Returns generic text associated with domainMX record Returns the mail servers for the domain

AAAA record Returns forward mapping of IPv6 hosts as A does for IPv4NS record Returns the authoritative name servers for the domain

SO A record Returns the key eharaeteristies and attributes for the domainSRV record Allows for discovery of services provided by host

2.1.5 Network latency

Network latency forms part of the overall latency experienced by users, i.e, the amount of time between them requesting the content and content delivery, on the Internet, Various factors come

8

into play within network latency. The first is propagation delay, which is the delay generated by the distance the packets have to travel to reach the destination (Padmanabhan and Mogul, 1996), DNS-based latency, (or name resolution latency), is the latency generated by the DNS resolution process during the overall network interaction (Jung et al, 2002), The latency values given in this thesis refer to the latency generated through contacting the authoritative servers of .za domains,

2.1.6 Open resolvers

Open resolvers are public DNS resolvers that serve recursive name lookups to any client that contacts it with a DNS query (Eossow, 2014), This means that the server will respond to queries from any host on the Internet, As such, open resolvers are used as ’reflectors’, allowing attackers to spoof an IP address and inundate the target IP with packets from open resolvers in different subnet blocks, effectively launching a DDoS attack (Paxson, 2001),

2.1.7 DNS Blackhole Lists

DNS blackhole lists (DNSBL), or Real-time Blackhole lists, are databases containing IP addresses and/or domain names which have been identified as spam sources, and can be queried. Queries will return that the IP address or domain is in the blackhole list, and should thus be filtered or marked, or respond that the queried value is not in the list (Miszalska et al, 2007), Right-hand- side blackhole lists are a subset of DNSBLs that contain lists of spam email TLDs, The name comes from the fact that the right hand side, i.e, after the @ sign, of the email address is validated (Miszalska et al, 2007),

2.1.8 Bitflipping

Bitflipping is the oeeurrenee of random errors, as a result of software or hardware malfunction, radiation or environmental factors, that manifests as the corruption of one or more bits of the data (Dinaburg, 2011), Figure 2,1 illustrates a possible bitflip. The ’n’ character is sent to be stored in memory, and has the ascii binary value 01101110, However, the one of the bits in memory becomes corrupted, resulting in the value 01101111, or ’o’.

9

While most bitflips do not have an impact on host activity, some bitflips create opportunities for malicious entities to gain information about or to attack end-hosts, as a result of the corrupted information being web-facing (Dinaburg, 2011),

2.2 D N S Threats

This section highlights some of the methods that malicious entities use, with respect to the DXS infrastructure, to launch or control illegitimate web activity. It covers historic DXS abuses, and also discusses some of the current threats faced by DXS implementations,

2.2.1 Historical DNS threats

A number of different methods of domain squatting have manifested themselves throughout the years.

One of the main functions of DXS is the resolution of domains to IP addresses (Aitehison, 2005), so it comes as little surprise that this functionality is targeted and abused. The first form of squatting was the aggressive registering of domains that others might want to use, and then selling these to organizations or persons that are interested in acquiring the domain, a process known as cybersquatting (Moore and Edelman, 2010), Typosquatting, the practice of registering mistyped popular domains, began as a practice in 1999 (Moore and Edelman, 2010), Typosquatting relies on the fact that users make mistakes when typing the domain (Agten et al, 2015), which will then resolve to the squatter host instead of the intended host,

Soundsquatting is a variation on typosquatting, where the incorrect part of the domain will be a homophone of the correct domain (Xikiforakis et al, 2014), An example of this would be textsale.ru

10

(legitimate domain) and textsail.ru (soundsquatted domain) (Nikiforakis et al, 2014), where the incorrect user input will direct users to the squatted site instead of the legitimate content server.

Homograph attacks form another subset of squatting activity. Attackers will register domains that render similarly if not identically to legitimate domains (Holgers et al, 2006). This form of squatting differs from others as it does not rely on the target host to mistype the domain, but rather relies on their lack of ability to distinguish between legitimate and homograph domains that are presented to them, prompting them to click on potentially malicious hyperlinks (Holgers et al, 2006).

2.2.2 Cache poisoning

Cache poisoning is the act of changing or adding records to a resolver’s cache, either on the client or server side, with the result of a DNS query for that domain returning the address to the attacker’s domain instead of the legitimate address (Olzak, 2006). Cache poisoning attacks are carried out by querying for a legitimate domain, and then sending crafted responses, attempting to match the transaction ID of the query, in order to feed the caching resolver a malicious record (Olzak, 2006). Four large threats that face end-users are identity theft, distribution of malware, dissemination of false information and man-in-the-middle attacks, launched through the webpage that is served to the target host as a result of the poisoned record (Olzak, 2006).

2.2.3 Amplification attacks

An amplification attack is a DDoS attack that relies on the use of reflectors to generate large responses to small packets, pointed at the target host through IP spoofing (Paxson, 2001). DNS attacks, specifically, will abuse the fact that response packets can contain more data than query packets, particularly for ANY replies (Faehkha et al, 2014) or EDNS0 enabled resolvers (Eossow, 2014), which generate responses sometimes orders of magnitude larger than the original query. DNS amplification attacks are commonly launched using open resolvers, as they accept and reply to queries from any source.

2.2.4 Fast-flux botnets

Service availability is a concern faced by both legitimate and malicious enterprises on the Internet (Nazario and Holz, 2008). Botmasters have been known to use dynamic DNS to ensure that bots can reach one of a number of Command and Control (C&C) hosts if the original one is taken down (Choi et al, 2007). Attackers have taken this a step further by using fast-flux botnets, for which domain mappings are changed frequently to one or more of the controlled bots, which then act

11

as a proxy for the C&C, relaying content between the botnet end-point and the malicious server (Nazario and Holz, 2008), This makes it significantly more difficult to block or request a takedown of the malicious service in question (Nazario and Holz, 2008),

2.2.5 Bitsquatting

Bitsquatting is a relatively new form of domain squatting identified by Dinaburg (2011), Bitsquatting relies on a DNS domain in memory experiencing a bitflip, which then leads to incorrect resolution of the domain through DNS (Dinaburg, 2011), Malicious entities will register domains that differ from popular domains by one bit, while still remaining a valid DNS domain, in an attempt to take advantage of the traffic routed to their servers as a result of bitflipping (Nikiforakis et al, 2013).

2.3 R elated Research

This section presents research that is relevant to the material seen in the thesis. The research is grouped into two main areas, DNS Operations and Practice and DNS Threats and Abuse. The former looks at the sphere of legitimate DNS use while the latter concerns itself with possibly malicious DNS activity,

2.3.1 DNS Operations and Practice

One of the first papers to deliver analysis on DNS traffic, ’An Analysis of Wide-Area Name Server Traffic’ utilizes two 24-hour traffic traces to explore the performance of DNS on the network. It considers a variety of performance issues related to DNS traffic, some of which are still extremely relevant today. Three performance issues that were identified are Caching, Retransmission Algorithms and “The net effect”, which is the generation of multiple queries as the result of the queried servers or their respective root servers being unreachable for a period of time (Danzig et al, 1992), While this thesis does not concern itself with retransmission algorithms, both of the other issues were identified as important effectors of DNS traffic generation and bandwidth consumption. It was found that a large amount of DNS traffic was generated as a result of incorrect configuration of DNS domains and their related Resource Records, as well as miseonfiguration with respect to the servers themselves (Danzig et al, 1992), It was also noted that RPC timeouts and Cache leaks were a contributor to unnecessary traffic, a point that is confirmed in the TTL analysis section of this thesis, Danzig et al (1992) also noted that, as of late 1991, the DNS namespace consisted of 16 000 different domains and around 1 000 000 leaf nodes that represented individual end-hosts, which serves to put into perspective how vastly different its structure is today.

12

’The Contribution of DXS Lookup Costs to Web Object Retrieval’ looks at the lookup costs associated with DXS queries on a network. The analysis considered DXS TTLs, their values, the effect TTLs have on traffic reduction and how DXS TTLs related to overall DXS performance. The first statement was that raising TTL times would result in a higher cache hit-rate, i.e, more packets served a cached reply from the cache server (Wills and Shang, 2000), This is as a result of the records remaining live in the cache server longer and are as such able to serve more queries per cached record. The found that only 10% of records changed as their TTL record expired in the cache on a per server basis. Overall, only around 20% of records were changing between timeouts, indicating that a vast number of DXS TTL values are set too low (Wills and Shang, 2000), The researchers claimed that setting a minimum TTL value of 15 minutes would noticeably improve cache hit-rates (Wills and Shang, 2000),

Figure 2,2: Cumulative Distribution of TTL vlues for Random and Hot Servers (Wills and Shang, 2000)

Figure 2,2 gives the cumulative distribution of TTL values seen for random and hot servers, A set of 100 popular, or hot, domains were compared to a set of 100 random domains. They found that, surprisingly, the popular domains had higher TTLs than random domains (Wills and Shang, 2000), While this analysis shows 20% of TTL values below the 10 minute mark, figure 2,3 shows a much lower TTL average thirteen years later.

An in-depth analysis on many aspects and behaviors of DXS traffic is delivered in ’An Empirical Reexamination of Global DXS Behavior’, as it attempts to build on and compare results from previous analyses regarding observed DXS traffic. Comparisons with past papers yield interesting results with respect to changes in the nature of DXS traffic, including query type frequency, query success rates, DXS TTL distribution and the presence of repeated DXS queries (Gao et al, 2013), Of particular interest is the comparison of TTL distribution with the previous work by Jung et al. (2002), mentioned above. This gives a comparative analysis of the evolution of DXS TTL practice relative to observed Resource Records, on which this thesis hopes to build. The TTL distribution

13

in this paper is given in Figure 2,3,

Figure 2,3: The cumulative distribution of TTLs of XS record returned by root servers, and three record types, A, AAAA and XS, returned by other servers, (Gao et al, 2013)

This paper noted that there was a marked decrease in TTL values, most notably for the A and AAAA resource records observed in the dataset, when compared to the results presented in Jung et al (2002), The increase in A and AAAA queries, as well as a decrease in PTR queries, was also noted when compared to previous research results. This paper provides invaluable findings with respect to TTL behavior that this thesis hopes to build on in the coming sections. Another important finding in this paper relates to the XXDOMAIX presence generated by Domain Xame System Black Lists (DXSBL), This comes about as a result of how the DXSBL are configured, where queries for domains that are not on the list return XXDOMAIX response packets instead of confirmation reply packets (Gao et al, 2013),

!A review of current DXS TTL practices5 is a preliminary paper to the TTL analysis present in this thesis. This research looks at DXS TTL configuration over a six month period between January and June 2014, The research found that there was a strong trend towards lower TTL settings, sacrificing bandwidth and query response speed in order to decrease reaction time to downed servers or enable faster server load balancing (van Zyl et al, 2015), It was noted that, while CDXs had the lowest TTL presence, other major web-based organizations such as Google and Facebook also tended to use TTL values far below those recommended (Lottor, 1987) in RFC 1033 (van Zyl et al, 2015),

A short but interesting paper, 5 An Exploration study into the location and routing of the most popular websites in South Africa5 is on the geoloeation of website hosting from a South African context. The authors geolocated web-hosters for the top 100 sites viewed from South Africa according to Alexa, and found that around 50% of the websites had locally hosted content; not including CDX content, for which the value remains unclear (Barnett and Ehlers, 2012), This study is also interesting as it notes the limitations of the MaxMind geoloeation database, specifically

14

suspected inaccuracies with respect to country bueketing(Barnett and Ehlers, 2012), which is used throughout this thesis as well. This paper explores web connectivity and international web configuration from a South African perspective, a theme that this thesis builds on.

In ’Speed Matters for Google Web Search’, ’Google conducted an experiment on the effect latency had on end-users perception of the web service. They created fake latency at the server-end of some connections, Google found that slowing down search results by between 100 ms and 400 ms caused searehes-per-user to decrease by between 0,2% and 0,6% (Brutlag, 2009), They found that user searches decreased further the longer they were exposed to the experiment. Users who had been exposed to a 200ms delay since the beginning of the experiment performed 0,22% fewer searches during the first three weeks, but 0,36% fewer in the following weeks. Similarly, those exposed to a 400ms delay did 0,44% fewer in the first three weeks, and 0,76% fewer thereafter (Brutlag, 2009), This seems to indicate that experienced latency has a large effect on end-user experience, and can affect user activity.

This research, ’An Empirical Study of Spam Traffic and the Use of DNS Black Lists’, was motivated by a large observed increase in DNSBL DNS traffic seen on MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) between 2000 and 2004, DNSBL traffic went from 0,4% of all DNS lookups in 2000 to 14,09% of all DNS lookups in 2014 (Jung and Sit, 2004), Three reasons were identified for the observed increase. The first was the marked increase in actual mail traffic to the servers, the second was that spamming hosts were relying on open relays and compromised client machines to deliver the spam instead of sending it directly from the origin machine. The third was the increase in DNSBL services available on the web in that period of time (Jung and Sit, 2004).

2.3.2 DNS Threats and Abuse

’Winning with DNS Failures: Strategies for Faster Botnet Detection’ proposes methodologies that utilize NXDOMAIN responses in order to rapidly detect the C&C for a fast-flux botnet. They found that botnets that automatically generated domains to try to reach the C&C would generate many NXDOMAIN replies in a short amount of time (Yadav and Reddy, 2012), Filtering of the data was divided into steps that generated metrics based on the source IP address. Domain entropy is then tested, where generated C&C domains should have a high entropy as they are a randomized distribution of alphanumeric characters (Yadav and Reddy, 2012), Using failure correlation was also suggested, where the entropy of failed domains is compared to successful query domains. The researchers also noted the presence of DNSBL queries, which triggered false positives when their methodology was used (Yadav and Reddy, 2012),

The paper ’An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks’ is one of the preliminary works on the ability of reflectors to generate Distributed Reflective Denial of Service

15

(DEDoS) attacks, and the subsequent threat this creates to network users. The paper discusses threats posed by TCP, UDP and ICMP services with respect to reflected attacks, but for the sake of relevance only their findings with respect to DNS will be discussed here. This paper also suggested possible defenses against reflected attacks, and an overview will also be given of those related to DNS DEDoS attacks,

DNS was identified as offering two possibilities for reflection. The first is for an attacker to spoof packets to DNS servers, which then inundate the victim with DNS replies, whose IP address is the address spoofed by the attacker (Paxson, 2001), Paxson suggests that this can be countered by filtering out packets that use port 53, the port assigned to DNS traffic (Mockapetris, 1987b), at the cost of impeding the access of the victim to DNS via external DNS services. This however can be mitigated by creating holes within the filter through which certain trusted DNS servers can be reached, restoring the victim’s DNS capabilities to a certain extent (Paxson, 2001), The second reflective attack is perpetuated using DNS servers that recursively query other servers to resolve requests (Paxson, 2001), This form of reflected attack targets name servers for specific zones, which allows attackers to stream queries to other name servers for the respective zone, which then creates a bombardment of recursive queries towards the target server. This can be further supplemented by spoofing the target server as the requester, ensuring that both queries and replies are used to DoS the victim, and was identified as an early form of amplification (Paxson, 2001), This paper proves the risks generated by reflected attacks, and the need to mitigate them. It also gives insights into the ways that the methods of using reflectors to perform DNS DEDoS attacks have changed over the years, especially when comparing it to more recent works such as Eossow (2014),A recent and very thorough work on the nature of amplification, ’Amplification Hell: Eevisiting Network Protocols for DDoS Abuse’ delivers research on the utilization of UDP-based network protocols in disrupting network activity and availability, through the use of DEDoS attacks. These DEDoS attacks are called reflective as the malicious entity uses a third-party infrastructure to launch the attacks against the victim, and does not directly attack the victim themselves. This paper also focuses on reflectors that allow the abuser to amplify the attack through the misuse of UDP protocols, of which DNS is one (Eossow, 2014), While this paper concerns itself with 14 seperate UDP protocols, the focus of this review will be on the results gathered with respect to DNS abuse, as these results are most relevant to the thesis. The data gathered for this paper comes from 130 real-world DEDoS attacks as well as scans captured across two darknets (Eossow, 2014), This paper noted that DNS is an interesting case with respect to amplification protocols, as the number of available amplifiers is known, unlike other protocol amplifiers. This comes about as a result of dedicated projects in existence that track the number of open resolvers that could be used to launch DNS DEDoS attacks. One of these is the Open Eesolver Project2, which has identified over 20 million unique-IP open resolvers currently active on the Internet, of which over 15 million

2http: / / openresolverproject.org/

16

respond to all queries, indicating that they pose a significant amplification threat (Mauch, 2013),

Two ways of evaluating the amplification factor of attacks were suggested in this paper, and are given below,B A F len(U D P payload) a m p lifier tov ictim P A F num ber o f packets a m plifier to victim

len(U D P payload) attacker to a m p lifier num ber o f packets attacker to a m plifier

BAF represents the bandwidth amplification factor of the attack while PAF represents the packet amplification factor of the attack (Eossow, 2014), Results on observed amplification factors are further broken down into three levels in the paper. These were the average observed amplification factors of the whole dataset, worst 50%, and worst 10% respectively. The results for DNS amplification are further broken down into ANY lookups at authoritative name servers (NS) and ANY lookups at open resolvers (OR), and are given in Table 2,2, As is seen, the DNS bandwidth amplification factor achieved by abusing name servers was 54,6 times the attacking packet on average, while the open resolver abuse resulted in an average bandwidth amplification of 28,7 times the attacking packet. The packet amplification was 2,08 times of the attacking packet for name servers and 1,32 times for open resolvers.

Table 2,2: Observed average amplification factors

ProtocolB A F P A F

All 50% 10% AllDNS (NS) 54.6 76.7 98.3 2.08DNS (OR) 28.7 41.2 64.1 1.32

This paper noted that most, if not all, of the observed queries attempting DRDoS attacks were ANY queries, which allow attackers to enforce high amplification rates , as resolving ANY queries for domains will result in large responses (Rossow, 2014), This research is relevant to the Post- attaek-ampliheation scanning research seen later in the thesis, as it not only gives a BAF and PAF baseline with which to compare observed results, but also notes various behavioral eharaeteristies of amplification packets that will aid in their identification within the dataset,

’Fingerprinting Internet DNS Amplification DDoS Activities’ is a study on using darknet packet captures to infer DDoS activity on the Internet, Traffic captured by a darknet is filtered for possible amplification packet traffic generated by attacks. Of this traffic, queries with the ANY RR set were found to make up the majority of possible amplification packets. It was stated that the increase in ANY traffic seen in darknet space over recent years could be as a result of an increase in amplification attack popularity (Faehkha et al, 2014), Of the domains captured, the most popular was Root, as attackers attempted to request a large amount of zone information to maximize packet amplification (Faehkha et al, 2014), Their analysis showed that DNS amplification attacks would sometimes vary and slow the attack rate to make the attack less detectable (Faehkha et al, 2014), This paper is one of the few examples of amplification attack inference using passive packet

17

collectionThe first published paper on the Bitsquatting, ’Bitsquatting: DNS Hijacking without Exploitation’ offers comprehensive analysis on the reasons for bitflips, analysis on captured bitflips and recommendations with respect to mitigating the threat presented by bitflips. The three main causes of observed bit-errors were identified as manufacturing defects and contamination; operating outside environmental tolerances and radiation (Dinaburg, 2011), Dinaburg also raises the issue that many manufacturers do not use error checking and correction (ECC) schemes in their hardware, including high-grade mobile devices. The occurrence of flipped bits in the RAM pose a serious security threat when the flipped bit occurs in the domain string, A flipped domain bit will lead to a connection being established with the possibly bitsquat domain, instead of the intended domain, allowing the domain owner to send phishing pages, browser exploits or executable scripts, or make other attempts at compromising the security of the end-host (Dinaburg, 2011), The bitflip analysis found that a high occurrence of queries for a single bitflip showed bit-errors at the responding server, while less frequent and more varied bitflips were usually indicative of end-hosts. The paper also found that certain operating systems were more prone to flipped bits than others, Dinaburg (2011) noted a smaller bitflip presence for Apple OS HTTP User-Agents while a larger number of Other OS HTTP User-Agent bitflips were recored; when compared to average OS User-Agent frequency for visits to Wikipedia, Other OS in this case refers to gaming console and mobile operating systems, as well as less common computer operating systems. The suggestions for bitsquatting mitigation were two-fold. The first was to register all possible bitflips of the domain intended for use, while the second was the adoption of integrity checks, such as Cyclic Redundancy Checks, and ECC Memory to decrease the chances of a bitflip error remaining undetected (Dinaburg, 2011),

The paper ’Bitsquatting: Exploiting Bit-flips for Fun, or Profit?’ was written in an attempt to discover if malicious entities were attempting to take advantage of the bitflip behavior reported in Dinaburg (2011), The researchers generated bitflipped domains for the Alexa top 500 domains3. They then performed varied analysis from the rate of bitflip site registration to the content served by bitsquatted sites. It was found that 40% of the bitflipped domains were owned by legitimate entities (Nikiforakis et al, 2013), For the most part, the domains were found to be owned by the same organization that owned the top domain investigated. Another 15% of the squatted domains were parked websites, i.e, domains run by domain-parking agencies which serve advertisements relevant to the domain name in order to encourage misdirected users to click on them for revenue (Nikiforakis et al, 2013), Other interesting domain behavior was also noted, 15% of the registered domains redirected to unrelated websites or the websites of competitors, a further 10% of domains listed as ’for sale’ on the domain itself, and 6,8% showed advertisements but were not affiliated with a domain-parking agency. Of the investigated domains, 3,2% were serving malware, either

3http://www. alexa.com/topsites

18

http://www

through the direct inclusion of malicious scripts, or indirectly through the advertising network present on the site (Nikiforakis et al, 2013), Four defenses against bitsquatting were suggested in this paper. Addressing the problem at the hardware level, through the implementation of CEC and ECC, is the suggested approach. Mitigating errors at the software level is also suggested through the use of the DNSSEC, TLS and/or SSL protocols (Nikiforakis et al, 2013), Another suggested approach is to remove the incentive of Bitsquatting, by implementing legal frameworks that restrict the activity of obviously squatted domains (Nikiforakis et al, 2013), The final option is for the owner of the legitimate domain to register all of the possible bitflips of the domain. It should be taken into consideration, however, that the most frequently resolved domains are more at threat than minor domains, as an increase in queries and responses for any given domain increases the likelihood of a domain being flipped (Nikiforakis et al, 2013), This in effect means that the only domain owners that should consider this defence are those that see enough traffic to mitigate the cost of flipped-domain registration.

2.4 Chapter Summary

This chapter has three main aims. The first was to introduce the reader to certain technical concepts that appear frequently in the thesis, and which need to be understood in order to gain meaning from the findings delivered in the rest of the paper. The most important of these are the following: Authoritative servers exist to serve records for which they are responsible, and will not serve other records. Caching servers will recursively query domains queried through them, unless the domain exists in the cache and has a live TTL, in which ease the cached record will form the response packet, DNS TTL values determine the length of time for which a record can remain in the local caching resolver’s memory before a new record has to be fetched. Bitflipping is the process by which one or more bits becomes corrupted in memory.

The second aim was to introduce the reader to some of the threats of abuse with respect to DNS, The two most relevant are amplification attacks, whereby attackers will spoof the IP of the target address and flood it with DNS responses larger than the query packets sent to reflectors, and bitsquatting, the targeted domain squatting of domains that differ from popular domains by one bit.

The third aim was to introduce the reader to some of the relevant literature in the field of DNS traffic and DNS threat analysis. The articles cover aspects of the areas discussed later in the thesis, including DNS TTL characteristics, the effects of latency, amplification attack behavior, and the prevalence of bitsquatting on the Internet,

19

Chapter 3

Data and Data Processing

This chapter discusses the source of the data on which this research is based, as well as an overview of the datasets on which analysis was performed. Data collection is covered in section 3,1, The tools used for data evaluation, analysis and visualization will be discussed, where they were not produced by the researchers themselves, in section 3,2, The preprocessing of the data is handled in section 3,3, followed by a high-level overview of the entire dataset in section 3,4, Section 3,5 discusses some cases of anomalous packet activity seen in the dataset. Sections 3,6 to 3,9 describe the subsets of data that have been isolated from the overall dataset.

3.1 D ata Collection

The dataset was collected from a production /24 IPv4 network block which is part of the 196/8 IPv4 network block. The data was gathered from the 1st of October 2013 to the 31st of August 2015, Between this period of time there is one gap within the dataset between April and June 2014, The data was collected by capturing traffic observed, either from or destined to all IP addresses within the /24 block, both TCP and UDP packets, across port 53, The IP block included two authoritative DNS servers and two caching DNS servers within the live end-hosts. Figure 3,1 illustrates the topology of the /24 IPv4 network from where data was gathered. The packet sniffer was connected to the Internet-facing port of the firewall, which was also connected to the /24 IP block. Two authoritative servers as well as two caching servers make up four of the end-hosts within the IP block. The captured packets were subsequently stored as pcap hies in a database.

20

Figure 3,1: Configuration of /24 IP block from which data was collected

3.2 Description of Tools

This section describes the various tools used both in the processing and analysis of the data that were taken from external sources,

3.2.1 Libtins

The C----libtins1 (Fontanini, 2015) library, a multiplatform network packet sniffing and craftinglibrary, was used for packet processing of the pcap files, Libtins was selected because of its efficient performance, an important consideration when dealing with large pcap files. Benchmark testing showed that libtins had a faster parsing speed than other well known packet libraries, including dpkt and seapy (Fontanini, 2015), The documentation available with respect to the libtins library also made it a more reasonable choice than libraries such as dpkt,

3.2.2 Python

Python was selected for three reasons as the core programming language. The first is that the language integrates extremely well with unix-based operating systems, on which the majority of this research was done. Python also offers an elegant and simple syntax that promotes code readability and user-friendliness (Sanner, 1999), Third, Python delivers excellent performance with regards

1 h ttp://libtins. github.io /'download /

21

http://libtins

to parsing, string manipulation and dictionary searches (Preehelt, 2000), which enable faster data processing and analysis during the research process,

3.2.3 Maxmind Geolocate Database

The Maxmind GeoLite databases maintained by Maxmind allow for the mapping of IPv4 addresses to the geographic positions of their end-hosts. It was used in this research in conjunction with the pvgeoip2 library, which is based on Maxmind’s GeoIP C API (Ennis, 2015), The GeoLite City database3 was used in this research,

3.2.4 IPv4 heatmap

The ipv4-heatmap package4 was created by the Measurement Factory, This allows the mapping of the one-dimensional IPv4 address space onto a two-dimensional image represented using a 12th order Hilbert curve (Irwin and Pilkington, 2008), Each pixel of the generated 4096x4096 image represents a single /24 network containing 256 hosts (The Measurement Factory, 2015),

3.2.5 fping

fping5 is a tool used for conducting ping sweeps to search for live hosts (Teo, 2000), fping was selected for its functionality, which allowed users to give fping a list of IP addresses instead of pinging each IP seperatelv, fping also allowed variables to be set regarding the number of pings that would be sent for each IP address given, which allows for a more comprehensive and accurate look at latency averages observed with respect to these IP addresses,

3.2.6 Wireshark

The e d it cap6 tool is a program designed to read some or all packets from a pcap hie, optionally converting or filtering them in various ways before writing the remaining packets to another pcap hie. The ed itcap to o l was used here to separate the captured pcap hies into monthly blocks. The mergecap7 tool is a program designed to merge multiple pcap hies into one, and was used to merge pcap hies containing different halves of a single month, after they had been hltered using editcap,

2https: / / pypi.python.org/pypi / pygeoip /3 http: / / dev.maxmind.com / geoip/legacy/geolite /4http: / / maps.measurement-factory.com / software/index.html5http://fping. org/6https://www.wireshark.org/docs/man-pages/editcap.html7https://www. wireshark.org/docs/man-pages/mergecap.html

2 2

http://fping

https://www.wireshark.org/docs/man-pages/editcap.html

https://www

The Wireshark8 packet inspection tool was also used to inspect packets to allow for more concrete analysis of the findings in this thesis.

3.3 Preprocessing

First editcap was used on the available pcap hies to separate the datasets into months, mergecap was used on datasets separated by editcap that had a month split between them in order to concatenate the dataset into monthly pcap hies; which were used for subsequent processing.

Figure 3,2: Preprocessing method to create datasets for analysis

Figure 3,2 gives a representation of the preprocessing carried out in order to create datasets for analysis. The monthly peaps were processed using libtins (Fontanini, 2015) to create comma separated value (CSV) data hies of the relevant peaps.

After this certain packets were filtered out. These packets were corrupted as a result of server miseonhguration or corruption during the routing process, which resulted in them being illegible and/or parsing incorrectly. Figure 3,3 shows example output generated by corrupt packets when parsed,

8 ht t ps: / / www. ■wireshark. org/

23

, 2 . in - ad d r. a rp a , RRSIG, 1 , , 3600, ©[fjf ♦5<T, ♦. [ffin - add r||rp a*D D ^ f CK-8*K*T$**« jiD»g»g»S5»»»4»t»[fl»E»«i4«-»[f]1v[f^4»»»Z»»: Pt ♦«Rv%[i|]y *<>«> ' ♦♦♦♦4*[UJ*Qv(l*U4««fi!x4>«><>: ♦] }*^f§K*«>0*

♦♦A* 3[fjj LW*^Y. ; 0*Z*Y

♦♦«dKC ♦♦♦B«[fflUf F X , ♦YN[?jt"2<»<»; ■ ,n*B*"*«W

_&j*Plli'*P _ __qRnoC«Jf§*zX)*y*«-*KHFi*«*[[§«[|f .♦b*Gy«-««, 37. in -a d d r . a rp a , DNSKEY, 1, ,3600,

'*«£**d*«I«<><>« -♦= l q»»«|||t)w »;i|f|j»A|ia«’»»*»ff«y»uV»<\*»<»Y»By«'<»<»<» s * p * ' ]«« 3 7 .in -a d d r .a rp a ,R R S IG ,1, ,3 6 0 0 ,aHfl»5%f[fSEHi7in-addrH|rpaz[fl»llfl1»qF3<> «>7*o«7*A[!|h«***«0[!|}«*e)«« y b |J

' b o» |;H D »» '»vD »»» |;If: »|i|j|)K»V=»r♦♦ 1 q«»Q »»|jj» |f j Y » | j f l ) (♦ r ♦♦[?K)♦<*<>«>«,43.6.66.in -a d d r . a r p a , DNSKEY,, 36 00 , [ f |4 3 .6 .6 6 . in - a d d r . a r p a , R R S IG , 1 , , 3600 , e ijf i* jB T o o B : N [ |l3 [ |J l | |6 in - a d d r [ f f rp a l* o 6 * B « * r< ^ |S _ [ !§ i j * i f { t»«

' bo»|;HD»»'»vD»»»|;If: »|i|j|)K»V=»r♦♦ 1 q«»Q»»|ij»|ijY»|jf l ) ( ♦ r ♦♦[?K)♦<*<>«>«,43.6.66.in -ad d r . a rp a , DNSKEY,, 3600, [f|43 .6 .6 6 . in - ad d r. a rp a , RRSIG, 1 , , 3600, eijfi* jBTooB: N [|l3[|Jl||6 in-addr[ff rp a l*o 6 *B « *r< ^ |S _[!§ i j * i f { t»«

' bo»|; HD»»'»vD»»»|; I f : »|i|j|)K»V=» r ♦♦ 1 q«»Q»»|ij»|ijY»|jf l ) (♦ r ♦♦[?K )♦<*<>«>«, 4 3 .6 .6 6 . in - addr . arpa .DNSKEY,, 3600, [f|43 .6 .6 6 . in - ad d r. a rp a , RRSIG, 1 , , 3600, eijfi* jBTooB: N [|l3[|Jl||6 in-addr[ff rp a l*o 6 *B « *r< ^ |S _[!§ i j * i f { t»«

| * ;* « [ ? } !l»»» c4» [!lH » [l»r«y»»*fD )K »q k\H l»[!18[!f|»f«»»"u}L»\c)N5[!llHS>»H»»6»mv»«»»»[!i»»q»»p[!ltx»I«»«»«i»v[fB

l»«||ib«»Mq»"»[iP1 [f?]=ac**3̂ S ♦*+̂ «**̂ {**v\**l'*T♦XHA,9 4 .in - a d d r . a rp a , DNSKEY, 1 ,,3 6 0 0 ,|5]94. in - a d d r . a rp a ,

RSIG , 1 , , 3 600 ,0Hfl*4»T»HHH^4in -addr[||rpay^*Y«.[f§ |fjk» ;tl»|fW jU

#f««.g*9[f} [fBx»»l}< *; Q /x *[flir n»»»»[fB»4[fi, ♦&!. »«U»»»»q[fl; »2 l»<>»a<.*a«G»n« a«*«s[?3 |«*nA 1 »v|JllI»»»»»»H M B___ y [|}U*«« | ♦♦=Ce*[|jj*A *̂<'*«><> | ««<><>

Figure 3.3: Corrupted packet output

There was also a known miseonfiguration error for IP 196,x,x,130, within the monitored range, which generated PTR queries directed at two IAXA black hole9 servers, which were also filtered from the dataset. IP fragments were also filtered from the datasets.

From here, the CSV hies were filtered using various characteristics to create data subsets. Filtering by source and destination IP address for the four servers resulted in the creation of authoritative and cache server datasets. These datasets were further filtered to create additional datasets comprised only of authoritative server responses, and responses received by cache servers. The responses to the cache servers were further filtered by domain to create a .za response dataset.

Filtering by identified amplification generated a dataset of known or suspected amplification attacks. This was followed by filtering for packets with the AXY RR hag set to remove false positives from the dataset. The subsequent research was performed using these monthly CSV data hies and their subsets.

The XXDOMAIX dataset was filtered at the pcap level using the command below:

tcpdump -n - r <input.cap> -w <o u tp u t. cap> "udp[ll] & Oxf = 3

9 The IAXA black hole servers exist to respond to reverse-lookup queries for IP addresses reserved by RFC 1918

24

where Oxf points to the part of the header that contains the error number space, and 3 is the ECODE for Non-Existent Domain (NXDOMAIN) failures (Eastlake, 2013), The resulting output was then processed into a CSV hie via libtins .

The various filtering processes, unless otherwise specified, were performed using tools developed in Pvthon,

3.4 Overview of D ataset

The dataset spans twenty two months between the period of October 2013 and August 2015, Table 3,1 gives information relating to the overall composition of the dataset. It should be noted that the dataset size (given in bytes) is a representation of the size of the pcap hies and includes packets that were hltered out as a result of miseonhguration, as mentioned in section 3,3, The number of packets however represents packets in the dataset post-filtering, and counts only the packets on which analysis was performed. The total number of packets on which analysis was performed is just under 3,5 billion, comprising some 578 GB of initial data.

Table 3,1: High level view of processed data

Month # of days % of hours # of packets % of total packets # of unique IPs Size (bytes) % of total bytesOctober 2013 31 100 137 792 142 3.940 136 461 23 808 353 832 4.116

November 2013 30 100 133 145 106 3.807 134 638 20 958 712 584 3.624December 2013 31 100 175 661 225 5.022 116 174 23 101 638 356 3.994.January 2014 31 100 236 963 425 6.775 127 704 31 622 040 972 5.468February 2014 28 100 155 029 695 4.432 160 289 31 351 807 424 5.421March 2014 31 100 408 824 999 11.689 164 629 54 340 269 380 9.396April 2014* 12 39.444 242 632 653 6.937 107 204 31 482 598 264 5.443May 2014* 3 6.586 2 392 107 0.068 31 243 355 478 064 0.061•June 2014* 25 80.972 111 205 783 3.179 129 837 18 151 581 540 3.139•July 2014 31 100 133 495 938 3.817 137 296 23 787 923 592 4.113

August 2014 31 100 94 691 272 2.707 128 793 15 292 726 124 2.644September 2014 30 100 155 549 492 4.447 136 745 24 801 018 752 4.288October 2014 31 100 171 123 957 4.893 162 515 29 751 124 984 5.144

November 2014 30 100 184 681 747 5.280 130 114 31 528 195 160 5.452December 2014 31 100 80 872 961 2.312 100 525 12 621 737 824 2.182January 2015 31 100 137 860 035 3.941 126 387 22 717 030 796 3.928February 2015 28 100 156 387 164 4.471 128 858 26 176 830 264 4.526March 2015 31 100 178 941 264 5.116 132 041 31 037 853 360 5.367April 2015 30 100 84 355 017 2.412 109 043 13 610 216 616 2.353May 2015 31 100 183 408 170 5.244 126 693 32 552 629 472 5.629June 2015 30 100 173 990 025 4.974 123 125 28 944 171 700 5.005July 2015 31 100 164 889 418 4.714 129 222 28 368 275 908 4.905

August 2015 31 100 127 261 293 3.638 112 586 21 954 632 708 3.769Total 625 14936 3 497 665 267 100 722 394 578 316 847 676 100

* datasets do not represent a complete monthly capture.

Most of the months in Table 3,1 are complete from 00:00:00 on the 1st to 23:59:59 on the last day of the month, as is indicated by the number of hours represented in each dataset. Exceptions to this are April, May and June of 2014, due to a gap in the available data. As a result of this, April

25

and May 2014 have been excluded from all analysis in order to not let incomplete datasets skew the results. After consideration, June 2014 was included as it was able to record days 6 through 30 in the dataset, and is considered mostly complete.

Figure 3.4 gives a Hilbert Curve representation of the IPv4 IP space (Irwin and Pilkington, 2008) observed across the entire dataset. Here it can be seen that there is a distributed IP presence within the dataset itself, representing communication between many different subnets with the /24 IPv4 subnet from which the data is drawn.

APNIC AP JIC — DDN-RVN M u ltica st M u ltica st M u ltica st M u ltica st F utu re use F utu re use F utu re use!

Futu re usej

1IF ̂ CC ~ •— MIT ARINs T T i T ■

M u ltica st M u ltica st M u ltica st M u ltica st F utu re use F utu re use F utu re use F utu re use

ARIN M u ltica st M u ltica st M u ltica st M u ltica st F utu re use F utu re use F utu re use F utu re use

R IP E b ^*— - IBM— — - CC DSI-North A M u ltica st M u ltica st M u ltica st M u ltica st F utu re use F utu re use F utu re use F utu re use

ARNIC ^ hD aim ler AG APNIC 11 . NCC / PNIC A C APNIC m c APNIC LACNIC

■' . » A .

' T R IN IC

APNIC — e

f— “ APNIC " P S IN e t ' . NCC ARIN A C API\ c APNIC LACN3 AR M-ini5tered| iFRiBjc

APNIC APNIC AP R IP E NCC — — . : n i c U S - D 0 D U S - D 0 D Pl\ C IN A IN : E N R I : NCC

ARIN E NCC A N C — — APNIC ■ NCC R I : NCC APNIC ARIN ARIN A- R-I V NCC w"i"T 'l:C*rim

a r iN AR IN APNIC A C APNIC IANA - Loopback “ — P LACNIC LACNICs * 4 ‘ ';

ARIN ARIN ARIN ARIN APNIC APNIC: A APNIC — “ PC — — R I NCC AR " LACNIC

klPE 1 g R IP E Ni AF IN ARIN APN C APNIC A 1 JIC — APNI 'APNIC R I ■ NC&.* ■ 1

LACNIC

R IP E NCC ARIN A 1 N / A PNIC A MIC C - ■ ■ , » LACNIC

SI '

C LACNIC R IP E 1 ..CC' L'.*

• NCC R IF E CCiyPC^fP PPP'-.;

R I NCC IN AR APNIC APNICB

— ARUM APNIC

R IP E CC R IP E R I.. NCC R IP E NCC. ARIN ARIN BI C C AR N — — — — - A IN'— —

R I NCC a NCC r i p e :c NCC A IN Apr i§.ARIN AR k — ■?— ™ Ad.iniste.ed by AKiN — — » — —

r i ' • : c F IP E NCC PE NC< R IP E NCC APNIC AFRINIC AFR] \flCAPN C “ ; “ *.-■; .. -

Figure 3.4: IPv4 Hilbert Curve of IP addresses in dataset

The meaning behind this visualization of IP addresses,as well as the software used to produce it,

26

is discussed in section 3.2.4. This heatmap uses the I AN A IPv4 Space Registry overlay, showing the registries of the various IP blocks. This allows for easy identification of which registries are communicating with the observed IP block.

Figure 3.5: Time series of packets from 1 October 2013 to 31 August 2015

Figure 3.5 is a time series of packet traffic across the entire dataset. While the first 12 days of April and first 3 days of May 2014 were recorded, they were omitted from the time series as they will not be included in the discussions on the dataset and analysis to follow. This then leaves a gap in the time series from 1 April to 6 June 2014, marked as B in figure 3.5. The packet presence is noticeably larger for March 2014, which is expected as it comprises the largest percentage of the total dataset. There is a trailing spike in traffic, marked D, observed in December 2013, an increase in packet frequency across the month of January 2014, marked C, and a large singular spike in traffic on the 10th of February 2014, labeled A. The latter will be further looked at in section 3.5.

3.5 Observations of packet behavior across dataset

This section deals with some anomalous packet behavior observed across the dataset. While this is not completely relevant to the analysis that will follow this chapter, the captured activity is presented so that the reader may better understand why some observed values in the datasets are

27

counter-intuitive.

3.5.1 Traffic spike observed 10 February 2014

Figure 3,6 shows a packet time series for the month of February, The month itself only holds 155 million packets so the fact that one day’s worth of traffic would comprise nearly 10 percent of the total traffic, at over 14 million packets, stands out.

Figure 3,6: Timeseries of packets captured for February 2014

Analysis of the day in question led to the following findings, A significant amount of traffic was caused by a server misconhguration of one of the end-hosts in the IP block, which resulted in malformed packets constantly being sent to 108,61,239,225, This accounted for just over 9 million packets during the course of the day, Xo replies were received from any of the IP addresses within the 108.61.239/24 IP block.

3.5.2 Shift in authoritative and caching packet presence for May - July 2015

There is a notable increase in the overall presence of authoritative traffic coupled with a decrease in the presence of caching traffic between May and July of 2015,

28

Table 3,2: Top 10 source IP blocks seen for April 2015 authoritative and caching datasets

/16 / 24Rank Authoritative IPs in block Cache IPs in block Authoritative IPs in block Cache IPs in block

1 192.221 3597 205.251 2041 8 .0 .6 255 205.251.199 2542 8 .0 2941 192.185 728 192.221.163 255 205.251.198 2543 66.249 1466 156.154 361 192.221.162 255 205.251.197 2544 61.220 1208 173.245 359 192.221.151 255 205.251.196 2545 74.125 281 192.254 240 216.40.44 253 205.251.192 2546 216.40 253 216.21 124 8.0.18 251 205.251.195 2537 52.12 217 193.108 1 1 1 8.0.16 251 205.251.193 2518 173.252 194 208.76 103 66.249.76 251 205.251.194 2519 151.164 194 217.160 1 0 1 8.0.23 246 193.108.91 192

1 0 1 2 .1 2 1 170 50.87 1 0 0 8 .0 .1 0 240 173.245.58 179

Table 3,2 gives a /24 and /16 IP block breakdown of IP addresses communicating with the two servers. This table is a strong representation of trends seen in most of the other months. The 192,221/24 and 8,0/24 IP blocks usually contribute the most unique IP addresses to the authoritative dataset, while the 205,251/16 IP block dominates IP presence in the caching dataset. The IP addresses communicating with the authoritative servers are queries for domains while the IPs communicating with the caching servers are query responses.

Table 3,3: Top 10 source IP blocks seen for May 2015 authoritative and caching datasets

/16 / 24Rank Authoritative IPs in block Cache IPs in block Authoritative IPs in block Cache IPs in block

1 192.221 3231 205.251 2043 205.251.197 254 205.251.199 2542 8 .0 2656 192.185 918 205.251.195 254 205.251.198 2543 205.251 2045 156.154 404 205.251.194 254 205.251.197 2544 66.249 1310 173.245 399 205.251.193 254 205.251.196 2545 61.220 1050 192.254 319 205.251.199 253 205.251.195 2546 192.185 717 216.21 268 205.251.198 253 205.251.194 2547 173.245 362 184.154 232 205.251.196 253 205.251.193 2548 156.154 352 50.87 2 2 2 192.221.162 253 205.251.192 2549 192.254 273 193.108 219 205.251.192 252 173.245.58 2 0 0

1 0 173.252 254 208.76 204 8.0.18 249 173.245.59 195

Only one month later, the 205,251/16 IP block has an equally strong presence in both the authoritative and caching IP contributors, and ranks third overall for unique IPs seen for authoritative servers, despite not being a top IP contributor in any of the previous datasets. The 205,251/16 IP block held seven out of ten positions for /24 IP blocks in June, as well as retaining its third rank for /16 IPv4 IPs contributed, July saw the IP block holding eight of the top ten /24 positions while ranking first for overall IP contribution by a /16 IPv4 block. This is not continued by the August 2015 dataset however, which retains characteristics similar to the IP contributors of previous months.Packet flows indicated that during this time one of the authoritative servers, 196,x,x,75, was acting as a caching server by sending queries to and receiving responses from the IP blocks in question.

29

It is suspected that this was configured as such because of one of the caching servers, 196,x,x,77, being offline. This was most likely done in order to balance the cache server load, which is more strenuous than the load on the authoritative servers.

3.6 Overview of A uthoritative D ataset

The authoritative dataset was filtered from the total dataset as it forms part of the TTL dataset seen in section 4,1, This was done by filtering the dataset for packets that had a source or destination IP address that belonged to one of the authoritative servers in the observed IP block. Table 3,4 gives a summary of the authoritative datasets filtered from the CSV hies. It should be noted here that the size (in bytes) is of these hies and not the .cap hies, and the accompanying percentages are also calculated against the CSV hie size for that month. This holds true for all subsequent data size comparisons. Authoritative servers hold domain records, and are queried by other end-hosts for information on those domains. The authoritative dataset was created by hltering for packets destined to or sent from the IP addresses of the two known authoritative servers.

Table 3,4: High level view of processed Authoritative data

Month f t of packets % of total monthly packets

f t of unique IPs Size (bytes) % of total monthly

bytesOctober 2013 2 993 563 2.137 42 891 329 016 262 2.442

November 2013 4 050 830 3.042 46 571 446 009 496 3.393December 2013 3 661 817 2.085 45 287 402 344 104 2.453January 2014 3 971 267 1.676 46 216 436 145 491 1.939February 2014 6 133 090 3.956 51 652 653 935 585 4.286

March 2014 5 392 802 1.319 56 606 589 739 291 1.521June 2014* 4 285 626 3.854 50 799 466 891 814 4.105July 2014 5 022 776 3.762 54 063 548 088 455 3.895

August 2014 5 307 639 5.605 53 068 578 293 706 5.749September 2014 5 881 709 3.781 55 223 641 799 056 3.859

October 2014 6 341 608 3.706 59 276 690 493 931 3.646November 2014 5 478 611 2.967 52 681 596 528 112 2.944December 2014 4 741 805 5.863 48 603 515 800 706 6 .1 0 1

January 2015 5 896 603 4.277 53 040 646 006 657 4.257February 2015 7 779 344 4.974 54 703 855 775 895 4.795

March 2015 7 228 079 4.039 55 186 794 857 236 4.136April 2015 7 043 041 8.349 51 137 775 126 280 8.690May 2015 34 266 603 18.683 92 935 3 851 282 313 20.050June 2015 27 022 755 15.531 81 153 2 997 293 863 16.624July 2015 16 091 494 9.759 76 526 1 776 308 825 10.078

August 2015 6 261 108 4.919 41 184 6 8 8 459 139 5.045Total 174 852 170 4.999 3 4 4 4 4 5 19 280 196 217 5.715


30

While there is usually a large unique IP presence in the authoritative datasets, there is only a small packet percentage presence for most of the months. This does not hold true, however, for the months of May, June, and - to a lesser extent - July of 2015, where recorded unique IP addresses as well as packet percentage representation are far above other observed values.

0/8 1/8 14/8 15/8 16/8 19/820/8 21/8 234/8 235/8 236/8 239/8 240/8 241/8 254/8 255/8j

3/8 2/8 13/8 12/8 17/8 18/823/8c 7 * 22/8 233/8 232/8 237/8 238/8 243/8 242/8 253/8 252/8

4/8 7/8 8/8 11/830/8 29/8 24/8 25/8 230/8 231/8 226/8 225/8 244/8 247/8 248/8 251/8

5/8 6/8 9/8 10/831/8 28/8 27 826/8 229/8 228/8 227/8 224/8 245/8 246/8 249/8 250/8

58/8 57/8 53/8 32/8 35/8 36/8 37/8 218/8 219/8 220/8 223/8 202/8 201/8 198/8197/8

59/8 56/8 55/8 52/8F33/8 34/8 39/8 38/8 217/8216/8 221/8 222/8 200/8 199/8 196/8

60/8 61/8 50/851/8 6/8 45/8 40/8 4 214/8 215/8 210/8 209/8 204/8 205/8 194/8

63/8 yW749/8 48/8 47/8 44/8 43/8 42/8 213/8 212/8 211/8208/8 207/8 206/8 193/8 T92/8

64/8 67/8 68/8 69/8 122/8 123/8 124/8 127/8 128/8 131/8 132/8 133/8 186/8 187/8 188/8 191/8

65/8 71/8 70/8 1 1/8 120/8 125/8 126/8 129/8 130/8 135/8 134/8 185/8 184/S 189/8 190/8

78/8 77 72/8 73/8 118/8 119/8 114/8 113/8 142/8 141/8 136/8 137/8 182/8 183/8 178/8 177/8

79/8 76/8 75/8 7 117/8 116/8 115/8 112/8 143/8 140/8 139/8 138/8 181/8 180/8 179/8 176/8

80/8 81/8 94/8 95/8 96/8 97/8 110/ 111/8 144/8 145/8 158/8 159/8 160/8 161/8 74/8 1 '5/8.

83/8 82/8 89 !/899/8 98/8 109/8 108/8 147/8 146/8 157/8 156/8 163/8 6: ;■173/8 172/8

84/8 8 7888/8 91/8 100/8 103/8,104/8 107/8. 148/8 151/8 152/8 155/8 164/8 1 > 7/8 168/8 171/8

85/8 86/8 89/8 90/8 101/8 102/8■-1

105/8 106/8 149/8 150/8 153/8 154/8 165/8 166/8 169/8 170/8

Figure 3.7: IPv4 Hilbert Curve of client IP addresses in dataset

The reasons for this are discussed in section 3.5. The authoritative dataset overall holds a mere 175 million packets, much smaller than the captured cache dataset. This is to be expected as authoritative servers will generally see less traffic than their caching resolver counterparts unless

31

they serve very low TTLs coupled with the fact that they are authoritative for very popular domains. It is this that makes the large authoritative presence between May and July so anomalous, as the packet percentage presence of the two servers actually approach one another.

The IPv4 Hilbert curve of observed addresses in figure 3,7 shows a spread across most of the /8 IPv4 blocks. The 54/8 presence is much more pronounced than other blocks, and indicates that the 54/8 presence in the overall Hilbert curve can be attributed to traffic to and from the authoritative servers. Interestingly, none of the /24 IP blocks in the 58/8 IP block contribute a significant number of IP addresses to the authoritative cache. The /16 presence for the 58/8 IP block is more notable, and some of the /16 IPv4 blocks will occasionally rank in the top ten contributors of IP addresses to the authoritative dataset.

Table 3,5 gives a breakdown of observed /24 and /16 IP blocks within the authoritative dataset for July 2014, While there is no single large /24 block IP contributor presence from the 58/8 IP block, there are a number of IP addresses from different /24 IP blocks that create a larger /16 IP presence, with respect to unique IP addresses.

Table 3,5: Top 10 source IP blocks seen for authoritative datasets July 2014

IP block size /16 /24Rank Authoritative IPs in block Authoritative IPs in block

1 192.221 4356 192.221.150 2532 8 .0 3447 66.249.74 2523 66.249 1314 8.0.15 2494 61.220 1305 192.221.151 2495 74.125 371 192.221.143 2496 54.90 219 192.221.139 2467 54.203 187 192.221.138 2468 54.91 185 192.221.134 2459 54.89 183 192.221.167 241

10 54.74 183 66.249.66 240

Amazon technologies does have a number of /10, / l 1, /12 and 13 subnets in the 54/8 IPv4 block, while the block itself is administered by ARIN, This traffic is most likely generated by Amazon Web Services ,through third parties using their cloud hosting software, which are trying to reach domains for which the server has authoritative records.

3.7 Overview of Cache D ataset

The cache dataset was filtered from the total dataset as sections 4,1 and 4,2 are made up of this dataset. Section 4,2 more so, as authoritative replies to the two caching servers for .za domains were filtered out in order to gather the necessary data for authoritative server geoloeation. An

32

overview of the caching dataset is given in Table 3,6, The caching dataset represents a much greater packet percentage when compared to other datasets. There are two reasons for this, the first is that the filtering criteria is broader than the NX DOMAIN and Amplification filters, as it targets any packet to and from the caching resolvers, the second is that the caching servers saw more traffic on average than the authoritative servers, as they were not authoritative for extremely popular domains, while popular domains were constantly queried through the caching resolvers. This dataset also contains the largest number of unique IP responses as the caching servers receive response packets from authoritative servers across the Internet,

Table 3,6: High level view of collected data

Month i f of packets % of total monthly packets

i f of unique IPs Size (bytes) % of total monthly

bytesOctober 2013 51 121 777 37.101 81 053 6 148 029 736 45.627

November 2013 53 454 301 40.147 76 908 6 398 171 422 48.674December 2013 82 793 019 47.132 57 572 9 597 971 528 58.520January 2014 109 809 929 46.340 72 906 12 781 938 116 56.816February 2014 56 6 8 6 532 36.565 100 948 6 781 035 956 44.448

March 2014 188 760 346 46.171 98 549 21 941 444 555 56.579June 2014* 43 951 343 39.523 75 569 5 283 291 552 46.455July 2014 42 028 142 31.483 70 846 5 078 619 295 36.089

August 2014 35 342 637 37.324 6 8 431 4 255 975 551 42.011September 2014 64 346 538 41.367 73 708 7 754 985 986 46.627October 2014 59 127 006 34.552 93 967 7 183 009 480 37.924

November 2014 65 954 042 35.712 71 748 7 963 8 6 8 754 39.301December 2014 30 867 320 38.167 4 ( 534 3 661 454 337 43.310January 2015 50 346 994 36.520 69 706 6 070 039 859 40.001February 2015 52 128 094 33.332 71 509 6 359 485 172 35.632

March 2015 60 244 649 33.667 72 768 7 357 672 570 38.288April 2015 27 035 565 32.050 51 087 3 285 589 272 36.834May 2015 40 508 020 22.086 60 877 4 902 267 514 25.521June 2015 47 264 942 27.165 64 449 5 863 556 885 32.521July 2015 49 546 971 30.048 70 570 6 125 539 381 34.755

August 2015 34 040 395 26.748 59 828 4 144 218 993 30.369Total 1 245 358 562 35.605 346 316 148 938 165 914 41.729


There is a notable dip in percentage packet representation for May, June, and - to a lesser extent - July 2015, This is linked to the larger authoritative presence noted over that period and will be discussed further in 3,5, Overall the caching dataset holds just under 1,25 billion packets, and represents around 35% of all packets captured in the dataset.

As is seen in figure 3,8, there is a smaller but noteworthy 54/8 IPv4 presence in the caching dataset. This is as a result of Amazon cloud authoritative servers existing in this IP block, of which they control certain sub-blocks as mentioned previously.

33

0/8 1/8 14/8 15/8 16/8 19/820/8 21/8 234/8 235/8 236/8 239/8 240/8 241/8 254/8 255/8j

3/8 2/8 13/8 12/8 17/8 18/823/8 22/8 233/8 232/8 237/8 238/8 243/8 242/8 253/8 252/8

4/8 7/8 8/8 11/830/8 29/8 24/8 25/8 230/8 231/8 226/8 225/8 244/8 247/8 248/8 251/8

5/8 6/8 9/8 10/831/8 28/8 27/8 26/8 229/8 228/8 227/8 224/8 245/8 246/8 249/8 250/8

58/8 57/8 4/853/8 32/8 35/8 36/8 37 8 218/8 219/8 220/8 223/8 201/8 .198/8 ' 97/8

59/8 56/8 55/8 52/8 33/8 34/8 39/8 38/8 7/8 216/8 221/8 222/8 200/8 199/8 196/8

60/8 61/8 50/8 51/8 i/845/8 40/8 41/8 214/8 215/8 210/8 209/8. 204/8 205/8 194/8 5/

63/8 62/8 4 848/8 47/8 44/8 43/8 42/8 213/8 212/8 211/8 208/8 207/8 206/8 1 3/8 1'92/8

64/8 67/8 68/8 69/8 122/8 123/8 124/8 127/8 128/8 131/8 132/8 133/8 186/8 187/8 188/8 191/8

65/8 / 71/8 70/8 121/8 120/8 125/8 126/8 129/8 130/8 135/8 134/8 18! 184/8 189/8 190/8

788 77/8 i; !/873/8 118/8 119/8 114/8 113/8 142/8 141/8 136/8 137/8 182/8 183/8

'00 17 8

79/8 76/8 75/8 7. 117/8 116/8 115/8 112/8 143/8 140/8 139/8 138/8 181/8 180/8 179/8 1 678

80/8 -/895/8 96/8 97/8 110/8 1.11/8 144/8 145/8 158/8 159/8 160/8 161/8 175/8

88, 8 !/89 i/899/8 98/8 109/8 108/8 147/8 146/8 157/8 156/8 163/8 62/8 173/8' 172/8

84/8 87 888/891 /8 100/8 10: 104/8 107/8 148/8 151/8 152/8 155/8 164/8 167/8 168/8 171/8

85/886/8 89/8 90/8 101/8 102/8 105/8 106/8 1 978 150/8 153/8 154/8 165/8 66/8 169/8 170/8

Figure 3.8: IPv4 Hilbert Curve of IP addresses in dataset

This Hilbert curve plot indicates a good spread of communication across IPv4 address space at the /8 level captured in these datasets, as almost all of the /8 IP blocks, not including those reserved for future use, are populated to some extent. When compared to the authoritative Hilbert curve in figure 3.7, there seems to be fewer densely populated clusters, like the 54/8 IP block, but overall traffic from many of the blocks seen in the authoritative set. Figure 3.8 also shows an increase in smaller concentrated clumps of IPs when compared to figure 3.7, particularly in the 173/8 to 193/8 IP range.

34

This heatmap and the Authoritative heatmap in figure 3,7 use the /8 IP block overlay instead of the IANA registry overlay seen in figure 3,4, This is done to show the /8 IP block distribution of the Hilbert curve, as well as to make the figures more meaningful to the reader.

3.8 Overview of Am plification D ataset

The amplification dataset is the smallest of the filtered whole datasets to appear in this thesis. It was filtered from the dataset using reported attack domains10 as an identifier. The packets were then further filtered, accepting only ANY EE packets, in order to remove false positives. These false positives were generated as some of the attack domains are legitimate domains and as such generate non-amplification query traffic. Table 3,7 describes the amplification presence in the monthly datasets. The largest amplification presence amounts to merely 0,222% of a monthly dataset. One of the key reasons for the dataset being so small is that there are no open resolvers present in the 196.x.x.x 21 IP block for these scans to take advantage of, and as such no response packets have been recorded. The dataset will be discussed further in section 5,1,


Month i f of packets % of total monthly packets

i i of unique IPs Size (bytes) % of total monthly

bytesOctober 2013 306 364 0 .2 2 2 85 31 030 187 0.230

November 2013 1 0 2 0 1 0 0.077 2 2 10 405 133 0.079December 2013 37 298 0 .0 2 1 13 3 882 634 0.024January 2014 21 818 0.009 11 2 215 590 0 .0 1 0

February 2014 52 700 0.034 16 5 262 240 0.034March 2014 44 505 0 .0 1 0 15 4 669 692 0 .0 1 2

June 2014* 6 009 0.005 15 629 147 0.006July 2014 9 952 0.007 21 1 013 588 0.007

August 2014 13 6 6 6 0.014 25 1 390 746 0.014September 2014 10 902 0.007 2 0 1 107 062 0.007October 2014 7 900 0.004 16 822 639 0.004

November 2014 6 148 0.003 16 632 665 0.003December 2014 6 593 0.008 25 669 385 0.008January 2015 4 338 0.003 16 440 621 0.003February 2015 4 199 0.003 14 429 931 0 .0 0 2

March 2015 4 974 0.003 15 503 684 0.003April 2015 2 583 0.003 7 264 280 0.003May 2015 3 044 0 .0 0 2 7 312 795 0 .0 0 2

June 2015 4 095 0 .0 0 2 1 0 418 065 0 .0 0 2

July 2015 2 793 0 .0 0 2 5 284 768 0 .0 0 2

August 2015 9/8 0 .0 0 1 5 99 119 0 .0 0 1

Total 652 869 0.019 325 6 6 483 971 0 .0 1 1

* datasets do not represent a complete monthly capture,

10 h ttp : / / dnsamplification attacks, blogspot ,co. za /

35

3.9 Overview of NX dom ain dataset

The NXDOMAIN dataset contains all responses with the NXDOMAIN error flag (Andrews, 1998) set, indicating that the queried domain does not exist. Overall, this dataset accounts for just under 143 million packets. This dataset was filtered using the tcpdump command mentioned in section 3,3, NXDOMAIN responses were filtered into a separate dataset as these responses are usually indicators of anomalous activity (Yadav and Eeddv, 2012), It must be taken into account that only the replies are captured here; queries have not been included in the filtered dataset. This dataset was filtered using tcpdump, as mentioned in seetion3,3. Further analysis on NXDOMAIN traffic is done in section 4,3,


Month f t of packets % of total monthly packets

f t of unique IPs Size (bytes) % of total monthly

bytesOctober 2013 4 800 190 3.484 17 442 769 302 413 3.231

November 2013 4 341 797 3.261 16 927 692 394 489 3.304December 2013 4 298 557 2.447 19 616 696 180 506 3.014January 2014 4 698 313 2.017 17 853 761 163 116 2.407February 2014 4 780 242 3.083 20 722 768 147 593 2.450

March 2014 5 803 551 1.420 19 837 9 4 4 724 915 1.739June 2014* 3 199 786 2.877 21 026 503 612 858 2.774July 2014 4 429 901 3.318 23 619 815 629 109 3.429

August 2014 4 040 682 4.267 20 643 702 114 083 4.591September 2014 4 768 943 3.066 23 472 807 022 101 3.254

October 2014 6 431 531 3.758 24 706 1 106 018 089 3.718November 2014 6 530 777 3.536 18 552 1 185 156 713 3.759December 2014 6 034 674 7.462 14 774 1 030 469 783 8.164January 2015 7 490 611 5.433 17 978 1 341 201 081 5.904February 2015 8 210 950 5.250 19 022 1 445 870 257 5.523

March 2015 9 155 147 5.116 18 718 1 531 014 630 4.933April 2015 7 488 729 8.877 14 978 1 244 785 242 9.146May 2015 8 779 328 4.787 19 389 1 527 449 716 4.692June 2015 13 503 773 7.761 20 057 2 500 045 944 8.637July 2015 14 066 828 8.531 22 158 2 537 062 858 8.943

August 2015 9 8 6 8 415 7.754 18 911 1 707 882 116 7.780Total 142 722 725 4.081 121 379 24 617 247 612 4.257

The * notes datasets that do not represent a complete monthly capture.

3.10 Chapter Summary

This chapter discusses the dataset, the filtering and preprocessing of the data, and gives overviews of the dataset as well as the subsets created for more focused analysis,A number of tools were used in the processing and filtering stage of the research. The most notable of these are libtins, a C ++ packet parsing library with which the peap reader was written;

36

Wireshark, a packet sniffer and analysis UI, as well as its derivative tools editcap and mergecap,

which aided in the processing of the pcap hies; fping, a ping sweep tool which was used to determine authoritative server latency; the Max.Mind Geolocate Database which was used in order to correlate IP addresses to the countries in which they are based.

The total dataset spans 21 months and holds close to 3.5 billion packets. From this dataset, four separate subsets were formed that are used in three of the analysis sections. The authoritative and caching subsets are analyzed for TTL implementation and behavior. Analysis on the NXDOMAIN reply dataset forms its own section, as does analysis on the amplification dataset on post-attack amplification scanning. The section on bithipping and bitsquatting utilizes the entire dataset.

37

Chapter 4

DNS Operations

This chapter deals with three areas related to the practice of DNS implementation and usage captured by the dataset. Section 4,1 gives a breakdown of observed DNS TTL values across the dataset. Section 4,2 looks at the geolocation of authoritative servers for queried ,za domains, as well as the latency generated for ,za queries as a result of the location of the authoritative servers; from a South African context. Section 4,3 looks at NXDOMAIN responses for queries captured over the various months.

4.1 Breakdown of D N S response TTLs

DNS time-to-live values are implemented to instruct servers caching the responses of DNS resolvers as to how long the record should remain viable within the cache memory. Once this value times out, the cache is instructed to query the authoritative server of the domain instead of replying to queries with the cached data. This section gives a breakdown of observed TTL values across the dataset,

4.1.1 Observed TTL frequency

Table A.l gives a ranked breakdown of the frequency of DNS TTL values observed throughout the dataset, and is found in the appendix. Figure 4,1 illustrates the ranked position of the TTL values throughout the dataset. The results here are slightly skewed in favor of lower TTL values. This is because lower TTL values result in more queries to the respective authoritative server of the domain, as the cached records become stale faster. As a result, more replies with low DNS TTL values present. While the presence of lower TTL values is then expected, it would also be expected that the lowest TTL value would rank the highest given an equal distribution of TTL value configurations, which is not seen in this case.

38

The 300 TTL value, equal to a TTL of five minutes, is the TTL value with the highest presence across all datasets. This suggests not only that the low TTL value leads to many repeated queries to authoritative servers using this TTL, but also that the TTL value has been adopted by a large number of domains. The 60, or one minute, and twenty second TTL values are almost always ranked second and third throughout the dataset. One notable exception to this is December 2013, which sees a much more predominant presence of the 3600 and 86400 TTL values.

Figure 4.1: Top TTL changes over observed period

This difference in TTL presence is in part attributed to the nature of the December 2013 dataset, which saw less queries for services related to the Akamai CDN family, a content distribution network, and a large contributor of 20 and 60 second TTL values in other datasets, which together represented around 25% of observed TTL values for the overall dataset. The ranking of these TTL values also corresponds to the prevalence of different resource records captured in the datasets, and will be discussed further in 4.1.3.Previous work by Wills and Shang (2000) suggests that cache hit percentages, i.e. cache servers replying with a cached record instead of querying the authoritative server, can be improved by around 5% by implementing a minimum TTL of 15 minutes (900 seconds). Using this TTL as a standard minimum would greatly reduce the amount of authoritative replies captured in this dataset, of which the 300 TTL represents between 24-30% of all replies per month; and the 60 TTL a further 15-20%. Of course in some cases, particularly CDN TTLs, it may not be feasible to enforce a minimum value as that may affect system performance (Holz et al, 2008).

39

September 2014 stands out as it is the only month to have a TTL value of 1 in the top 10 ranking. This is even more curious as it would be expected that if the TTL was related to commonly queried domains that it would appear in more, or maybe even all, months given the nature of its low TTL, Further analysis revealed that most of the 1 value TTL values were linked to query responses for sc.sa;.rules.mailshell.net, where xx is a placeholder of two numeral characters and not part of the domain itself. These queries were linked to botnet activity from an unidentified botnet by Kwon e.t al. (2014), Six subdomains of .rules.mailshell.net. sc21, scl8, scl9, scl7, sel and sc2, contributed almost all of the 1 TTL packets observed in the dataset. While these domains are present in other months, they are not nearly as large as the presence recorded in September 2014, This botnet was used to launch DDoS attacks towards the end of September 2014, as is seen in figure 4,2,

Figure 4,2: Queries for sc.sa;.rules.mailshell.net domains during September 2014

Figure 4,2 is a timeseries of queries for the aforementioned domains from one host in the dataset, 196.X.X.162, a known proxy for a local network, during September 2014, This IP, among others, targeted five servers with more than 10 000 queries and a number of others with queries totaling less than 1000 of these. One of the target end-hosts, IP 155,232,135,5 was the most affected victim, receiving over 300 000 queries from 196,x,x,162 alone. It should be noted here that the mailshell.net TLD has been identified in other research as part of the DXSBL infrastructure (Metcalf and Spring, 2014)

40

4.1.2 Normalised TTL frequency

Table 4,1 gives the frequency of DNS TTL values after the data has been normalised in order to remove duplicated responses. This is done in order to counter the frequency skewing that comes about as a result of low TTL values generating more response queries than cached records with higher TTL values, given the same query frequency on the network (Jung et al, 2002),

Table 4,1: Normalised TTL frequencypHTi.k I 1 I 2 I 3 I 4 I 3 I 6 I 7 I 8 I 9 I ItT

Mouth TTL % of T TLs TTL % of TTLs TTL % of TTLs TTL % o f TTLs TTL % of TTLs TTL % of TTLs TTL % o fT T L s TTL % of TTLs TTL % of TTLs TTL % of TTLsO ctober 2013 86400 21.973 300 17.329 3600 13.406 7200 9.133 900 8.824 14400 3.290 600 3.00: i 13200 2.724 1800 2.370 21600 1.937

November 2013 300 21.366 86400 20.279 3600 13.680 7200 8.798 900 6.486 14400 1.023 600 3.081 1800 2.333 43200 2.439 28800 1.860December 2013 86400 34.433 3600 13.392 300 11.936 7200 7.687 900 7.189 43200 1.614 172800 2.{'01 11100 1.934 28800 1.944 1.667January 2014 300 20.911 86400 19.836 3600 12.234 900 8.948 7200 7.342 1.907 14400 1.388 13200 2.890 600 2.270 1800 1.931February 2014 86400 23.698 300 13.842 3600 13.261 900 10.379 14400 6.898 7200 3.933 43200 •i.aiO 3.481 172800 2.437 600 1.871

March 2014 86400 18.368 300 18.193 900 13.293 3600 11.318 14400 8.471 1.198 3200 3.106 13200 2.978 7200 2.423 600 2.148June 2014 86400 18.023 300 14.143 3600 14.063 900 11.490 14400 6.904 28800 6.486 1 .{<{<7 {'00 3.097 7200 2.893 1800 2.814July 2014 86400 17.343 300 17.424 3600 16.133 900 9.733 14400 3.877 28800 4.388 600 3.322 7200 3.106 1800 3.010 2.933

August 2014 300 22.396 86400 16.861 3600 14.004 900 10.773 14400 6.668 600 3.130 1800 3.003 2.713 7200 2.639 21600 2.276September 2014 300 24.476 86400 13.412 3600 14.133 900 8.188 6.623 14400 3.384 600 3.3:i7 1800 3.040 7200 2.741 60 2.264

O ctober 2014 300 20.111 3600 16.338 86400 16.486 900 8.973 14400 8.080 600 4.019 7200 3.178 1800 3.206 60 3.128 43200 2.016November 2014 300 23.308 86400 16.346 3600 14.803 900 9.760 14400 6.042 600 3.799 60 3.311 7200 2.739 1800 2.742 43200 1.913December 2014 86400 183813 300 18.314 900 13.183 3600 14.228 14400 3.090 60 3.947 600 3 .111! 28800 2.786 7200 2.363 1800 2.319January 2013 300 20.420 86400 17.443 3600 14.423 900 13.341 14400 6.722 60 3.633 600 3.233 13200 2.334 1800 2.440 7200 2.436February 2013 300 23.710 86400 16.179 3600 14.497 900 9.796 14400 6.413 60 3.768 600 3.220 1800 2.663 7200 2.396 43200 2.219

March 2013 300 26.166 86400 13.842 3600 13.132 900 9.891 14400 6.639 60 3.773 600 3.333 7200 2.310 1800 2.497 28800 2.117April 2013 300 22.283 86400 16.633 3600 13.108 900 11.931 14400 3.128 60 4.773 600 3.373 7200 2.683 1800 2.347 28800 2.483May 2013 300 23.199 3600 13.830 86400 13.418 900 9.691 14400 3.686 60 4.294 600 3.822 21000 3.406 7200 2.619 1800 2.604June 2013 300 21.290 86400 19.439 3600 13.412 900 10.389 14400 4.978 60 3.383 600 3.30:i 21000 2.983 7200 2.736 1800 2.263July 2013 86400 24.266 300 16.443 3600 16.034 900 9.936 14400 4.331 600 3.426 60 3.310 7200 2.939 21600 2.700 43200 2.328

August 2013 86400 22.889 3600 14.821 900 13.082 300 12.629 14400 4.411 60 4.228 600 3.349 21600 3.243 7200 2.826 43200 2.316

It is interesting to note that apart from the 86400 (one day) TTL value, none of the TTL values that rank in the top 4 exceed two hours, and from January 2014 none of them exceed one hour. This is a clear indicator that domain administrators are favoring lower TTL values, as noted by Gao et al (2013), It seems clear when looking at table 4,1 that the 300, 86400, 3600 and 900 TTL values are most favored as domain TTL values.

One of the largest contributors to the 300 TTL values seen in the dataset are domains related to Google, The gstatic.com, google.com, googlevideo.com and googlehosted.com top-level domains all contributed a number of subdomain responses with TTL values of 300, The Akamai CDN family also responded with 300 TTLs for subdomains for three TLDs, akadns.net, akamaihd.net and edgesuite.net. Other notable corporate contributors of the 300 TTL are yahoo.com, yahoodns.net, skype.net and photobucket.com. This seems to indicate that Internet-based organizations are making use of lower TTLs in an attempt to better control the distribution of connections between servers, much like a CDN, while also enabling quick configuration changes to ensure minimal downtime due to server failure.

The largest contributor of 86400 TTL values are responses for PTE queries. This value is recommended in RFC 1035 (Moekapetris, 1987b) and further defined as the default value for PTR and other RR types not subject to constant change in RFC 1912 (Barr, 1996), There is also a notable presence of apple.com and icloud.com subdomains that respond with 86400 TTLs, Some google.com subdomains also responded with the one day TTL, but less so than those that responded with 300 TTLs,

41

Microsoft domains, most notably the windows.com, hotmail.com and live.com TLDs, were some of the largest contributors of 3600 TTL values. The mcafee.com subdomains were also a large contributor of this TTL,

The largest contributor of 900 TTL responses was spamhaus.org, a Domain Name System Black List (DNSBL) (Jung and Sit, 2004), A DNSBL allows mail recipients to query sending hosts against the list, filtering out known spam hosts (Jung and Sit, 2004), The queries were either A or TXT EE queries, taking the form of {IPv4address}.zen.spamhaus.org. For the month of January 2015 alone, spamhaus.org subdomains were responsible for 88,719% of unique 900 TTL responses captured on the dataset.There were no significant contributors for 600 TTL domains, which showed a less concentrated spread of domains than other TTL values. Four main contributors of this TTL were xvideos.com CNAME queries, as well as various PTE queries that make up around 5% of the 600 TTL responses, while softonic.com and avast.com subdomains each make up 2,5% of the 600 TTL replies respectively.

The 60 TTL presence was relatively interesting, as most of the unique subdomains that responded with this TTL fell under the mailspike.net and spamhaus.org domains. There was also a noticeable presence from akadns.net CDN domains, as well as subdomains present for googlevideo.com and amazonaws.com, indicating that these domains are mirroring CDN configuration and behavior. The Facebook CDN - fhcdn.com - also responded with a number of 60 TTL replies, CDN TTL values are typically low to allow the CDN to change domain mapping quickly in order to facilitate server load balancing (Krishnamurthv et al, 2001),

Gao et al. (2013) stated in their paper that observed TTL values have decreased when compared to past research, and papers cited by them backed their findings. This research shows close results to that paper, showing that TTL values at or below one hour are far more prevalent than TTL values above two hours. This of course does not include the 86400, or 1 day, TTL the prevalence of which is most likely due to the fact that it is the recommended TTL time(Lottor, 1987), and in many cases the default TTL assigned to records, not including MX , This becomes even more obvious when EFC 1912 states “Popular documentation like [EFC 1033] recommended a day for the minimum TTL, which is now considered too low except for zones with data that vary regularly,” (Barr, 1996).

Of particular interest are is the 0 TTL presence that appears between December 2013 and September 2014, which will be discussed in 4,1,4,

4.1.3 Normalised TTL frequency for resource records

TTL frequency for nine separate resource records was also investigated. These nine were chosen as they consistently appear throughout the dataset, which then allows for a broader comparison of

42

TTL behavior. Table 4,2 gives a breakdown of the most popular TTL setting for various resource records observed across the dataset.

Table 4,2: Normalised TTL frequency by resource record by monthE E A P T E < * \ V M E T X T M X A A A A N S S O A S E V

M o n t h T T L . . i n n T T L . .1 n n T T L % o f E E T T L % o f E E T T L % o f E E T T L % o f E E T T L % o f E E T T L % o f E E T T L % o f E E

u - f . i h - i 2 0 1 5 3 0 0 2 7 4 2 8 h 4 0 0 5h 542 5hfifi 1 9 .3 7 0 9 0 0 7 3 .0 4 2 3 6 0 0 2 2 .3 3 9 3 0 0 7 5 .5 7 3 8 6 4 0 0 3 6 .7 9 2 8 6 4 0 0 3 0 .6 6 7 3 0 0 5 0 .0 0 0

V i v m h ' i 2 0 1 5 3 0 0 2 " 52 5 8 h 4 0 0 5 2 .5 3 3 5hfifi 2 2 .0 7 6 9 0 0 5 9 .2 6 0 3 6 0 0 2 0 .3 7 9 3 0 0 8 2 .7 6 4 8 6 4 0 0 3 2 .2 2 3 8 6 4 0 0 6 3 .6 3 6 3 0 0 5 0 .0 0 0

D< < < m ix i 2 0 1 5 3 0 0 2 0 M 0 8 h 4 0 0 51 7 2 5 5hflfl 2 2 .9 4 9 9 0 0 7 6 .0 9 1 3 6 0 0 1 8 .7 9 0 3 0 0 5 3 .3 3 3 3 6 0 0 4 3 .5 4 8 8 6 4 0 0 6 2 .5 0 0 8 6 4 0 0 4 0 .0 0 0

J a n u a r y 2 0 1 4 3 0 0 51 0 2 5 8 h 4 0 0 4 7 8 h 5 5hflfl 2 2 .5 3 5 9 0 0 7 7 .6 4 1 1 4 4 0 0 3 6 .0 7 1 3 0 0 7 9 .2 9 7 3 6 0 0 4 6 .5 3 5 8 6 4 0 0 7 0 .0 0 0 3 0 0 5 0 .0 0 0

t ' b i i ic t n 2 0 1 4 3 0 0 2 7 .2 7 5 8 h 4 0 0 5 0 Ot,8 5hflfl 2 2 .5 9 2 9 0 0 8 9 .8 5 2 1 4 4 0 0 5 9 .2 9 5 3 0 0 8 2 .4 2 5 8 6 4 0 0 4 2 .4 6 6 8 6 4 0 0 4 1 .6 6 7 8 6 4 0 0 2 8 .5 7 1

M m - L 2 0 1 4 3 0 0 2 7 4 8 8 8 h 4 0 0 4 0 1)20 5hflfl 2 2 .6 5 5 9 0 0 9 0 .4 4 6 1 4 4 0 0 5 8 .0 0 9 3 0 0 7 8 .7 8 6 8 6 4 0 0 3 6 .0 4 7 8 6 4 0 0 4 5 .4 5 5 3 0 0 6 0 .0 0 0

J u n o 2 0 1 4 3 0 0 1 7 h 7 0 8 h 4 0 0 4 7 8 5 2 5hflfl 2 1 .9 6 7 9 0 0 7 7 .1 0 5 1 4 4 0 0 4 3 .4 3 6 3 0 0 7 0 .4 2 4 8 6 4 0 0 3 8 .8 0 6 8 6 4 0 0 5 6 .2 5 3 0 0 5 7 .1 4 2

Tub 2 0 1 4 3 0 0 2 2 h 8 8 8 h 4 0 0 4 0 l h l 5hflfl 2 1 .7 1 0 9 0 0 6 8 .6 1 5 3 6 0 0 2 4 .7 8 3 3 0 0 7 0 .6 3 4 3 6 0 0 3 9 .7 2 6 8 6 4 0 0 3 9 .1 3 0 8 6 4 0 0 3 7 .5 0 0

A u g u s t . 2 0 1 4 3 0 0 51 4 52 8 h 4 0 0 51 5 5 4 5hflfl 2 1 .8 0 4 9 0 0 7 2 .2 5 5 1 4 4 0 0 3 4 .8 1 9 3 0 0 8 4 .1 8 9 8 6 4 0 0 4 1 .1 7 6 8 6 4 0 0 4 6 .1 5 4 3 0 0 5 0 .0 0 0

p t- m i )-1 2 0 1 4 3 0 0 51 1 7 8 8 h 4 0 0 51 lh l ] 5hflfl 2 1 .6 1 2 9 0 0 6 4 .3 6 1 3 6 0 0 2 3 .2 9 2 3 0 0 8 3 .3 4 4 3 6 0 0 3 6 .0 6 6 8 6 4 0 0 2 7 .0 2 7 3 0 0 5 7 .1 4 3

( M . , ! . - ! 2 0 1 4 3 0 0 2 4 4 8 1 8 h 4 0 0 5 0 504 5hflfl 2 1 .6 4 9 9 0 0 6 4 .3 4 1 3 6 0 0 2 8 .1 4 4 3 0 0 8 8 .8 4 5 8 6 4 0 0 3 8 .3 5 6 8 6 4 0 0 4 3 .0 7 7 3 0 0 5 7 .1 4 3

V i v m l x i 2 0 1 4 3 0 0 52 0 8 1 8 h 4 0 0 5 0 2 1 1 5hflfl 2 0 .4 6 6 9 0 0 6 7 .8 5 2 3 6 0 0 2 5 .8 3 1 3 0 0 8 9 .3 5 0 3 6 0 0 4 9 .2 0 6 8 6 4 0 0 4 4 .6 8 1 3 0 0 3 3 .3 3 3

D - - - m b - 1 2 0 1 4 3 0 0 2 h 8 7 h 8 h 4 0 0 4 0 8 0 7 5hflfl 2 1 .7 8 7 9 0 0 7 2 .0 5 5 3 6 0 0 2 5 .0 6 2 3 0 0 7 7 .2 5 3 3 6 0 0 4 4 .5 9 5 7 2 0 0 4 0 .7 4 1 8 6 4 0 0 4 0 .0 0 0

fc tiiiic tn 2 0 1 5 3 0 0 2 8 5 h 4 8 h 4 0 0 51 1 4 8 5hflfl 2 1 .0 8 2 9 0 0 7 8 .4 1 5 1 4 4 0 0 3 3 .2 7 2 3 0 0 8 7 .0 0 8 3 6 0 0 4 5 .2 0 5 7 2 0 0 2 6 .8 2 9 3 0 0 3 8 .4 6 2

t - L i l i a n 2 0 1 5 3 0 0 54 Ohh 8 h 4 0 0 4 8 5 5h 5hflfl 2 1 .6 5 7 9 0 0 7 1 .1 2 4 1 4 4 0 0 2 7 .9 9 4 3 0 0 8 9 .8 2 7 3 6 0 0 4 9 .3 8 3 8 6 4 0 0 3 2 .6 5 3 3 6 0 0 2 8 .5 7 1

M a i- L 2 0 1 5 3 0 0 54 504 8 h 4 0 0 4 8 8 1 0 5hflfl 2 1 .0 0 8 9 0 0 6 8 .4 9 3 1 4 4 0 0 2 7 .6 5 3 3 0 0 8 9 .3 7 7 3 6 0 0 4 0 .0 0 0 7 2 0 0 3 2 .5 0 0 3 6 0 0 3 0 .0 0 0

A p r i l 2 0 1 5 3 0 0 2 0 5 4 1 8 h 4 0 0 4 8 1 5 8 5hflfl 2 0 .4 6 2 9 0 0 6 5 .7 2 9 3 6 0 0 2 4 .9 1 4 3 0 0 7 9 .9 4 0 3 6 0 0 3 5 .5 5 6 8 6 4 0 0 3 9 .1 3 0 3 0 0 3 7 .5

M a i 2 0 1 5 3 0 0 5 5 0 55 8 h 4 0 0 4 h 074 5hflfl 2 2 .4 5 6 9 0 0 6 1 .3 7 1 8 6 4 0 0 2 3 .7 5 2 3 0 0 4 7 .2 2 4 3 6 0 0 3 8 .4 6 2 8 6 4 0 0 4 5 .8 3 3 3 6 0 0 4 6 .1 5 4

J u n o 2 0 1 5 3 0 0 50 5 58 8 h 4 0 0 4 4 0 5h 5hflfl 2 2 .3 0 6 9 0 0 6 9 .2 8 7 3 6 0 0 2 3 .5 4 8 3 0 0 4 0 .5 5 6 3 6 0 0 3 1 .4 2 9 8 6 4 0 0 4 4 .0 0 0 3 6 0 0 5 0 .0 0 0

b i l l 2 0 1 5 3 0 0 2 4 2 8 7 8 h 4 0 0 4 h 8 5 0 5hflfl 2 2 .9 9 0 9 0 0 7 2 .9 3 6 3 6 0 0 2 3 .7 1 3 3 0 0 3 4 .6 4 1 3 6 0 0 3 4 .5 4 5 8 6 4 0 0 3 0 .7 6 9 3 6 0 0 4 1 .6 6 7

V u g m f 2 0 1 5 3 0 0 l h 570 8 h 4 0 0 4 h 544 5hflfl 2 3 .0 4 2 9 0 0 7 4 .0 3 3 3 6 0 0 2 2 .5 3 0 3 0 0 4 1 .1 6 8 8 6 4 0 0 4 0 .0 0 0 8 6 4 0 0 4 2 .8 5 7 3 6 0 0 3 6 .3 6 4

There seems to be a clear tend towards lower TTL configurations for many of the resource records present in table 4,2, The 5 minute TTL is the most popular A record TTL across all months, which suggests that domain administrators value the ability of promptly redirecting domain traffic to different servers more than the increased bandwidth cost created by smaller TTL values. The lower 300 TTL presence for A record traffic in June of 2014 comes about as a result of a larger presence of 0 TTL and 28800 TTL A queries than in other months. The increased 28800 TTL presence in this month comes about as a result of responses for subdomains of rhs,mailpoliee.com, which is a Eight Hand Side Black List (EHSBL), EHSBLs contain domain names belonging to TLDs, and derive their name by storing and filtering emails based on the domains given at the right hand side of the @ in the address (Miszalska et al, 2007), While these are similar to DNSBL services, they filter using the TLD and not the IP address of the sender (Jung and Sit, 2004), This indicates that the IP block was the target of email spamming during this month. While August 2015 shows a similar reduction in the prevalence of 300 TTL values, this is because of a decrease in ratio between this and other common A record TTL values, and is not as a result of anomalous traffic. This decrease can also be partially, but not wholly, attributed to an increase in 900 TTL A record traffic as a result of a larger spamhaus.org, a DNSBL, presence in the dataset.

The one day TTL is the most popular PTE TTL choice, and its prevalence in the dataset remains fairly consistent throughout the captured months. The 3600 and 300 TTL values rank second and third respectively for PTE records for most of the months in the dataset, but their presence is much lower than the one day TTL, 43200 and 28800 TTLs also rank in the top 5 TTLs seen for most months. This seems to indicate that there is less need to have frequently updated PTE records as opposed to other record types. This difference in TTL selection could also be explained

43

by the targets of different resource records, PTE records may not necessarily target the same domains as A records, which would create a discrepancy in TTL frequency.

The one hour TTL remains the most frequent CNAME TTL throughout the dataset. This is in part due to CNAME requests for services hosted through the Akamai CDN domains, whose CNAME TTLs are set to 3600, While the Akamai edgesuite.net and akadns.net domains are the two largest contributors of 3600 CNAME TTLs, they are closely followed by subdomains for apple.com, amazonaws.com, windowsupdate.com, skype.net and icloud.com, indicating that domain administrators from various spheres and organizations are favoring the one hour TTL for this resource record.

An overwhelming number of TXT responses yielded a 15 minute, or 900 TTL, This presence is largely due to the configuration of TXT responses for spamhaus.org domains, 86400 was the second most used TTL configuration for TXT records, and would have ranked first if it was not for the large 900 presence created by the spamhaus.org domains. Interestingly, the 10 TTL had the third largest presence, which was generated by sophosxl.net subdomains. These are generated by anti-virus software from SophosLabs, which runs its SXL protocol using DNS queries as part of their threat detection infrastructure1.

The distribution of 3600 and 14400 TTL values remains similar throughout most of the months, indicating that they are both equally popular TTL choices for MX domains. The 14400 TTL is prevalent as it is the default TTL value for MX records. The large 3600 presence is seen for a number of unique MX domains, and indicates a shift in industry towards lower MX TTL values, which corresponds to findings for other TTL values across resource records.

The 3600 and 86400 TTLs are the most popular choices for NS records. The 3600 TTL suggests that some domains require more flexible name server configurations, but it can also be as a result of administrators leaving flexibility in ease a name server for their domain fails, and may not point to the name servers for those domains being less reliable than for other domains.

The 300 TTL is by far the most popular configuration for AAAA records, a similar trend to the A records captured in the dataset. An increase in 86400, 3600 and 1800 TTL values for AAAA records led to the decrease in 300 TTL presence in May 2015, This change in TTL configuration remains the same in the months following May, barring August 2015 where the 1800 TTL was favored over the 3600 TTL, but otherwise similar to previous months. The noticeable drop in 300 TTL frequency for December 2013 comes about as a result of a large 200 TTL presence for subdomain responses to the exodus,desyne.com domain; examples being EXOduS. DEsYNc. Com, exOduS.DEsYnC.coM, EXODUs.dEsYNc.COm among others. This phenomenon could be due to 0x20 bit manipulation (Dagon et al, 2008), and is discussed further in section 5,3,2,

SOA records show a strong preference for the one day TTL, EFC 1035 stated that SOA TTL

1 https: / / www.sophos.com / en-us / support/knowledgebase / 117936.aspx

44

http://www.sophos.com

values should be set to 0 to prevent caching (Mockapetris, 1987b), but this was amended in EFC 2181, which notes the comment and refutes it, suggesting that SOA records can utilize other TTL values (Elz and Bush, 1997),

Interestingly, the 300 and 3600 TTL presence for SRV records is frequent throughout the dataset, EFC 2782 states that SRV weight should only be used statically, and dynamic server selection would require lower TTL values that would clutter network caches and increase bandwidth use (Gulbrandsen et al, 2000), It would seem that the increase in network speed, bandwidth and cache memory have allowed administrators to take greater advantage of SRV records with respect to the estimation and selection of services related to their domain,

EFC 1033 recommends TTL values of between one day (86400 seconds) and 1 week (604800 seconds), and suggests only lowering the TTL values if changes are expected (Lottor, 1987), This EFC was written in 1987, and its recommendations are far removed from the current TTL distribution observed in the dataset, in which the majority of the top ranking TTL values fall under one day,

4.1.4 0 TTL presence analysis

Below is an explanation to the large 0 TTL presence seen between December 2013 and September 2014, The presence of disposable domains will be discussed and a review non-disposable 0 TTL domain activity given,

4.1.4.1 Disposable Domains:

Approximately 99% of the unique 0 TTL packets in each dataset were hosted by mailshell.net, a domain owned by m ailsh e ll2, an Internet security hrm that offers email-, web- and dns-hltering as well as anti-phishing solutions. This is as a result of their employment of disposable domains in their service (Chen et al, 2014), The 0 TTL is set, in this instance, to ensure that DNS cache servers are not overloaded by creating cached records for multiple thousands of one-use domains, which would severely affect the performance and memory of the DNS caching sever in question. While both spamhaus.org and mailshell.net are mentioned in Chen et al (2014), spamhaus domains did not result in a noticeable influx of 0 TTL packets ,

4.1.4.2 Non-disposable 0 TTL presence

Not included in table 4,3 are in-addr,arpa responses for TeamViewer servers, TeamViewer is a remote access and online collaboration service3, and will as a result generate one-use records so

2http://www. mailshell.com/ns/3https://www.teanrviewer.com/en/index.aspx

45

http://www

https://www.teanrviewer.com/en/index.aspx

that end hosts can connect to the created server on the end-host that is hosting the session. These PTE responses also had a 0 TTL set, but these responses are similar to disposable domains in the sense that they are one-time use and so have not been included in the following analysis. Table 4,3 concerns itself with only the months that had the 0 TTL present in the top ten TTL ranking.

Table 4,3: Top 10 normalized frequent 0 TTL domains

R a n k J a n 14 F eb 14 M a r 14 J u n 14 J u l 14 A u g 14 S e p 14

1 o u tlo o k .c o m o n tlo o k .c o m o n tlo o k .c o m o n tlo o k .c o m o u tlo o k .c o m o u tlo o k .c o m o u tlo o k .c o m2 e s p ie r .m o b i li ic liin a .c o m d o m o b ile .c o m sp o tify .c o m d s tv .c o m s ite 2 u n b lo c k .c o m d s tv .c o m3 d s tv .c o m d s tv .c o m s h a re s d k .c n d s tv .c o m sp o tify .c o m c tn s n e t .c o m sp o tify .c o m4 n b p iis h .c o m liv e .c o m d s tv .c o m s n p e r s p o r t .c o m s u p e r s p o r t .c o m d p l iv e u p d a te .c o m s u p e r s p o r t .c o m5 liv e .co m ly ric s 0 0 7 .c o m liic li in a .c o m liv e .n e t o ld m u tu a l .c o .z a d s tv .c o m p la y t im e .b g6 s in k d n s .o rg to p n e w in fo .c n d r e s s th a t .c o m te d ro 2 .f r l iv e .n e t h id e b iiN .c o m te d ro 5 .f r7 s u p e r s p o r t .c o m s n p e r s p o r t .c o m s a le s 2 0 0 .c o m o ld m u tu a l .c o .z a a m n e ts a l .c o m n s 3 7 .n e t o ld m u tu a l .c o .z a8 liv e .n e t liv e .n e t liv e .c o m liv e .c o m v ita l te k n o lo j i .c o m s u p e r s p o r t .c o m g re e n tr e e a p p s .r o9 g r e e n tr e e a p p s . ro g re e n tr e e a p p s .r o jo y o g a m e .c o m w w iio n lin e .c o m g re e n tr e e a p p s .r o n a ru to g e t .c o m d s in t ic .n e t10 d o m o b ile .c o m e N p o rt-s n p p ly .c o m g o o d p lio n e .m o b i v i ta l te k n o lo j i .c o m v e e a m .c o m a n i l .n e t v i ta l te k n o lo j i .c o m

The outlook.com domain is almost always the leading contributor of 0 TTL responses, not including disposable domains. This is as a result of Microsoft configuring their outlook.com replies to have a TTL of 0, most likely to prevent an overconsumption of DNS memory on caching resolvers. The domains live.com and live.net also fall under the Outlook DNS infrastructure. Almost all of these queries are A queries. The three most interesting results here are dstv.com, supersport.com and oldmutual.co.za, not only because of the South African context, but also because all three of them (Old Mutual to a lesser extent) are among the top 10 contributors to the 0 TTL response traffic, A breakdown of these three domains will be given below,

dstv.com : DSTV subdomain responses have TTLs of either 600 or 0, All of the 0 TTL responses are for A queries, and have 18 individual subdomains responding with a 0 TTL, Responses for the dstv.com domain also return 0 TTLs, There is evidence that the resolved IP changes between queries for this domain, which suggests either active server load-balancing or the mimicking of CDN-like behavior from the domain,

supersport.com: The supersport responses are also all A queries. While there is a positive TTL presence for supersport CNAME queries, all A queries return a 0 TTL for seven subdomains seen in all ten months and two subdomains seen in May and June, Responses for supersport.com and supersport, mobi also return 0 value DNS TLLs, which suggests that the domain administrators set the TTLs to prevent record caching.

46

oldmutual.co.za: Old Mutual returns 0 TTLs for six subdomains present in each month, including responses for A queries for www.oldmutual.co.za. As with the previous two, all of the 0 TTL queries are A queries.It was suggested in Larson and Barber (2006) that a 0 TTL presence indicates that the owner of the domain is planning to change the way their domains are configured, and wants to ensure that the expiring configuration is not cached. This does not seem to be the ease with the three domains in question, as they sustain their TTL values throughout the ten month period. One reason that this TTL value is set to 0 would be that it gives the managing entity of the authoritative server the ability to instantaneously reroute traffic to different servers for each query. While this has the benefit of allowing for maximum data distribution management with respect to servers, it creates a much larger consumption of network bandwidth at the authoritative server, as it is queried every time a query is processed for the relevant domain. Setting a TTL of 0 is detrimental to both bandwidth consumption and load experienced by the authoritative server of the domain (Larson and Barber, 2006), as the domain query is forwarded to the authoritative server every time the query is made by an end host, instead of being served by a local cache server.

4.2 Analysis on authoritative servers for .za domains

Authoritative servers for domain records are not necessarily topologically or geographically near the servers that query for those domains, nor are they necessarily in close proximity to the content servers for which they hold the domain record. This could occur for a number of reasons, including but not limited to: off-shore hosting being cheaper than local alternatives; international web-hosts offering a more secure or complete service than local counterparts; or multinational corporations that manage their DNS infrastructure from the original country. This chapter looks at the geographical distribution of authoritative servers responsible for .za domain replies, in order to determine the geographical authoritative server presence for local (in this ease .za) domains. Further analysis is done on the DNS-based latency experienced when querying for these domains. This is intended to give the reader an idea of the effect that server location has on end-user latency experience, as well as allowing for a comparison of experienced latency times for international servers.

4.2.1 Geolocation of .za authoritative servers

Table 4.4 shows the top ten countries that have a .za domain authoritative server presence. These countries are ranked by the percentage of unique IP addresses that respond with replies to .za queries. The country names have been abbreviated using ISO 3166-1 alpha-2 codes 4,

4 http: / / data.okfn.org/data/core / country-list

47

http://www.oldmutual.co.za

Table 4,4: D istribution of unique IP responses for .za domains

Rank 1 2 3 4 5Month Country %ofTotal Country %olTotal Country %olTotal Country %ofTotal Country %olTotal

October 2013 US 444)12 ZA 36.267 UK 7.028 DE 5.050 NL 1.296November 2013 US 444)80 ZA 36.605 UK 6.532 DE 5.344 NL 1.432December 2013 ZA 434)03 US 37.947 UK 6.741 DE 5.618 CA 1.379January 2014 US 43.627 ZA 36.542 UK 6.623 DE 5.814 NL 1.386February 2014 US 43.526 ZA 36.573 UK 6.705 DE 5.605 NL 1.419

March 2014 US 42.479 ZA 37.191 UK 6.422 DE 5.563 NL 1.545June 2014 US 42.119 ZA 38.763 UK 6.109 DE 5.505 NL 1.395July 2014 US 43.053 ZA 37.601 UK 5.804 DE 5.276 CA 1.477

August 2014 US 40.726 ZA 39.516 UK 6.268 DE 5.389 CA 1.430September 2014 US 44.322 ZA 36.349 UK 6.281 DE 5.174 NL 1.432October 2014 US 44.541 ZA 36.166 UK 6.576 DE 4.932 NL 1.582

November 2014 US 45.008 ZA 36.116 UK 5.650 DE 4.623 NL 1.477December 2014 US 41.434 ZA 40.361 UK 5.496 DE 4.895 NL 1.417January 2015 US 44.425 ZA 37.456 UK 5.575 DE 5.192 NL 1.498February 2015 US 45.586 ZA 34.836 UK 6.337 DE 4.666 NL 1.608

March 2015 US 45.372 SA 35.579 UK 6.203 DE 4.691 NL 1.480April 2015 US 44.813 ZA 37.871 UK 5.206 DE 4.126 CA 1.350May 2015 US 42.717 ZA 38.261 UK 5.652 DE 5.000 NL 1.449June 2015 US 43.711 ZA 37.256 UK 5.865 DE 5.275 NL 1.475July 2015 US 43.586 ZA 36.917 UK 5.649 DE 4.555 NL 1.931

August 2015 US 42.964 ZA 38.808 UK 5.331 DE 4.665 NL 1.411

Rank 6 t 8 9 10Month Country %ofTotal Country %ofTotal Country %olTotal Country %ofTotal Country %olTotal

October 2013 CA 1.296 PP 0.819 AU 0.478 MU 0.307 SG 0.273November 2013 CA 1.048 PP 0.838 AU 0.454 SG 0.349 MU 0.314December 2013 NL 0.919 PP 0.817 AU 0.511 MU 0.460 PL 0.255January 2014 CA 1.155 PP 0.770 AU 0.616 MU 0.308 SG 0.270February 2014 CA 1.100 PP 0.816 AU 0.745 SG 0.319 MU 0.319

March 2014 CA 1.408 PP 1.133 AU 0.618 IE 0.378 SG 0.309June 2014 CA 1.244 PP 1.207 AU 0.641 MU 0.377 IE 0.264July 2014 PP 1.196 NL 1.161 AU 0.739 SG 0.352 MU 0.352

August 2014 NL 1.393 pp 1.173 AU 0.550 SG 0.513 MU 0.330September 2014 CA 1.334 pp 0.911 AU 0.683 SG 0.358 MU 0.325October 2014 CA 1.179 pp 1.055 AU 0.713 SG 0.310 IE 0.310

November 2014 CA 1.252 pp 1.220 AU 0.610 CH 0.353 IE 0.353December 2014 CA 1.374 pp 1.073 AU 0.472 SG 0.429 CH 0.386January 2015 CA 1.289 pp 1.080 AU 0.592 MU 0.314 CH 0.244February 2015 CA 1.513 pp 1.230 AU 0.820 SG 0.410 MU 0.284

March 2015 CA 1.322 pp 1.165 AU 0.756 SG 0.378 CH 0.252April 2015 NL 1.311 pp 1.080 AU 0.810 MU 0.347 IE 0.347May 2015 pp 1.268 CA 1.268 AU 0.580 SG 0.362 MU 0.326June 2015 pp 1.475 CA 1.180 AU 0.627 SG 0.295 MU 0.295July 2015 pp 1.567 CA 1.239 AU 0.656 SG 0.364 MU 0.328

August 2015 pp 1.294 CA 1.254 AU 0.784 MU 0.314 CH 0.274

The United States of America (US) is almost always the largest responder with respect to .za domains. South Africa (ZA), for which the country code top-level domain (ccTLD) is reserved, holds the second largest presence of unique IP responders. These two countries represent around 80% of the total replies seen for .za domains across the dataset. The United Kingdom (UK) and

48

Germany (DE) rank third and fourth respectively, showing a smaller authoritative server presence than the US or ZA presence, but consistently 3,5-4% higher than the responder presence seen from other countries, Canada (CA), France (FR) and the Netherlands (XL) are each responsible for between 1-2% of the responding servers, while countries that appear towards the end of the ranking include Australia (AU), Singapore (SG), Mauritius (MU) and Switzerland (CH),

Figure 4,3: Geographic heatmap of authoritative server presence for February 2015

Figure 4,3 shows a server distribution heatmap for February 2015, The United States of America and South Africa are the most densely populated, A lot of the servers are spread across Europe, with the West being favored slightly over the East, The Far East and Australia also have a notable presence, but there is no contact from most of Africa, South America and the Middle East (not including Turkey),

4.2.2 Topology of .za domains

Table 4,5 describes the IP address and domain distribution with respect to /16 IP blocks observed in the dataset. The 196,0/16 and 197,0/16 IP blocks are local IP blocks, while the other /16 IP blocks represent international authoritative servers.

49

Table 4,5: Top 5 /16 network topology seen in .za dataset

M outh It. 7 o f UUtqt-C 11'̂ lo 7 o f UUtqt-C If* -16 7 o f u u iq u e IPs // o f dom ains -16 7 of u u iq u e IP s // o f dom ains -16 7 o f u u iq u e IPs // o f dom ainsO c to b er 201.! 2d.-|.2.’ii 2 .o o l S2 l o l . l . ’i 2.111.1 i l l 17-1.120 i.77-1 103 196.-11 i.672 992 196.27) 1.7)37) 7)9-1

_\o’ CUllX'f 2 0 l.l 102. S3 .1.012 i l l 2d."i.2."i .I..;.-!.; 90 16-1.17)1 i.886 97) 208.76 1.87)1 f>0 196.-11 1.711 967)D ecem ber 2 0 1 .: 192. s7. .1.770 SO 2d.-..2.-i 2.20S -Id 197.2-12 2.117) 629 196.27) 2.0-13 362 196.17) 1.788 171Jam : a t1 2011 102. s7. .-..io« 17.1 2d."i.2."i .1.000 id s 16-1.17)1 1.8-18 9-1 197.221 LSiO i 262 208.76 1.617 60l-ebruar1 2 d i l 102. s7. :..o7o 2iS 2d."i.2."i 1.202 117) 197.221 2.07)7,') i 7)17) 16-1.17)1 1.987 103 197.2-12 1.667 i -13-1

M arch 2 d i l 102. s7. 1.017. 2do 2d."i.2."i .1.017. 103 208.76 2.679 60 16-1.17)1 1.889 107) 197.221 1.77)1 i 7)83Ju u c 2 d l l 2d.-|.2.’il 1.71.1 s s 1 0 2 . 1 s i 1..171 163 208.76 2.-113 -17 16-1.17)1 2.112 102 197.2-12 1.737) 3 38-1J u b 2 d l l 102. s7. :...-i22 lo.l 2d."i.2."i 1.17.1 87 208.76 2.077) -18 197.2-12 2.077) i 37)1 16-1.17)1 1.970 102

A t- u * t 2 d l l 102. s7. l.OfS.’i 17-1 2d."i.2."i .1.07.0 7 i 16-1.17)1 2.383 9-1 208.76 2.089 -1-1 197.221 2.016 i 7)20S ep tem b er 2 0 1 1 102. s7. o.odo 23s 2d.-..2.-i 1.10 i 97 16-1.17)1 2.278 117 208.76 2.180 66 197.2-12 2.117) 2 060

O cto b er 2011 102. S.i 7.0-li • l2o 2d."i.2."i 1..111 112 197.2-12 2.297) i 7)96 208.76 1.987) 7)6 16-1.17)1 1.892 117).Vo’ cm lxT 2 d l l 102. s7. 0.0 2o7 2d."i.2."i 7..KU 120 197.2-12 2.119 i 7)0 i 208.76 1.97)8 -17) 16-1.17)1 1.89-1 96D ecem ber 2 d i l 2d.-|.2.’i! 1.0 S2 1 0 2 . 1 s i 1.7.01 120 197.2-12 2.362 870 208.76 1.803 28 16-1.17)1 1.760 61Jam :am 2017. 102. S."i o.2 22.1 2d."i.2."i l.O i.l i l l 197.2-12 2.197) i 3 i i 208.76 2.07)6 39 197.221 1.777 i -17)7i-eb tuar’ 2017. 102. s7. 7.0 d 2sr> 2d."i.2."i .’i.Ol.l 137 197.2-12 1.97)7) i -19-1 208.76 1.892 -11 16-1.17)1 1.702 77

M arch 2d!.’. 102. s7. o.O.’.fs ■2)2 2d."i.2."i .-..(Ido 133 197.2-12 2.111 i 7)13 208.76 1.732 39 197.221 1.700 i 77)0A p ril 2dir> 2d.-|.2.’ii 7>.70S i l 102. i i .is 176 197.2-12 2.37)2 i 131 173.2-17) 1.928 96 197.221 1.737) i 180Ma’ 2d!:. 2d.-|.2.’ii 7).290 11 102. i 7>. 117. 177 197.2-12 2.029 i 301 173.2-17) 1.812 88 16-1.17)1 1.812 70Ju u e 2di."i 2d.-|.2.’ii (1.102 102. i r>.o-io 180 173.2-13 2.088 106 197.2-12 1.836 i 307) 197.221 i . 7)8-1 i -171J u b 2di.’i 2d.-|.2.’ii 7..O0O lo 102. i l.o.-.d 166 197.2-12 2.237) i 2-10 173.2-17) 2.127 100 16-1.17)1 1.766 70

A u -m t 2di."i 2d.-|.2.’ii 7>.S02 00 102. i l . s o i 17)0 197.2-12 2.313 i 17)2 173.2-17) 2.197) 98 16-1.17)1 1.803 68

International IP blocks show a greater unique authoritative server IP population with respect to the overall dataset, when compared to local IP blocks. This is expected as the overall dataset shows a greater international IP presence overall when compared to the local authoritative IP presence, as seen in table 4,4, What is interesting is that the local /16 IP blocks, while showing a lower concentration of unique authoritative IPs, resolve a larger number of unique domains when compared to international /16 IP blocks. This would suggest that, while there are less authoritative servers for .za domains in local IP blocks than in those abroad, the local authoritative servers are each responsible for a greater number of unique domains when compared to their international counterparts. This means that while there are many fewer individual authoritative servers resolving for .za domains in ZA IP space, the authoritative servers have a higher concentration of unique domains for which they are responsible, while international authoritative servers will usually not be responsible for more than a few domains,

4.2.3 Latency seen for .za domains

Table 4,6 gives a breakdown of average latencies observed when pinging authoritative servers for IP addresses in countries that showed the largest unique authoritative presence for .za domains. The latency average was calculated using five ping times for each IP address gathered using fping, mentioned in section 3,2,5,

50

Table 4,6: Average latency observed for top geographical responders (ms)

M o n th US ZA UK D E C A FR NL AU M U SG C H average

O c to b e r 2013 276.286 34.618 207.554 211.347 302.967 210.893 199.195 463.123 48.587 424.825 469.554 183.012N ovem ber 2013 279.754 35.199 208.689 215.718 290.801 209.699 199.618 490.719 48.047 430.861 495.64 185.890D ecem ber 2013 272.860 35.129 208.314 209.746 282.925 212.030 198.139 472.424 48.102 424.287 205.27 170.524.January 2014 277.805 34.482 207.785 211.277 306.240 208.524 200.576 484.551 49.845 414.000 358.864 189.830F e b ru a ry 2014 278.857 37.287 208.382 211.259 301.336 211.363 200.669 455.243 51.378 432.027 337.486 190.986

M arch 2014 281.572 34.663 206.385 212.941 305.733 209.892 200.666 472.953 49.849 431.149 449.01 190.241Ju n e 2014 275.636 35.303 204.663 213.830 307.309 210.019 199.286 472.308 48.748 404.518 460.546 183.843Ju ly 2014 277.602 34.908 204.865 212.954 297.361 210.130 199.647 419.709 48.835 421.563 469.72 197.677

A u g u s t 2014 275.084 35.398 204.850 212.215 295.412 210.669 199.638 426.577 48.248 405.615 392.098 181.817S e p tem b e r 2014 275.447 35.714 206.487 213.049 295.243 210.843 199.208 471.075 46.435 405.493 372.460 190.042

O c to b e r 2014 276.721 35.995 207.785 213.422 300.604 214.637 199.433 407.581 52.717 421.670 233.153 190.171N ovem ber 2014 272.153 34.200 206.062 212.113 292.630 215.673 201.617 439.158 48.026 416.347 276.569 188.244D ecem ber 2014 266.606 35.351 206.050 210.893 295.532 212.514 198.222 474.102 50.521 425.329 268.484 175.467Ja n u a ry 2015 272.137 34.988 205.739 212.516 297.721 214.112 205.208 415.962 50.592 392.406 281.334 184.883F e b ru a ry 2015 271.639 35.014 206.615 211.855 293.922 210.437 207.940 406.656 48.813 430.411 238.043 190.670

M arch 2015 272.920 34.823 206.891 211.327 294.616 215.111 202.221 428.444 53.523 403.356 263.058 189.835A p ril 2015 265.890 36.384 208.618 210.568 297.100 217.660 200.310 417.436 51.074 412.997 231.114 182.553M ay 2015 263.138 35.241 204.626 212.392 299.306 211.390 207.056 419.618 48.033 423.698 269.632 178.598Ju n e 2015 262.072 34.721 207.098 212.169 297.443 210.875 199.401 395.310 49.879 423.375 233.248 179.586Ju ly 2015 263.363 36.387 208.168 211.364 297.779 211.598 205.483 399.366 52.033 411.820 216.381 180.947

A u g u s t 2015 261.170 35.878 207.233 215.389 299.126 217.183 201.157 418.732 52.653 405.993 266.483 176.032

Despite the US having the largest authoritative server presence for ,za domains, the average latency observed for these servers is higher than half of the top ten countries, being lower than only Canada, Australia, Singapore and Switzerland on occasion. The average US ping is roughly nine times that of its ZA counterparts, indicating that there is a significant DNS latency introduced by over half of the authoritative servers queried, when other locations are taken into consideration as well. Surprisingly, although Mauritius shows less than 1% of the overall authoritative server presence, it shows much lower latencies than more favored authoritative servers, Mauritius is also the only non-loeal area to offer latency rates below the observed average for the eleven most prevalent geographic authoritative server clusters.

One aspect of latency generation noted during research is that there is much greater fluctuation in latency generation in larger countries than smaller ones. This is believed to be the result of the distribution of authoritative servers across the landmass. For example a server in California would have a different distance and routing path from the pinging host than a server in New York, This fluctuation is more noticeable in the Australia dataset than the US and CA counterparts despite all three of them representing large land masses. This is as a result of there being less authoritative servers present from the AU region than the others, which leads to the data being less able to create a stable average than counterparts with a higher presence. The Switzerland latencies show a marked decrease from the beginning to the end of the dataset. There are two possible reasons for this. The first is that the number of unique IP addresses from the CH region is small, resulting in non-normalized fluctuation of latencies. The second is that pings to those IP addresses are instead rerouted to different servers for a response, or the reported geographic area

51

is incorrect with respect to the IP address. The latter is observed in other cases below.

Three IP addresses in the US dataset, 196,220,43,240, 196,220,42,13 and 196,220,42,14 respond with pings as low as 14ms throughout the dataset. While the IP addresses are registered for use in the United States, and placed in Atlanta according to RobTex5, they consistently return pings lower than the local average, which is physically impossible. Electrons simply cannot travel between the US and ZA in 14ms, This means that the pings are either being rerouted to a local server, or the end-host location of the IP address is not in the country for which it is registered. The IP 176,124,112,100 showed a similar ping time for the UK dataset. All four of these IP addresses are linked to name servers for ,za domains. These observed latencies are expected to be the result of the use of Anycast in the DNS implementation of these IP addresses. End-hosts that query these domains will be routed to the closest replica of the Anycast group (Sarat et al, 2006), Anycast is used not only to increase the availability and reliability of DNS records, but also to reduce experienced latency times (Sarat et al, 2006),

It is clear, when considering the results in subsection 4,2,1, that many queries to authoritative servers for ,za domains experience much greater DNS-based latency than ,za domains with local authoritative servers. The question, then, is why and to what extent the experienced latency is important.

In a 2012 paper discussing the reduction of network latency via redundancy, it was noted that increased latency times would decrease user visits to and interaction with the web medium which was affected by the latency (Vulimiri et al, 2012), The paper went on to cite two separate latency studies performed by Google (Brutlag, 2009) and Bing (Souders, 2009), Bing noted that a 500ms delay resulted in a 1,2% revenue drop, while a 2s delay resulted in a loss of 4,3% (Vulimiri et al, 2012), Google stated that a latency increase of between 100 and 400ms resulted in a reduction in user searches between 0,2% and 0,6%, with search frequency decreasing further as the time users were exposed to latency increased. They also found that search frequency would take time to recover even after the latency was removed (Brutlag, 2009), Amazon also stated that every 100ms latency penalty implies a 1% decrease in overall sales (Singla et al, 2014),

Older studies on user perception of injected latency found that users, when asked to rate webpages, would rate the pages lower as loading time increased. Interestingly, when asked to rate how interesting the web-page was, users would identify the faster loading web-pages as more interesting than the latency injected ones (Eamsav et al, 1998), This has large implications for international web-hosting, as increased local latency times could negatively affect the perception of the hosted web content, which is in some cases also the target userbase for the hosted content.

These papers suggest that even experienced latency at the level of a few hundred milliseconds could have a large impact on end-user experience, and that web-hosts using non-local authoritative

5https://www. robtex.org

52

https://www

servers are negatively impacting their website delivery and user experience, when compared to their local peers,

4.2.4 Domain breakdown

This section takes a deeper look at ,za domain characteristics by splitting the datasets into those for various sub-TLDs for the ,za ccTLD. An overview of authoritative server geoloeation and latency experienced is given. The TTL values and RE frequency for the different TLDs will also be considered and discussed with reference to the previous section. All of the TTL and EE values are taken from normalized datasets, which were processed in the same way as the normalized TTL dataset to allow for accurate comparisons. The geoloeation figures as well as the TTL and RR tables are excerpts from tables A,2 to A, 11 found in the appendix, which contain a top five breakdown for the former, a top ten breakdown of the latter, as well as relevant percentages,

.co.za Figure 4,4 illustrates the distribution of servers for the top five geographic responders. Servers from the US make up the largest authoritative contribution, followed closely by servers situated in ZA, There is a constant presence from UK and DE servers, which each represent around 5% of the total server presence. The fifth ranked country is for the most part the Netherlands, but is displaced by Canada in April 2014 and France in June 2015, These ratios indicate that a large number of DNS responses to .co.za queries experience higher latencies than the dataset average, particularly the large US presence that generates more latency than any other ranked country barring Canada,

53

Table 4.7 gives a breakdown of the most frequently observed TTL values for .co.za domains. The 7200 TTL is as popular for .co.za domains as the 300 TTL is for the entire dataset, representing about 25% of all normalized TTLs. Apart from the 86400 and 14400 TTLs, all of the other top five TTL values fall at or below two hours. The prevalence of the 7200 TTL throughout the .co.za dataset suggests that these domains have a higher TTL setting than the world average, at least with respect to those TTLs captured in the dataset. This is further supported by the lower ranking seen for the 300 TTL which retains the top rank throughout the overall normalized TTL dataset. A records are the most frequently seen RR with respect to .co.za domains, accounting for between 67% and 79% of unique reply packets. This indicates that most of the .co.za queries are redirected to servers hosting content, and a large amount of those, around 40%, experience nearly 300ms of latency. While latency costs are more negligible for MX queries, which rank second almost consistently, they have an impact on content experience by end users as stated in Vulimiri et al. (2012). While this latency cost is mitigated by the larger TTLs when compared to the overall dataset averages, it is not completely avoided.

54

Table 4,7: Top 5 observed TTL and RRs for .co.za

R ank 1 2 3 4 5 R ank 1 2 3 4 5M onth T T L T T L T T L T T L T T L M onth RR R R R R R R R R

O ctober 2013 7200 14400 86400 3600 600 O ctober 2013 A MX CX A M E T X T P T RN ovem ber 2013 7200 14400 86400 3600 600 Novem ber 2013 A MX CX A M E T X T AAAAD ecem ber 2013 7200 86400 3600 14400 600 D ecem ber 2013 A MX T X T CX A M E SOAJa n u a ry 2014 7200 3600 14400 86400 600 Ja n u a ry 2014 A MX CX A M E T X T AAAAFebruary 2014 7200 86400 14400 3600 600 February 2014 A MX CX A M E T X T AAAA

M arch 2014 7200 86400 3600 14400 600 M arch 2014 A MX CX A M E T X T AAAAJune 2014 86400 7200 3600 14400 600 Ju n e 2014 A MX CX A M E T X T SOAJu ly 2014 7200 86400 3600 14400 600 Ju ly 2014 A MX CX A M E T X T AAAA

A ugust 2014 7200 86400 3600 600 14400 A ugust 2014 A MX CX A M E T X T AAAASeptem ber 2014 7200 86400 3600 14400 600 Septem ber 2014 A MX CX A M E T X T AAAA

O ctober 2014 7200 3600 86400 14400 600 O ctober 2014 A CX A M E MX T X T AAAAN ovem ber 2014 7200 3600 14400 600 86400 Novem ber 2014 A MX CX A M E T X T AAAAD ecem ber 2014 7200 3600 600 14400 86400 D ecem ber 2014 A MX CX A M E T X T AAAAJa n u a ry 2015 7200 3600 600 14400 86400 Ja n u a ry 2015 A MX CX A M E T X T AAAAFebruary 2015 7200 3600 14400 600 86400 February 2015 A MX CX A M E T X T AAAA

M arch 2015 7200 14400 3600 600 86400 M arch 2015 A MX CX A M E T X T AAAAA pril 2015 7200 3600 600 14400 86400 A pril 2015 A MX CX A M E T X T AAAAM ay 2015 7200 3600 600 14400 86400 M ay 2015 A MX CX A M E T X T AAAAJune 2015 7200 600 3600 14400 86400 Ju n e 2015 A MX CX A M E T X T XSJu ly 2015 7200 600 3600 14400 86400 Ju ly 2015 A MX CX A M E T X T P T R

A ugust 2015 7200 600 3600 14400 86400 A ugust 2015 A MX CX A M E T X T P T R

.org.za The .org.za domains show a similar server distribution to .co.za domains. Figure 4,5 shows some differences when compared to figure 4,4 , The two most notable differences are the larger ZA server presence as well as the more prominent CA presence across the board. The .org.za responses were most frequently seen from ZA servers, accounting for around 50% of unique server responses. US servers were ranked second overall for server contribution. Interestingly, Canada ranked consistently fifth throughout the dataset. Canada records some of the worst latency averages in the dataset, which will affect between 2% and 4% of replying .org.za authoritative server packets.

A summary of the .org.za TTL and RR frequency is given in table 4,8. The TTL frequency is similar to that observed by the .co.za subset, but the 7200 TTL is more favored, accounting for between 29% and 51% of the observed TTLs. A records make up a more substantial part of this subset when compared to the .co.za subset. Between 76% and86% of RRs were A records. This suggests that .org.za queries also experience significant DNS based latency, but less so than the previous subset, as there is a higher ZA presence of authoritative servers coupled with the increase in the 7200 TTL prevalence.

55

Perc

enta

ge o

f tot

al a

utho

ritat

ive

serv

ers

Figure 4.5: Geographic distribution observed for authoritative servers of .org.za

Table 4.8: Top 5 observed TTL and RRs for .org.za

R ank 1 2 3 4 5 R ank 1 2 3 4 5M onth T T L T T L T T L T T L T T L M onth R R R R R R R R R R

O ctober 2013 7200 86400 3600 14400 600 O ctober 2013 A M X C N A M E T X T SOAN ovem ber 2013 7200 14400 86400 3600 600 Novem ber 2013 A M X C N A M E T X T SOAD ecem ber 2013 7200 3600 86400 14400 300 D ecem ber 2013 A M X T X T CN A M E SOAJa n u a ry 2014 7200 3600 86400 14400 600 Ja n u a ry 2014 A M X T X T CN A M E SOAFebruary 2014 7200 86400 3600 600 14400 February 2014 A M X C N A M E T X T SOA

M arch 2014 7200 3600 86400 14400 600 M arch 2014 A M X C N A M E T X T SOAJu n e 2014 7200 3600 86400 600 14400 Ju n e 2014 A M X C N A M E T X T SOAJu ly 2014 7200 3600 600 86400 300 Ju ly 2014 A M X C N A M E T X T SOA

A ugust 2014 7200 3600 14400 86400 600 A ugust 2014 A M X C N A M E T X T SOAS eptem ber 2014 7200 600 14400 3600 86400 Septem ber 2014 A M X C N A M E T X T SOA

O ctober 2014 7200 14400 3600 600 86400 O ctober 2014 A CN A M E M X T X T SOAN ovem ber 2014 7200 600 3600 14400 86400 Novem ber 2014 A CN A M E M X T X T AA AAD ecem ber 2014 7200 600 3600 14400 86400 D ecem ber 2014 A M X C N A M E T X T N /AJa n u a ry 2015 7200 14400 3600 600 86400 Ja n u a ry 2015 A M X C N A M E T X T AA AAFebruary 2015 7200 14400 3600 600 86400 February 2015 A CN A M E M X T X T N /A

M arch 2015 7200 600 14400 3600 86400 M arch 2015 A CN A M E M X T X T AA AAA pril 2015 7200 3600 600 14400 300 A pril 2015 A M X C N A M E T X T AA AAM ay 2015 7200 3600 600 14400 300 M ay 2015 A M X C N A M E T X T N /AJu n e 2015 7200 600 3600 14400 300 Ju n e 2015 A M X T X T CN A M E N /AJu ly 2015 7200 600 3600 14400 300 Ju ly 2015 A M X T X T CN A M E N /A

A ugust 2015 7200 3600 600 14400 300 A ugust 2015 A M X T X T CN A M E N /A

56

.gov.za Unsurprisingly, the largest region contributor for .gov.za domains is South Africa, as seen in figure 4.6. As gov.za domains are usually maintained by the local government, it comes as no surprise that there is a large local authoritative server presence, as well as a small international one. This would suggest that there is relatively low overall DNS latency presence when serving content from .gov.za domains. The US presence is ranked 2nd throughout the .gov.za dataset, and there infrequent replies from servers in the UK, DE and NZ regions. One concern with the government not managing authoritative servers in-house, let alone locally, is that it will be difficult if not impossible for them to respond if the international authoritative server for their domain goes offline.

Figure 4.6: Geographic distribution observed for authoritative servers of .gov.za

Table 4.9 gives an overview of .gov.za domains for which non-local authoritative servers gave replies. Some domains have local authoritative replies, indicating that the non-local servers most likely serve as a redundancy mechanism in case of unavailability of local authoritative responders. Some domains however, including the Eastern Cape Departments of Education ( and Health(ecdoh.gov.za)show no local responding servers. This suggests that the domain maintenance may

have been outsourced to third party management, and is not run by local goverment administrators. Interestingly, most of the domains resolve locally themselves, while five are hosted internationally and one returns NXDOMA1N responses at the time of writing, ft is possible that the websites with local domain hosting and international authoritative servers are the result of legacy infrastructure, while it is more likely that the management of the sites hosted abroad is completely outsourced.

57

Table 4,9: .gov.za domains using non-loeal authoritative servers

Domain (.gov.za) Server Local IPs International IPs Domain hosted locallyaarto NZ 1 1 Yes

breedevallei CA 0 1 Yeseamdeboo US 3 1 Yes

ehrishanidm UK 0 2 Yeseedoe US 0 2 Yeseedoh US 0 2 NXDOMAIN

eedoereseareh US 0 2 No - USengeobolm US 1 1 Yes

george US 0 1 Yesgis.bemm DE 0 1 Yeshessequa US 0 1 No - DE

Johannesburg DE 0 1 No -DEkouga US 1 1 Yes

kznunemplovedgrads US 0 2 Yeslesedilm US 0 1 Yes

rustenburg US 0 1 No - USStellenbosch US 2 1 No - DE

srvm US 2 1 Yesbvm UK 0 1 Yes

The .gov.za subset shows a large 600 TTL presence, accounting for between 26% and 34% of TTLs. This is also the only subset that has the 300 TTL ranked in the topfive5. This, coupled with the large A EE query presence (75%-86%) means that cumulative DNS based latency would be far greater than other subsets if a similar number of non-loeal authoritative servers were responsible for these domains. Fortunately, almost all of the responding authoritative servers are locally based, and while DNS based latency is still experienced, to individual end users it would represent a DNS latency cost of around 30ms, which is almost instantaneous when compared to other observed latency figures, such as the average latencies recorded in table 4,6. The fact that low TTLs are predominantly favored increases the risk of offshore authoritative servers. If the server crashes, locally cached records will time out relatively quickly, which will then prevent end-hosts from reaching the site, as the authoritative server is no longer responding.

58

Table 4,10: Top 5 observed TTL and EEs for .gov.za

Rank 1 2 3 4 5 Rank 1 2 3 4 5Month TTL TTL TTL TTL TTL Month RR RR RR RR RROctl3 600 3600 86400 7200 300 Octl3 A CNAME MX TXT NSNov 13 600 86400 3600 7200 14400 Novi 3 A CNAME MX TXT NSDecl3 600 3600 86400 7200 300 Decl3 A CNAME TXT MX N/AJanl4 600 3600 86400 7200 10800 Janl4 A CNAME TXT MX N/AFebl4 600 3600 86400 10800 300 Febl4 A CNAME TXT MX N/AMar 14 600 3600 86400 300 7200 Marl4 A CNAME TXT MX N/AJunl4 600 3600 86400 7200 300 Junl4 A CNAME TXT MX N/AJull4 600 3600 86400 300 10800 Jull4 A MX CNAME TXT N/AAugl4 600 3600 86400 7200 10800 Augl4 A CNAME MX TXT N/ASepl4 600 3600 86400 300 7200 Sepl4 A CNAME TXT MX N/AOctl4 600 3600 86400 300 10800 Octl4 A CNAME TXT MX N/ANov 14 600 3600 86400 7200 300 Novi 4 A CNAME MX TXT N/ADecl4 600 86400 3600 7200 300 Decl4 A CNAME MX TXT N/AJanl5 600 3600 86400 7200 300 Janl5 A CNAME TXT MX N/AFebl5 600 3600 86400 7200 300 Febl5 A CNAME TXT MX N/AMar 15 600 3600 86400 7200 300 Marl 5 A CNAME TXT MX N/AApr 15 600 3600 86400 7200 43200 Apr 15 A CNAME TXT MX N/AMay 15 600 3600 86400 10800 14400 May 15 A CNAME TXT MX N/AJunl5 600 3600 86400 300 43200 Junl5 A TXT CNAME MX N/AJull5 600 3600 86400 300 14400 Jull5 A MX TXT CNAME N/AAugl5 600 3600 86400 300 43200 Augl5 A TXT MX CNAME N/A

.ac.za The geographic distribution of authoritative servers for .ae.za domains is illustrated in figure 4,7. The .ae.za dataset shows a strong ZA presence, but is ranked third for both ZA frequency and US frequency when compared to other ,za subsets. This subset also shows a favoring of DE authoritative servers over UK servers when compared to the overall results, as well as more notable AU presence. The large ZA presence is also expected here, as most academic institutions manage their domains internally. The .ae.za domains will overall generate less latency than their .co.za and .org.za counterparts, but more than .gov.za and other ,za domains as a result of the larger US and AU presence.

The ae.za dataset shows an 86400 TTL presence much higher than the dataset average, with between 41% and 53% of all TTL values for this subset, and retains the first rank throughout all months. While the A record presence is lower on average than other ,za subsets, it shows greater variation, with between 56% and 80% of EEs being A records. While this subset has a strong ZA authoritative server presence, it also has a non-negligible international server presence, including a higher Australian authoritative server percentage than other subsets, which results in high latency values. Nonetheless, the 86400 TTL presence as well as the 10800 TTL presence in the top five ranks, works to greatly mitigate the effects of DNS-based latency on queries, as they are more likely to have live entries in the local cache servers than other subsets, based on TTL alone.

59

Perc

enta

ge o

f tot

al a

utho

ritat

ive

serv

ers

Time (months)

Figure 4.7: Geographic distribution observed for authoritative servers of .ae.za

Table 4.11: Top 5 observed TTL and RRs for .ae.za

Rank 1 2 3 4 5 Rank 1 2 3 4 5Month TTL TTL TTL TTL TTL Month RR RR RR RR RROctl3 86400 3600 10800 900 7200 Octl3 A CNAME MX TXT 7200Novl3 86400 3600 10800 900 300 Novl3 A CNAME MX TXT 300Decl3 86400 3600 10800 900 600 Decl3 A MX TXT CNAME 600Janl4 86400 3600 10800 900 600 Janl4 A CNAME MX TXT 600Febl4 86400 3600 10800 900 600 Febl4 A CNAME TXT MX 600Marl4 86400 3600 10800 900 600 Marl4 A CNAME MX TXT 600Junl4 86400 3600 60 900 600 Junl4 A CNAME TXT MX 600Jull4 86400 3600 10800 900 600 Jull4 A CNAME MX TXT 600Augl4 86400 3600 900 10800 1800 Augl4 A CNAME MX TXT 1800Sepl4 86400 3600 900 1800 10800 Sepl4 A CNAME TXT MX 10800Octl4 86400 3600 900 10800 1800 Octl4 A CNAME TXT MX 1800Novl4 86400 3600 900 10800 1800 Novl4 A CNAME MX TXT 1800Decl4 86400 3600 900 1800 10800 Decl4 A CNAME MX TXT 10800Janl5 86400 3600 900 10800 1800 Janl5 A CNAME MX TXT 1800Febl5 86400 3600 10800 900 1800 Febl5 A CNAME MX TXT 1800Marl5 86400 3600 900 10800 1800 Marl5 A CNAME MX TXT 1800Aprl5 86400 3600 10800 900 1800 Aprl5 A CNAME MX TXT 1800Mayl5 86400 3600 10800 900 1800 Mayl5 A CNAME TXT MX 1800Junl5 86400 3600 900 10800 1800 Junl5 A CNAME TXT MX 1800Jull5 86400 3600 10800 7200 1800 Jull5 A CNAME MX TXT 1800Augl5 86400 3600 900 1800 10800 Augl5 A CNAME MX TXT 10800

60

.za other Figure 4.8 gives a breakdown of server distribution for domains that do not fall under the previous four categories. The most notable difference between this and other subsets is the large presence of servers situated in Mauritius. This means that these domains will exhibit the lowest non-local DNS latency values for any of the subsets. There is also clear fluctuation with respect to geographical distribution for this dataset, as seen by the variation of frequency for any of the given geographic areas barring ZA. This is as a result of the subset of data containing less traffic than its counterparts, as well as the fact that there is little domain query continuity in this dataset, i.e. each month has domains that are not queried often and will not comprise queries in most other given months. In this dataset, the most frequent TLDs were school.za and net.za. Other notable TLDs include .mil.za, .edu.za, nis.za and .web.za.

Figure 4.8: Geographic distribution observed for authoritative servers of other .za domains

Table 4.12 shows the highest TTL values consistently ranking in the top five, where the 84600 TTLs and 86400 TTLs appear ranked first and third more frequently than lower TTL values. It should be noted here however that the overall large TTL presence is smaller than that seen in the .ae.za subset, as the two aformentioned TTLs combined account for between 40%-53% of observed TTLs, and will on average represent less of the overall TTL values than the 86400 TTL does for the .ae.za subset. The A RR frequency holds the first rank again, identical to other .za subsets, and represents between 68%-86% of unqiue responses. The frequency of higher TTL values coupled with the large ZA authoritative server presence suggests that DNS-based latency experienced for these domains is low on average. This is further strengthened by the large MU server presence,

61

which offers average latency only slightly above local latency averages.

Table 4,12: Top 5 observed TTL and EEs for other .za domains

Rank 1 2 3 4 5 Rank 1 2 3 4 5Month TTL TTL TTL TTL TTL Month RR RR RR, RR, RROct,13 3600 84600 86400 7200 600 Oct,13 A MX CNAME SOA N/ANovl3 84600 86400 3600 7200 600 Novl3 A MX CNAME SRV SOADecl3 84600 7200 86400 3600 600 Decl3 A MX CNAME N/A N/AJan 14 84600 86400 3600 600 7200 Jan 14 A MX CNAME TXT N/AFeb 14 84600 3600 86400 7200 600 Feb 14 A MX CNAME TXT SOAMar 14 84600 3600 86400 7200 600 Mar 14 A MX CNAME TXT SOAJunl4 600 84600 86400 3600 7200 Junl4 A MX SOA CNAME SRVJull4 84600 3600 600 86400 7200 Jull4 A MX SOA CNAME AAAAAugl4 84600 3600 86400 600 300 Augl4 A MX CNAME SOA N/ASepl4 84600 86400 600 3600 7200 Sepl4 A CNAME MX SOA TXTOct,14 84600 86400 600 7200 3600 Oct,14 A CNAME SOA MX N/ANovl4 84600 86400 3600 600 300 Novl4 A MX CNAME SOA TXTDecl4 84600 3600 600 86400 7200 Decl4 A MX SOA SRV CNAMEJan 13 84600 600 3600 86400 7200 Jan 13 A MX SOA CNAME NSFeb 13 84600 3600 86400 600 7200 Feb 13 A MX SOA CNAME TXTMar 13 84600 3600 86400 600 7200 Mar 13 A MX CNAME SOA TXTAprl5 86400 600 84600 3600 7200 Aprl5 A MX CNAME TXT SOAMay 13 86400 84600 600 3600 7200 May 13 A MX CNAME TXT N/AJunl5 86400 3600 84600 600 7200 Junl5 A MX TXT CNAME SOAJull5 86400 84600 600 3600 7200 Jull5 A MX TXT CNAME N/AAugl5 86400 600 84600 3600 7200 Augl5 A MX CNAME TXT SOA

4.3 N X dom ain analysis

Authoritative NX DOMAIN status codes are returned with responses when a domain queried at an authoritative server does not exist. Some NX DOM AIN traffic can be indicative of malicious network behavior; an example of this being continued queries for domains that respond with correct NX DOM AIN responses that show positive TTLs (Oberheide et al, 2007), However, more often than not, NX DOM AIN status code generation is the result of host misconhguration (Kumar et al, 1993) or as a result of Internet spam-filtering services utilizing the DNS protocol in their service (Jung and Sit, 2004), examples of which can be seen in table 4,15,

4.3.1 Observed NX TTLs and RRs

Tables 4,13 and 4,14 describe the top ranked TTL and EE values observed for normalised NX DO

MAIN traffic across the dataset. The 86400 TTL is for the most part the top ranked TTL, with the exception of June and July 2014,

62


Rank 1 2 3 4 5Month TTL % of TTLs TTL % of TTLs TTL % of TTLs TTL % of TTLs TTL % of TTLs

October 2013 86400 31.240 3600 8.311 900 6.779 10800 2.068 7200 2.016November 2013 86400 43.271 900 12.297 3600 11.122 7200 2.680 1800 2.276December 2013 86400 30.868 3600 14.983 900 8.552 7200 3.903 600 2.976January 2014 86400 39.490 3600 12.674 900 9.325 7200 3.129 1800 2.731February 2014 86400 49.997 3600 10.428 900 8.319 7200 2.385 300 2.047

March 2014 86400 48.802 3600 10.819 900 10.416 7200 2.526 1799 2.419June 2014 900 34.501 86400 27.912 3600 9.909 1799 3.044 7200 2.552July 2014 900 35.680 86400 24.218 3600 7.385 7200 1.905 600 1.749

August 2014 86400 37.359 900 25.000 3600 6.195 1799 4.560 7200 1.694September 2014 86400 35.655 900 20.132 3600 7.146 1799 2.902 7200 1.647October 2014 86400 23.018 900 9.952 3600 3.798 1799 1.363 10800 2.116

November 2014 86400 12.031 900 3.012 3600 2.518 1799 1.011 10800 0.926December 2014 86400 13.369 3600 5.004 900 4.928 600 0.910 10800 0.848January 2015 86400 7.397 900 3.213 3600 2.778 1799 0.718 600 0.551February 2015 86400 25.401 3600 1.897 900 1.857 1799 0.749 600 0.381

March 2015 86400 18.275 900 2.646 3600 2.497 1799 1.002 600 0.495April 2015 86400 18.300 900 2.902 3600 2.293 1799 0.881 600 0.546May 2015 86400 26.532 900 4.077 3600 2.950 1799 1.893 600 0.709June 2015 86400 16.499 3600 5.318 900 3.102 1799 1.847 21599 0.771July 2015 86400 20.874 3600 6.776 900 4.577 1799 2.238 600 0.770

August 2015 86400 21.630 900 1.904 3600 1.543 1799 1.290 600 0.393

Two interesting TTL values, the 1799 and 21599 TTLs, stand out as they are not standard TTL values, which are almost always multiples of 60, Surprisingly, both of these TTL values are response TTLs from 8,8,4,4 and 8,8,8,8, the two Google DNS servers. Clients in the observed IP block generating NX DOMAIN queries by sending miseonhgured packets directly to the Google DNS servers instead of routing them through the local cache servers will often see these TTL values in response.

The increase in the 900 TTL frequency is directly related to the increase in MX EE frequency seen for the same months. These months saw the cache servers send MX queries with between four and six seemingly random letters, and is expected to be the result of a brute force mail server search from an affected spam bot, or a compromised host being used as an open mail relay (Sehonewille and van Helmond, 2006),

63


Rank 1 2 3 4 5Month RR % of RRs RR % of RRs RR % of RRs RR % of RRs RR % of RRs

October 2013 A 72.580 TNT 12.737 PTR 5.874 MN 3.500 AAAA 2.108November 2013 A 67.910 TNT 17.072 PTR 5.129 MN 3.613 AAAA 2.955December 2013 A 42.509 TNT 25.945 PTR 15.480 MN 7.499 SOA 3.420January 2014 A 56.586 TNT 21.369 PTR 7.447 MN 5.983 AAAA 3.167February 2014 A 64.250 TNT 14.608 PTR 8.908 MN 5.397 AAAA 3.064

March 2014 A 66.166 TNT 14.573 MN 6.792 PTR 5.922 AAAA 2.897June 2014 A 39.743 MN 31.369 TNT 15.923 PTR 4.243 AAAA 4.182July 2014 A 34.893 MN 33.308 TNT 12.800 PTR 5.600 SRV 5.014

August 2014 A 46.427 MN 23.659 TNT 10.988 AAAA 7.385 PTR 4.328September 2014 A 52.574 MN 17.590 TNT 10.515 AAAA 8.461 PTR 4.790

October 2014 A 53.176 AAAA 12.731 SOA 10.780 MN 8.961 PTR 8.808November 2014 SOA 40.942 A 40.185 AAAA 7.169 PTR 5.366 TNT 2.952December 2014 A 49.396 SOA 31.331 MN 5.319 AAAA 5.174 PTR 4.255January 2015 SOA 53.659 A 29.980 AAAA 4.686 PTR 3.549 TNT 3.382February 2015 SOA 41.084 A 32.423 AAAA 16.222 PTR 4.863 TNT 2.688

March 2015 SOA 33.997 A 33.229 AAAA 13.882 PTR 12.331 TNT 3.723April 2015 A 58.532 AAAA 15.694 PTR 12.396 SOA 7.297 MN 2.704May 2015 A 56.061 AAAA 19.855 PTR 7.920 SOA 6.710 TNT 5.326June 2015 A 63.967 AAAA 16.170 PTR 6.397 SOA 5.624 TNT 3.799July 2015 A 58.649 AAAA 14.324 SOA 9.936 TNT 7.458 PTR 4.91

August 2015 A 78.924 AAAA 11.475 SOA 4.204 PTR 1.680 TNT 1.674

These two months show the largest MX presence, and exhibit a much higher percentage of overall EE traffic than other research suggests should be seen (Zdrnja et al, 2007), The large SOA presence in November 2014, as well as between January and March 2015, are as a result of miseonhgurations seen for 196,x,x,162, and will be mentioned in subsection 4,3,3,1,

4.3.2 Top Cache NX traffic

Most of the observed NXDOMAIN responses for the caching servers were from DNSBLs (Jung and Sit, 2004), Many DNSBL services receive queries for IP addresses attached to a domain registered for that DNSBL, and will respond with an NXDOMAIN response if the identified IP address is not found on the list itself (Yadav and Eeddv, 2012), Table 4,15 is a list of the DNSBL services for which NXDOMAIN responses appeared. These responses were filtered out as they are not true NX responses, but form part of the DNSBL framework (Yadav and Eeddv, 2012), As such, they are not actually representative of queries for domains that do not exist.

64

Table 4,15: Domain extensions seen in DNSBL NXDOMAIN responses

Domain TLDspamhaus.org

uribl.commulti.surbl.org spameop.net

seore.senderseore.com sa-aeeredit.habeas.com

sa-trusted.bondedsender.org dnsbl. sorbs

sibl. support-intelligence. net list.dnswl.org iadb.isipp.com mailspike.net

mailpoliee.com

4.3.2.1 Responses from 146.231.128.1

The authoritative server hosted at 146.231.128.1 is responsible for the largest number of NXDOMAIN responses within the caching dataset. Table 4,16 describes the observed packet traffic as well as some of the commonly seen domain queries that led to NXDOMAIN responses.

Table 4,16: Packet breakdown of 146.231.128.1 NXDOMAIN traffic

Month i f of packets % of NX packets i f of domains Top domain i f of responsesOctl3 33 946 0.007 16 439 "l.async. org.za 860Nov 13 30 248 0.007 16 488 "l.async. org.za 954Decl3 21 715 0.005 8 736 "l.async.org.za 755Jan 14 24 282 0.005 10 251 "l.async.org.za 943Febl4 34 240 0.007 18 126 kwc-ntfs007. kc. ecape. school, za 1 082Marl 4 36 687 0.006 19 346 ns3.24ohone2014.co.za.async.org.za 961Junl4 19 092 0.006 7 897 "l.async.org.za 816Jull4 21 586 0.005 7 834 "l.async.org.za 1 475Augl4 24 343 0.006 10 059 "l.async.org.za 1 368Sepl4 20 360 0.004 7 166 "l.async.org.za 1 049Oct.14 10 670 0.002 5 080 hn. kd. ny. adsl. asy nc .org.za 290Nov 14 9 806 0.002 4 896 dO 11. alb ene. info. asy nc. org. za 633Decl4 8 895 0.001 5 613 hn. kd. ny. adsl. asy nc .org.za 151Jan 15 14 146 0.002 8 209 tiffin2.voipphoneonline.com.async.org.za 219Febl5 15 385 0.002 7 094 superpositions, enj oy daring, com. async .org. za 424Marl 5 12 432 0.001 6 071 gc.gc.ecape.school.za 144Aprl5 10 230 0.001 4 058 mtal.imxM. info, async. org.za 470May 15 17 559 0.002 4 183 mtal.imxM. info, async. org.za 1 958Junl5 15 110 0.001 5 036 dealzzy. net .async. org. za 1 366Jull5 10 652 0.001 5 552 ne73-nat. renet,. ru .async. org. za 222Augl5 11 397 0.001 5 870 193.189.116.67.host.e-ring.pl.async.org.za 410

Queries for the ::l.async.org.za domain are believed to be an IPv6 configuration error which creates

65

malformed IPv6 packets. Other domains of this type that appear throughout the dataset include ::1.org.za, fe80::l.async.org.za, ::1 and fe80::181f:20e5:e533:d,17.org.za amongst others. Table 4,16 also highlights instances of miseonhguration that leads to TLD domains being appended to the queried domain, for example dealzzy.net.async.org.za. The most common appended TLDs are async.org.za, org.za, school.za and ecape.school.za. These two miseonhgurations generated most of the observed caching NXDOMAIN responses throughout the entire dataset. Section 4,3,2,3 will look at some of the unexpected NXDOMAIN traffic that remains after these miseonhgurations have been filtered out.

4.3.2.2 Response cluster

There was a cluster of NXDOMAIN responses captured in February 2015, as seen in table 4,17, This is the only such cluster of responses captured throughout the caching dataset. All of the captured queries are for domains within the .local or .vp.local domain space. This is the result of a server miseonhguration that led to local network addresses being queried through global DNS,

Table 4,17: Packet clustering seen in February 2015

Source IP # of packets # of domains Top domain # of responses192.58.128.30 11 892 4 548 local 216192.5.5.241 11 874 4 544 local 193

202.12.27.33 11 816 4 509 local 178199.7.83.42 11 804 4 459 local 176198.41.0.4 11 804 4 490 local 165

193.0.14.129 11 784 4 507 local 197192.203.230.10 11 769 4 421 local 183

192.33.4.12 11 729 4 469 local 200192.228.79.201 11 725 4 465 local 177192.36.148.17 11 724 4 481 local 199192.112.36.4 11 689 4 454 local 209128.63.2.53 11 652 4 497 local 171

The IP addresses seen in the Source IP column all correspond to root DNS servers, which responded to these packets as the local TLD is not a registered or recognized TLD in DNS infrastructure. It has been suggested that the TLD be prohibited in an Internet-Draft (Chapin and MeFadden, 2011) that expands on RFC 2606 (Eastlake and Panitz, 1999), the RFC that speeihes reserved DNS TLDs, It was suggested that this be done as a result of the use of the .local TLD on private networks, where the presence of a global DNS doeal TLD may cause differences in resolution behavior for the TLD on different local networks, which poses a security threat (Chapin and MeFadden, 2011),

6 6

The ,su ccTLD is the ccTLD used by the old Soviet Union, which has persisted in the ccTLD registry after the dissolution of the state itself (Von Arx and Hagen, 2002), Continued legitimate use of the ccTLD is non-existent, but its use has been noted even in current years with respect to malicious traffic (Ling et al, 2014), Snort6, an intrusion detection system, flags ,su domains as possible malware activity (Hermanowski, 2015), A 2012 study that tracked DDoS activity listed the ,su TLD as the sixth most frequent TLD observed for victim URLs present in that dataset (Buseher and Holz, 2012), Table 4,18 describes the captured ,su ccTLD activity across the caching dataset.

4 .3 .2 .3 U n ex p ected N X D O M A IN traffic seen at caching servers

Table 4,18: Packet breakdown of ,su ccTLD cache traffic

Month # of packets # of domains Top domain # of responses # of source IPsOct 13 116 40 ns.neic.nsk.su 39 25Novi 3 81 33 ns.neic.nsk.su 29 26Decl3 72 18 ns2.transfer.su 42 18Jan l4 32 12 finley.su 11 16Febl4 90 21 ns2.transfer.su 44 24Mar 14 34 20 www.su 10 18Jun l4 27 17 www.su 5 20Ju ll4 29 23 ns.neic.nsk.su 4 18Augl4 20 15 redsun.lvk.cs.msu.su 2 14Sepl4 34 21 host-176-107-248-ll.it-net.su 5 16Oct 14 53 24 sunnyweek.su 7 20Novi 4 92 29 nitmurmansk.su 30 27Decl4 25 22 46-161-129-86-nts.su 3 16Jan l5 236 20 bnswhat.su 105 15Febl5 644 13 bnswhat.su 382 9Mar 15 169 59 bnswhat.su 61 18Aprl5 130 15 host-94.198.132.vernet.su 103 16Mayl5 145 68 luposer.su 19 15Jun l5 30 19 ns2.airlink.su 6 16Jull5 12 8 tracker.irc.su 2 8Augl5 20 15 host-77.91.195.112. vernet. su 3 15

The amount of captured ,su traffic for the caching dataset is small. Some of the captured domains are most likely the result of DNS miseonfiguration, for example the www.su domains captured in March and June 2014, as they are lacking an actual domain to resolve. Two months that exhibit strange domain activity are March and May 2015, where a number of pseudo-random, single-query domains with the ,su ccTLD were captured. Examples of the captured domains are jjheuuxwbvidq.su and jirsdtduo.su, among others. This traffic behavior seems to point to the

6https://www. snort, org/

67

http://www.su

http://www.su

http://www.su

https://www

presence of a fast-flux botnet (Yadav et al, 2012), using the ,su ccTLD to generate domains on which its C&C is hosted (Stalmans and Irwin, 2011),

4.3.3 Other NX traffic

This section looks at anomalous NXDOMAIN traffic captured between hosts on the local IP block and non-loeal DNS servers. Section 4,3,3,1 describes the packet behavior of a proxy server of a local network, while section 4,3,3,2 discusses captured ,su ccTLD domains seen in the same dataset,

4.3.3.1 196.x.x.l62

The system with IP 196,x,x,162 acts as a proxy address, and is a network address translation (NAT) server for a local network within the monitored IP block. As is seen in table 4,19, the miseonfiguration presence began in July 2014, and has persisted throughout the rest of the dataset.

The large SOA presence seen for the months of November 2014, and January through March 2015, seen in table 4,13 are generated by this IP address. The SOA queries are the result of miseonfiguration at the end-host, where unqualified domains are queried through the global DNS instead of of on the local network. These queries will query loealhost SSID names as domain names, for example Emmas-iPad, android-2d73b2b20838e999 and John-PC, XxxXxxxxx-HP (X/x has been used in place of the name and surname that identified the PC) is another such example, and was the most queried domain for the months of July and August 2014, The query miseonfiguration seems to be related to the presence of end-hosts on the wireless network, and their subsequent interaction with the NAT server.

Each month also shows a large Web Proxy Auto Discovery (WPAD) query domain presence. Browsers utilize Proxy Auto Configuration (PAC) to eliminate the need for manual proxy configuration, and WPAD, which is automatically enabled in most browsers, requests the URL of the PAC script from the DHCP and DNS servers (Smith, 2010), Attackers have been known to create malicious PAC servers in an attempt to compromise target hosts through WPAD, where the PAC server will deliver malicious code to the end-hosts (Pashalidis, 2003), Attackers are able to identify WPAD addresses, and subsequently respond with URLs that lead to malicious PAC scripts, by sniffing network queries (Smith, 2010), At least in the ease of 196,x,x,162 traffic, this could lead to multiple WPAD addresses being compromised. One known attack of this kind had an infected computer masquerade as a WPAD proxy, which then identified a compromised server as a Microsoft Update server, which led to uninfected hosts downloading malware that they believed to be Windows Updates (Sullivan, 2015),

6 8

Table 4,19: Packet breakdown of 196.x.x.l62 NXDOMAIN traffic

M o n th # o f p a ck e ts % o f m o n th N X p ack e ts # o f d o m ain s T o p d o m ain # o f re sp o n se s # o f sou rce IP s

O c to b e r 2013 47 0 .0 0 0 1 e x am p le .fake 47 1N ovem ber 2013 - - - - - -D ecem b er 2013 - - - - - -

J a n u a ry 2014 - - - - - -F e b ru a ry 2014 - - - - - -

M a rch 2014 - - - - - -

Ju n e 2014 682 0 .0 0 0 152 n s4 . s t ilep ro j ec t . com 57 126Ju ly 2014 384 617 0.086 25 701 X x x X x x x x x -H P 4839 3 134

A u g u s t 2014 204 984 0.051 18 482 X x x X x x x x x -H P 2583 1 944S e p tem b e r 2014 242 187 0.051 25 866 1 0 .in -a d d r .a rp a 6245 2 591

O c to b e r 2014 443 409 0.069 39 807 local 11 929 2 682N ovem ber 2014 537 288 0.082 34 902 local 13 723 2 479D ecem b er 2014 203 914 0.034 16 186 local 6 693 1 377J a n u a ry 2015 568 487 0.076 34 491 local 19 964 2 399F e b ru a ry 2015 595 689 0.073 26 889 local 29 322 1 421

M a rch 2015 453 410 0.050 16 639 local 35 166 98A p ril 2015 207 477 0.028 17 214 m ail 17 325 1208M ay 2015 266 140 0.030 17 991 local 37 444 66Ju n e 2015 243 009 0.018 24 085 local 32 473 78Ju ly 2015 283 559 0 .0 2 0 18 865 local 41 035 112

A u g u s t 2015 270 744 0.028 17 118 m ail 80 259 1 168

Another miseonfiguration that is seen at this address is the presence of PTE queries for addresses defined in RFC 1918, in this ease the 172,16,0,0/16 and 192,186,0,0/8 subnets (Rekhter et al, 1996), This gives potential attackers insights into the IP address space used behind the NAT, and creates a security threat as it better enables them to target end-hosts behind the NAT itself. The presence of RFC 1918 address miseonfigurations has been highlighted in other papers, most notably Zdrnja (2006),

The presence of the 47 example.fake NXDOMAIN queries in October 2013 stands out, as at that time none of the many server miseonfigurations seen in later months were present. These queries seem indicative of malware that points to a static DNS domain hosted on a compromised end-host. All 47 queries occurred within 2 ms, and were sent to an IP located in Vietnam, It is also possible, however, that the query presence is as a result of local queries for a fake DNS domain leaking to the global DNS during Network File System (NFSv4) testing by setting up a fake nameserver7,

4.3.3.2 .su ccTLD traffic

The .su ccTLD presence in the non-authoritative and non-eaehing NXDOMAIN dataset is sporadic, but contains a greater number of packets than those captured in the caching dataset. The nitmurmansk.su presence stands out as anomalous. Not only did it generate large volumes of packet traffic when compared to the other .su domains, it was also the most queried .su domain in November 2014 of the caching dataset, as seen in table 4,18,

7http: / / wiki.linux-nfs.org/ wiki/index.php/Fake_DNS_Realm

69

Table 4,20: Packet breakdown of ,su ccT L D traffic from other servers

M onth # o f packets # o f dom ains T op source IP # o f source IP s T op d e s tin a tio n IP # o f responses T op dom ain # o f responses

O c to b e r 2013 -N ovem ber 2013 -D ecem ber 2013 -J a n u a ry 2011 13 i 8.8.4.4 i 196.x.x.210 13 finley.su 13F e b ru a ry 2014 -

M arch 2011 1 i 8 .8 . 8.8 i 196.x .x .227 1 w w w .su 1J u n e 2014 -J u ly 2014 5 2 195.58.27.158 4 1 9 6 .x .x .l62 5 w w w .su 3

A u g u st 2014 2 i 195.58.1.145 1 1 9 6 .x .x .l62 2 n s.e -b u rg .su 2S ep tem b er 2011 -

O c to b e r 2014 61 5 155.232.135.5 2 1 9 6 .x .x .l62 61 low balance .su 20N ovem ber 2014 1 404 5 S.8.8.8 3 1 9 6 .x .x .l62 1 404 n itm u rm an sk .su 912D ecem ber 2014 1 170 4 155.232.135.5 3 1 9 6 .x .x .l62 1 170 n itm u rm an sk .su 896J a n u a ry 2015 1 509 6 155.232.135.5 5 1 9 6 .x .x .l62 1 507 n itm u rm an sk .su 1 278F e b ru a ry 2015 735 5 155.232.135.5 3 1 9 6 .x .x .l62 735 n itm u rm an sk .su 603

M arch 2015 1 338 5 155.232.135.5 3 1 6 9 .x .x .l62 1 338 n itm u rm an sk .su 1 109A pril 2015 51 5 155.232.135.5 3 1 9 6 .x .x .l62 51 n itm u rm an sk .su 26M ay 2015 1 i S.8.8.8 1 1 9 6 .x .x .l62 1 w w w .su 1J u n e 2015 24 6 41,0,1,1 21 1 9 6 .x .x .l62 6 inv isib le .m sk .su 16J u ly 2015 135 3 193,232.156,17 7 196,x.x.80 134 c razyerro r.su 118

A u g u st 2015 407 3 193,232.156,17 136 196,x.x.80 407 c razyerro r.su 393

The nitmurmansk.su domain is interesting as it is the top domain in the Other dataset from November 2014, as seen in table 4,20, and is the top domain for the caching dataset for November 2014 as well. This domain is also responsible for more packets each month than many other months combined. The large increase in packet frequency suggests a malware infection trying to reach a server for commands and updates. This is supported by the fact that the packets are usually generated by three IP addresses, but in the ease of 196,x,x,162, there could be multiple infected hosts behind the NAT,

4.4 Chapter Summary

This chapter builds on past work in the DNS operations sphere. Section 4,1 describes the current TTL implementations and practices seen on the Internet, The research shows that organizations are favoring lower TTL values, most likely because of the infrastructure flexibility that it provides, despite increasing network traffic and bandwidth cost. Many of the TTL values seen fall below the 15 minute value recommended by Wills and Shang (2000), Observed CDN TTL values are typically lower than other observed TTLs, ranging from 20 seconds to 10 minutes. The author believes that, overall, TTL values will decrease further as network performance increases in the future. The presence of large amounts of 0 TTL disposable domains is of interest, as this is created by DNSBL interaction, Jung and Sit (2004) noted an increase in DNSBL related traffic, and this data suggests that its presence has increased further, not only in quantity but also in variation of use.

The geoloeation, and subsequent latency generation of authoritative servers for ,za domains is discussed in section 3,6, The findings showed that the United States held the most unique au

70

http://www.su

http://www.su

http://www.su

thoritative servers, followed by South Africa, for the entire dataset. There were however large differences in authoritative server distribution for subsets of the ,za domain dataset. The .org.za and .eo.za domains were more likely to have international authoritative servers, while the .ac.za, .gov.za and (other),za domains were more likely to have local authoritative servers. The comparison of server location to generated latency showed that the large number of servers present at sites in the United States, Canada, and to a lesser extent Australia, were generating DNS-based latencies above the internationally observed average, and orders of magnitude higher than locally observed latencies.

Section 3,9 describes the NX DOMAIN response activity captured in the dataset, A large amount of this traffic was found to be generated by DNSBL services, which would use NX DOM AIN responses in their infrastructure to send confirmation that the tested address was not in the blacklist. After that had been filtered, it was found that the largest contributor to N.XDO.MAIN responses were server miseonhgurations. Varying miseonhgurations were captured, the most dangerous of which were WPAD queries, which give attackers information about WPAD server IDs, and PTE queries for addresses on the local network, which give attackers and monitors insight into the address block used by local networks. Filtering the discontinued ,su eeTLD also revealed interesting packet activity, much of which could be considered an indicator of malware activity on the network.

This chapter built on the knowledge of the fields relating to DNS TTL values and N.XDO.M AIN

response analysis, while also introducing new research from a South African context in the form of server geoloeation for authoritative servers of .za domains. This is especially important, considering the evidence that latency times in the order of hundreds milliseconds, affect user Internet experience and site loyalty. Considering this, .za sites that target a local audience should consider shifting their authoritative server to a locally based alternative, in order to not suffer the cost of DNS-based latency on their userbase.

71

Chapter 5

DNS Abuse

This chapter focuses on the malicious use and abuse of DNS infrastructure. Section 5,1 deals with DNS amplification attack scans captured in the dataset, and will look at packet throughput as well as the temporal relationship between amplification scans captured and reported amplification attacks. Section 5,2 describes the methodology used for identifying bitflips, as well as the identification and subsequent filtering of false positives. Section 5,3 discusses the analysis of the identified bitflips, bitflip identifiers, and possible bitsquats detected in the dataset.

5.1 D N S post-attack am plification scanning

Denial-of-Service (DoS) attacks are a type of attack used by malicious entities in an attempt to limit or discontinue legitimate services connected to a network, DoS attacks fall under two main categories. Crafting packets with the intent to exploit vulnerabilities in the implemented software of the victim host is the first category, while the second category focuses on the consumption of critical system resources, e.g, network bandwidth (Kambourakis et al, 2008), in an attempt to incapacitate the target host. Distributed Reflective Denial-of-Service (DRDoS) attacks are DoS attacks that use reflectors (Paxson, 2001), public servers that utilize UDP-based network protocols and respond to packet requests without the need for validation (Rossow, 2014), as part of the attack framework. The attacker will spoof the source IP of packets before sending them to the reflector, which will in turn forward the reply to the target host. These attacks are considered category two attacks as the aim is the consumption of resources and bandwidth, DNS amplification attacks are a class of DRDoS attack that exploits the fact that DNS protocols allow reply packets to be much larger than query packets. These attacks also take advantage of the fact that UDP packets are easily spoofed. This results in what is known as the amplification factor, which is the ratio of the size of the response to the request (Anagnostopoulos et al, 2013), DNS amplification attacks are conducted using open resolvers, which are public resolvers that process queries from any client

72

(Rossow, 2014), The Open Resolver project (Maueh, 2013) has identified over 19 million servers that reply to DXS packets, just over 14 million open resolvers returning the correct query response, which is considered to pose a significant network security threat (as of 3 November 2015), One of the reasons an open resolver attack is so effective is as a result of caching, which enables the resolvers to send the attack packet from its cache rather than repeatedly querying the attack domain, significantly increasing the speed and throughput of the attack.

Figure 5,1: Architecture of a distributed DXS scan

Figure 5,1 describes a suggested architecture for a distributed DXS scanning framework. Such a framework would explain the large unique IP TTL presence observed for individual IP addresses within the dataset. The fact that the domains used in the scans are from known attack domains would also suggest that the scanners are looking for open resolvers that have records for, or will respond to queries for, those domains, instead of dropping the queries as a result of filter settings at the open resolver itself. It is believed that the scans showing only a single IP TTL value use the same IP address to send and receive packets, similar to the scanning architecture suggested by Faehkha et al (2014),

5.1.1 Reported attacks

DXS amplification attack responses will only be seen by the targeted server, whose IP address has been spoofed in the query packets (Paxson, 2001), Xone of the IP addresses in the monitored /24 IPv4 block were the targets of DXS amplification attacks, and as a result only query packets were captured. This research relies on a website that reports on amplification attacks observed on a low

73

bandwidth open DNS server 1. The domains reported by the aforementioned are used to validate the fact that the captured scans are related to DNS amplification activity on the Internet, The attack dates, as well as attack packet sizes where referenced, are taken from the aforementioned and not recorded in the dataset itself.

5.1.2 Characteristics of captured scans

Table 5,1 outlines the composition of the captured scan traffic, A range of domains as well as target IP addresses were captured in the dataset. In the twenty-one months of data capture, only eleven unique domains appeared as the most frequently queried domain for any given month.

Table 5,1: Captured amplification scans

M onth — o f packets rr o f dom ains — o f ta rg e t IP s Top dom ain % o f m o n th ly scansO c to b e r 2013 300 304 17 85 30259.info 41.9C5

N ovem ber 2013 102 010 19 22 fkfkfkfa.com 14.793D ecem ber 2013 37 298 8 13 fkfkfkfa.com 39.183January’ 2014 21 818 11 11 fkfkfkfa.com 24.938February’ 2014 52 700 13 1C pddos.com 4G.55G

M arch 2014 44 505 C 15 ahuyehue.info 45.323Ju n e 2014 6 009 9 15 m agas.bslrpg .com 39.241Ju ly 2014 9 952 8 21 w radish .com 42.042

A ugust 2014 13 GOG 11 25 w ebpanel.sk 54.544S ep tem b er 2014 10 902 7 20 w ebpanel.sk 5C.3CC

O c to b e r 2014 7 900 1C 1C w radish .com 4C.C84N ovem ber 2014 C 148 8 1C w radish .com 24.C91D ecem ber 2014 C 593 10 25 globe.gov 31.382Ja n u a ry 2015 4 338 8 1C gransy.com 21.047F ebruary 2015 4 199 9 14 p id arasrik .ru 33.74C

M arch 2015 4 974 C 15 defcon.org 45.C78A pril 2015 2 583 5 7 defcon.org 48.974M ay 2015 3 044 9 7 defcon.org 29.928Ju n e 2015 4 095 C 10 defcon.org C8.449Ju ly 2015 2 793 4 5 defcon.org 74.472

A ugust 2015 978 5 5 defcon.org 33.742

October 2013 is the largest amplification traffic source for individual packets, number of unique domains represented as well as overall IP representation. Apart from October and November 2013, none of the subsequent months show a six digit packet influx. The domain repetition seen in the top domain field is also notable, especially the defcon.org domain, which is the most commonly seen domain for six consecutive months, and shows the highest individual domain representation percentage in the monthly datasets, A ease study of the October 2013 dataset as well as the defcon.org domain are given in subsections 5,1,5,1 and 5,1,5,3,

1 h ttp : / / dnsamplification attacks, blogspot ,co. za /

74

5.1.3 Temporal relation between scans and attacks

As the DNS Amplification Attack Observer only reports the day the attack was logged and not the time, all scans that occurred on the same day as the attack will be considered to have happened before the attack was reported. Table 5,2 makes reference to the scans that were recorded the day after the amplification attack using that domain was reported, A table describing the temporal relationship between all the captured scans of the dataset and the reported attacks can be found from tables A, 12 to A,32 in the appendix.

Table 5,2: Seans recorded the day after attack was reported

D o m ain R e p o r te d a t ta c k d a te * First re co rd e d scan # o f scan s a f te r a t ta c k L a s t re co rd e d scan

30259 .info 9 O c to b e r 2013 10 O c to b e r 2013 17 22 O c to b e r 201337349. info 15 O c to b e r 2013 16 O c to b e r 2013 44 18 O c to b e r 2013

a a .10781.info 12 O c to b e r 2013 13 O c to b e r 2013 4 16 O c to b e r 2013babyw ow .co .uk 11 O c to b e r 2013 12 O c to b e r 2013 6 18 O c to b e r 2013

g tm l2 .com 19 O c to b e r 2013 20 O c to b e r 2013 3 31 O c to b e r 2013k ra s ti.u s 18 O c to b e r 2013 19 O c to b e r 2013 1 19 O c to b e r 2013

p ip c v se m n a h e r . com 17 O c to b e r 2013 18 O c to b e r 2013 2 31 O c to b e r 2013c h ea tsh a re z .c o m 11 N ovem ber 2013 12 N ovem ber 2013 4 16 N ovem ber 2013

re a n im a to r .in 1 N ovem ber 2013 2 N o v em b er 2013 3 11 N ovem ber 2013s isk a l.c o m 9 N ovem ber 2013 10 N ovem ber 2013 2 17 N ovem ber 2013

t h e b es td o m a in in th e w o rld . c lo u d n s . eu 15 N ovem ber 2013 16 N ovem ber 2013 i 16 N ovem ber 2013t.p b u b .in fo 6 N ovem ber 2013 7 N o v em b er 2013 3 13 N ovem ber 2013

x .m p n p .in fo 14 N ovem ber 2013 15 N ovem ber 2013 2 17 N ovem ber 2013x .s ln m .in fo 17 N ovem ber 2013 18 N ovem ber 2013 i 18 N ovem ber 2013

a m p .c ra ck -z o n e .ru 22 D ecem b er 2013 23 D ecem b er 2013 2 27 D ecem b er 2013g ru n g v m a n .c lo u d n s . o rg 17 D ecem b er 2013 18 D ecem b er 2013 2 22 D ecem b er 2013

sa v e ro a d s .ru 2 Ja n u a ry 2014 3 Ja n u a ry 2014 2 15 J a n u a ry 2014x .x ip zersscc .co m 24 J a n u a ry 2014 25 Ja n u a ry 2014 i 25 J a n u a ry 2014

g e rd a r3 .ru 10 F e b ru a ry 2014 11 F e b ru a ry 2014 4 25 F e b ru a ry 2014ah u y eh u e .in fo 8 M arch 2014 9 M arch 2014 8 28 M a rch 2014

w w w .jrd g a .in fo 1 M arch 2014 2 M arch 2014 5 26 M a rch 2014la lk a .co m .ru 28 Ju n e 2014 29 J u n e 2014 3 30 Ju n e 2014w eb p an e l.sk 23 Ju ly 2014 24 Ju ly 2014 5 31 Ju ly 2014n lh o s tin g .n l 17 O c to b e r 2013 18 O c to b e r 2013 i 19 O c to b e r 2013

sv is t2 1 .cz 12 N ovem ber 2014 13 N ovem ber 2014 3 20 N ovem ber 2014

* all attack reports, as previously mentioned, are taken from dnsamplifieation,blogspot.com

Of the captured scans, 25 domains were scanned, sometimes by multiple IP addresses, the day after the attack was reported. There are many other scans that occurred from days to months after the reported attack, and a minority of scans that occurred shortly before the attacks were reported; as seen in tables A,12 to A,32, The data shows a clear link between attack dates and attack domain scanning behavior, particularly in the eases seen in table 5,2, There are multiple instances of scans being launched shortly after attacks have occurred, indicating that not only are these entities aware of the attacks, but that they attempt to take advantage of the domains used in the attacks themselves.

75

http://www.jrdga.info

The relationship between attacks and amplification scanning is important as it offers researchers another method by which to study amplification attacks without having access to peap hies that capture the attack itself. By looking at captured query scans that match the amplification scan profile, they are able to determine with some certainty that the present domain has been, or will be, utilized in a DNS amplification attack.

5.1.4 Target spoofing

A summary of the packet behavior of the IP address that generated the most packets in any given month is outlined in table 5,3, The most anomalous result seen here is the number of unique IP TTL values seen for any given IP address, A large number of unique TTL values is an indicator of IP address spoofing (Jin et al, 2003), IP address spoofing is a necessary part of DRDoS amplification attacks (Paxson, 2001), as this is how reply traffic is directed towards the victim.

Table 5,3: Top monthly spoofed IP behaviour

Month Top IP A of packets A of IP TTLs A of domains Top domain A of destination IPsOct 13 198.206.14.130 16 033 48 5 pkts.asia 253Nov 13 80.82.64.231 16 388 56 9 siskal.com 253Dec 13 94.102.56.229 9 429 56 3 amp.crack-zone.ru 253Jan 14 94.102.56.229 6 882 56 6 savcroads.ru 253Feb 14 46.105.111.230 10 401 54 2 pddos.com 253Mar 14 46.45.178.250 6 995 240 1 www.jrdga.info 181Jun 14 178.32.56.245 1 744 2 3 wradish.com 253Jul 14 178.32.56.245 3 830 5 2 wradish.com 253Aug 14 178.32.56.245 3 520 4 2 wcbpancl.sk 253Sep 14 23.95.82.66 1 771 2 2 wradisli.com 253Oct 14 198.23.213.90 2 530 1 4 wradisli.com 253Nov 14 192.3.186.210 1 265 1 2 wradisli.com 253Dec 14 89.248.172.169 759 1 1 globc.gov 253Jan 15 162.213.155.176 704 1 3 pidarastik.ru 253Feb 15 162.251.118.42 1 012 2 3 pidarastik.ru 253Mar 15 192.3.207.2 1 969 2 2 dcfcon.org 253Apr 15 192.3.194.138 759 2 1 dcfcon.org 253May 15 167.114.67.106 1 010 1 2 dcfcon.org 253Jun 15 167.114.173.202 1 767 3 1 dcfcon.org 253Jul 15 151.80.99.219 2 025 3 1 dcfcon.org 253Aug 15 104.255.70.245 472 1 3 globc.gov 245

Some of the characteristics seen in table 5,3 point more strongly to scanning behavior than amplification attack behavior. Amplification attacks will almost always target open resolvers (Rossow, 2014) to increase the overall packet throughput to the victim (Faehkha et al, 2014), This makes the traffic observed in the dataset anomalous, as there were not any operating open resolvers in the observed /24 IP block during the traffic capture period. Furthermore, all of the IP addresses

76


in the /24 IP block, not including 196.x.x.0 and 196.x.x.255, were targeted by the captured traffic, suggesting scanning behavior. Scanning for DNS open resolvers is a suggested source of the observed packet traffic, but would usually indicate that the source IP address is not spoofed, so as to gather meaningful data from the reply packets sent from open resolvers (Fachkha et al, 2014). This assumption is not supported by the large range of IP TTLs seen for many of the captured IP addresses.

5.1.5 Case studies

The following sections contain three case studies on the captured amplification query traffic. Subsection 5.1.5.1 gives a more detailed look at the month of October, the month that showed the largest packet influx as well as the presence of the most unique source IP addresses. Subsection5.1.5.2 looks at traffic related to the www.jrdga.info domain, which shows the largest collection of unique TTL values in the dataset, as well as one of the highest individual domain packet counts. Subsection 5.1.5.3 looks at the defcon.org domain, which is of interest not only as a result of its popularity as a scanning domain, but because it serves as a legitimate domain which is being exploited, and not a domain under the control of a malicious host.

5.1.5.1 October 2013

October 2013 is the month that showed the largest number of individual packets, as well as the second largest unique domain subset. The dataset is presented in two sections, the first for traffic with the .info ccTLD and the second for all other domains.

(a) .info domains

Figure 5.2: Timeseries for October 2013 scans by domain

Time (days)

(b) Other domains

The .info domain timeseries in hgure5.2a shows the two highest packet frequencies seen for a single domain in a one day period across the entire dataset. The 30259.info domain scans represent the

77


largest packet influx and contains 17 unique source IP addresses. The attack was reported on 9 October, after which 39 160 packets were captured on the 10th, 80 159 packets captured on the 11th, and 4 254 and 976 packets captured on 12 and 13 of October 2013, Further scans were recorded on 15, 16 and 23 October, but did not show similar packet values to the two days after the attack.

The 36372.info domain scans showed the second highest single day packet influx, totaling 41 484 on 14 October, the only day with captured scans. These scans are interesting as they all come the day before the attack was reported, and show eight unique source IP addresses. This seems to indicate that these scans were carried out in preparation for the attack launched the next day, and are not post-attack amplification scans, unlike many of the other captures.

The 37349.info scans are also notable. As is seen in figure 5,2a , there are only three scans recorded, the first coming the day after the attack was reported. While the packet figures are only 4 547, 3 045 and 945 packets for the three days that the scans were present, these domain scans showed the highest concentration of unique IP addresses in the dataset, totalling 44,

Of the 43 scans pictured in figure 5,2b, only four of them were captured pre-attack. One scan was captured for the irlwinning.com domain the day before the attack was reported, while a further two were captured on the day of the attack. One scan was also captured on the day of the attack report for the pkts.asia domain; the other 39 were all post-attack amplification scans. The pkts. asia domain stands out as it was the most commonly queried domain for the top source IP packet provider as seen in table 5,3, and also have scans that were captured across the entire month, including the first and last day, despite not appearing throughout the rest of the dataset. Overall there were only 11 unique IP addresses that scanned for the pkts.asia domain,

5.1.5.2 www.jrdga.info

Figure 5,3 is a timeseries of scanning activity for www.jrdga.info during March 2014, This domain was selected for the ease study due to the large unique IP TTL presence in the scans, the highest seen at any one time. The first scan, comprising 940 packets, comes one day after the attack was reported, as with many of the attacks mentioned in subsection 5,1,3, After a period without activity, there is another scan on the 9th, followed by a collection of 3 separate IP scans from the 24th to the 26th of the month. The most interesting aspect of this is the scan by 46,45,178,250 on the 24th and 25th, The first scan shows 237 unique IP TTL values for the 6244 packets of the same source IP, indicating a greater botnet size than for most other captured scans. While the scan on the 25th by the same IP address shows only 37 IP TTLs, and results in much fewer packets, there are unique IP TTL values present that were not recorded in the first scan, indicating that the botnet may have used different hosts to launch the second scan.

78



A breakdown of source IP activity is given in table 5.4. After the large scans observed in March, two additional but smaller scans were captured in July and September 2014, four and six months after the reported attack respectively. The July scan targetted all 253 IP addresses of the observed /24 IP block over the course of two days, and showed only one IP TTL value for all packets, indicating that the scanning server was both sending and receiving packets. The September scan targetted only 35 IP addresses, most likely as a result of random IP address generation, and showed 11 unique IP TTL values, lower than the values observed in March.

Table 5.4: IP characteristics of www.jrdga.info scans

D ate Source IP # of packets # of IP T T L s # of d e s tin a tio n IP s

2 M arch 2014 94.102.52.76 940 42 259 M arch 2014 94.102.63.238 2199 46 202

24 M arch 2014 46.45.178.250 6244 237 18125 M arch 2014 46.45.178.250 751 37 78

26 M ar 14 80.82.78.100 2478 96 18726 M arch 2014 142.0.41.225 976 41 122

3 Ju ly 2014 94.102.49.178 84 1 844 Ju ly 2014 94.102.49.178 169 1 169

17 S ep tem b er 2014 162.212.181.242 35 11 35

It is also worth noting that another domain scan in March 2014 returned 240 unique IP TTL values. A scan on 14 March for ahuyehue.info resulted in 5466 packets to 126 IP addresses in the observed /24 IP block. The number of unique TTL values as well as the fact that both scans

79


targetted less IP addresses than the total block comprises suggests that both scans were carried out by the same botnet, despite the source IP address of the scan in question not matching that seen for the www.jrdga.info scan,

5.1.5.3 defcon.org

The defcon.org scans offer an interesting ease study for multiple reasons. The first is that the targeted domain is a legitimate domain, and not a domain controlled by a malicious host. The second is the nature of the scanning captured in the dataset. As seen in table 5.5, the scanning is much more uniform, and there is less evidence of packet clumping as is seen with other domains, which produce thousands of packets in a single day.

Table 5.5: Number of packets received for defeon.org

D ay D ec 14 J a n 15 F eb 15 M ar 15 A p r 15 M ay 15 J u n 15 J u l 15

1 253 48 -2 253 -3 844 6025 3276 237 253 2537 253 253 2538 -9 253 253

10 103 -11 253 253 25312 249 30213 -14 253 506 -15 228 253 198 -16 253 55 -17 194 -18 253 312 -19 51 125 -20 253 253 128 -21 -22 253 -23 253 -24 224 253 -25 325 253 253 -26 271 -27 253 251 -28 55 253 254 -29 253 23 -30 266 253 -31 -

# o f IP s seen 9 3 5 3 2 3 4 3

The scanning behavior is also different from other captured domains in the sense that the same source IP address will perform multiple individual scans on the domain in a given month, as seen by the difference in packet representation between table 5.3 and packet distribution in table 5.5, particularly for June and July 2015. Table 5.6 shows that this behavior is not limited to a single

80


month, as some source IPs scan the same IP block with the same domain in different months as well, IP addresses that appear in multiple months have been bolded.

Table 5,6: IP addresses scanning defeon.org domains

Dec 14 Jan 15 Feb 15 Mar 15 A pr 15 May 15 Ju n 15 Jul 15198.7.63.129 173.242.112.113 96.8.115.114 192.3.207.2 192.3.194.138 167 . 114 . 67.106 167 . 114 . 173.202 151.80.99.219104.218.48.7 141.255.164.162 23.94.1913.82 64.16.211.238 167.114.67.106 178.19.106.10 167.114.210.12 199.168.139.13946.36.37.81 162.213.115.176 172.245.24.154 167.114.114.98 167 . 114 . 173.202 63.141.227.10 172.73.123.160

162.251.114.66 209.105.232.87 167 . 114 .67.10664.6.108.171 46 . 19 . 137.234

46 . 19 . 137.234192.129.201.106

192.3.34.2141.255.166.210

This is theorized to come about as a result of the defcon.org domain being a legitimate domain. Responding servers or open resolvers that choose to drop packets for this domain during attacks may choose to accept them again at a later stage, as legitimate queries for this domain will no doubt be seen. This would also explain the elongated scanning pattern, spanning seven months, as attackers are seeking exploitable servers which may have been reconfigured to allow replies for these queries once more.

5.1.6 Bandwidth amplification factors of domain queries

Table 5,7 shows the bandwidth amplheation factors of some of the scans captured in the dataset. No responses were captured, as none of the scanning IP addresses or attack targets were present in the observed IP block. As such, the response sizes are taken from the attack reports on dnsamplification. blogspot. com.

Table 5,7: Bandwidth amplification factor of queried domains

Domain Query size (bytes) Response size (bytes) BAF30259.info 87 and 99 4 211 2 48.402 or 42.53536372.info 99 4 211 3 42.53537349.info 87 and 99 4 211 4 48.402 or 42.535

www.jrdga.info 91 4 112 5 45.187defcon.org 87 4 084 6 46.943

Bandwith ampliheaiton factor (BAF), is the factor by which bandwidth consumption is increased between the query packet and reply packet. It is calculated by dividing the size of the response packet by the size of the query packet for that response, an equation for which can be seen in section 2,3,2, The BAF recorded here are higher than the average recorded open resolver BAF but lower than the average name server BAF recorded in Rossow (2014), The values are closest

81


to the BAF average recorded for the worst 50% of ANY lookup amplification attacks observed at open resolvers (Eossow, 2014), which would make sense given the large packet response size. The DNS infrastructure used to limit packet size to 512 bytes (Anagnostopoulos et al, 2013), which suggests that these attacks targetted EDNSO enabled open resolvers (Vixie, 1999) to achieve the 4KB response size; which also explains why the amplification factors are closer to the worst 50% of ampliheation attacks rather than the overall average (Eossow, 2014),

5.2 Bitflip analysis

This section deals with bitflip identification and analysis in the dataset. Bitflipping and bitsquatting were covered in subsection 2,1,8, The bitflip analysis focuses only on the domains present in the dataset, and does not concern itself with the possible flips seen for other data in the packets,

5.2.1 Bitflip identification approach

First the monthly datasets were filtered so that only a unique list of all seen domains in that month remained. The list of domains was then processed to form a list of binary domains,

for line in f:

h = [bin(ord(ch)) [2:],zfill(8) for ch in line]

for x in h:

i += x

i = i [: -5]

g .w r ite ( i+ "\n ")= 11 11

In Python, ord() is a built-in function that returns the value of the byte if the argument is an 8-bit string, given a string of length l 7. The b i n ( ) function is a built-in function that returns a binary string when given an integer. The b i n ( ) function returns binary in the form Obxv where x is the highest positive bit and v is any combination of positive and negative bits. As a result [2:] is used to strip the first two characters of the bitstring, while ,z f i l l ( 8 ) pads the front of the binary string until there are 8 bits, to represent a 1 byte character. The i = i [: -5] is there to remove the bits generated by the newline character, which in hindsight would have been much more elegantly solved by calling . s t r i p () on the line.

The following code was then used to cheek if there were possible bitflips among the given bitstrings,

7https://docs, python. org/2/library/functions.html#ord

82

https://docs

def i s _ b i t f l i p ( s l , s2) :

i f not le n (s l ) == l e n ( s 2 ) :

r a is e Exception("Strings are not equal length")

b it s f l ip p e d = 0

fo r index in r a n g e ( le n (s l) ) :

i f s i [index] != s2 [ in d e x ] :

b i t s f l ip p e d += 1

i f b i t s f l ip p e d > 1 :

return False

return b it s f l ip p e d == 1

This function works by comparing the values of bits in two given strings. The first test is to see if the two bitstrings are of equal length, and if they are not, to discard the comparison as it is not a possible bitflip. The loop then iterates through both strings using the index value of the characters in the string, comparing the bits. When two non-equal bits are found, the b it s f l ip p e d counter is increased by one, A second test throws out the strings if there are more than one bit differences present at any given time. The function then returns the boolean value b it s f l ip p e d == 1, which will evaluate to true if there is a single different bit in the bitstring. The results given by the code were then tested using a completely different algorithm as a sanity check,

def rec(x) :

rc = m ath.log(x,2)

return (rc == in t(rc ) and 2**rc == x)

i f le n ( l in e ) != le n ( q ) :

continue

y = in t ( l in e ,2 ) ~ in t(q ,2 )

i f y == 0:

continue

z = rec(y)

This function receives an integer value, v, which is the integer value of the resulting XOR of the two bitstrings. The function then calls the built-in log() function, which will determine whether or not the XOR’d integer is a power of 2, i.e, a single bitflip, by using log with base 2, and

83

expecting a non-decimal positive number. The first function test is to determine if the log of the power returned an integer, indicating a single flip, while the second test is a sanity test of the log function itself, which would sometimes return integer values to logarithms that were not precisely a power of 2,

Both functions returned the same output on test eases as well as the binary lists generated from the datasets,

5.2.2 False positives and filtering

The bitlfip identification algorithm seen in section 5,2,1 resulted in many false positives as a result of domain naming conventions, DNS infrastructure usage and the structure of certain EEs,

5.2.2.1 Domain names

Many domain names, especially ones that are not used by human clients or do not resolve to user- content hosting IP addresses, will use numbering as a naming convention instead of a name targeted towards consumers. An example of this is all63.phobos-apple.com.akadns.net and al063.phobos- apple.com.akadns.net, which are both valid domains that form part of the Akamai CDN infrastructure, but return a positive bitflip as 1063 and 1163 have a 1 bit difference while all the other bits are identical. The s3-3-w.amazonaws.com and s3-l-w.amazonaws.com domains are another example, both valid Amazon domains that register a bitflip as a result of 1 and 3 having a one bit difference. Efforts were made to filter out bitflips generated by naming conventions by filtering the domain dataset through name server resolution of the domain. Domains that were not found to be valid were of greater interest as they constituted a higher chance of being a true bitflip,

5.2.2.2 Use of DNS infrastructure

Services like DNSBL also generated false positives, as they append an IP address to their domain, for example 93.x.xJ96.zen.spamhaus.org and 92.x.x. 196.zen.spamhaus.org, which register as a bitflip due to the 3 of 93 and 2 of 92 having a one bit difference. This is only problematic due to these queries passing through the filter that tested the validation of domains, as queries for IPs will return NXDOMAIN responses, as mentioned in subsection 4,3,2, Efforts were made using pattern matching to filter these false positives from the existing datasets,

5.2.2.3 PTR queries

PTE queries accounted for a significant portion of false positives. For example, the 93.0.168.192. in- addr.arpa and 91.0.168.192. in-addr.arpa queries returned a positive bitflip as well as the 93.0.168.192.in-

84

addr.arpa and 83.0.168.192. in-addr.arpa queries. It was decided that the PTE queries would be filtered from the datasets before further processing as a result of the number of false positives generated in the dataset, more so than any other query type. They were filtered through pattern matching and not by EE, to ensure that only numerical flips are removed,

5.2.2.4 Further filtering

A number of legacy domain names were not filtered out by resolving hostnames, as they were no longer valid domains, and as such were removed manually from the datasets.

5.3 Bitflip findings

This section details the observations made during the analysis of possible bitflips left after the filtering stages. Section 5,3,4 showcases some of the possibly squatted domains that have been identified throughout the analysis,

5.3.1 Case insensitive nature of DNS

Some of the possible bitflips captured for domains are domains where one of the characters of the domain is uppercase, i.e, fsmx.async.org.za and fsmx.async.Org.za. As a result of the ease- insensitive nature of DNS (Eastlake, 2006), it becomes difficult to say with certainty whether or not the observed domain difference is as a result of a flipped bit or simply different configuration at the querying host. It also hinders the filtering of possible bitflips through domain validation, as those domains will count as valid due to the nature of DNS, Case-flipped queries that resolved to an active domain were ignored, as mentioned in section 5,2,2,4,

The presence of ease-flipped letters was also noticeable in the domain dataset for non-existent or non-resolvable domains. For the unresolved asyne.org,za domain, the permutations asyNe.org,za, Asyne.org,za, async.oEg.za, asynC.org,za, async.Org.za , asyne.org,Za were all captured in June 2014, All of these have a bit difference of one from the original domain. Another ease from the same month is moria.org, which resulted in the permutations moria.Org, moEia.org, moriA.org, morla.org , mOria.org, Moria.org, moria.orG,

For both domains, we see flips appearing in the domain itself, the TLD and the ccTLD. This, coupled with the fact that the original domain is non-resolvable, seems to indicate that it is more likely to be a flipped bit as opposed to different ease configurations by end-hosts, A possible explanation for this ease inconsistency is given in section 5,3,2,

85

5.3.2 Recorded IN-ADDR.ARPA flips

It was mentioned in 5,2,2,3 that PTE records had been filtered out, due to the generation of false positives through the presence of an IP address in the domain. While the addresses themselves were problematic, these queries form an interesting ease study as there is evidence of ease change in these domains as well.

5.3.2.1 Example Flips

166. x.x.l96.IN-ADDR.ARPA

167. x.x.l96.IN-ADDR.ARPA

These two queried domains registered as a bitflip due to 166 and 167 being one bit apart. This is an example of a falsely identified bitlfip. Almost all of the PTR, queries were listed as flips due the the close nature of the queried IPs, which exist in the observed network block, A small subset of the captured queries show interesting domains that are indicative of true bitflipping,

167.x.x.l96.IN-ADDR.ARPA

167,x,x,196,IN-ADDR,ARPa

In this example, the bitflip was not detected as a result of IP differences, but because of a ease difference in the domain extension. Table 5,8 shows the unique permutations captured for this domain extension during August 2015, There were 39 TLD bitflips recorded for IN-ADDR.ARPA in that month. The flipped bit has been bolded. This is similar to the ease inconsistencies for the exodus.desync.com domains mentioned in section 4,1,3,

Almost all of the PTR bitflip traffic was captured at the two authoritative servers.

Table 5,8: Permutations of PTR query domain extensions August 2015

Extension Expected ascii Captured ascii Expected bits Captured bitsIN-AdDR.ARPA D d 01000100 01100100IN-ADdR.ARPA D d 01000100 01100100iN-ADDR.ARPA I 01001001 01101001In-ADDR.ARPA N n 01001110 01101110IN-aDDR.ARPA A E 01000001 01100001IN-ADDr.ARPA R r 01010010 01110010IN-ADDR.ARpA P p 01010000 01110000IN-ADDR.ArPA R r 01010010 01110010IN-ADDR.aRPA A E 01000001 01100001IN-ADDR.ARPa A E 01000001 01100001

86

This case difference seen for these addresses, among others, was mentioned in section 5,3,1, It is interesting to note that all of the bits are flipped at the same position in the letter byte array. The uniformity of the flipped bit suggests that this bitflip may be caused by a software or hardware related issue in this case, and is not due to happenstance. It is also possible that it is a 0x20 bit hack (Wessels, 2012), Manipulation of the 0x20 bit in the domain was suggested as a security feature to increase the difficulty of cache poisoning attacks (Dagon et al, 2008), as this would force poisoners to guess the correct Capital Sequencing of the domain for pattern matching. This configuration is also most likely the cause of the registered flips mentioned in section 5,3,1, The irony of this is that cache poisoners are increasing hit chances by flipping the 0x20 bit in domain names, which are seen as case-insensitive by the receiving servers (Vixie and Dagon, 2008),

5.3.2.2 Frequency of flips for IN-ADDR.ARPA queries

Table 5,9 looks at the IN-ADDR.ARPA case flips present. The number of packets refers to the number of queries in the dataset that had an uppercase IN-ADDR.ARPA in the domain name, while the number of flips refers to the number of packets with a case-flipped letter, for the months in the dataset. While the number of flipped packets is low, the percentage of captured packets is much higher than bitflip frequency is suggested in other research (Wessels, 2012), The ratio of packets to IP addresses also suggests that these bitflips are the result of a system configuration or error rather than a memory error.

Table 5,9: Flip frequency for IN-ADDR.ARPA packets

M onth # o f flips # o f packe ts % o f packe ts # o f IP s

O c t 13 22 7 952 0,277 12N ov 13 42 10 292 0,408 20D ee 13 24 11 072 0,217 12J a n 14 14 5 380 0,260 9F eb 11 14 6 815 0,205 8M ar 14 23 7 344 0,313 9J u n 14 19 5 855 0,325 8J u l 14 34 8 444 0,403 18

A ug 14 28 6 615 0,423 13S ep 14 32 8 350 0,383 17O c t 14 50 9 993 0,500 24N ov 14 58 10 107 0,574 26D ee 14 35 6 645 0,511 15J a n 15 52 12 909 0,403 19Fob 15 53 13 373 0,396 26M ar 15 91 16 529 0.551 44A p r 15 173 53 586 0,323 48M ay 15 82 9 624 0,852 48J u n 15 83 11 216 0,740 47J u l 15 112 13 561 0,826 50

A ug 15 39 11 155 0,350 29T o ta l 997 246 817 0,404 62

87

The fact that so few packets were captured in any given month, and also that there was no evidence of domain clumping, suggests that these queries come from systems or end-hosts that have implemented 0x20 bit encoding (Dagon et al, 2008) to increase their DNS cache security, and not as the result of an attempted cache poisoning attack. Such a defense could cause problems however if a numerical character is flipped, in which ease the domain would resolve differently.

5.3.3 Recorded bitflips

This section looks at some of the flips captured in the dataset. Some of the flips are categorized as possible typos, and will be discussed. Other captured domains are almost certainly flips as they deviate from DNS naming standards (Moekapetris, 1987b),

5.3.3.1 Possible Typos

Some of the bitflips were more likely a typing error that resulted in the string being one bit different, Moore and Edelman (2010) define a measure of distance called fat finger distance for measuring the likelihood of a typo in a domain, and also the likehood of a domain being tvposquatted. This distance is one adjacent key on the keyboard from the desired key.

Table 5,10: Bitflipped domains as a result of typos

Domain Adjacent characterggogle.com -

www. faceb oo j . com kwww.youtbe.com -

www. vouub e. comq -www. fqcebo ok. com a

wsw.etoro.com wwww.ru.ac.xa zvqhoo.comq a

sww.saprepschool.com wgoogld.com e

kingswoodcollegd.com efacebokk.com 0

These bitflips are all most likely the result of typing errors instead of a memory error. All but three of the examples have letters within fat-finger distance of the typo. The other three are interesting as they do not follow this pattern. It is suspected that the g key was tapped twice when the domain was inputted in the first ease, causing the error. The youtbe.com and youube.com eases are clearly an error in character ommision, but are mentioned as they were recorded as bitflips for one another,

88

http://www.youtbe.com

http://www.ru.ac.xa

This adds an interesting dynamic to bitflipping, as it could be used to statistically enhance the chance of traffic to a typosquatted domain if they register a domain that is also a bitsquat of the original domain.

5.3.3.2 Definite Bitflips

Examples of bitflips captured in the dataset are given in table 5.11. The tilde (~) in the a syn c .o rg .za

domains is interesting as it is the result of a flip at the 0x04 bit for lower z, Five seperate addresses saw a flip at the 0x04 bit of the letter d. These eases are all examples of bitflips invalidating addresses, as they no longer conform with domain name specifications (Mockapetris, 1987a), This means that some bitflips, due to the nature of the character the flip produces, cannot be bitsquatted.

Table 5.11: Bitflipped domains

Domain Domainnsl. async.org. ~a i ‘entity, apple. com. akadns .netns2. async.org. ~a c‘n.spotxchange.com

kingswoodcollage.com plus.coogle.comkingswoodkollege.com talkomsa.net

ww7.sacschool.com speampowered.comwww.goocle.com c‘n.fastclick.net

eray.com c‘n.spotxchange.comrT3p04sa.guzzoni-apple.com.akadns.net a‘xhm.d. chango.com

Other bitflips are also observed in letter changes, which could be the result of typos. The distance between the letter and its substitute is more than the fat-finger distance on a QWERTY keyboard, making it more likely that these are true bitflips,

5.3.4 Possible Bitsquats

The sites that were filtered from the main dataset were processed so that only the TLDs remained, and those were put through the Linux command so rt -u to create a list of domains, from which possible bitsquat domains were identified.

The site ba rc leys .co m , which is a bitflip for barc la ys .co m , displays a blank page when visited. This site is considered as empty. Around 2,7% of bitsquatted sites deliver no content at all (Nikiforakis e t a l., 2013), The fo o g le .co m domain returns ’Coming soon’. The three domains cm a il.co m ,

h o tm a a l. com and w atppad. com are listed as for sale on the site. Domains for sale make up roughly 10% of bitsquatted domain sites (Nikiforakis e t a l , 2013),

89

http://www.goocle.com

The fabebook.com domain is most likely a bitsquat while webme.com is most likely a typosquat of webmd. Both redirect traffic to unrelated sites. The goggle.com domain is a known typosquat domain, which is coincidentally also a bitsquat. The site tries to persuade visiters to sign up for a £3-per-text quiz competition, offering Apple merchandise as prizes8.

The verixon.net bitsquat is owned by Verizon, and relocates to their home page www.verizon.net. It is surprising that, of the subset, this is the only squatted domain owned by the organisation that is being squatted.

Table 5,121ooks at the bit difference between the squatted domains and the target domains. The flipped bit distribution is greater than the Case-flipped domains. These bitsquatted domains are all squatting well known domains, which confirms past research (Nikiforakis et al, 2013),

Table 5,12: Bitflip seen in Bitsquatted domains

Domain Expected ascii Captured ascii Expected bits Captured bitsbarcleys.com 8. e 01100001 01100101

cmail.com g c 01100111 01100011fabebook.com C b 01100011 01100010

foogle.com g f 01100111 01100110goggle.com 0 g 01101111 01100111

watppad.com t P 01110100 01110000webme.com d e 01100100 01100101

It seems that, in line with the findings of Nikiforakis et al. (2013), while there is a definite bitsquatting presence on the Internet, very few of the bitsquatted domains are tailored to serving malware, and more often than not are simply using the domain to generate revenue through domain parking or sale; or owned by the same owner of the legitimate domain that is being squatted.

5.4 Chapter Summary

This chapter covers three main topics. The first is post-attack amplification scanning activity, which is covered in section 5,1, A lot of work has been done around DNS amplifieaition attacks, but to the knowledge of the author this is the first time that amplification scanning behavior has been linked to amplification attacks that have already been carried out, sometimes months before the scans themselves occur. This behavior is important for a number of reasons. Firstly, it allows researchers that have access to darnket packet captures to infer amplification attacks through observed scanning activity. It also indicates that possible attackers will attempt to take advantage of attack domains used by other parties. There were many instances where amplification scans

8http://www.theregister.co.uk 2011 10 12 google_v_goggle/

90

http://www.verizon.net

http://www.theregister.co.uk

were captured the day after the attack was reported, strongly suggesting a temporal link between attacks and post-attack scanning.

Section 5,2 outlines the code used for possible bitflip detection. Two methods were used as a confirmation of accuracy with respect to bit differences. The largest issue encountered was the number of false positive bitflips encountered during processing. Many domains have numbers attached to identical domain strings as part of their naming convention, including the PTE EE, which resolves an IP address. These domains all registered as bitflips as a result of the one bit difference between the numbers in the domain name, A number of filtering strategies were attempted in order to separate true bitflips from false positives. First, all of the PTE queries that showed digit flips instead of character flips were filtered out. Second, domains were filtered by their ability to be resolved, in order to preserve genuine digit bitflips while excluding similar but actively registered domains, DNSBL flips that occurred on digits, i.e, of the IP addresses, were also filtered out from the non-resolving domain dataset. Lastly, certain legacy domains had to be manually filtered. The need to manually filter certain flips is also mentioned in Dinaburg (2011), indicating that he encountered a similar problem with automatic filtering algorithms.

The last section, 5,3, describes the results of the bitflip analysis. The first thing to note here is the large presence of flipped 0x20 bits, causing a change in capitalization of the domain. While it is technically a bitflip, it is believed to be the result of software configuration (Dagon et al, 2008) and not the result of random oeeurrenee or machine malfunction. Very few definite bitflips were found considering the number of false positives, although it is possible that some actual bitflips were filtered out accidentally, it is better to err on the side of caution. The example bitflips showed a much wider variety of positions of the flipped bit, which further confirms the assumption that the large number of 0x20 flipped bits are not true bitflips. Of the confirmed bitflips, many domains were malformed, as some of the flipped bits resulted in domains that do not conform to domain name specifications. Finally, some examples of Bitsquatting were identified from the dataset. Similar to the findings reported by Nikiforakis et al. (2013), many of the squatted domains were either owned by the legitimate domain company, were parked domains, ad-revenue domains, or pages that redirect to unrelated content.

91

Chapter 6

Conclusion

This chapter reflects on the goals identified at the start of the thesis, and evaluates to what level they have been achieved. It also discusses some of the important findings of the thesis, as well as why they are important. Concluding remarks are then followed by recommendations for future avenues of study in the field of DNS traffic analysis.

6.1 Reflection on goals

The first goal outlined in the thesis was to gain an understanding of how legitimate services and end-hosts were currently utilizing DNS, in an attempt to better understand DNS packet activity and configurations on the Internet, To achieve this three separate studies were conducted on DNS TTL usage, DNS authoritative latency for local domains and NX DOMAIN presence in the dataset. This goal was achieved in the following ways: The thesis offers extensive analysis of DNS TTL implementation and behavior from a wide variety of authoritative servers, spanning a number of resource records, and representing different domain needs. The geolocation of .za authoritative servers is original work that builds on creating a locally contextualised understanding of the spread of authoritative servers for local domains. The evaluation of DNS-based latency generation also works to achieving this goal, as it creates a clearer understanding of the latency costs implicit in authoritative server choice. The NX DOM AIN analysis sheds light on the cost of host miseonfiguration to the network, as well as some of the security threats that are generated by miseonfigurations that result in N.XDO.M AIN responses. The large DNSBL presence found in both the TTL analysis, as well as the N.XDO.M AIN analysis, covers a large area of current common DNS utilization in third party services. This goal, however, could not be completely realized as the covered sections are not able to fully encompass current DNS practice and utilization. There is simply too much data, with numerous avenues of study, to be included in a single thesis.

The second goal was to investigate instances of malicious DNS behavior and DNS abuse. This goal

92

was met through analysis on two distinct forms of DNS abuse, amplification-attack scanning and bitsquatting. The first step towards this goal was a thorough analysis of the temporal relationship between DNS amplification DDoS attacks and DNS amplification scanning using attack domains. This thesis found a direct correlation between attack reports and scanning behavior, and was able to link amplification scans to attacks that had been reported the day before, as well as scans for attacks that happened months before. The second step to achieving this goal was an analysis of possible presence of bitflips within the dataset. The successful identification of confirmed bitflips, as well as analysis on observed Bitsquatted domains captured in the dataset, shed more light on a relatively new field in DNS security. While the same holds true for both sections in the sense that there is simply too much data to cover all of the captured malicious DNS activity, the author believes that the second goal has been fully completed. The research on this area is original, relevant to current DNS threats, and an important foundation for future work in the ease of post-attack amplification scanning.

6.2 K ey Findings

This section outlines what the researcher believes to be the most important findings arising from the research conducted, and will discuss the reasons they are considered to be so. The findings on latency relate to the first research goal, and offer solutions for improving DNS operational ability as well as user experience with respect to DNS, The findings on amplification scans and bitsquatting relate to the second goal, and shed light on how malicious entities abuse the DNS infrastructure to achieve their own ends; as well as possible means of combating that abuse,

6.2.1 Latency and its cost

Several papers (Ramsay et al, 1998; Brutlag, 2009; Vulimiri et al, 2012) highlighted the effects that experienced latency has on user perception of and interaction with web-hosted content. The inversely proportional relationship between user experience and experienced latency indicate a clear need for content webhosts to consider latency when implementing their network infrastructure. This assertion becomes relevant when considering the geoloeation of authoritative servers for .za domains, as seen in section 4,2, Around 40% of unique authoritative servers were placed in the United States, generating between 200 ms and 300 ms of latency. The percentage of international servers outweighed local authoritative servers over the total subset of data, indicating that many .za webhosts, of which presumably some target ZA residents as a primary consumer base, introduce hundreds of milliseconds of DNS-based latency. By switching to local authoritative servers, they could see an increase in site revenue while also improving end-user experience.

93

6.2.2 Temporal relationship between amplification attacks and scans

Confirming a temporal relationship between amplification attacks and post-attack amplification scanning, seen in section 5.1, allows for the inference of amplification attack activity from datasets that did not capture the attack itself. This is important from a security perspective as it shows that known attack domains pose a threat to DDoS targets even after an attack has been launched. As a result, the computer security community should move towards not only filtering packets by IP or domain name to prevent DDoS attacks, steps should also be taken to deregister known attack domains, while also decreasing the number of open resolvers present on the Internet. This finding is also relevant from a researcher’s perspective as it allows researchers to infer DDoS amplification attack activity without capturing packets of the DDoS itself, but by observing the times and numbers of recorded DNS amplification scans.

6.2.3 Confirmation of other Bitsquatting research

Of the Bitsquatted domains identified in section 2.1.8, all of them fell into the groups identified by Nikiforakis et al (2013). There was also a similar distribution of different bitsquatting behavior to the results delivered in that paper. The confirmation of the results of others is important in relatively new fields of study, of which Bitsquatting is undoubtedly one. The most important finding, however, is that the prevalence of bitsquatted domains is far greater than the prevalence of malware-serving domains. This indicates that the current threat from observed bitsquatted domains is much lower than it could be. While this is a positive result, it leaves a lot of room for future illegitimate activity to develop, and the author believes that action should be taken to prevent or mitigate future threats created as a result of bitflipping.

6.3 Future work

• There is a lot of work that could be done on TXT RR data mining. When DNS was first implemented, TXT records existed to hold generic text or comments about the domain records (Aitchison, 2005). Now however DNS TXT records have a number of uses, among them being used for DNS-Based Service Discovery (Cheshire and Krochmal, 2013). Further analysis into TXT record utilization could create a better understanding of current DNS practice.

• Further work should also be considered in the vein of creating a locally contextualized understanding about our end-host and network interaction with the Internet as a whole. Barnett and Ehlers (2012) and this thesis are but small steps in the direction of a more unified understanding of local and international network interaction. Further study could take a

94

number of paths, but the author suggests evaluating the presence of local traffic captured by darknets. This would serve to give insight into the global packet presence generated by local infected or miseonhgured hosts, but will also allow a comparison between data volumes and packet activity seen from local hosts and international hosts,

• There is also scope for future work in the area of Bitflipping analysis. One interesting study would be to attempt to correlate bitflip frequency with regional temperatures from the geographic location of the observed IP block over an extended period. Another avenue of analysis would be to study the domains that return responses to bitflipped queries, specifically cheeking whether or not the domain was registered before or after the Dinaburg (2011) paper.

95

References

Agten, P., Joosen, W ., Piessens, F., and Nikiforakis, N. S e v e n m o n th s ’ w orth o f m is ta kes:

A lo n g itu d in a l s tu d y o f typ o sq u a ttin g abuse. In P roceedings o f th e 2 2 n d N e tw o rk a n d D is tr ib u ted

S y s te m S e c u r ity S y m p o s iu m (N D S S 2 0 1 5 ). 2015,

Aitchison, R. P ro D N S a n d B IN D . Apress, August 2005, ISBN13: 978-1-59059-494-0,

Anagnostopoulos, M., Kambourakis, G., Kopanos, P., Louloudakis, G., and Gritzalis,S. D N S a m p lifica tio n a tta ck revisited . C o m p u te rs & S e c u r i ty , 39:475-485, 2013,

Andrews, M. N eg a tive cach ing o f D N S queries (D N S N C A C H E ) . RFC 2308 (Proposed Standard), March 1998, Updated by RFCs 4035, 4033, 4034, 6604,URL h ttp : / / www. ie t f . org/rf c /r f c2308. tx t

Barnett, R. J. and Ehlers, K. A n E xp lo ra to ry s tu d y in to th e loca tion a n d ro u tin g o f th e m o s t

p o p u la r w ebsites in so u th a frica . 2012, Accessed on 28/11/2015,URL http://www.iadisportal.org/digital-library/an-exploratory-study-into-the-loeation-and- routing-of-the-most-popular-websites-in-south-afriea,

Barr, D. C o m m o n D N S O p era tiona l a n d C o n fig u ra tio n E rro rs . RFC 1912 (Informational), February 1996.URL http: //www. ie t f . org/rf c /r f cl912.tx t

Brutlag, J. Speed m a tte r s f o r Google web search. Google, June 2009, Accessed on: 15/10/2015, URL http://services,google,com/fh /hies/blogs/google_delayexp,pdf,

Biischer, A. and Holz, T. T racking D D o S a tta cks: In s ig h ts in to the b u sin ess o f d isru p tin g the

web. In P roceedings o f th e 5 th U S E N IX W orkshop on L arge-Sca le E xp lo its a n d E m e rg e n t T hrea ts

( L E E T ) , S a n Jo se , C A , U SA . 2012, Accessed on 01/12/2015,URL https://www.usenix.org/system/files/conference/leetl2/leetl2-final26.pdf.

Chapin, L. and McFadden, M. R eserved top level d o m a in n a m es . Internet Draft, May 2011, URL http s://too ls.ie tf.org /h tm l/d raft-ch ap in -rfc2606b is-00

96

http://www.iadisportal.org/digital-library/an-exploratory-study-into-the-loeation-and-routing-of-the-most-popular-websites-in-south-afriea

http://www.iadisportal.org/digital-library/an-exploratory-study-into-the-loeation-and-routing-of-the-most-popular-websites-in-south-afriea

http://services,google,com/fh/hies/blogs/google_delayexp,pdf

https://www.usenix.org/system/files/conference/leetl2/leetl2-final26.pdf

https://tools.ietf.org/html/draft-chapin-rfc2606bis-00

Chen, Y., Antonakakis, M., Perdisci, R., Nadji, Y., Dagon, D., and Lee, W. DNSnoise: Measuring the pervasiveness of disposable domains in modern DNS traffic. In Dependable Systems and Networks (DSN), 201 f f f t h Annual IEEE/IFIP International Conference on, pages 598-609. IEEE, 2014.

Cheshire, S. and Krochmal, M. DNS-Based Service Discovery. RFC 6763 (Proposed Standard), February 2013.URL h ttp : / / www. i e t f . o rg /rf c / r f c6763. tx t

Choi, H., Lee, H., Lee, H., and Kim, H. Botnet detection by monitoring group activities in dns traffic. In Computer and Information Technology, 2007. CIT 2007. 7th IEEE International Conference on, pages 715-720. IEEE, 2007.

Dagon, D., Antonakakis, M., Vixie, P., Jinmei, T., and Lee, W. Increased DNS forgery resistance through 0x20-bit encoding: security via leet queries. In Proceedings of the 15th ACM conference on Computer and communications security, pages 211-222. ACM, 2008.

Danzig, P. B., Obraczka, K., and Kumar, A. An analysis of wide-area name server traffic: a study of the Internet Domain Name System. ACM SIGCOMM Computer Communication Review, 22(4):281-292, 1992.

Dinaburg, A. Bitsquatting: DNS Hijacking without exploitation. Proceedings of BlackHat Security, 2011. Accessed on 30/11/2015.URL http://media.blaekhat.eom/bh-us-ll/Dinaburg/BH_US_ll_Dinaburg_Bitsquatting_W P.pdf.

Eastlake, D. Domain Name System (DNS) Case Insensitivity Clarification. RFC 4343 (Proposed Standard), January 2006.URL h ttp : / / www. i e t f . o rg /rf c / r f c4343. tx t

Eastlake, D. Domain Name System (DNS) IANA Considerations. RFC 6895 (Best Current Practice), April 2013.URL h ttp : / / www. i e t f . o rg /rf c / r f c6895. tx t

Eastlake, D. and Panitz, A. Reserved Top Level DNS Names. RFC 2606 (Best Current Practice), June 1999. Updated by RFC 6761.URL h ttp : / / www. i e t f . o rg /rf c / r f c2606. tx t

Elz, R. and Bush, R. Clarifications to the DNS Specification. RFC 2181 (Proposed Standard),July 1997. Updated by RFCs 4035, 2535, 4343, 4033, 4034, 5452.URL h ttp : //www. i e t f . o rg /rf c / r f c2 18 1 .t x t

97

http://media.blaekhat.eom/bh-us-ll/Dinaburg/BH_US_ll_Dinaburg_Bitsquatting_WP.pdf

Ennis, J. P u re P y th o n G eo IP A P I . June 2015, Accessed on: 07/09/2015,URL h t tp s ://pyp i.py thon .org /pypi/pygeoip /

Fachkha, C., Bou-Harb, E., and Debbabi, M. F in g e rp r in tin g in te r n e t dns a m p lifica tio n

D D o S a c tiv itie s . In N e w Technologies, M o b ility a n d S e c u r ity (N T M S ) , 2014 6 th In te r n a tio n a l

C on feren ce on, pages 1-5, IEEE, 2014,

Fontanini, M. lib tin s - p a c k e t cra ftin g a n d sn iffin g library. March 2015, Accessed on: 14/04/2015, URL h t tp : / / l i b t i n s . g ith u b . io

Gao, H., Yegneswaran, V., Chen, Y., Porras, P., Ghosh, S., Jiang, J., and Duan, H. A n

em p ir ica l reex a m in a tio n o f global D N S behavior. In A C M S IG C O M M C o m p u te r C o m m u n ic a tio n

R eview , volume 43, pages 267-278, ACM, 2013,

Gulbrandsen, A., Vixie, P., and Esibov, L. A D N S R R fo r sp ec ify in g th e loca tion o f serv ices

(D N S S R V ) . RFC 2782 (Proposed Standard), February 2000, Updated by RFC 6335,URL h t tp : / / www. i e t f . o rg /rf c /r f c2782. tx t

Hermanowski, D. O pen source se c u r ity in fo r m a tio n m a n a g e m e n t s y s te m su p p o r tin g it se cu r ity

audit. In C yb ern e tics ( C Y B C O N F ) , 2015 I E E E 2 n d In te r n a tio n a l C on feren ce o n , pages 336-341, IEEE, 2015.

Holgers, T., Watson, D. E., and Gribble, S. D. C u ttin g through th e co n fu sio n : A m ea su re

m e n t s tu d y o f hom ograph a tta cks . In U S E N IX A n n u a l T echn ica l C on ference , G enera l Track,

pages 261-266, 2006,

Holz, T., Gorecki, C., Rieck, K., and Freiling, F. C. M ea su r in g a n d d e tec tin g fa s t - f lu x

serv ice n e tw o rks . In S y m p o s iu m on N e tw o rk a n d D is tr ib u te d S y s te m S e c u r ity (N D S S ) . 2008,

Irwin, B. and Pilkington, N. H igh level in te r n e t scale tra ffic v isu a liza tio n u s in g H ilbert C urve

m a p p ing . In V iz S E C 2007, pages 147-158, Springer, 2008,

Jin, C., Wang, H., and Shin, K. G. H op -co u n t filte r in g : an e ffec tive d e fen se a g a in st spoofed

D D o S tra ffic . In P roceedings o f the 10 th A C M con ference on C o m p u te r a n d co m m u n ic a tio n s

secu r ity , pages 30-41, ACM, 2003,

Jung, J. and Sit, E. A n em p ir ica l s tu d y o f sp a m tra ffic a n d th e use o f D N S black lis ts . In P roceedings o f the 4 th A C M S IG C O M M co n ference on I n te r n e t m e a s u r e m e n t, pages 370-375, ACM, 2004.

Jung, J., Sit, E., Balakrishnan, H., and Morris, R. D N S P e r fo rm a n c e a n d th e E ffe c tiv e n ess

o f C aching. N e tw o rk in g , I E E E /A C M T ra n sa c tio n s o n , 10(5):589-603, 2002,

98

https://pypi.python.org/pypi/pygeoip/

Kambourakis, G., Moschos, T., Geneiatakis, D., and Gritzalis, S. Detecting DNS amplification attacks. In Critical Information Infrastructures Security, pages 185-196, Springer, 2008.

Krishnamurthy, B., Wills, C., and Zhang, Y. On the use and performance of content distribution networks. In Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement, pages 169-182. ACM, 2001.

Kumar, A., Postel, J., Neuman, C., Danzig, P., and Miller, S. Common DNS Implementation Errors and Suggested Fixes. RFC 1536 (Informational), October 1993,URL h ttp : //www. i e t f . o rg /rf c /r f cl536.tx t

Kwon, J., Kim, J., Lee, J., Lee, H., and Perrig, A. Psybog: Power spectral density analysis for detecting botnet groups. In Malicious and Unwanted Software: The Americas (MALWARE), 2014 9th International Conference on, pages 85-92. IEEE, 2014.

Larson, M. and Barber, P. Observed DNS Resolution Misbehavior. RFC 4697 (Best Current Practice), October 2006,URL h ttp : / / www. i e t f . o rg /rf c /r f c4697. tx t

Ling, Z., Luo, J., Wu, K., Yu, W ., and Fu, X. Torward: Discovery of malicious traffic over tor. In INFOCOM, 2014 Proceedings IEEE, pages 1402-1410, IEEE, 2014.

Lottor, M. Domain Administrators Operations Guide. RFC 1033, November 1987,URL h ttp : //www. i e t f . o rg /rf c /r f cl033.tx t

Mauch, J. Open resolver project. In Presentation, DNS-OARC Spring 2013 Workshop (Dublin). 2013. Accessed on 24/05/2014.URL https://indieo,dns-oare,net/event/0/session/0/eontribution/24/material/slides/l,pdf,

Metcalf, L. and Spring, J. Domain parking: Not as malicious as expected. Technical report, Pittsburgh PA Software Engineering Institute, 2014. (No, CERTCC-2014-57), Carnegie-Mellon University.

Miszalska, I., Zabierowski, W ., and Napieralski, A. Selected 'methods of spam filtering in email. In CAD Systems in Microelectronics, 2007. CADSM’07. 9th International Conference- The Experience of Designing and Applications of, pages 507-513, IEEE, 2007,

Mockapetris, P. Domain names - concepts and facilities. RFC 1034 (INTERNET STANDARD), November 1987a. Updated by RFCs 1101, 1183, 1348, 1876, 1982, 2065, 2181, 2308, 2535, 4033, 4034, 4035, 4343, 4035, 4592, 5936.URL h ttp : //www. i e t f . o rg /rf c /r f cl034.tx t

99

https://indieo,dns-oare,net/event/0/session/0/eontribution/24/material/slides/l,pdf

Mockapetris, P. Domain names - implementation and specification. RFC 1035 (INTERNET STANDARD), November 1987b. Updated by RFCs 1101, 1183, 1348, 1876, 1982, 1995, 1996, 2065, 2136, 2181, 2137, 2308, 2535, 2673, 2845, 3425, 3658, 4033, 4034, 4035, 4343, 5936, 5966, 6604.URL h ttp : //www. i e t f . o rg /rf c /r f cl035.tx t

Moore, T. and Edelman, B. Measuring the perpetrators and funders of typosquatting. In Financial Cryptography and Data Security, pages 175-191. Springer, 2010.

Nazario, J. and Holz, T. As the net churns: Fast-flux botnet observations. In Malicious and Unwanted Software, 2008. MALWARE 2008. 3rd International Conference on, pages 24-31. IEEE, 2008.

Nikiforakis, N., Balduzzi, M., Desmet, L., Piessens, F., and Joosen, W. Soundsquatting: Uncovering the use of homophones in domain squatting. In Information Security, volume 8783 of Lecture Notes in Computer Science, pages 291-308. Springer, 2014.

Nikiforakis, N., Van Acker, S., Meert, W ., Desmet, L., Piessens, F., and Joosen, W.Bitsquatting: Exploiting bit-flips for fun, or profit? In Proceedings of the 22nd international conference on World Wide Web, pages 989-998. International World Wide Web Conferences Steering Committee, 2013.

Oberheide, J., Karir, M., and Mao, Z. M. Characterizing dark dns behavior. In Detection of Intrusions and Malware, and Vulnerability Assessment, pages 140-156. Springer, 2007.

Olzak, T. Dns cache poisoning: Definition and prevention. 2006. Accessed on: 13/09/2015.URL http://www.infoseewriters.eom.

Padmanabhan, V. N. and Mogul, J. C. Using predictive prefetching to improve world wide web latency. ACM SIGCOMM Computer Communication Review, 26(3):22-36, 1996.

Pashalidis, A. A cautionary note on automatic proxy configuration. In IASTED International Conference on Communication, Network, and Information Security, CNIS 2003, New York, USA, December 10-12, 2003, Proceedings, pages 153-158. ACTA Press, 2003.

Paxson, V. An analysis of using reflectors for distributed denial-of-service attacks. ACM SIGCOMM Computer Communication Review, 31(3):38-47, 2001.

Prechelt, L. An empirical comparison of C, C++, Java, Perl, Python, Rexx and Tel. IEEE Computer, 33(10):23-29, 2000.

Ramsay, J., Barbesi, A., and Preece, J. A psychological investigation of long retrieval times on the world wide web. Interacting with computers, 10(l):77-86, 1998.

1 0 0

http://www.infoseewriters.eom

Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and Lear, E. A d d ress

A llo c a tio n fo r P r iv a te In te r n e ts . RFC 1918 (Best Current Practice), February 1996, Updated by RFC 6761,URL http: //www. ie t f . org/rf c /r f cl918.tx t

Rossow, C. A m p lific a tio n hell: R e v is itin g n e tw o rk pro toco ls f o r D D o S abuse. In S y m p o s iu m on

N e tw o rk a n d D is tr ib u te d S y s te m S e c u r ity (N D S S ) . 2014,

Sanner, M. F. P y th o n : a p ro g ra m m in g language fo r so ftw a re in teg ra tio n a n d d e v e lo p m e n t.

J o u rn a l o f M o lecu la r G raph ics a n d M o d ellin g , 17(1) :57—61, 1999,

Sarat, S., Pappas, V., and Terzis, A. O n th e u se o f a n yca st in D N S . In C o m p u te r C o m

m u n ic a tio n s a n d N e tw o rks , 2006. I C C C N 2006. P roceedings. 15 th In te r n a tio n a l C on feren ce o n ,

pages 71-78. IEEE, 2006.

Schonewille, A. and van Helmond, D.-J. T h e d o m a in n a m e serv ice as an ID S . R esearch

P ro jec t f o r th e M a s te r S y s te m -a n d N e tw o rk E n g in eer in g a t th e U n ive rs ity o f A m s te r d a m , 2006,

Singla, A., Chandrasekaran, B., Godfrey, P., and Maggs, B. T h e in te r n e t a t th e speed

o f light. In P roceedings o f th e 13 th A C M W orkshop on H o t T op ics in N e tw o rk s , page 1, ACM, 2014.

Smith, N. S e c u r ity T hrea ts A g a in s t S ecu re S o cke ts L a y e r (S S L ) . Ph.D, thesis, Nova Southeastern University, 2010,

Souders, S. V elocity a n d th e b o tto m line . Online, July 2009, Accessed on 14/08/2015,URL http://radar,oreilly,eom/2009/07/veloeity-making-your-site-fast,html,

Stalmans, E. and Irwin, B. A fra m e w o rk fo r dns based d e tec tio n a n d m itig a tio n o f 'malware

in fe c tio n s on a n e tw o rk . In In fo r m a tio n S e c u r ity S o u th A fr ic a ( IS S A ) , 2011 , pages 1-8, IEEE, 2011.

Sullivan, D. T. S u rv e y o f 'malware th rea ts a n d reco m m en d a tio n s to im p ro ve cyb ersecu rity fo r

in d u s tr ia l con tro l s y s te m s v e rs io n 1.0 . Technical report, Raytheon Technical Services Company LLC, 2015. Accessed on 15/10/2015.URL http://www,dtie,mil/egi-bin/GetTRDoe?AD=ADA617910,

Teo, L. P o r t sca n s a n d p in g sw eeps exp la ined . L in u x Jo u rn a l, 2000(80es):2, 2000,

The Measurement Factory, ip v4 -h ea tm a p : M a p p in g th e ip v f address space. March 2015, Accessed on: 12/06/2015,URL h ttp : / / maps . measurement - fact ory. c om/

1 0 1

http://radar,oreilly,eom/2009/07/veloeity-making-your-site-fast,html

http://www,dtie,mil/egi-bin/GetTRDoe?AD=ADA617910

van Zyl, I., Rudman, L. L., and Irwin, B. A review of current DNS TTL practices. In Otten, D. F. and Balmahoon, M. R., editors, Southern Africa Telecommunication Networks and Applications Conference (SATNAC) 2015, pages 131 -136, August 2015,

Vixie, P. Extension Mechanisms for DNS (EDNSO). RFC 2671 (Proposed Standard), August 1999, Obsoleted by RFC 6891,URL h t tp : / / www. i e t f . o rg /rf c / r f c2671. tx t

Vixie, P. and Dagon, D. Use of Bit 0x20 in DNS Labels to Improve Transaction Identity. Internet Draft, March 2008, Accessed on: 02/12/2015,URL h ttp s :/ / to o ls .ie tf .o rg /h tm l/d ra f t-c h a p in -r fc 2 6 0 6 b is -0 0

Von Arx, K. G. and Hagen, G. R. Sovereign domains: A declaration of independence of cctlds from foreign control. Rich. JL & Tech., 9:4-8, 2002,

Vulimiri, A., Michel, O., Godfrey, P., and Shenker, S. More is less: reducing latency via redundancy. In Proceedings of the 11th ACM Workshop on Hot Topics in Networks, pages 13-18, ACM, 2012.

Wessels, D. Observations on Checksum Errors in DNS Queries to VeriSign’s Name Servers. Verisign Incorporated, February 2012, Accessed on 17/11/2015,URL http://www.verisign.com/assets/VRSN_Bitsquatting_TR_20120320.pdf?inc= www.verisignine.eom,

Williamson, C. Internet traffic measurement. Internet Computing, IEEE, 5(6):70-74, 2001,

Wills, C. and Shang, H. The contribution of DNS lookup costs to web object retrieval. Technical report, Worcester Polytechnic Institute, 2000, Technical Report: TR-00-12,

Yadav, S., Reddy, A. K. K., and Ranjan, S. Detecting algorithmically generated domain-flux attacks with DNS traffic analysis. Networking, IEEE/ACM Transactions on, 20(5):1663-1677, 2012.

Yadav, S. and Reddy, A. N. Winning with DNS failures: Strategies for faster botnet detection. In Security and privacy in communication networks, pages 446-459, Springer, 2012,

Zdrnja, B. Security Monitoring of DNS traffic. University of Auckland, 2006, Accessed 13/07/2015.URL http://eiteseerx.ist,psu,edu/viewdoe/download?doi=10,1,1,511,7926&rep=repl&type=pdf,

Zdrnja, B., Brownlee, N., and Wessels, D. Passive monitoring of DNS anomalies. In Detection of Intrusions and Malware, and Vulnerability Assessment, pages 129-139, Springer, 2007.

1 0 2

https://tools.ietf.org/html/draft-chapin-rfc2606bis-00

http://www.verisign.com/assets/VRSN_Bitsquatting_TR_20120320.pdf?inc=

http://www.verisignine.eom

http://eiteseerx.ist,psu,edu/viewdoe/download?doi=10,1,1,511,7926&rep=repl&type=pdf

Appendices

103

Table A .l: Dataset TTL frequency

R an k I 1 I I 2 I I 3 I I 4 I I 5 I 6 I 7 I I 8 I I 0 I I 10M onth T T L % olT otal T T L % olT otal T T L % olT o ta l T T L % olT otal T T L % olT otal T T L % olT o ta l T T L % olT otal T T L % olT otal T T L % olT otal T T L % olT otal

O c to b e r 2013 300 24.939 60 14.203 20 12.122 3600 10.445 600 6.445 30 5.402 86-100 4.077 7200 3.666 900 3.665 21600 1.990.Novem ber 2013 300 26.222 60 14.959 20 11.270 3600 10.554 600 6.655 30 4.96-1 86-100 3.772 7200 3.532 900 3.390 1800 1.8-15D ecem ber 2013 300 20.270 3600 15.068 86-100 14.038 600 13.419 60 6.266 7200 5.575 900 3.587 20 2.626 1800 1.946 43200 1.933J a n u a ry 2014 300 27.6-18 60 13.172 3600 10.784 600 8.511 20 7.951 86-100 5.235 7200 3.89-1 30 3.594 900 3.406 1800 2.177

F eb ru a ry 2014 300 22.943 60 13.477 3600 11.257 20 9.123 86-100 7.8-12 600 6.442 30 4.3-13 900 4.014 7200 3.738 1800 2.205M arch 2014 300 27.499 60 14.749 20 10.019 3600 9.603 600 6.236 30 4.622 86-100 4.198 900 3.93-1 1800 2.151 3200 1.93-1J u n e 2014* 300 25.829 60 16.395 20 12.171 3600 9.636 30 5.769 600 5.609 900 3.383 86-100 2.816 120 2.331 1800 2.255Ju ly 2014 300 28.091 60 17.232 20 12.806 3600 9.712 30 5.708 600 5.46-1 900 2.954 86-100 2.492 1800 2.145 120 2.092

A ugust 2014 300 30.126 60 14.902 20 11.002 3600 9.744 30 6.358 600 6.111 900 3.271 86-100 2.659 1800 2.354 120 1.836S ep tem b er 2014 300 28.369 60 15.958 20 11.082 3600 8.759 6.336 30 5.637 600 4.996 120 2.585 900 2.497 86-100 2.172

O c to b e r 2014 300 31.117 60 16.858 20 10.979 3600 10.173 30 5.312 600 5.247 900 2.839 86-100 2.516 120 2.435 1800 1.983.Novem ber 2014 300 32.315 60 17.189 20 10.907 3600 9.805 30 5.320 600 5.086 120 3.089 900 2.249 86-100 2.254 1800 1.921D ecem ber 2014 300 32.811 60 12.890 3600 11.050 20 10.725 600 7.576 30 4.113 86-100 3.333 900 3.300 1800 1.6-18 21600 1.443J a n u a ry 2015 300 31.356 60 18.741 20 10.889 3600 9.758 600 5.639 30 4.191 900 2.813 86-100 2.579 120 1.906 1800 1.549

F eb ru a ry 2015 300 32.161 60 18.221 20 10.509 3600 9.657 600 5.365 30 4.574 120 2.773 900 2.458 86-100 2.284 1800 1.589M arch 2015 300 32.497 60 17.769 20 10.635 3600 9.829 600 5.333 30 4.898 120 3.483 900 2.466 86-100 2.216 1800 1.541A p ril 2015 300 31.691 60 18.0-10 3600 10.085 20 9.693 600 7.092 30 5.016 900 2.750 86-100 2.680 21600 1.537 1800 1.495M ay 2015 300 28.438 60 19.665 20 13.689 3600 8.666 30 5.710 600 5.698 120 4.102 900 2.2-41 86-100 1.898 21600 1.395J u n e 2015 300 27.303 60 18.331 20 12.393 600 8.832 3600 8.675 30 5.230 120 3.226 86-100 2.697 900 2.336 1800 1.337Ju ly 2015 300 28.855 60 16.88-1 20 11.682 3600 9.743 600 6.218 30 4.494 86-100 4.109 900 2.632 120 1.661 21600 1.333

A ugust 2015 300 26.3-16 60 19.468 20 12.470 3600 9.891 600 6.579 30 5.116 86-100 3.543 900 3.113 120 1.485 21600 1.463

Table A,2: Top 5 geoloeation distribution for .eo.za domains

Rank 1 2 3 4 5Month Country % of IPs Country % of IPs Country % of IPs Country % of IPs Country % of IPs

October 2013 US 45.060 ZA 33.044 UK 7.275 DE 5.248 NL 1.376November 2013 US 45.072 ZA 33.444 UK 6.718 DE 5.574 NL 1.440December 2013 ZA 39.516 US 39.032 UK 6.989 DE D. ( o3 CA 1.344January 2014 US 44.780 ZA 33.442 UK 6.811 DE 6.117 NL 1.468February 2014 US 44.762 ZA 33.233 UK 6.797 DE 5.821 NL 1.427

March 2014 US 43.665 ZA 34.3 {4 UK 6.610 DE 5.839 NL 1.542June 2014* US 43.785 ZA 35.068 UK 6.336 DE 5.851 NL 1.493July 2014 US 44.524 ZA 34.246 UK 6.039 DE 5.514 CA 1.463

August 2014 US 42.443 ZA 35.502 UK 6.585 DE 5.752 NL 1.428September 2014 US 45.505 ZA 32.753 UK 6.551 DE 5.401 NL 1.463October 2014 US 45.344 ZA 33.103 UK 6.844 DE 5.166 NL 1.645

November 2014 US 46.437 ZA 32.833 UK 5.898 DE 4.876 NL 1.568December 2014 US 42.143 ZA 36.964 UK 5.580 DE 5.045 NL 1.473January 2015 US 45.535 ZA 34.902 UK 5.854 DE 5.446 NL 1.519February 2015 US 46.818 ZA 32.050 UK 6.497 DE 4.930 NL 1.608

March 2015 US 4G.4o4 ZA 33.176 UK G.3o3 DE 4.975 NL 1.513April 2015 US 46.480 ZA 34.870 UK 5.517 DE 4.323 NL 1.317May 2015 US 44.212 ZA 35.463 UK 5.885 DE 5.304 NL 1.510June 2015 US 44.790 ZA 34.681 UK 5.910 DE 5.521 FR. 1.555July 2015 US 44.876 ZA 34.356 UK 5.745 DE 4.775 NL 1.980

August 2015 US 44.598 ZA 35.804 UK 5.318 DE 4.941 NL 1.508

104

Table A,3: Observed TTL and RRs for .eo.za domains

Rank 10Mouth TTL „ t i 1 i Ls TTI. „ i i i i Ls TTI. „ i i n Ls TTI. „ 1 i i i Ls T T L % of TTLs T T L % of T TLs TTL % of T TLs T T L % o f T TLs T T L % of TTLs TTL % of TTLs

( iftt.k -i 2ui:: 7200 22 ■' 11 11100 1 » ' 1 » 'MOO 11 117 3600 13.736 dOO 11.070 J00 7).600 7260 2.606 60 1.7)24 10800 1.492 38400 1.486X \*em bet 2dU' 7200 21 1 i2 11100 l l d ' l 'MOO 1 1 '0 0 3600 l ' l ' - dOO 11.7)01 J00 6.184 7260 2.730 10800 1.647 60 1.7)70 43200 1.299December 2 tT ' 7200 20 >0' '0 100 1 , *'*« 3600 11 >1* * 11100 13.7)17) dOO 12.003 J00 7.622 7260 2.79 60 1.771 1800 1.7)7)3 38400 1.274

Jnnunp UP 11 7200 2 ’ 'To 3600 l.'i.V.h 11100 13.626 'MOO 1 ' 11 - dOO 11.661 J00 6.618 7260 2.81 1800 2.17)6 60 1.800 43200 1.226IVhmr.p Hull 7200 '•MOO 13.676 11100 1 ' 111 3600 13.31 1 dOO 11.696 J00 6.7)09 7260 J.00 } 1800 2.664 60 1.47)6 10800 1.231

Mmcb Hull 7200 21 l ' 1' 'MOO 1 1 7 ') 3600 13.313 11100 12.97)2 dOO 11.7)47 J00 6.226 1800 2.93 ■5 7260 2.783 60 1.389 38400 1.211June 21)14' 86400 2 1 1< " 7200 21.399 3600 12 112 11100 11 1 - ' dOO 10.410 J00 7). 6 7) 8 7260 2.7)0 5 1800 2.7)03 60 1.119 10800 1.012

Jub Hull 7200 2 1 0 7 ' 'MOO 1 ' 1-7' 3600 13.631 11100 12 111 dOO 11.637 J00 6.723 1800 5.7)0 7260 5.224 10800 1.349 60 1.218A un is! 21)11 7200 'MOO h.dUU 3600 13.097 dim 11 2 d ' 11100 11.221 J00 6.426 1800 5.89 5 7260 2.896 28800 1.817 60 1.302

SepteUlliel 21)11 7200 21 l ' l 'MOO 1 ) 2 '’1 3600 12 '0 1 11100 11.793 dOO 11.441 J00 6.133 1800 5.37) 7260 2.827) 28800 2.7)31 10800 1.207)( Iftek -l 2U11 7200 22 D*<1 3600 1 1 7 11 'MOO l ' d ' l 11100 13.267) dOO 11.620 J00 7).907) 28800 1.47)0 1800 5.238 7260 2.481 60 1.7)17

A f'em b e l 21)11 7200 3600 11 '71 11100 12 '2 1 dim 12.7)37) 'MOO 12.443 J00 6.393 1800 5.417) 7260 2.727 28800 2.402 60 1.443DeCeUll-et 21*11 7200 21 211 3600 In.U'.IU dim 11 ’07 11100 12 121 'MOO 10.7)7)7 J00 7.731 1800 5.713 7260 2.900 28800 1.67)7) 60 1.610January 21)If) 7200 3600 14.117 dim 1 ' 1-1 11100 13.20 1 'MOO 10.7)67) J00 6.927) 1800 5.446 7260 5.002 28800 1.870 60 1.7)26IVbllir.p 2U1.'. 7200 21 i '2 3600 11 O '1' 11100 13.197 dim 12.739 'MOO 10.388 J00 6.848 1800 5.697) 7260 5.187 28800 1.763 60 1.7)64

March 2Ui:. 7200 21 12 ' 11100 11 201 3600 1 ' vi-l dim 12 ‘'12 'MOO 10.088 J00 6.492 1800 5.7)24 7260 5.07)9 28800 2.011 60 1.7)99April 2U1.J 7200 2 ' vv 1 3600 11 272 dim 13.363 11100 12 '1-7 'MOO 9.809 J00 7.07)1 1800 5.7)61 7260 5.097 28800 1.987 60 1.712,\bo 2Ui:. 7200 2l< 071 3600 1 ' dim 13.723 11100 11 7 1 ' 'MOO 9.267 J00 6.723 1800 5.322 7260 5.226 28800 2.07)9 60 1.4947)June 2l)lf) 7200 dim 1 r i.l )2r i 3600 13.273 11100 11 '0 ’ 'MOO 9.118 J00 6.631 1800 5.27)6 7260 2.702 28800 2.114 60 1.7)66Jub 2U1.'. 7200 I;»U dim 14.771 3600 13.036 11100 11 'MOO 9.7)78 J00 7.327) 1800 5.792 7260 2.628 28800 2.121 60 1.7)16

A u m si 2bl."i 7200 dim 1 ' 112 12 'M 11100 11 ' .1 'MOO 9.334 J00 7.329 1800 4.133 7260 5.329 28800 2.77)9 60 1.7)97)

R ank 10M onth R R 'A. o f RRs R R R R o f 1!1N R R i; i ; At o f R R s R R At o f R R s R R At o f R R s R R Vi. o f R R s R R At o f R R s R R At o f R R sO ct 13 \ 75.522 MX 13.397 C X A M F o.-iso T X T 1 129 i t i ; 0.066 SOA 0.060 AAAA 0.027 XS 0.016 AXY 0.005 X /AX ovl3 \ 75.3-15 MX 14.005 C X A M F 0.2-15 T X T 1 .• 1 A A A A 0.028 SOA 0.011 XS 0.006 X /ADec 13 \ 67.295 MX 21.1*9 T X T 5.9t>5 C X A M F 17* SO A 0.031 AAAA 0.031 XS 0.010 X /AJanl-1 \ •1.779 MX 1-1,103 C X A M F 6.210 T X T 1 29 AAA.A 0.040 SOA 0.020 P T R 0.013 XS 0.007 X AFebl-1 \ 5.653 MX 13,565 C X A M F 6,514 T X T 4.177 AAA.A 0.034 XS 0.023 SOA 0.017 P T R 0.011 SllV 0.006 X /AMarl-1 \ 7.074 MX 12,s 57) C X A M F 6.0-18 T X T ......... AAA.A 0.044 SOA 0.017 XS 0.017 P T R 0.006 X AJiml-1 \ 9.413 MX 11.7 •2 C X A M F 5.112 T X T . ** SO A 0.028 XS 0.028 AAAA 0.028 SllV 0.011 X AJull-1 \ 2.422 MX 1*.U 55 C X A M F 5.1*2 T X T 1 2> 9 AAA.A 0.036 XS 0.024 SllV 0.006 SOA 0.006 X A

Augl-1 \ 5.148 MX 1-1,l it) C X A M F 6.039 T X T 1 297 AAA.A 0.047 XS 0.029 SOA 0.012 P T R 0.012 X ASepl-1 \ 7.402 MX 11.*7i7 C X A M F 7.073 T X T . 72 AAA.A 0.058 SOA 0.019 XS 0.014 P T R 0.005 X AO ft 1-1 \ 6.734 ('-NAME 9.sM MX 9. *20 T X T , AAA.A 0.102 XS 0.018 SOA 0.009 X /ANov 1-1 \ 5.168 MX 10.772 C X A M F 10.2-1-1 T X T . • 71 AAA.A 0.111 SOA 0.010 P T R 0.010 XS 0.010 SllV 0.005 X /AD ef 1-1 \ 9.134 MX 19,1-1-1 C X A M F 0.59* T X T 1 • *2 AAA.A 0.097 XS 0.030 SOA 0.015 X /AJ a n lo \ 7-1.030 MX 12.191 C X A M F 9.8*9 T X T AAA.A 0.083 SOA 0.017 XS 0.017 SllV 0.011 P T R 0.011 X AF eb l5 \ 73.702 MX 11.*7i2 C X A M F 10.80S T X T .9 7 9 AAA.A 0.120 SllV 0.015 SOA 0.015 XS 0.010 X AM arl5 \ 73.490 MX 11.374 C X A M F 10.0*5 T X T 1 27' i AAA.A 0.144 SllV 0.014 SOA 0.014 XS 0.010 X AA p r lo \ 73.2161 MX 13.21* C X A M F *.259 T X T 119 AAA.A 0.098 SOA 0.0261 XS 0.0261 SllV 0.007 X AMay 15 \ 77.379 MX 12,1*7 C X A M F 5.555 T X T 1 1*1 AAA.A 0.045 SOA 0.023 SllV 0.011 XS 0.011 I T T 0.006 X AJ u n lo \ 77.236 MX 12,510 C X A M F 5,17* T X T ■I.6J 1 XS 0.040 P T R 0.034 AAAA 0.034 SOA 0.017 SPY 0.011 X AJ u l l5 \ 77.8-11 MX 11.932 C X A M F 5,1*1 T X T 1 • 27 i t i ; 0.029 AAAA 0.029 XS 0.017 SllV 0.012 SOA 0.012 X A

Auj>15 \ 75.862 MX 13,556 C X A M F 5.392 T X T 9 ,* i t i ; 0.057 AAAA 0.038 SOA 0.025 SllV 0.019 XS 0.013 X A

Table A,4: Top 5 geoloeation distribution for .org.za domains


October 2013 ZA 44.886 US 34.943 UK 6.818 DE 4. o4o CA 3.409November 2013 ZA 44.548 US 37.003 UK 6.116 DE 3.976 CA 2.446December 2013 ZA 48.428 US 28.931 UK 8.805 DE 6.918 CA 3.774January 2014 ZA 46.964 US 31.579 UK 7.287 DE 4.858 CA 3.239February 2014 ZA 47.727 US 31.169 UK 7.468 DE d . 8 4 4 CA 3.247

March 2014 ZA 43.567 US 35.380 UK 7.018 DE 4.971 CA 2.632June 2014* ZA 45.614 US 36.842 UK 5.614 DE 4.211 CA 2.105July 2014 ZA 43.791 US 35.621 DE 5.882 UK 4.575 CA 2.941

August 2014 ZA 42.236 US 37.267 UK 5.590 DE 4.658 CA 4.037September 2014 ZA 43.223 US 37.084 UK 5.882 DE 5.882 CA 3.069October 2014 ZA 44.784 US 39.440 UK 4.326 DE 3.817 CA 2.290

November 2014 ZA 44.179 US 37.910 UK 5.671 DE 5.075 CA 2.090December 2014 ZA o3.333 US 28.571 DE 6.190 UK 5.238 CA 2.857January 2015 ZA 45.946 US 36.149 DE 5.068 UK 4.730 CA 3.716February 2015 ZA 47.309 US 35.411 UK 7.082 DE 2.833 CA 2.833

March 2015 ZA 46.392 US 36.856 UK 5.928 DE 3.351 CA 3.093April 2015 ZA 52.434 US 31.461 DE 5.243 UK 4.120 CA 3.371May 2015 ZA 49.045 US 32.166 UK 5.732 CA 4.4o9 DE 3. o03June 2015 ZA 51.118 US 29.393 UK 6.709 CA 4.473 DE 3.834July 2015 ZA 50.316 US 31.329 UK 6.646 DE 4.430 CA 2.532

August 2015 ZA 51.957 US 28.114 UK 8.185 DE 4.982 CA 3.203

105

Table A,5: Observed TTL and EEs for .org.za domains

h rtlk 10Mouth TTI. „ t i i i Ls T T L % o f TTLs T T L % o f TTLs T T L „ t i i i Ls TTI. „ t i i i Ls TTI. , t i i i Ls TTL % of T TLs T T L % o f T TLs T T L % of TTLs TTL % of TTLs

i k Et k i J u l ' 7200 • ' 4 ( , VU 100 12.682 3600 11.713 14400 dim 7 ' l l 300 d.r.m 10800 2.420 7260 2.227 60 0.968 21600 0.968V n m l m JUl ' 7200 ’1 ' J ' 1 11100 14.07)0 86400 12.161 3600 11.806 dim 8.a0l 300 o.um 10800 2.7)97 7260 2.243 43200 1.67)3 28800 1.1811 u t im b u J U l ' 7200 lu ' ' i 3600 11.603 86400 10.127 14400 7.8U0 300 7 ’'1 dim n.d'.ld 7260 2.743 10800 2.2.611743 43200 1.07)7) 1200 0.844

J am a ' JU ll 7200 12 J 'IV 3600 10.7)74 86400 10.183 14400 'v dim i ,i U2 300 i< >' 1800 2.872 7260 2.611 10800 1.7)67 43200 1.044i t i m i n ' JU ll 7200 i ' U'd vl> 100 8.401 3600 8.178 600 d.ldd 11100 i, > r 300 ■ d 1800 3.048 7260 1.710 10800 1.264 43200 0.7)97)

'1 a t I JU ll 7200 A’.JnU 3600 9.7)79 86400 8.999 14400 d.'.IOI dim i 'Ud 300 4.717 1800 4.209 7260 1.47)1 10800 1.016 1200 0.798W JU ll 7200 T 117 3600 12.704 86400 10.692 600 10 l ' 1' 11100 nun,;; 300 9.937 1800 7).031 7260 2.138 10800 2.138 1200 1.006Jub JU ll 7200 J., 'Jv 3600 11.687) 600 11.413 86400 300 TOT) 11100 9.377) 1800 7).707 7260 2.038 10800 2.038 43200 1.223

' m u s t JU ll 7200 ’J oul 3600 11.916 14400 11.427) 86400 vjv dim " 11 300 ' 177 1800 6.7)11 7260 2.088 10800 1.966 43200 1.106S q iia n l iu JU ll 7200 :j2.or»9 uuu 11.373 14400 11.373 3600 10 d 'd 'd 100 ■' '0 1 300 7.37)3 1800 4.020 7260 2.647 1200 1.667 10800 1.7)69

i k Et 1 JU ll 7200 " i , i ' 11100 12.821 3600 11.491 600 'd 100 T2 12 300 7.787 1800 2.944 10800 2.67)9 10800 1.330 1200 1.237)V n m l i u JU ll 7200 ■j l,UU 11.830 3600 11.719 14400 1 l.ld l 'd 100 9.263 300 ' '71 1800 2.344 7260 1.897 43200 1.897 10800 1.7)631 i i t im b u JU ll 7200 33.097) l,UU 11.807 3600 11.449 14400 'd 100 '■ ' l i 300 ' 10' 7260 2.2.372862 1800 2.683 10800 2.147 43200 1.968

J am a ' JUl i 7200 36.207) 11100 10.861 3600 10.737 600 10 l v7 'd 100 300 ' ’d i 7260 2.372 1800 2.247 10800 1.623 43200 1.124i t b in a ' J u l i 7200 ’1 ’ . ’ 11100 11.927 3600 11.7)19 600 III.1. )U, 'd 100 ' UU 1 300 ' 0 i 1 1800 3.976 7260 1.733 43200 1.223 10800 1.019

'1 a tb J u l . 7200 33.301 dim 11.900 14400 11.324 3600 1 0 ‘'10 'd 100 9.309 300 7 'd ‘‘ 7260 2.399 1800 2.303 1200 1.7)36 43200 1.344'p u l J U l i 7200 ’0 ' i7 3600 12.143 600 11.7)71 14400 1 I.T7I 300 10 112 'U 100 ' 11 ' 1800 2.87)7 7260 2.714 60 1.286 43200 1.286'1 a JUl , 7200 33.209 3600 12.7)17) 600 12.268 14400 1 I.LVJ 300 ' 12u 'U 100 ' i i 7260 2.230 1800 2.230 10800 1.611 60 0.991

June JUla 7200 ’0 1* * 1 dim 12.903 3600 12.000 14400 10 300 10.326 'U 100 8.000 1200 2.323 7260 2.067) 1800 2.067) 10800 1.677Jub J u l ) 7200 29.699 dim 12.67)7 3600 12.7)31 14400 r.’.imu 300 ....... . 'd 100 7.393 1800 2.77)7 7260 2.007) 1200 1.880 10800 1.629

' m u s t J u l ) '0 M 11.444 600 10.218 14400 ■' ‘'lu 'd 100 V 'V 1800 7).47)0 7260 2.997 1200 2.316 43200 1.907

R an k 3 6 8 9 10M onth HR. % o f R K s R R id ; % o f R R s id ; % o f Ribs id ; % o f Ribs id ; % o f R R s % o f Ribs RR. % o f Ribs RR. % o f Ribs RR. % o f RibsO ct 13 \ 81.413 M X 7*Ms ( \ \ M L 7.067 1 X 1 ) 2*!i U.I9J \ s 111)*!, \ lN o v l3 \ 79.221 M X *i f>si ( \ \A lL b.s-ls 1 X 1 1 52 1! lb s \ lD ee 13 \ 79.114 M X 14 1 1 ' 1 X 1 4.6-41 ( \ \ M L i.KOO 0.211 \ lJ a n l4 \ \2 t> 57 MX s ;>> 1 X 1 1 17! ( \ IM L 1 17! 1! R \ lF e b l4 \ sb 122 MX b '41 ( \ \ M L 1 fill! 1 X 1 2.602 0.1-19 AAAA 0.074 \ lM a rl4 \ sb sb i MX > f>f>l! ( \ \A lL 4.790 1 X 1 2 612 i!ii71 \ l, Iu n l4 \ s i 1 )2 MX *i is 2 ( \ \ M L 6.667 1 X 1 2 S' i 1 i! 126 \ l,Iu ll4 \ 7 s si 4 MX 11 s 2 i ( \ \A lL 1 ,s*!i 1 X 1 1 212 0.136 AAAA 1! 11 )6 \ l

A u g l4 \ MX ll).l)6 l ( \ \ M L K 1!' !K 1 X 1 ) 6,sl n l 2 ) AAAA 1! 12 ) \ lS e p l4 \ 7o n2i! MX *i i i s ( \ \A lL iS 1)1 1 X 1 1 2 1 ' 1! .110X1! AAAA 11.11! IKI \ lO ct 14 \ ? ! >s2 ( \ \ M L *! 4 >2 MX ■S 1172 1 X 1 2 7 '1 U.UOo AAAA 1) I)*!.' \ lN o v l4 \ 7s 12 ' ( \ \A1L ll! 1 'f> MX K 2.-'*! 1 X 1 5 12 > AAAA 1! ))> \ lD ee 14 \ 7t> n2'i MX 11 s4 s ( \ \ M L 1 6 '1 1 X 1 1 172 \ li a n l o \ MX '! JS ( \ \A lL 7.491 T X T 2.871 A A A A 0.125 -N/AF e b lo \ 76 '«>2 ( \ \ M L MX 8.767 T X T 3.262 -N/AM ario \ ( \ \A1L * i * is! MX 7.006 T X T 3.167 A A A A 0.288 -N/AA p r lo \ ? ! 2sf> MX l«i 141 ( \ \ M L 5.429 T X T 5.000 A A A A 0.143 -N/AM ay lo \ ? ! f>7s MX *!*!!; ( \ IM L 5.452 T X T 4.957 -N/Ai u n lo \ s i 14 5 MX '• 27s 1 X 1 4.768 C.NAML 4.510 -N/AJ u l io \ s 2 2i !f> MX s 772 1 X 1 4.762 C.NAML 4.261 -N/A

A u g lo \ s u .o i s M X llL7t>3 1 X 1 4.496 C.NAML 4.223 N /A

Table A,6: Top 5 geoloeation distribution for .gov.za domains


October 2013 ZA 96.226 US 3.774 - - - - - -

November 2013 ZA 94.845 US 3.093 NZ 1.031 DE 1.031 - -

December 2013 ZA 96.825 US 3.175 - - - - - -

January 2014 ZA 94.565 US 4.348 DE 1.087 - - - -February 2014 ZA 94.898 US 5.102 - - - - - -

March 2014 ZA 92.593 US 3.704 UK 0.926 NZ 0.926 DE 0.926June 2014* ZA 94.231 US 4.808 NZ 0.962 - - - -July 2014 ZA 96.000 US 3.000 NZ 1 .0 0 0 - - - -

August 2014 ZA 9 4 ,4 4 4 US 4.630 DE 0.926 - - - -September 2014 ZA 95.833 US 3.333 DE 0.833 - - - -

October 2014 ZA 95.370 US 4.630 - - - - - -

November 2014 ZA 95.146 US 4.8o4 - - - - - -

December 2014 ZA 97.260 US 2.740 - - - - - -

January 2015 ZA 94.624 US 4.301 DE 1.075 - - - -

February 2015 ZA 93.333 US 5.714 DE 0.952 - - - -

March 2015 ZA 94.898 US 4.082 UK 1.020 - - - -

April 2015 ZA 95.402 US 4.598 - - - - - -

May 2015 ZA 94.624 US 5.376 - - - - - -

June 2015 ZA 92.771 US 7.229 - - - - - -

July 2015 ZA 96.739 US 3.261 - - - - - -

August 2015 ZA 96.552 US 3.448 - - - - - -

106

Table A,7: Observed TTL and EEs for .gov.za domains

flank 10Mon 111 T T L % of TTLs T T L % of TTLs TTL % of T TLs TTL % of TTLs TTL % of TTLs TTI. , i t 1 I t s T T L % of T TLs TTL % of TTLs TTL % of TTLs T T L % of TTLs

Octobei 2013 600 33.334 3600 22.727 86400 17.172 7200 7).7)7)6 300 1.011 1 0 V0 0 1 )1 ) (>d 3.7)31 38400 2.020 14400 2.020 7260 1.010Xovembei 2013 600 32.418 86400 18.681 3600 18.681 7200 6.044 14400 4.941 1 ’‘'l> 1 0 H I0 4.396 60 3.297 38400 2.198 7260 1.099Decembei 2013 600 30.273 3600 28.440 86400 14.679 7200 7).7)07) 300 4.187 1 1 1 0 0 1 iv 7 1 0 H I0 4.187 60 2.77)2 38400 2.77)2 240 0.917Jauuaiv 2014 600 26.316 3600 24.661 86400 19.883 7200 6.433 10800 6.433 i v lv (>d 3.109 14400 2.339 38400 1.77)4 604800 0.7)87)

Febiuaiy 2014 600 26.923 3600 24.7)19 86400 17.788 10800 7.212 300 1.769 1 1 1 0 0 1 '2 7 7200 3.846 38400 1.923 60 1.442 1800 1.442Maicb 2014 600 33.333 3600 22.87)7 86400 16.667 300 6.190 7200 4.286 1 1 1 0 0 1 0 V0 0 3.333 60 2.381 38400 2.381 7260 0.97)2June 2014’ 600 30.928 3600 24.227 86400 18.041 7200 ">.17)7) 300 l . l l l 1 0 V0 0 1.111 (>d 2.062 38400 2.062 1800 2.062 14400 2.062July 2014 600 34.211 3600 21.7)79 86400 18.421 300 1.263 10800 4.211 ’ l-v 1 (>d 3.118 1800 3.17)8 38400 2.107) 14400 1.7)79

August 2014 600 32.103 3600 23.684 86400 13.684 7200 1.789 10800 1.263 (id ’ l 'v 1 1 1 1 0 0 3.118 300 2.632 1800 2.632 38400 2.107)Septembei 2014 600 33.061 3600 19.184 86400 16.327 300 6.7)31 7200 6.122 1 0 V0 0 a.Odd 1 1 1 0 0 3.673 7260 2.041 38400 2.041 60 1.633

Octobei 2014 600 31.197 3600 21.368 86400 16.667 300 7).983 10800 1.983 a.aab (>d 2.991 38400 2.137 14400 2.137 7260 1.282Xovembei 2014 600 31.429 3600 18.7)71 86400 17).238 7200 7.143 300 7.143 1 0 V0 0 (,.190 (>d 2.817 14400 2.381 7260 1.429 38400 1.429DeeembeT 2014 600 29.861 86400 21.7)28 3600 17.361 7200 6.944 300 6.210 1 0 V0 0 1 M-l 1 1 1 0 0 3.472 60 2.083 43200 2.083 38400 2.083Jauuaiv 2013 600 30.811 3600 21.081 86400 16.216 7200 7.027 300 1.946 1 0 V0 0 ’ 7 V 1 ’v u n i 3.243 1800 3.243 60 2.162 14400 1.622te b iu a iy U01;» 600 26.300 3600 22.7)00 86400 17.000 7200 8.000 300 6.000 1 0 V0 0 a.000 1 1 1 0 0 3.000 38400 2.7)00 43200 2.000 1800 2.000

M aid] 2013 600 31.884 3600 21.27)6 86400 18.37)7 7200 7). 314 300 4.831 1 1 1 0 0 1 T 1 0 V0 0 3.861 38400 1.932 7260 1.449 60 1.449A piil 2013 600 30.247 3600 17.901 86400 14.198 7200 7.407 43200 7.407 6.173 1 1 1 0 0 4.321 10800 4.321 38400 3.086 1800 1.87)2May 2013 600 33.333 3600 21.637 86400 11.696 10800 6.433 14400 1.848 1 1>7V 7200 4.094 43200 4.094 38400 2.339 1800 1.77)4June 2013 600 31.169 3600 22.078 86400 14.286 iOO 7.792 43200 1.191 1 ,1 , 1 1 1 0 0 4.7)41 10800 3.247 38400 2.7)97 60 1.299July 2013 600 28.070 3600 18.713 86400 11.696 iOO 7.018 14400 7.018 l> ” 1 ’2 0 0 1.263 10800 4.678 38400 2.339 1800 2.339

August 2013 600 26.946 3600 23.37)3 86400 10.778 iOO 8.982 43200 7.186 1 1 1 0 0 , 4.192 10800 4.192 60 1.796 38400 1.796

L a n k 2 8 4 0 7 8 9 10M o n th b b % o f b b s b b % o f b b s b b % o f b ib s b b % o f b b s b b ' .4 b 1C b b ' .4 b ib s b b % o f b ib s b b % o f b ib s b b % o f b ib s b b % o f b ib s

O c t l3 80.808 C X A M E 14.141 M X 1010 T X T 1.818 \ 5 U.O'.IO X VX ov 13 82.007 C X A M E 12.088 M X 8 297 T X T 1.099 \ 5 0.319 X VD c c l3 87).,521 C X A M E 7.889 T X T 1 009 M X 8.009 \ V,!cinl4 82.47>0 C X A M E 11.090 T X T M X 2.924 X AE e b l4 80.709 C X A M E 12.800 T X T 0.0O0 M X 8.808 X AM a r l4 81.907) C X A M E 12.837 T X T 2 s o 7 M X 2.881 X A,Iu n l4 80.082 C X A M E 8.708 T X T 1 091 M X 2.002 X A,fu ll4 88.17)8 M X 0.842 C X A M E 0.642 T X T 8.188 X A

A u g l4 80.000 C X A M E 18.084 M X 8.054 T X T 2.082 X AS e p l4 81.224 C X A M E 18.001 T X T 2.587 M X 2.887 X AO c t l4 81.197 C X A M E 18.248 T X T 2.991 M X 2.8(71 X A. \o v l4 70.190 C X A M E 18.288 M X 4 702 T X T 8.810 X AD c c l4 77.088 C X A M E 9.722 M X 5 111 T X T 4.801 X AJc in lo 79.47)9 C X A M E 10.811 T X T 4 .508 M X 4.808 X Af e b l o 79.000 C X A M E 12.000 T X T ■I.OUU M X 4.800 X AM a r io 74.890 C X A M E 18.489 T X T 8 114 M X 4.881 X AA p r lo 73.920 C X A M E 12.908 T X T 0 171 M X 4.988 X AM ctylo 80.117 C X A M E 7.002 T X T 0 411 M X 8.848 X A3 u n i 3 81.109 T X T 0.494 C X A M E 0 494 M X 8.844 X AJ u l io 81.287 M X 7.018 T X T 0 411 C X A M E 8.208 X A

A n g lo 81.487 T X T 0.887 M X 8 955 C X A M E 8.988 X A

Table A,8: Top 5 geoloeation distribution for .ae.za domains


October 2013 ZA 72.174 US 13.913 DE 4.348 UK 3.478 AU 1.739November 2013 ZA 77.228 US 13.861 DE 4.950 AU 1.981 UK 0.990December 2013 ZA 82.432 US 9.459 DE 5.405 UK 2.703 - -

January 2014 ZA 76.596 US 13.830 DE 4.255 UK 2.128 AU 2.128February 2014 ZA 75.229 US 15.596 DE 3.670 UK 2.752 AU 1.835

March 2014 ZA 81.308 US 11.215 DE 4.673 UK 1.869 AU 0.935June 2014* ZA 78.899 US 12.844 DE 4.587 AU 1.835 UK 0.917July 2014 ZA 81.731 US 9.615 DE 3.846 UK 1.923 AU 1.923

August 2014 ZA 79.824 US 12.281 DE 3.509 UK 2.632 MU 0.877September 2014 ZA 78.814 US 13.559 DE 3.390 UK 2.542 AU 1.695October 2014 ZA 82.300 US 10.620 DE 3.540 UK 2.655 AU 0.885

November 2014 ZA 73.913 US 14.783 UK 4.348 DE 4.348 AU 1.739December 2014 ZA 76.000 US 16.000 DE o.333 UK 2.667 - -

January 2015 ZA 75.893 US 15.179 DE 4.454 UK 2.679 AU 1.786February 2015 ZA 73.984 US 17.073 UK 3.252 DE 3.252 AU 1.626

March 2015 ZA 79.464 US 12.500 DE 3.571 UK 2.679 AU 1.786April 2015 ZA 79.245 US 16.038 DE 3.774 AU 0.943 - -May 2015 ZA 76.190 US 15.238 UK 3.810 DE 3.810 AU 0.952June 2015 ZA 78.641 US 13.592 DE 3.883 UK 1.942 AU 1.942July 2015 ZA 71.560 US 19.266 UK 3.670 DE 3.670 AU 1.835

August 2015 ZA 72.222 US 18.519 UK 3.704 DE 3.704 AU 1.852

107

Table A,9: Observed TTL and RRs for .ae.za domains

I? auk 10Mouth TTL of TTLs T l'L of TTLs T l'L % of TTLs TTL % of TTLs TTL % of TTLs TTL '••I of TTLs TTL Vi of TTLs TTL Vi of TTLs T l'L % of TTLs TTL % of T TLs

October 21)13 &{< mu 17.2(0 0(-l!l! 17.alt) 10800 9.87)4 900 4.927 7200 2.872 800 2.101) 600 l.f>27, 11 Hill l.f>27, 60 1.460 27,9200 1.460Xovembei UUl.t &{< mu l&.om 0{-l!l! 11.171 ID 800 11.404 900 7).482 800 2.412 7200 2.108 600 2.108 27,02111! 1.071 172800 1.7,27, 8600 1.216Decembei UUlO &{< mu all .1)1)1) 0{-l!l! 1 1.28b ID 800 9.877) 900 4.46a 600 2.679 800 2.670 1728UU 2.670 721)1! 2.222 60 2.222 27,9200 2.222Jaisuarv 21114 f>(dl!l! Ih.shs 0{-l!l! li.au .: ID 800 9.719 900 6.0477) 600 4.104 7200 2.876 27,021)1! 2.876 17281)1! 1.011 200 1.728 60 1.7,119I'ebiuaw 2U1 1 &(> mu la .521! 0{-l!l! 17.U25 ID 800 7.7)27 900 6.681 600 8.948 800 2.6f>f> 27,021)1! 2.6f>f> 721)1! 2 ..:.:o 172800 1.971 8600 1.424

March 21114 f>(dl!l! 1&,(..::i 0{-l!l! 15.071 ID 800 8.711 900 4.900 600 4.900 800 3.1185 72111! 2.722 27,02111! 1.17,2 172800 1.47,2 14400 1.270June 21114'' SldUU 15.Ilf, f, 0{-l!l! 17.711) 60 7).268 900 4.211 600 4.211 1800 10800 200 2.17,f, 2.107, 27,9200 2.107,July 2U11 SldUU 10.825 0{-l!l! 10.825 ID 800 4.7)61 900 4.886 600 8.7)09 1800 2.:if>2 81)1! 2.682 27,02111! 2.2f>l 7200 1.920 60 1.7,79

Ju q iM 2U11 &(> mu .11.(0,a 0{-l!l! l0.U5(> 9uu 7).268 10800 4.87)6 1800 8.086 600 2.722 1728111! 2.722 200 2.7,11 27,9200 2.178 14400 1.996September 2U11 f>(dl!l! d.&Ull 0{-l!l! 17.288 9uu 7). 7) 14 1800 4.178 10800 8.428 600 2.f>82 800 2.286 721)1! 1.100 60 1.490 14400 1.490

Octobei 2lll 1 SldUU .2.101 0{-l!l! 1(.,1(.7 9uu 6.906 10800 7).976 1800 8.718 800 2.7)28 6UI! 2.801! 721)1! l.f>aO 172800 1.461 60 1.228Xovembei 2U11 SldUU .l.r.o& 0{-l!l! 17.U17 9uu 7.610 10800 6.697 1800 4.110 800 2.187, 721)1! 1.070 ()l!U 1.671 60 1.270 27,9200 0.761D m m b e i 2U11 &(> mu 11.812 0{-l!l! 2b.820 9uu a.7)7a 1800 7).226 10800 4.181 800 8. If) 1 60 2.180 721)1! 2.001 27,9200 2.091 600 1.294Jaisuarv 2l!lf> f>(dl!l! ll.JU l 0{-l!l! 22.21.1 9uu 7.7)87 10800 4.412 1800 8.809 800 8.127, 27,02111! 2.77,7 721)1! 2.201! 600 1.828 172800 1.287I'ebiuaw 2111a SldUU 10..101 0{-l!l! 10.(>5ll ID 800 7.188 900 6.826 1800 2.428 800 2.1)10 721)1! l.f>f>l 60 1.77,1! 172800 1.246 27,9200 1.211

Maids 2111a SldUU r.i.122 0{-l!l! lb.7l!8 9uu 9.601 10800 7.87)7 1800 2.618 800 2.211 721)1! 1.871! 17281)1! 1.716 600 1.122 27,9200 1.122April 2Ula &(> mu .all. 1.12 0{-l!l! If). 1.1a ID 800 7.27)4 900 6.7)68 1800 8.282 800 2.761 721)1! 2.1)78 ()l!U 1.727 172800 1.7,7,4 60 1.026May 2Ula f>(dl!l! 5U.3U7 0{-l!l! l(oi7.: ID 800 7). 726 900 7).817 1800 8.887) 600 2.f>68 800 2.210 721)1! 2.1! 17, 60 1.626 172800 1.626Juise 2Ula SldUU 18.28.: 0{-l!l! If).2 HI 9uu 7).17)0 10800 4.721 1800 4.7)06 600 2.7)77, 800 2.7)77, 721)1! 2.261 172800 2.146 60 1.7,02July 2Ula &(> mu 1.0127 0{-l!l! l8.82b ID 800 6.680 7200 4.67)6 1800 4.67)6 900 1.17,8 800 2.026 27,02111! 2.021 600 1.822 172800 1.822

Aliquot 2Ula f>(dl!l! ib.72.: 0{-l!l! 2U.5U7 9uu 7).920 1800 7).074 10800 4.67)2 7200 2.7 lf> ()l!U 2.7,27 200 2. 27 172800 1.480 60 1.268

R an k 2 3 3 6 7 8 3 10M o n th R R X u f R R s R R -4 R R s R R •A RR> RR % o f R R s R R % o f R R s R R % o f R R s R R % o f R R s RR % o f R R s RR % o f R R s R R % o f R R sO c t l3 N 74.333 ( '.N A M E 13.371 M X 3.832 T X T 3.102 N A A A 1.460 . \ A\ o v 13 N 73.b74 ( '.N A M E 13.818 M X 1.347 T X T 3.283 N A A A 1.374 . \ AD ec 13 N 78.123 M X 8.338 I X I 3.804 ( 'N A M E 3.804 N A A A 1.786 S( >A 0.446 N / A

,Jan l4 N 73.132 ( '.N A M E 13.113 M X 4 .3 13 T X T 3.672 N A A A 1.312 . \ AF e b l4 N 73.118 ( '.N A M E 17.184 I X I 1.731 M X 3.763 N A A A 1.371 . \ AM cirl4 N 74.22b ( '.N A M E 13.878 M X 1.448 T X T 3.267 N A A A 1.336 Si »A 0.181 \ A,Iim l4 N 77.833 ( '.N A M E 12.438 I X I 1.111 M X 3.333 NAAA 2.632 Si »A 0.173 0.173 N / A,!u ll4 N 73.783 ( '.N A M E 13.883 M X 4.211 T X T 3.333 NAAA 2.436 SRY 0.173 0.173 N /A

A u g l4 N 73.333 ( '.N A M E 13.78 8 M X 4.323 T X T 3.442 NAAA 2.174 NS 0.181 \ AS e p l4 N 71.833 ( '.N A M E 13.821 I X I 2.381 M X 2.381 NAAA 2.233 NS 0.143 \ AO c t l4 N 33.373 ( '.N A M E 27.888 I X I 2.323 M X 2.330 NAAA 1.332 NS 0.111 \ A. \o v l4 N 33.473 ( '.N A M E 28.787 M X 2.832 T X T 2.388 NAAA 1.373 Si »A 0.132 0.132 N /AD ec 14 N 73.313 ( '.N A M E 12.133 M X 8.383 T X T 3.833 NAAA 3.484 . \ AJc in lo N 73.221 ( '.N A M E 23.772 M X 1.431 T X T 3.123 NAAA 1.838 S( »A 0.368 NS 0.184 N /AFA , 13 N 33.832 ( '.N A M E 12.137 M X 3.383 T X T 2.826 NAAA 1.480 Si »A 0.133 N S 0.133 N /AM a r l 3 N 33.88.3 ( '.N A M E 33.333 M X 2.383 T X T 2.740 N A A A 1.434 . \ S 0.123 N AA p r l3 N 82.388 ( '.N A M E 28.131 M X 1.321 T X T 3.276 N A A A 2.063 S( »A 0.172 N S 0.172 N /AM a v l3 N 73.141 ( '.N A M E 11.043 T X T 3.883 M X 3.476 N A A A 2.243 . \ S 0.204 N S N / A

J u n lS N 78.328 ( '.N A M E 10.730 T X T 4 .077 M X 3.863 N A A A 2.730 . \ S 0.213 N A,lu l l S N 83.372 ( '.N A M E 7.834 M X 4.636 T X T 3.846 N A A A 2.632 . \ A

A u g l 3 N 73.887 ( '.N A M E 13.331 M X 4.017 T X T 3.334 N A A A 2.360 . \ S 0.211 N’/'A

Table A, 10: Top 5 geoloeation distribution for .other za domains


October 2013 ZA 82.222 US 6.667 UK 4 ,4 4 4 MU 4 ,4 4 4 DE 2 .2 2 2

November 2013 ZA 80.000 US 8.889 UK 4 ,4 4 4 MU 4 ,4 4 4 DE 2 .2 2 2

December 2013 ZA 78.571 US 10.714 UK 3.571 MU 3.571 DE 3.571January 2014 ZA 80.851 US 8.511 UK 4.255 MU 4.255 DE 2.128February 2014 ZA 73.810 US 11.905 MU 9.524 UK 2.381 DE 2.381

March 2014 ZA 77.778 US 1 1 .1 1 1 MU 4 ,4 4 4 DE 4 ,4 4 4 UK 2 .2 2 2

June 2014* ZA 84.000 US 8 .0 0 0 MU 6 .0 0 0 UK 2 .0 0 0 - -

July 2014 ZA 67.164 US 8.955 MU 4.478 UK 2.985 DE 1.493August 2014 ZA 86.765 US (. 3o3 MU 4.412 UK 1.471 - -

September 2014 ZA 77.778 US 9.259 MU 9.259 UK 1.852 NL 1.852October 2014 ZA 84.314 US 9.804 UK 1.961 NL 1.961 MU 1.961

November 2014 ZA 82.258 US 8.065 UK 3.226 MU 3.226 NL 1.613December 2014 ZA 79.545 US 9.091 MU 6.818 UK 2.273 NL 2.273January 2015 ZA 83.333 US 6.250 MU 6.250 UK 2.083 DE 2.083February 2015 ZA 82.222 US 6.667 MU 6.667 UK 2 .2 2 2 DE 2 .2 2 2

March 2015 ZA 77.083 US 10.417 MU 4.167 DE 4.167 UK 2.083April 2015 ZA 77.778 MU 6.667 DE 6.667 US 4 ,4 4 4 UK 2 .2 2 2

May 2015 ZA 77.083 US 8.333 MU 6.250 DE 4.167 UK 2.083June 2015 ZA 76.316 MU 7.895 US 5.263 DE 5.263 UK 2.632July 2015 ZA 77.778 US 8.889 MU 6.667 UK 2 .2 2 2 NL 2 .2 2 2

August 2015 ZA 78.261 US 10.870 MU 4.348 UK 2.174 NL 2.174

108

Table A, 11: Observed TTL and EEs for other .za domains

h rtlk 10Mouth T T I. , t i i i Ls TTL % of T TLs T T L % of TTLs T T L % of T TLs TTL % of TTLs TTL % of T TLs TTL % of T TLs T T L % of T TLs T T L % of TTLs TTL % of TTLs

i k Et k i J n l ' 3600 Ju 01J v luoo 23.97)8 86400 20.833 7200 10.417 600 10.417 28800 3.127) J00 2.08333 900 1.042 38400 1.042 14400 1.042V n m l m JUl ' v luoo H H1 '•U100 20.833 3600 18.07)6 7200 11.111 600 11.111 28800 6.9444 J00 2.778 900 1.389 1800 1.389 14400 1.3891 u t i m b u J U l ' v luoo H H1 7200 19.444 86400 16.667 3600 13.889 600 11.111 900 2.778 J00 2.778 28800 2.778 1800 2.778 14400 2.778

J am a ' JU ll v luoo H H1 vuloo 20.7)89 3600 17.647 600 11.767) 7200 10.294 28800 7).882 J00 2.941 900 1.471 38400 1.471 1800 1.471l i b n i a i JU ll v luoo 32.222 3600 20.000 86400 16.667 7200 12.222 600 10.000 28800 7).7)7)6 J00 2.222 900 1.111 A A

'1 a t I JU ll v luoo 26.761 3600 21.127 86400 18.310 7200 12.676 600 8.47)1 28800 7).634 J00 2.817 900 1.408 6000 1.408 14400 1.408Jinn JU ll liUU 27 U 1' v luoo 22.7)81 86400 16.129 3600 14.7)16 7200 11.290 300 6.47)2 1 J400 1.613 A AJub JU ll v luoo 'J'J.al H1 3600 22.7)00 600 18.77)0 86400 13.77)0 7200 10.000 300 7.7)00 1 J400 2.7)00 1800 1.27)0 1200 1.27)0 A A

'u n is ! JU ll v luoo Ju 3600 23.611 86400 12.7)00 600 12.7)00 300 6.944 38400 1.389 1800 1.389 14400 1.389 A AS tp l tm k i JU ll v luoo Jv .,vt, vuloo 18.841 600 18.841 3600 17).942 7200 10.147) 300 4.348 14400 2.899 A A

i k Et k i JU ll v luoo J . ‘'71 '•U100 23.377 600 18.182 7200 12.987 3600 12.987 300 7).197) 14400 1.299 A AV n m l i u JU ll v luoo J v ''17 '•UlOO 18.421 3600 18.421 600 17).789 300 9.211 7200 6.7)79 38400 1.316 14400 1.316 A A1 H tU lllnl JU ll v luoo 26.631 3600 20.408 600 18.367 86400 12.247) 7200 12.247) 300 4.082 1800 4.082 38400 2.041 A A

J am a ' JUl i v luoo J., (,vv uuu 21.877) 3600 17).627) 86400 10.938 7200 9.377) 300 7.813 14400 3.127) 38400 1.7)63 A Ai t b in a ' J u l i v luoo 21 ' ' l v 3600 21.918 86400 19.178 600 16.438 7200 6.849 300 6.849 38400 2.740 28800 1.370 1800 1.370 14400 1.370

'1 a tb J u l . v luoo Ju 3600 20.833 86400 19.444 600 16.667 7200 9.722 300 2.778 14400 2.778 38400 1.389 A A'p u l J U l i IOO '1 Jn> UUU 18.7)71 84600 17).714 3600 17).714 7200 11.429 38400 1.429 300 1.429 14400 1.429 A A'1 a JUl . VU 100 26.761 v luoo 18.310 600 16.901 3600 16.901 7200 8.47)1 38400 4.227) 300 4.227) 14400 4.227) A A

June JUla 100 21 J U 3600 22.727 84600 21.212 600 17).17)2 7200 6.061 38400 4.7)47) 300 3.031 601 1.7)17) 11100 1.7)17) A AJub J u l . 100 Ju v luoo 19.444 600 16.667 3600 16.667 7200 11.111 300 4 .167 38400 2.778 1800 1.389 11100 1.389 A A

A rm s! J u l . VU 100 27 1 1 ' uuu 20.000 84600 14.286 3600 14.286 7200 7).714 38400 7).714 300 4.286 14400 2.87)7 7260 1.429 43200 1.429

Ra nk •1 10M onth RR % o f RRs RR ol R lk RR 1; 1; It It % o f RRs RR % o f RRs RR % of RR s RR % o f RRs RR % o f RRs RR % o f RRsOc! 13 \ 79.167 MX 11,1 As CX A M L s , , , s o v 1 M 2 \ VX ov l3 \ 78.667 MX 10.667 CX A M L ......... SUV 1 . . . s o v 1.333 X /ADet-13 \ 81.081 MX 16.216 CX A M L 2 7i 1. X A

A 7 ,< J MX 15.M J CX A M L n 7U7 T X T 2 s ' l> l \ VI t h l i A s i 111 MX 7.77s CX A M L ■1,111 T X T s o v 1.111 X A: A sf .Ml MX 6 .S-I11 CX A M L •1.110 T X T 1.370 s o v 1.370 X AJUll 1 '1 A s 1 . MX 6.757 SOA 111 1 C \ V iL 2 7i 1. SUV 1.351 X A.J ill 1 1 A s j 11s MX 18.1s7 SOA 2 lu s C \ V iL 1 ...... u u 1.099 X A

A u - 1 1 A s J 7' if MX 8.602 CX A M L »7< SOV . 22< \ VSt [ i l l A s j 11 , C \ M IL 5.U52 MX 1 7< 2 SOV . 71 T X T 1.190 SRV 1.190 A A A A 1.190 X /AOc! 14 A s iS S j 1 C \ M IL 5„sH SOA MX \ VA. i l l A s i 211 MX 5.263 CX A M L 2i . SOV . s T X T 1 . 1.053 X /AD u l l A f S 7 MX l! 1,103 SOA 1 17s SUV 2 us C \ O IL 2 us U U 1,193 X /A

A Sf s MX 7.317 SOA 2 1 .u c \ V iL 2 1 >u XS 1 22i 1 \ Vl t h l A Si I s J J MX ! l,5iS! 1 SOA •1.110 C \ V iL •1.110 T X T 1 .7n \ V: A Si U ll MX iS.,333 CX A M L SOV 2-77ts T X T 1 »su \ VA pi 1 A s i U u MX iS,571 CX A M L 711 T X T 2 s 7 s o v 1 12U \ V: A 71 Is MX 12.676 CX A M L 7 M 2 T X T < .1 \ VJ III! 1 ■ > A 72 727 MX I 1S .I1S2 T X T C \ V iL 3 11311 s o v 1,515 X /A

A s i u U MX 11.111 T X T 1 1< 7 C \ V iL 2 77<s \ VA u _ l A ........... MX 11,129 C X A M L 1 2 s< T X T 2 s 7 s o v 1,129 X /A

Table A.12: Temporal relationship between attacks and scans October 2013

Dom ain R eported a tta c k date* # of scans before a tta ck F irst recorded scan # of scans a fte r a tta ck Last recorded scan

30259.info 9 O ctober 2013 0 10 O ct 13 17 22 O ct 1336088. info 11 O ctober 2013 3 11 O ct 13 1 13 O ct 1336372. info 15 O ctober 2013 8 14 O ct 13 0 14 O ct 1337349.info 15 O ctober 2013 0 16 O ct 13 44 18 O ct 13

aa. 10781. info 12 O ctober 2013 0 13 O ct 13 4 16 O ct 13babywow.co.uk 11 O ctober 2013 0 12 O ct 13 6 18 O ct 13

bitstress.com 21 Septem ber 2013 0 1 O ct 13 1 1 O ct 13fkfkfkfa.com 23 Septem ber 2013 0 1 O ct 13 5 26 O ct 13gtm i2.com 19 O ctober 2013 0 20 O ct 13 3 31 O ct 13

H izbullah.m e 28 Ju ly 2013 0 26 O ct 13 1 26 O ct 13iriw im iing.com 2 O ctober 2013 3 1 O ct 13 3 10 O ct 13

krasti.us 18 O ctober 2013 0 19 O ct 13 1 19 O ct 13pipcvsem naher. com 17 O ctober 2013 0 18 O ct 13 2 31 O ct 13

pk ts.as ia 1 O ctober 2013 1 1 O ct 13 i i 31 O ct 13Sandia.gov 28 Septem ber 2013 0 4 O ct 13 2 28 O ct 13

tx t.fw server.com .ua 18 O ctober 2013 0 23 O ct 13 4 26 O ct 13zzgst.com 9 Septem ber 2013 0 2 O ct 13 1 2 O ct 13

109

Table A ,13: Temporal relationship between attacks and scans November 2013

D om ain R ep o rte d a tta c k d a te* # o f scans before a tta c k F ir s t reco rded scan # o f scans a fte r a tta c k L as t reco rded scan

36088,info 11 O c to b e r 2013 0 17 N ov 13 i 17 O c t 13b itc h g o tra p e d . c loudns. eu 21 N ovem ber 2013 1 19 N ov 13 0 19 N ov 13

d ie a tsh a re z .c o m 11 N ovem ber 2013 0 12 N ov 13 1 16 N ov 13esd ienem nogo .com 19 N ovem ber 2013 1 19 N ov 13 1 25 N ov 13

fM M kfa.com 23 S ep te m b e r 2013 0 5 N ov 13 3 30 N ov 13hccfo rum s.n l 10 N ovem ber 2013 1 10 N ov 13 1 29 N ov 13H izbu llah .m e 28 J u ly 2013 0 1 N ov 13 1 1 N ov 13

k ra s ti.u s 18 O c to b e r 2013 0 13 N ov 13 1 21 N ov 13lrc-p ipec .com 14 N ovem ber 2013 0 16 N ov 13 1 16 N ov 13

p k ts .a s ia 1 O c to b e r 2013 0 3 N ov 13 3 7 N ov 13re a n im a to r.in 1 N ovem ber 2013 0 2 N ov 13 3 11 N ov 13

S and ia .gov 28 S ep te m b e r 2013 0 6 N ov 13 1 20 N ov 13s isk a l.co m 9 N ovem ber 2013 0 10 N ov 13 2 17 N ov 13

sto p d ru g s7 7 .co m 27 N ovem ber 2013 1 27 N ov 13 0 27 N ov 13th e h e std o m a in in th e w o rld . c loudns. eu 15 N ovem ber 2013 0 16 N ov 13 1 16 N ov 13

t.p b u b .in fo 6 N ovem ber 2013 0 7 N ov 13 3 13 N ov 13x .m p n p .in fo I t N ovem ber 2013 0 15 N ov 13 2 17 N ov 13

x .p riv e trc .co m 19 N ovem ber 2013 1 19 N ov 13 i 21 N ov 13x .sh im .in fo 17 N ovem ber 2013 0 18 N ov 13 i 18 N ov 13

Table A, 14: Temporal relationship between attacks and scans December 2013

Domain R eported a ttack date* j i of scans before a ttack F irst recorded scan j i of scans after a ttack Last recorded scanadrenaiinessss.ee 7 December 2013 0 20 Dec 13 i 20 Dec 13

amp.crack-zone.ru 22 December 2013 0 23 Dec 13 2 27 Dec 13datburger.cioudns.org 8 December 2013 0 22 Dec 13 i 22 Dec 13

dnsam piificationattacks.ee 4 December 2013 0 6 Dec 13 3 20 Dec 13fk fkfk fa .com 23 Septem ber 2013 0 5 Dec 13 5 30 Dec 13

grungyman.cioudns.org 17 December 2013 0 18 Dec 13 2 22 Dec 13iiineage2.ru 6 December 2013 0 8 Dec 13 3 21 Dec 13

krasti.us 18 October 2013 0 2 Dec 13 2 19 Dec 13

Table A, 15: Temporal relationship between attacks and scans January 2014

Domain R eported a ttack date* j i of scans before a ttack F irst recorded scan j i of scans after a ttack Last recorded scanbitcligotraped.cloudns.eu 21 November 2013 0 12 Jan 14 i 12 Jan 14

dnsam piificationattacks.ee 4 December 2013 0 19 Jan 14 i 19 Jan 14fk fkfk fa .com 23 Septem ber 2013 0 2 Jan 14 5 10 Jan 14gtmi2.com 19 October 2013 0 13 Jan 14 1 13 Jan 14krasti.us 18 October 2013 0 1 Jan 14 2 12 Jan 14

pddos.com 5 January 2014 0 7 Jan 14 3 16 Jan 14Sandia.gov 28 Septem ber 2013 0 9 Jan 14 2 12 Jan 14

saveroads.ru 2 January 2014 0 3 Jan 14 2 15 Jan 14tx t . fwser ver. com. ua 18 October 2013 0 19 Jan 14 i 19 Jan 14

x.xipzersscc.com 24 January 2014 0 25 Jan 14 i 25 Jan 14Zong.Zong.Co.ua 8 January 2014 0 10 Jan 14 i 10 Jan 14

110

Table A, 16: Temporal relationship between attacks and scans February 2014

D om ain R ep o rte d a tta e k d a te* # o f seans before a tta e k F ir s t reeo rded sean # o f seans a fte r a tta e k L as t reeo rded sean

evgeniym -iarehenko.ee 23 A u g u st 2013 0 17 Feb 14 2 18 Feb 14fkfkfkfr.eom 10 F e b ru a ry 2014 0 13 Feb 14 3 17 Feb 14g e rd a r3 .ru 10 F e b ru a ry 2011 0 11 Feb 14 4 25 Feb 14g tm l2 ,eom 19 O c to b e r 2013 0 1 F eb 14 2 15 Feb 14

H izbu llah ,m e 28 J u ly 2013 0 4 F eb 14 i 4 F eb 14k ra s ti.u s 18 O c to b e r 2013 0 9 F eb 14 2 15 Feb 14

n lh o s tin g .n l 17 O c to b e r 2013 0 8 F eb 14 i 8 F eb 14pddos.eom 5 J a n u a ry 2011 0 1 F eb 14 7 10 Feb 14S and ia .gov 28 S ep te m b e r 2013 0 15 Feb 14 i 15 Feb 14

saveroads .ru 2 J a n u a ry 2011 0 9 F eb 14 i 9 F eb 14su p e rm eg a tru e .m e d ir .ru 10 O c to b e r 2013 0 18 Feb 14 i 18 Feb 14

th eh estd o m a in in th ew o rld .e lo u d n s.eu 15 N ovem ber 2013 0 15 Feb 14 i 15 Feb 14tx t4 0 9 .te k je to n .e o m 10 O c to b e r 2013 0 18 Feb 14 i 18 Feb 14

Table A, 17: Temporal relationship between attacks and scans March 2014

D om ain R ep o rte d a tta e k d a te* # o f seans before a tta e k F ir s t reeo rded sean # o f seans a fte r a tta e k L as t reeo rded sean

ad m in .h lu eo ran g eeare .eo m 14 M arch 2014 0 22 M ar 14 2 29 M ar 14ahuvehue.in fo 8 M arch 2014 0 9 M ar 14 8 28 M ar 14

ddosfo rum s.pw 5 A pril 2014 1 29 M ar 14 0 29 M ar 14fkfkfkfr.eom 10 F e b ru a ry 2014 0 29 M ar 14 1 29 M ar 14

th eh estd o m a in in th ew o rld .e lo u d n s.eu 15 N ovem ber 2013 0 26 M ar 14 1 26 M ar 14ww w .j rd g a .info 1 M arch 2014 0 2 M ar 14 5 26 M ar 14

Table A, 18: Temporal relationship between attacks and scans June 2014

Dom ain R eported a tta c k date* A of scans before a tta ck F irst recorded scan A of scans a fte r a tta ck Last recorded scan

ahuvehue.info 8 M arch 2014 0 21 Ju n 14 1 21 Ju n 14bangtest.zong.co .ua 28 June 2014 2 7 Ju n 14 1 30 Ju n 14

ddosforum s.pw 5 A pril 2014 0 25 Ju n 14 2 30 Ju n 14doleta.gov 16 O ctober 2014 2 24 Ju n 14 0 29 Ju n 14gtm i2.com 19 O ctober 2013 0 30 Ju n 14 1 30 Ju n 14

iaika.com .ru 28 June 2014 0 29 Ju n 14 3 30 Ju n 14m agas.bsirpg.com 14 M ay 2014 0 7 Ju n 14 8 15 Ju n 14

w ebpanei.sk 23 Ju ly 2014 1 30 Ju n 14 0 30 Ju n 14w radish .com 27 A pril 2014 0 17 Ju n 14 2 21 Ju n 14

Table A, 19: Temporal relationship between attacks and scans July 2014

D om ain R e p o rte d a tta c k date* # of scans before a tta c k F irs t recorded scan # of scans a f te r a tta c k L ast recorded scan

energysta r.gov 13 O c to b e r 2014 1 4 Ju l 14 0 6 Ju l 14g tn il2 .com 19 O c to b e r 2013 0 1 Ju l 14 2 15 Ju l 14

k rasti.u s 18 O c to b e r 2013 0 2 Ju l 14 3 13 J u l 14lalka .com .ru 28 Ju n e 2014 0 6 J u l 14 25 Ju l 14

svist21 .cz 12 N ovem ber 2014 3 14 Ju l 14 0 23 Ju l 14w ebpanel.sk 23 Ju ly 2014 0 24 Ju l 14 •5 31 Ju l 14w rad ish .com 27 A pril 2014 0 1 Ju l 14 6 26 Ju l 14

w w w .jrdga.info 1 M arch 2014 0 3 Ju l 14 1 4 Ju l 14

1 1 1

http://www.j


Table A,20: Temporal relationship between attacks and seans August 2014

D om ain R ep o rte d a tta c k d a te* # o f scans before a tta c k F ir s t reco rded scan # o f scans a fte r a tta c k L as t reco rded scan

b an g te s t.zo n g .co .u a 28 J u n e 2014 0 25 A ug 14 i 25 A ug 14ddosfo rum s.pw 5 A pril 2011 0 16 A ug 14 i 16 A ug 14

do le ta .gov 16 O c to b e r 2014 2 25 A ug 14 0 25 A ug 14eiie rgystar.gov 13 O c to b e r 2014 6 20 A ug 14 0 31 A ug 14

g tm l2 .com 19 O c to b e r 2013 0 25 A ug 14 2 26 A ug 14la lka .com .ru 28 J u n e 2014 0 2 A ug 14 2 9 A ug 14

m agas.b slrpg .com 14 M ay 2014 0 31 A ug 14 i 31 A ug 14svist21.cz 12 N ovem ber 2014 2 21 A ug 14 0 25 A ug 14

tlieb estd o m ain in tliew o rld .c lo u d n s .eu 15 N ovem ber 2013 0 24 A ug 14 1 24 A ug 14w ebpane l.sk 23 J u ly 2014 0 1 A ug 14 15 31 A ug 14w rad isli.com 27 A pril 2014 0 1 A ug 14 5 31 A ug 14

Table A,21: Temporal relationship between attacks and seans September 2014

D om ain R e p o rte d a tta c k date* A of scans before a tta c k F irs t recorded scan A of scans a f te r a tta c k L ast recorded scan

do leta .gov 16 O c to b e r 2014 4 5 Sep 14 0 25 Sep 14energysta r.gov 13 O c to b e r 2014 4 1 Sep 14 0 17 Sep 14

sem a.cz 11 Ju ly 2013 0 30 Sep 14 1 30 Sep 14svist21 .cz 12 N ovem ber 2014 1 18 Sep 14 0 18 Sep 14

w ebpanel.sk 23 Ju ly 2014 0 1 Sep 14 14 30 Sep 14w rad ish .com 27 A pril 2014 0 8 Sep 14 1 8 Sep 14

w w w .jrdga.info 1 M arch 2014 0 17 Sep 14 1 17 Sep 14

Table A,22: Temporal relationship between attacks and seans October 2014

D om ain R ep o rted a tta c k date* /r o f scans before a tta c k F irs t recorded scan /r o f scans a fte r a tta ck L ast recorded scan

b itc ligo trapcd .c loudns.cu 21 N ovem ber 2013 0 7 O ct 14 1 10 O ct 14bm w .digm clil.cu.ee 16 O c to b er 2014 0 19 O ct 14 4 28 O ct 14

datbu rgcr.c loudns.o rg 8 D ecem ber 2013 0 10 O ct 14 1 10 O ct 14dnsan ip lificationattacks.ee 4 D ecem ber 2013 0 8 O ct 14 1 8 O ct 14

dolcta .gov 16 O c to b er 2014 0 31 O ct 14 1 31 O ct 14cncrgystar.gov 13 O c to b er 2014 2 5 O ct 14 3 30 O ct 14

cvgcniy-niarclicnko.ee 23 A ugust 2013 0 10 O ct 14 1 10 O ct 14grungym an, cloudns. org 17 D ecem ber 2013 0 7 O ct 14 1 8 O ct 14

gucssinfosys.com 13 O c to b er 2014 0 15 O ct 14 1 15 O ct 14n lliosting .n l 17 O c to b er 2013 0 18 O ct 14 1 19 O ct 14

no ttlicbcstdon iain in tlicw o iid .c loudns.o rg 28 N ovem ber 2013 0 7 O ct 14 1 9 O ct 14su p crm cga truc .m cd ir.ru 10 O c to b er 2013 0 8 O ct 14 1 10 O ct 14

svist21.cz 12 N ovem ber 2014 1 18 O ct 14 0 18 O ct 14tliebestdom ain in tliew orld . c loudns. cu 15 N ovem ber 2013 0 8 O ct 14 1 9 O ct 14

t x t 409. t ekj et on .com 10 O c to b er 2013 0 8 O ct 14 1 10 O ct 14w radisli.com 27 A pril 2014 0 5 O ct 14 6 31 O ct 14

Table A,23: Temporal relationship between attacks and seans November 2014

Dom ain R eported a tta c k date* A of scans before a tta c k F irst recorded scan A of scans after a tta ck L ast recorded scanb m w . cl igmeh L c n . c c 16 O ctober 2014 0 1 Nov 14 3 19 Nov 14

doleta.gov 16 O ctober 2014 0 6 Nov 14 4 25 Nov 14gransy.com 1 Jan u a ry 2015 1 27 Nov 14 0 27 Nov 14

krasti.us 18 O ctober 2013 0 27 Nov 14 1 27 Nov 14nlhosting .n l 17 O ctober 2013 0 1 Nov 14 3 24 Nov 14

non.cligmelil.cn.ee 25 Noverm ber 2014 0 26 Nov 14 1 26 Nov 14svist21.cz 12 N ovem ber 2014 0 13 Nov 14 3 20 Nov 14

wraclisli.com 27 A pril 2014 0 20 Nov 14 2 22 Nov 14

1 1 2


Table A,24: Temporal relationship between attacks and seans December 2014

D om ain R e p o rte d a tta c k d a te* # o f seans before a tta e k F irs t reeo rd ed sean # o f seans a f te r a t ta e k L ast reeo rded sean

b as ju k .co m .ru 9 D ecem ber 2014 2 8 D ec 14 0 9 D ec 14defcon.org 22 D ecem ber 2014 0 24 D ec 14 9 31 D ec 14dole ta .gov 16 O c to b er 2014 0 7 D ec 14 2 16 D ec 14

energ y sta r.g o v 13 O c to b er 2014 0 19 D ec 14 i 19 D ec 14free -google-2 .cloudns.org 8 D ecem ber 2014 0 13 D ec 14 i 13 D ec 14

globe.gov 17 D ecem ber 2014 2 15 D ec 14 6 31 D ec 14gransy .eom 1 Ja n u a ry 2015 2 2 D ec 14 0 25 D ec 14

m ax iim im stresse r.n e t 17 D ecem ber 2014 2 15 D ec 14 1 21 D ec 14p izda izd a .eo m .ru 13 D ecem ber 2014 0 15 D ec 14 1 15 D ec 14

svist21 .cz 12 N ovem ber 2014 0 21 D ec 14 3 31 D ec 14

Table A,25: Temporal relationship between attacks and seans January 2015

D om ain R e p o rte d a tta c k d a te* f t o f scans before a tta c k F irs t recorded scan f t o f scans a f te r a tta c k Last recorded scan

defcon.org 22 D ecem ber 2014 0 1 Ja n 15 3 6 J a n 15do leta .gov 16 O c to b e r 2014 0 8 Ja n 15 1 8 J a n 15

en ergysta r.gov 13 O c to b e r 2014 0 21 Ja n 15 1 21 Ja n 15globe.gov 17 D ecem ber 2014 0 7 Ja n 15 3 21 Ja n 15

gransy .eom 1 .January 2015 1 1 Ja n 15 3 5 Ja n 15n lh o stin g .n l 17 O c to b e r 2013 0 23 Ja n 15 1 23 Ja n 15

p id a ra s tik .ru 24 F e b ru a ry 2015 2 14 Ja n 15 0 23 Ja n 15uzu zu u .ru 9 F e b ru a ry 2015 2 23 Ja n 15 0 29 Ja n 15

Table A,26: Temporal relationship between attacks and seans February 2015

D om ain R e p o rte d a tta c k d a te* i t o f scans before a tta c k F irs t recorded scan i t o f scans a f te r a tta c k L ast recorded scan

cdnm yhost.com 24 F eb ru a ry 2015 2 18 Feb 15 0 20 Feb 15defcon.org 22 D ecem ber 2014 0 6 Feb 15 5 16 Feb 15globe.gov 17 D ecem ber 2014 0 15 Feb 15 i 15 Feb 15

gransy.com 1 Ja n u a ry 2015 0 1 Feb 15 3 23 Feb 15inboo t.co 17 D ecem ber 2014 0 19 Dec 15 1 20 Feb 15

p id a ra s tik .ru 24 F eb ru a ry 2015 5 11 Feb 15 0 20 Feb 15svist21 .cz 12 N ovem ber 2014 0 18 Feb 15 1 18 Feb 15iiziizim .ru 9 F eb ru a ry 2015 1 9 Feb 15 0 9 Feb 15vlch .net 17 D ecem ber 2014 0 7 Feb 15 2 18 Feb 15

Table A,27: Temporal relationship between attacks and seans March 2015

D om ain R e p o rte d a tta c k d a te* f t o f scans before a tta c k F irs t recorded scan f t o f scans a f te r a tta c k L ast recorded scancdnm yhost.com 24 F eb ru a ry 2015 0 3 M ar 15 5 30 M ar 15

defcon.org 22 D ecem ber 2014 0 7 M ar 15 3 30 M ar 15fkfkfkfa.com 23 S ep tem b er 2013 0 7 M ar 15 1 7 M ar 15gransy.com 1 Ja n u a ry 2015 0 8 M ar 15 3 18 M ar 15

hccforum s.n l 10 N ovem ber 2013 0 28 M ar 15 1 28 M ar 15v iareality .cz 24 F eb ru a ry 2015 0 9 M ar 15 2 12 M ar 15

Table A,28: Temporal relationship between attacks and seans April 2015

D om ain R e p o rte d a tta c k d a te* f t o f scans before a tta c k F irs t recorded scan f t o f scans a f te r a tta c k L ast recorded scancdnm yhost.com 24 F eb ru a ry 2015 0 4 A p r 15 2 8 A p r 15

defcon.org 22 D ecem ber 2014 0 9 A p r 15 2 29 A p r 15hccforum s.n l 10 N ovem ber 2013 0 10 A p r 15 i 10 A p r 15p id a ra s tik .ru 24 F eb ru a ry 2015 0 17 A p r 15 i 17 A p r 15

113

Table A,29: Temporal relationship between attacks and seans May 2015

D om ain R eported a tta c k date* ii of scans before a tta c k F irs t recorded scan ii of scans a fte r a tta c k L ast recorded scan

defcon.org 22 D ecem ber 2014 0 7 M ay 15 3 28 M ay 15dom enam ocy.pl 23 O ctober 2014 0 16 M ay 15 1 16 M ay 15energystar.gov 13 O ctober 2014 0 4 M ay 15 2 23 M ay 15freeinfosys.com 25 N ovem ber 2014 0 24 M ay 15 i 24 M ay 15

globe.gov 17 D ecem ber 2014 0 16 M ay 15 i 16 M ay 15gransv.com 1 Ja n u a ry 2015 0 15 M ay 15 4 25 M ay 15

m agas.bslrpg .com 14 M ay 2014 0 16 M ay 15 1 16 M ay 15svist21.cz 12 N ovem ber 2014 0 16 M ay 15 2 31 M ay 15

viareality .cz 24 F ebruary 2015 0 16 M ay 15 2 26 M ay 15

Table A,30: Temporal relationship between attacks and seans June 2015

D om ain R e p o rte d a tta c k d a te* i t o f scans before a tta c k F irs t recorded scan i t o f scans a f te r a tta c k L ast recorded scan

cdnm yhost.com 24 F eb ru a ry 2015 0 22 Ju n 15 1 22 Ju n 15defcon.org 22 D ecem ber 2014 0 11 Ju n 15 4 29 Ju n 15

energysta r.gov 13 O c to b e r 2014 0 6 Ju n 15 2 26 Ju n 15globe.gov 17 D ecem ber 2014 0 7 Ju n 15 2 23 Ju n 15svist21 .cz 12 N ovem ber 2014 0 6 Ju n 15 i 6 Ju n 15v lch .net 17 D ecem ber 2014 0 14 Ju n 15 i 14 Ju n 15

Table A,31: Temporal relationship between attacks and seans July 2015


067.cz 11 N ovem ber 2014 0 10 Ju l 15 1 10 Ju l 15defcon.org 22 D ecem ber 2014 0 3 Ju l 15 3 10 Ju l 15

en ergysta r.gov 13 O c to b e r 2014 0 8 Ju l 15 2 31 Ju l 15svist21 .cz 12 N ovem ber 2014 0 4 Ju l 15 2 8 Ju l 15

Table A,32: Temporal relationship between attacks and seans August 2015


defcon.org 22 D ecem ber 2014 0 2 A ug 15 3 29 A ug 15en ergysta r.gov 13 O c to b e r 2014 0 4 A ug 15 1 4 A ug 15

globe.gov 17 D ecem ber 2014 0 4 A ug 15 1 4 A ug 15gransy .com 1 Ja n u a ry 2015 0 2 A ug 15 2 7 A ug 15svist21 .cz 12 N ovem ber 2014 0 4 A ug 15 i 4 A ug 15

114

Documents

A longitudinal study of DNS traffic: Understanding current ... Zyl 2015 Msc.pdf · A thesis submitted in fulfilment of the requirements for the degree of MASTERS IN COMPUTER SCIENCE