Evaluation of zonemaster– a DNS verification toolUtvärdering av zonemaster– verifieringsverktyg för DNS

(1)

Evaluation of zonemaster

– a DNS verification tool

Utvärdering av zonemaster

– verifieringsverktyg för DNS

IAN MARNE

NIKLAS WENNBERG

KTH

(2)

(3)

Evaluation of zonemaster

– a DNS verification tool

Utvärdering av zonemaster

– verifieringsverktyg för DNS

Niklas Wennberg

Ian Marne

Degree Project in Computer Engineering First cycle,15 ECTS

Supervisor at KTH: Anders Lindström Examinator: Ibrahim Orhan

TRITA-CBH-GRU-2019:028 KTH

(4)

(5)

Abstract

The hierarchal distributed database, Domain Name System (DNS) provides name resolution for network applications, which is vital for the functionality of the Internet. An important part of the system design is to distribute the administration by delegation of domains. To maintain the availability of domains it is important that configuration is accurately per-formed. Zonemaster is a tool used for validating the quality of a DNS delegation by testing of misconfigurations. This thesis evaluates Zonemaster and how it relates to other DNS tools. The evaluation was conducted by identifying and designing configuration errors re-garding DNS delegation. These errors were tested by each tool. Their responses together with the extent of documentation regarding test specification was analyzed. The analyzed data was then divided into three categories: number of implemented tests, detected errors and if the test specification referred to a reliable source. The results showed that Zonemas-ter had all the tests implemented, detected and referred to 91,7% of them.

Keywords

(6)

(7)

Sammanfattning

Den hierarkiska distribuerade databasen, domännamnssystem (DNS) utför namnuppslag-ningar för nätverksapplikationer, vilket är en viktig del för Internets funktionalitet. Dess systemdesign möjliggör distribuerad administration genom delegering av domäner. För att behålla tillgängligheten av domäner är det viktigt att konfigurationen utförs korrekt. Zone-master är ett verktyg som används för att validera kvaliteten av en DNS-delegation genom att identifiera felkonfigureringar. Detta examensarbete utvärderar Zonemaster och dess re-lation till andra DNS-verktyg. Utvärderingen genomfördes genom att identifiera och ut-forma konfigurationsfel avseende DNS-delegering. Dessa fel testades av varje verktyg och deras svar, tillsammans med tillhörande testspecifikation analyserades. Analyserat data de-lades sedan in i tre kategorier: antal genomförda test, upptäckta fel och om testspecifikat-ionerna hänvisade till tillförlitliga källor. Resultaten visade att Zonemaster hade alla tester implementerade samt upptäckte och hänvisade till 91,7% av dem.

Nyckelord

DNS delegering, DNS konfigurationsfel, Auktoritär namnserver, DNS standarder, DNS verktyg

(8)

(9)

Acknowledgement

This thesis is a part of the degree project within the field of computer engineering, at the Royal Institute of Technology, that was carried out during spring 2019, at The Swedish In-ternet Foundation.

First, we want to thank our supervisors at The Swedish Internet Foundation, Mats Dufberg and Alexandra Adelöf. Secondly, our persons of reference Mattias Päivärinta and Anne-Marie Eklund-Löwinder and lastly Mats Strålberg for helping us with the zone setup. We also want to thank our supervisor at KTH, Anders Lindström, for the guidance during the project.

(10)

(11)

1 Introduction

We have become accustomed to constantly having access to information, entertainment and services of all kinds. These services are provided by the Internet. Being able to browse a website or send an email is based on an unseen infrastructure. One fundamental part of the infrastructure is the Domain Name System (DNS). Most network-based applications use DNS for name resolution. Name resolution refers to the process of mapping domain names to IP addresses and disruption of this process can effectively make these applications unus-able.

1.1 Problem statement

Administration of DNS is a challenge. Deep knowledge about how to configure DNS is vi-tal to maintain its availability. One important aspect of the design of DNS is the possibility of distributed administration through the delegation of domains. Lack of knowledge could lead to misconfigurations, which in turn could affect the availability of DNS [1]. A solution to the risk of domain name issues is usage of a DNS validation tool that runs a certain num-ber of test and matches the result with recognized recommendations.

The Swedish Internet Foundation (swe. Internetstiftelsen) is an independent organization that promotes positive development of the Internet in Sweden. The organization is responsi-ble for the administration of the top-level domain .se and .nu and technical maintenance of the domain name registry for those top-level domains. The foundation has developed a soft-ware package for health check of domains called Zonemaster together with their equivalent organization in France; AFNIC. Its purpose is to validate the quality of a DNS delegation. The vision for these two organizations is for Zonemaster to become the reference tool for tests of DNS.

At present, there is no evaluation of Zonemaster and how it relates to other DNS tools.

1.2 Aims and purposes

The purpose of this thesis is to evaluate Zonemaster based on its merits and weaknesses. Three main goals have been defined from the requirements specified by The Swedish Inter-net Foundation. To be able to reach the goals, supplementary questions were formulated for goal 1) and 2):

1) How efficiently Zonemaster validates DNS delegations compared to other similar tools (a) To what extent are the tools’ test cases referring to standard documents? (b) Does the other tools’ test something Zonemaster is not testing?

(c) How are the tools responding to errors in DNS configuration?

(16)

2 | INTRODUCTION

(a) Are configuration errors detected correctly?

(b) If errors are detected, how well are they described? 3) Further suggestions for improvements and development of Zonemaster

1.3 Delimitations

Due to the project timeframe, the authors, together with The Swedish Internet Foundation, have decided that only DNS tools that are well-documented and which perform tests on DNS delegation will be examined and compared.

Further due to the time limitation, only a collection identified test cases will be considered in this thesis. The scope of test cases will be chosen during the literary study.

(17)

2 Theory and background

This chapter presents the theoretical frame of reference that is relevant for the evaluation as well as the background to the problem

Section 2.1 gives a brief description of how the DNS works in order to understand a DNS delegation. Section 2.2 presents the concept of Internet Standards and the current standard issuers. In section 2.3 the requirements for a DNS delegation is recognized as well as a se-curity extension and common configuration errors. The tests and components of Zonemas-ter are explained in section 2.4. This is followed by a selection of identified DNS validation tools available for comparison.

2.1 Domain Name System

According to RFC 8499 “DNS Terminology” [2], there is not an agreed definition of DNS. However, the combination of four properties could be considered as a way of understanding the system as:

• a name scheme commonly used on the Internet.

• a distributed database representing information about certain objects.

• a database architecture enhancing distributed maintenance resilience and loose co-herency.

• a query-response protocol implementing the property of the database architecture. This section emanates the properties of RFC 8499 and aims to describe fundamental parts that is required to understand DNS delegation.

2.1.1 Structure

The objects mentioned in the second property which DNS provides information for are In-ternet hosts or other resources connected to the InIn-ternet or private networks. Data can be accessed due to the linking of nodes. Nodes are organized and distributed in a hierarchal in-verted tree structure, indexed by labels. The tree structure is referred to as the domain namespace and has a single node at the top called root. From one node’s point of view, a node below in the hierarchy is called a child node and a node above is called parent. Each child node could in turn have children of its own and together they form a subtree simply called a domain.

(18)

4 | THEORY AND BACKGROUND

Figure 2.1: Summary of host.example.se domain name

A label needs to be unique within its parent domain [5]. For example, two hosts both in-dexed with the label “host1.”, within “example.se” domain would not be allowed but the domain name host1.example.se and host1.exampletwo.se would work. This way of han-dling domain names provides a name scheme mechanism that is useful for being able to reach host services of the Internet and for organizations administrating parts of the DNS.

2.1.2 Zones and Datatypes

The domain space has an additional architectural feature called zones. Zones are partitioned areas of the domain space, starting at a node where an organization wants to manage a sub-tree. An organization controlling a zone has the possibility to modify data in the zone, en-large the subtree by adding new nodes or delegate new subzones to other organizations [5]. Information about zones is described in the zone datafiles. The format is specified in the DNS standards and can be interpreted by all DNS server software [6]. The zone datafiles consists of Resource Records (RRs) which contains data about domain names and specifi-cations about the tree structure [3]. The format of the zone file is made out of rows repre-sented by RR, which in turn usually contains the information prerepre-sented in the subsequent table 2.1:

Table 2.1: Explaining information in RRs [3]

Resource Records Description

owner the domain name associated to the RR.

type describe the resource type. Common types are host address (A), nameserver for the zone (NS), Start of authority (SOA), canonical name of an alias (CNAME), mail exchange (MX) and a pointer to another owner name (PTR).

class refers to the type of protocol family such as the Internet system or Chaos system.

(19)

2.1.3 Nameservers

The applications that serves as repositories of information about the domain namespace are called nameservers [3]. The information is generally about a zone and is distributed among the nameservers. A nameserver managing information about a zone is said to have authority for that zone. It is possible for a nameserver to be authoritative for several zones.

There are two main types of authoritative nameservers: primary nameserver and secondary nameserver, also known as master and slave. A valid zone file contains exactly one Start of Authority record and is loaded by slave servers through a process called zone transfer. Usu-ally a zone transfer is established from a master, but it is also possible to transfer the data from another slave, which means that a nameserver can act as both master and slave. Among several reasons, slave servers offer redundancy and geographical spread of data within a zone [4].

2.1.4 Resolvers

A resolver is a non-authoritative nameserver that resolves a domain name to an IP address for hosts on a network. Resolvers serve as local clients that access nameservers and store the results of lookups in a cache file. Their implementation is not noticeable for the user but enhances performance of retrieval of data [7].

2.1.5 Delegation

The mechanism of dividing domains into subdomains is known as delegation [4]. Delega-tion makes an organizaDelega-tion responsible for maintaining data within the appointed zone. Since the DNS is hierarchal structured, delegation becomes an important aspect when the system is scaling. Without the ability to delegate, only one source of data would exist in en-tire name space. Being able to configure your own domain space within a zone also gives the possibility to make decisions about adding extra security or adding more nameservers for load balancing.

By pointing out nameservers from the zone datafile gives an organization authority over the subdomain. Programmatically this is accomplished by adding a set of NS record for the child origin in the parent zones datafile.

2.2 Sources for DNS guidelines and recommendations

The following sections presents relevant issuers of guidelines and recommendations regard-ing DNS delegation.

2.2.1 Internet Standards

(20)

independent and interoperable implementations with considerable operational experience that are useful in some or all parts of the Internet. Before a specification becomes an Inter-net standard it evolves through a set of maturity levels. These maturity levels, “Proposed Standard”, “Draft Standard” and finally “Internet Standard”, are also known as the “stand-ard track”.

2.2.2 IETF

The Internet Engineering Task Force (IETF) is a loosely assembled organization consisting of network designers, researchers, vendors and operators. They coordinate discussions and agreements about the subject of technology, with the aim to improve and further develop the Internet [9]. IETFs mission is to improve the Internet by creating technically relevant documents with high quality that help people manage, design and use the Internet in the best possible way. These documents include best current practices, protocol standards, and sundry informational documents [10].

2.2.3 RIPE

Réseaux IP Européens (RIPE, French for “European IP Networks”) is an independent, non-profit organization that supports the technical development of the Internet in the European region. RIPE act as the Regional Internet Registry (RIR) providing Internet resources such as IP addresses and Autonomous System Numbers (ASNs) to members in their service re-gion. Any document, policy, procedure or proposal that have been suggested and accepted by the RIPE community is published online in the RIPE Document Store [11].

2.2.4 DNS-OARC

The Domain Name System Operations Analysis and Research Center [12] (DNS-OARC) is an organization that strives to improve the security, understanding and stability of the Inter-net's DNS infrastructure. DNS-OARC was conceived as a nonprofit membership organiza-tion where network researchers, software developer and DNS operators could engage in sharing data, discuss problems and solutions in a secure environment.

2.2.5 RFC

Since Steve Crocker invented Request for Comments (RFC) documents in 1969 they have become official record for Internet specifications, procedures, events and protocols. Docu-ments intended to be RFCs are usually generated by IETF working groups, although they can be submitted by anyone, and are undergoing careful proofreading by the RFC Editor together with IETF groups before publication [13].

(21)

“Informational” or “Experimental” RFCs [8]. Currently there is almost 300 RFC documents concerning DNS and approximately half of them are standards or BCP [14].

2.3 DNS configuration errors

Misconfigurations concerning delegation could negatively impact the performance and functionality of DNS.

In a study by V. Pappas et al., [15] the impact of configuration errors on DNS was evalu-ated. The study conducted large-scale measurements on how misconfiguration affect the performance of DNS robustness. The measurements were examined out of four classes of misconfigurations, namely delegation inconsistency, lame delegation, diminished server re-dundancy and cyclic zone dependency. Delegation inconsistencies and lame delegation was easily detected by periodically checking the parent and child zones NS records for incon-sistencies. Cyclic zone dependencies were detected by automatically resolving names through all authoritative servers within a zone, although detection of diminished server re-dundancy could not be performed by a single check.

The results of the measurements showed that human errors frequently occurred [15]. Dele-gation inconsistencies existed in 15% of the tested zones, lame deleDele-gation in 21% of the cases, cyclic dependencies in 2% and if guidelines regarding the placement of authoritative servers within a zone was not followed, diminished server redundancy is even more preva-lent than lame delegation.

Another published paper by van Adrichem et al. [16] points out the importance of name resolutions as vital for end users and network technologies like SIP, email and spam filter-ing. In the study, measurements were performed on the DNS security extension (DNSSEC) misconfigurations in six zones (.bg, .br, .se, .com, .nl and .co). The results showed that mis-configuration existed in a large quantity and the majority was caused by inconsistencies in DNSSEC specific RRs. In addition, when misconfigurations existed it effected the domain availability in 73.86% of the cases.

2.3.1 Delegation inconsistency

(22)

2.3.2 Lame delegation

Lame delegation is the resulting effect when a nameserver is configured to handle the name service for a zone and not doing it [1]. The cause could be if the nameserver is not config-ured to be primary nor secondary for the zone or if the host service stated is not running as a nameserver. If a lame delegation problem has arisen, nameservers within a zone can be reduced. When resolvers try to send queries to those servers, query time and DNS traffic can increase. Lame delegation in all delegated nameservers will also lead to unresolved hosts and bounced e-mail [17].

2.3.3 Diminished server redundancy

According to RFC2182 “Selection and Operation of Secondary DNS Servers” [18], DNS zones need a minimum of two authoritative nameservers placed in different Autonomous Systems (AS). RFC2182 also recommends that placement of nameservers don’t occur in the same geographical region. Zones have diminished server redundancy if these recom-mendations are disregarded. Diminished server redundancy can lead to single point of fail-ure or reduce the availability of a zone.

2.3.4 Common configuration errors

RCF1912 ”Common DNS Operational and Configuration Errors” [17] is a memo with the intent to summarize current Internet requirements and common best practices regarding the operation and configuration of DNS. The memo addresses common operational problems and misconfigurations giving the reader tips of how to avoid pitfalls when setting up name-servers. The most common parts in a zone where misconfigurations are made is among the Start of Authority (SOA) records and RR. Inconsistent RDATA between a master and a slave can lead to delegation inconsistency, together with different NS- and glue records be-tween a parent zone and a child zone. Another common DNS error is a wrongfully dele-gated zone, which can lead to a lame delegation.

The RIPE-203 document [19] lists recommended values for the TTL of “Refresh”, “Retry”, “Expire” and “Minimum” in the SOA record. The document states that making mistakes when configurating a DNS zone are common due to the many degrees of freedom it offers. The recommended TTL values in RIPE-203 are aimed at small and stable DNS zones.

2.4 Social and economic aspects of DNS configuration errors

When allowing an authoritative name server to be open recursive name service, the server risks being exploited in DDoS attacks [20].

(23)

service provider was victim of an DDoS attack, which made several big organizations serv-ers unreachable.

A report from the 2nd Annual Global Symposium on DNS Security, Stability and Resili-ency called “Measuring the Health of the Domain Name System” discusses health issues to the DNS [22]. The report mentions an event from October 2009, when an administrative er-ror when editing a zone record lead to the entire .se zone being unreachable for a time. The cause of the error was due to a simple misplaced “.”.

2.5 DNS security extension

DNSSEC is a security extension to the DNS protocol that provides data origin authentica-tion and data integrity [23]. DNSSEC offers protecauthentica-tion of RRs with digital signatures and public key cryptography. Protection of data within a zone is referred to as Zone signing. A zone is said to be signed when four types of RRs are included:

• DNS Public Key (DNSKEY): Storage for the public key originated from a

crypto-graphically generated key pair consisting of a public and private key.

• Signed RR (RRSIG): Contains a cryptographic signature.

• Delegation signer (DS): Contains the delegated signers hash digest of a DNSKEY.

• Next Secure (NSEC): A record used for validating the nonexistence of a name or

RR.

DNSKEY is used for signing zones [23]. Before digitally signing RRs within a zone, they are bundled together by type to RRsets. The RRset is then signed by the private key of the DNSKEY, and a RRSIG is created to cover that RRset. The RRSIG also contains infor-mation such as signer name, algorithm type of the digital certificate, timestamps and signa-ture, that is used to authorize the signer of RRsets. There must be at least one RRSIG per RRset encrypted with the same algorithm as the DNSKEY RRset in the top node of the zone (apex). In turn, the apex DNSKEY RRset must be signed accordingly to the DS RRset in the delegating parent, if any.

DNSSEC uses an authentication chain of trust that resolvers may use to validate RRsets and RRSIGs [23] The chain follows zones upwards in the hierarchy and is used by resolvers to compare DS records of the parent zone to the DNSKEY in the child zone. If the digests match, a delegation is said to be secure. In 2012, IANA presented standards for types of di-gest algorithms allowed by the DS RRs. Either SHA-1 or SHA-256 are mandatory and GOST R 34.11-94 and SHA-384 are optional.

2.6 Zonemaster

(24)

documentation regarding DNS protocol. These specifications control the behavior and ex-actly what should be tested, which users are able to run through a command line interface or a tailored web interface [24].

2.6.1 Test cases

The core of Zonemaster is the implemented tests, which fall into groups of high-level prop-erties:

- Basic: Tests that checks the most basic functionality of a domain. It's not possible to

perform any other tests if these fails.

- Delegation: Tests regarding the overlap between the delegating zone and the zone in

question.

- Consistency: A healthy domain needs consistency between its nameservers.

- DNSSEC: Tests for secure delegation and mandatory algorithms. Only relevant for

signed zones.

- Address: Resolved IP addresses must meet different requirements. - Name server: Tests concerning the behavior of the name server. - Connectivity: Tests for UDP and TCP connectivity

- Zone: The zone content in DNS are tested, such as SOA records. - Syntax: The format of names must meet the standards.

Depending on the choice of a user, the output from the tests are compiled by the system and reported back in form of a log file, as JSON output or directly into a database [25].

2.7 Other DNS tools

There are several DNS validation tools and services on the market. Some conduct extensive checks on DNS delegation correctness, while others focus on certain issues. At the scope of this thesis, only tools that are well-documented and similar to Zonemaster were chosen.

2.7.1 NAST

NAST (Name server tester) is an open-source software package written in Java, developed by DENIC. DENIC is a German not-for-profit cooperative which manage the country-code top-level domain .de. NAST lets the user carry out tests to avoid errors in the initial setup of a domain and to promote the delegation. NAST preforms 37 tests which DENIC specifies in the document Nameserver Predelegation Check [26].

2.7.2 MxToolbox

(25)

more information about each test. MxToolbox was founded in 2003 and acquired by J2 Global Inc. in 2016 [28].

2.7.3 DNSViz

DNSViz [29] is a is an open-source software tool for visualizing the status of a DNS zone. DNSViz was created to facilitate deployment of the DNS security extensions (DNSSEC). Analysis of a domain name resolution path in the DNS namespace is provided visually by the tool, together with the DNSSEC authentication chain. Eventual configuration errors de-tected by DNSViz is also listed. DNSViz was developed by Casey Deccio at Sandia Corpo-ration in 2012.

2.7.4 Internet.nl

This tool checks if the users Internet connection, email and website use reliable Internet standards. This tool is an initiative of the Dutch Internet Standards Platform and are main-tained by NLnet LAbs [30].

2.7.5 Knossos Check Domain

Knossos check domain intends to check the correctness of DNS delegations from a registry. Developed by Knossos Networks Limited, acquired by Liverton Technology Group Lim-ited in October 2015 [31].

2.7.6 Squish

Squish checks Internet addresses to ensure they are resolving and delegating correctly in the DNS tree. Created 2007. Maintained by Free Software Foundation [32].

2.7.7 TrustTrees

(26)

(27)

3 Methodology

Chapter 3 presents the chosen methods, tools and test environment for reaching the goals stated in Section 1.2. The choices were based on the initial literary study and pre-study. Section 3.1 describes the methods that were used to finish the literary study, pre-study as well as the identified tools. Section 3.2 describes how the test cases were identified. The chosen approaches for comparing the efficiency of validating a DNS delegation is stated in section 3.3. Section 3.4 explains how the test environment involving zones were setup and configured and Section 3.5 describes how the tools test specifications were analyzed.

3.1 Literary study and pre-study

During the first phase of the pre-study, a literary study was conducted to identify the rec-ommended requirements for DNS delegation. The study showed that the recrec-ommended re-quirements differ depending on the size and purpose of the domain. Therefore, common configuration errors concerning DNS delegation were chosen instead. This was achieved through analyzing RFC and RIPE documentation, together with previous work concerning DNS. The result of the study laid the foundation for which tests to be performed during the practical comparison of Zonemaster and the other DNS tools.

Identifying the extent of documentation regarding Zonemaster and other DNS tools was the main focus in the other phase of the pre-study. Several DNS tools were found with Google search and by email correspondence through DNS-OARC mailing lists [34]. Out of these tools, mentioned in Section 2.7, three tools were chosen for comparison with Zonemaster: DNSViz, MXToolbox and NAST. Unlike the other tools, these were either open-source or/and had documentation about their test cases. Offering documentation regarding the test cases was important for the theoretical comparison. Open source code gave a deeper under-standing of what the tests actually did.

Zonemaster, and the selected tools’ test specifications were then analyzed for a theoretically comparison and evaluation.

3.2 Choice of approach

Two approaches were identified for the evaluation of how efficiently Zonemaster is validat-ing a DNS delegation in comparison to other DNS tools:

1. The first approach was to set up two zones containing two nameservers each, configure them with errors that correspond to the identified test cases.

2. The second approach was to identify existing domains with configuration errors and test them with each tool for comparison.

(28)

14 | METHODOLOGY

and “rhybar.sz” had solely errors regarding DNSSEC and “error.com” had an inconsistency in the NS records between zones. By not covering all identified test cases, the second ap-proach was insufficient for this project. Setting up zones could give more control over the tests, by being able to manually configure errors one by one. Therefore, the first approach was chosen for the comparison of Zonemaster and other DNS tools’ test cases.

3.3 Zone setup

In order to create two zones, four nameservers were provided by The Swedish Internet Foundation as seen in table 3.1.

Table 3.1: Nameserver setup

Nameserver Type IP-address

ns1 A 13.53.139.36

ns2 A 13.53.199.244

ns11 A 13.53.188.169

ns12 A 13.53.136.214

The nameservers were delegated by Mats Strålberg (The Swedish Internet Foundation) from dnskurs.se, a subdomain to the TLD .se. The chosen domain name was exjobb, which lead to a new zone called exjobb.dnskurs.se. as presented in figure 3.1.

(29)

The setup of the two zones presented in this chapter was performed according to the recom-mended requirements described in Section 2.3 and passed all the tests presented in Section 3.4 when checked against each of the identified DNS tools.

3.3.1 Tooling

The chosen tools used for setting up the zones were Oracle VirtualBox for virtualization, Ubuntu 18.10 as operative system and Berkeley Internet Name Domain (BIND 9) software. BIND 9 [35] is a system that performs both recursive and authoritative DNS functions and is the most used DNS software on the Internet [36].

3.3.2 Configuration of the zone datafile

The first step in setting up the nameservers in exjobb.dnskurs.se was to create a file called

db.exjobb.dnskurs.se that maps hostnames to addresses, also known as a zone datafile. In

BIND 9 there is a configuration file that tie all zone datafile in a nameserver together, usu-ally called named.conf [4].

The zonefile db.exjobb.dnskurs.se (see listing 3.1) was written according to the format ex-plained in Section 2.1.2 and the SOA records followed the recommended values from RFC 1912 [17].

Listing 3.1: The complete zonefile of exjobb.dnskurs.se

Below the SOA records, one NS record for each authoritative nameserver in the zone was added. Next, the name-to-address mappings was created. The RR was added to

db.exjobb.dnskurs.se, after the NS record. The A stands for IPv4 address, and AAAA for IPv6 address.

3.3.3 Bind configuration file

(30)

The nameserver ns1 was the primary nameserver for the zone exjobb.dnskurs.se. and its configuration file therefore contained one zone statement for each zone datafile to be read. The completed configuration file is presented in appendix A.

3.3.4 Slave name server

Ns2 was set up as slave nameserver in the zone exjobb.dnskurs.se. and the configuration file named.conf was similar written as its counterpart in ns1. Listing 3.2 presents the zone

state-ment, it states that the nameserver is a slave for the zone exjobb.dnskurs.se. and keeps a backup copy of the zone in the local file bak.exjobb.dnskurs.se. The IP addresses in the master’s line is to the primary nameserver, which the slave uses for zone transfer.

Listing 3.2: Part of the configuration file for the nameserver ns2

3.3.5 Signing the zone

To implement DNSSEC in the zone exjobb.dnskurs.se. it had to be signed with two differ-ent keys called a zone-signing key (ZSK) and a key-signing key (KSK). To get NSEC3-ca-pable keys, as described in Section 2.5 the algorithm RSASHA256 was chosen with a 2048-bit key length. The keys were generated with the commands:

dnssec-keygen -a RSASHA256 -b 2048 -3 exjobb.dnskurs.se dnssec-keygen -a RSASHA256 -b 2048 -3 -fk exjobb.dnskurs.se

After the keys were created, modification was required in the configuration files options and zone statement. The server was configured in the options statement, as presented in ap-pendix A, to permit DNSSEC-validation by adding two settings and a key-directory. Listing 3.3 present the modification to the zone statement, which made the zone auto main-tained.

Listing 3.3: Modified zone statement in the configuration file

(31)

NSEC3. The keys were loaded with the rndc loadkeys command and signed with the rndc

signing -nsec3param command.

3.3.6 Delegation of a subdomain

The name luke.exjobb.dnskurs.se was chosen for the new subdomain of exjobb.dnskurs.se. The nameservers ns11 and ns12 was delegated to act as master and slave in the new zone. The configuration of the nameservers ns11 and ns12 was performed in the same way as the nameservers ns1 and ns2.

Appropriate NS records and glue records was added in the zone datafile

db.exjobb.dnskurs.se as presented in appendix A.

Complete zone datafile and configuration file of the subdomain luke.exjobb.dnskurs.se. is presented in appendix A.

3.4 Test cases

A total of 13 test cases, based on common configurations errors, were identified by analyz-ing RFC and RIPE documents together with previous related work mentioned in Section 2.3. The paper by V. Pappas et.al showed that delegation inconstancy, lame delegation and diminished server redundancy frequently occurred by human errors, however cyclic zone dependency only occurred in 2% in the tested domains. Therefore, cyclic zone dependency was excluded in this study. The tests are explained and categorized after where the miscon-figurations can occur.

3.4.1 Configuration concerning the SOA records

• Serial number consistency in SOA - If the serial number is not consistent between authoritative nameservers, the data served may be inconsistent. This was tested by configuring two nameservers with different serial numbers, in the same zone.

• RNAME consistency in SOA - The SOA RDATA has a field which refers to the administrative contact for the domain. The field called RNAME needs to be consistent between authoritative nameservers or eventual failures might be reported to different persons. This was tested by configuring two nameservers with different RNAME, in the same zone.

• Timers consistency in SOA - Operational inconsistency can occur if not all timer fields are consistent between authoritative nameservers. This was tested by configuring two nameservers with different TTL values, in the same zone.

• Refresh value - Low refresh value increases the traffic between DNS serv-ers. RIPE-203 recommends a minimum value of 24 hours. This was tested by setting the refresh value to 1 second.

• Retry value - Low retry value increases the bandwidth usage and the load on DNS servers. RIPE-203 recommends a minimum value of 2 hours. This was tested by setting the retry value to 1 second.

(32)

RIPE-203 recommends a minimum value of 1000 hours. This was tested by setting the expire value to 1 second.

• Minimum value – The minimum value serves as a default value for the TTL of all RRs without an obtained value. RIPE-203 recommends a

cache-friendly value of minimum 48 hours. This was tested by setting the mini-mum value to 1 second.

3.4.2 Configuration concerning the NS records

• Consistency between delegation and zone - Inconsistent NS records between the parent zone and child zone leads to delegation inconsistency. This was tested by re-moving a NS record in the child zone.

• Combination of CNAME record and NS record - NS records pointing to

CNAME results in unnecessary indirection in accessing the data. This common con-figuration error could not be tested due to an automatic error check performed by BIND. NS entries that coexist with a CNAME are ignored.

• Minimum number of nameservers – A zone needs at least two nameservers if one of them becomes unavailable. A zone with only one nameserver has diminished server redundancy. This was tested by removing a NS record in the selected zone.

3.4.3 Configuration concerning the parent server

• Consistency between glue and authoritative data - Inconsistent glue records be-tween the parent zone and child zone leads to delegation inconsistency. This was tested by removing an authoritative A record in the child zone.

3.4.4 Configuration concerning authoritative nameservers

• No open recursive name service – Open recursive nameservers are often a default configuration in DNS. If this service is not restricted or turned off the nameservers can be used in Denial of Service (DoS) attacks [37]. This was tested by configuring a authoritative nameserver to provide recursive name service.

• AS Diversity – A zone have diminished server redundancy if all the authoritative nameservers are placed in the same AS. This was tested by placing two nameservers in the same AS.

3.5 Analysis of test specification

To answer the supplementary questions a) and b), found in Section 1.2, of how efficiently Zonemaster tests common configuration errors regarding DNS delegations compared to other similar tools, an analysis of two stages were executed. Firstly, by assembling the cov-erage of each tools test cases that referred to any standard document, and secondly by iden-tifying if there existed any other test cases regarding DNS delegation in the other tools compared to Zonemaster.

(33)

4 Results

The following chapter presents the results of the thesis. The tools test results are presented in Section 4.1 and Section 4.2 assembles the results from the comparative analysis of the tools. The results are based on the chosen approach in Section 3.3 and the method of analy-sis of test specifications in 3.5.

4.1 Test results of Zonemaster

Table 4.1 – 4.4 presents results from the testing of the tools.

Each row represents the result of one of the twelve test cases from Section 3.4. The col-umns are interpreted as:

• Test – the test case performed.

• Test implemented – answers if the test is implemented by the tool, according to the test specification. The column is answered with “yes” or “no” and has dependencies with all other categories. A “no”-answer automatically infer that the other columns cannot occur and is represented by “ – “.

• Detected error – answers if the implemented test is detected by the tool.

• Message – presents the error message generated by the tool. No message is repre-sented by “ – “.

(34)

20 | RESULTS

4.1.1 Zonemaster

Table 4.1: Test result of Zonemaster

Test Test im- ple-mented

De-tected error

Message Ref. Class

Configuration concerning the SOA Records

Serial number consistency in SOA

Yes Yes (1) Saw 2 SOA serial numbers.

(2) Difference between the smaller serial (x) and the bigger one (y) is greater than the maximum allowed (0).

Yes Warn-ing Notice RNAME con-sistency in SOA

Yes Yes Saw 2 SOA rname. Yes Notice

Timers con-sistency in SOA

Yes Yes Saw 2 SOA time parameter set. No Notice

Refresh value Yes Yes SOA ‘refresh’ value (1s) is less than the recommended one (14400s).

Yes Notice Retry value Yes Yes SOA ‘retry’ value (1s) is less than the

rec-ommended one (3600s).

Yes Notice Expire value Yes Yes SOA ‘expire’ value (1s) is less than the

recommended one (604800s).

Yes Warn-ing Minimum

value

Yes Yes SOA ‘minimum’ value (1s) is less than the recommended one (300s).

Yes Notice

Configuration concerning the NS records

Consistency between dele-gation and zone

Yes Yes Delegation: Extra_name_parent ex-tra=ns12.luke.exjobb.dnskurs.se

Yes Error

Minimum numbers of nameservers

Yes Yes Child does not list enough (1) nameservers (ns1.exjobb.dnskurs.se). Lower limit set to 2.

Yes Error

Configuration concerning the parent server

Consistency between glue and authorita-tive data

Yes No - Yes -

Configuration concerning authoritative nameservers

No open re-cursive name service

Yes Yes Nameserver ns1.exjobb.dnskurs.se/<IP-address> is a recursor

Yes Error

AS Diversity Yes Yes All nameservers are in the same AS (AS-number)

(35)

4.1.2 DNSViz

Table 4.2: Test result of DNSViz

Serial num-ber con-sistency in SOA No - - - - RNAME consistency in SOA No - - - - Timers con-sistency in SOA No - - - - Refresh value No - - - - Retry value No - - - - Expire value No - - - - Minimum value No - - - -

Consistency between delegation and zone

Yes Yes exjobb.dnskurs.se to luke.exjobb.dnskurs.se: The following NS name(s) were found in the delegation NS RRset (i.e., in the

exjobb.dnskurs.se zone), but not in the au-thoritative NS RRset: ns12.luke.exjobb.dnskurs.se No Warn-ing Minimum numbers of nameservers No - - - -

Consistency between glue and au-thoritative data

Yes Yes Exjobb.dnskurs.se to luke.exjobb.dnskurs.se: A glue records exist for

ns12.luke.exjobb.dnskurs.se, but there are no corresponding authoritative A records.

No Warn-ing

(36)

22 | RESULTS

4.1.3 MXToolbox

Table 4.3: Test result of MXToolbox

Serial number consistency in SOA

Yes Yes Serial numbers do not match <serial nr><br/><serial nr> Yes Warn-ing RNAME con-sistency in SOA No - - - - Timers con-sistency in SOA No - - - -

Refresh value Yes Yes SOA Refresh Value is outside of the recommended range

ns1.exjobb.dnskurs.se reported Re-fresh 1 : ReRe-fresh is recommended to be between 1200 and 43200.

Yes Warn-ing

Retry value Yes Yes SOA Retry Value is outside of the rec-ommended range

ns1.exjobb.dnskurs.se reported Retry 1 : Retry is recommended to be be-tween 120 and 7200.

Yes Warn-ing

Expire value Yes Yes SOA Expire Value out of recom-mended range

ns1.exjobb.dnskurs.se reported Expire 1 : Expire is recommended to be be-tween 1209600 and 2419200.

Yes Warn-ing

Minimum value No - - - -

Consistency be-tween delegation and zone

Yes Yes Local NS list does not match Parent NS list <IP-address> was reported by the parent, but not locally

No Warn-ing Minimum num-bers of name-servers No - - - -

Consistency be-tween glue and authoritative data

No - - - -

No open recur-sive name ser-vice

Yes No - No -

(37)

4.1.4 NAST

Table 4.4: Test result of NAST

Test Test imple-mented De-tected error

Serial num-ber con-sistency in SOA

Yes Yes Primary Master (MNAME) inconsistent across SOA records (master)

[ns11.luke.exjobb.dnskurs.se., ns12.luke.exjobb.dnskurs.se.] No Warn-ing RNAME consistency in SOA

[ns11.luke.exjobb.dnskurs.se., ns12.luke.exjobb.dnskurs.se.] No Warn-ing Timers consistency in SOA

[ns11.luke.exjobb.dnskurs.se., ns12.luke.exjobb.dnskurs.se.] No Warn-ing Refresh value

Yes Yes Refresh value out of range, expected [3600..86400], found 1

No Warn-ing Retry value Yes Yes Retry value out of range, expected

[900..28800], found 1

No Warn-ing Expire

value

Yes Yes Expire value out of range, expected [604800..3600000], found 1

No Warn-ing Minimum

value

Yes Yes Minimum value out of range, expected [180..86400], found 1

Yes Warn-ing

Con-sistency be-tween dele-gation and zone

Yes Yes Two nameservers are required to perform test Yes Error

Minimum numbers of nameserv-ers

Yes Yes Two nameservers are required to perform test Yes Error

Con-sistency be-tween glue and author-itative data Yes No - No -

No open re-cursive name ser-vice

(38)

24 | RESULTS

4.2 Comparative results

The comparative analysis was conducted by extracting values from the categories “test im-plemented”, “detected errors” and “referral” from all tools test results in Section 4.1. Figure 4.1 shows a comparison of the number of executed tests and if the tests were mented in respective tool. Out of the twelve test cases, Zonemaster had all of them imple-mented, DNSViz 16,6%, MXToolbox 50% and NAST 91,7%.

Figure 4.1: Diagram of implemented tests by each tool

The correlation between the number of implemented tests and how many of those are de-tecting a preconfigured error are shown in figure 4.2. For contrast, undetected errors are visible in red and detected errors in blue. The results showed that Zonemaster detected 91,7% of its implemented tests, DNSViz detected 100%, MXToolbox 83,4% and NAST 90%.

Figure 4.2: Diagram showing the correlation between implemented tests and detected errors by each tool

12 2 6 11 0 2 4 6 8 10 12

Zonemaster CLI DNSViz MXToolbox NAST Number of tests implemented by the tools

Number of tests available in the tools

0 2 4 6 8 10 12

Zonemaster DNSViz MXToolbox NAST Correlation between implemented tests and detected

errors

(39)

Figure 4.3 shows the correlation between implemented tests and how many of those are re-ferring to a reliable source. The results showed that DNSViz did not refer no any if its im-plemented tests, Zonemaster referred to 91,7%, MXToolbox 66,7% and NAST only re-ferred to 30%.

Figure 4.3: Diagram visualizing the correlation between implemented tests and referral by each tool

0 2 4 6 8 10 12

Zonemaster DNSViz MXToolbox NAST Correlation between implemented tests and referral

(40)

(41)

5 Analysis and discussion

The following chapter interprets and analyzes the results and chosen methods from chapter three and four in relation to the aims and purpose of the thesis in chapter one.

5.1 Interpreting test results

This section presents the interpretation of the test results conducted in chapter four.

5.1.1 Zonemaster

Table 4.1 shows the results from the test executed on Zonemaster. A noticeable result when testing for “Consistency between glue and authoritative data” is that the test is implemented but could not find the error, which is discussed in Section 5.2. Another interesting point could be made when comparing how many of the tests regarding common configuration er-rors that are referring to a reliable source with the total test base in appendix B.1. Out of the total of 84 tests, 10 was missing a reference which is similar to the results presented in fig-ure 4.3.

Otherwise, all tests were implemented together with visible messages and classifications for the detected errors.

5.1.2 DNSViz

The tests executed on DNViz, visible in figure 4.1, show the lack of implemented tests con-cerning common configuration errors regarding DNS delegation. Only 2/12 test cases proved to be available. However, as explained in Section 2.7.2, the tools main focus lies on troubleshooting deployment of DNSSEC. Taking that in consideration it is uncertain if the tools intention really is to cover common configuration errors concerning DNS delegation. It is worth noticing, that the two implemented tests did not refer to reliable sources even though the full test suite in appendix B.2 showed a 77/118 coverage. Further results showed that warnings and error messages existed on all tests.

5.1.3 MXToolbox

(42)

28 | ANALYSIS AND DISCUSSION

When identifying an error, messages are visible and clear. However, there is only one class of errors available, namely a warning. By not classifying errors, a user might not under-stand the level of severity of an error compared to another.

Noticeable is that when testing for “No open recursive name service”, the tool states that it is executing the test, but they could not identify the preconfigured error.

5.1.4 NAST

As seen in figure 4.1, NAST implemented 11/12 tests. Of the 11 implemented tests, the tool referred to three reliable sources. Comparing with the full test suite in appendix B.4, the re-sult does not reflect the selection regarding common configuration errors, where 17 out of 37 tests referred to a reliable source. When analyzing tests regarding consistency, the test between delegation and zone detects an error and responds with the message “Two name-servers are required to perform test”. The same message is received when running the test “Minimum numbers of nameservers”. The reason for the same response, is because the tests were misconfigured in the same manner as presented in Section 3.4 and NAST demands the presence of two nameservers to be able to perform a test. A different method when design-ing the test “Consistency between delegation and zone” could have been to manipulate the IPv4 address in the child zones NS record instead of removing it, which could have led to another answer.

Further analyzing the test results, shows that the test “Consistency between glue and au-thoritative data” is implemented but not detected.

5.2 Discussion

One thing all tools have in common is the sources to which their test specifications refer. The majority of the sources consist of RFC documents, indicating that the test specifica-tions are reliable and that the same test performed by different tools is likely to be imple-mented in a similar manner. It also shows that RFC documents are dominant as instructions for how a DNS delegation should be performed.

Zonemaster implemented all of the selected tests in this work. However, looking into the full test suites in appendix C, the other DNS tools have implemented tests which Zonemas-ter is lacking. For example, if this thesis focused more on DNSSEC, DNSViz would proba-bly get a better result as they perform, according to its test specifications, more tests than Zonemaster in that area. MXToolbox performs a test where a recommended format on the SOA serial number is checked, though we do not consider it to be a configuration error by ignoring the format since it has no influence on DNS functionality, but only facilitates its maintenance.

(43)

The descriptions on the configuration errors in Zonemaster can be considered somewhat thin, especially for a less experienced user. The descriptions that present the user with guidelines on how to correct an error, are the configuration errors that affect SOA's TTL value. Though, these tests are some of the less critical ones performed, when it comes to what effect an error is causing. More detailed descriptions or references to e.g. RFC docu-ments where the user can get a better understanding of their situation, would have been preferable.

When configuring the domain with errors based on the identified test cases, a challenge oc-curred which prevented the test from Section 3.4.2 “Combination of CNAME record and NS record” to be performed. As stated in the same section, this was due to automatic checks by the software BIND. If the approach of preconfiguring errors would be chosen for a larger scope of tests, it is possible that the approach would not work.

5.3 Social and economic aspects

(44)

(45)

6 Conclusions

This thesis indicates that Zonemaster is efficient in validating common configuration errors regarding DNS delegation, compared to the other tools. Due to the delimitation of tests, there still an uncertainty if all of Zonemaster’s test cases reflects the result.

When it comes to common configuration errors, the tool distinguished itself from the other DNS tools by performing better on all aspects examined in this report. Results shows that all the tests were implemented and out of these, 91.7% were discovered with associated ref-erence in the test specification, which indicates that Zonemaster is a reliable DNS tool that effectively validates the quality of a DNS delegation concerning common configuration er-rors.

A recommended next step for The Swedish Internet Foundation and AFNIC to fulfilling their vision of Zonemaster becoming the reference tool for tests of DNS, is to perfect the current test specifications before adding new ones. By perfecting we mean ensuring that the implementation complies with the specification and that all contains updated references. Section 2.4 describes the event where the .se zone became unreachable as a result of a mis-configuration. Therefore, an interesting topic to research would be the extent of misconfig-urations in the .se domain and the way it affects organizations revenues.

(46)

(47)

References

[1] K. Lu, K. Dong. C. Wang. H. Xu. DNS Configuration Detection Model. The 2014 2nd International Conference on Systems and Informatics (ICSAI 2014). Shanghai, 2014. p. 613-618. [Cited 2019 Feb 26]. Available from:

https://ieeexplore-ieee-org.fo-cus.lib.kth.se/stamp/stamp.jsp?tp=&arnumber=7009359&isnumber=7009247

[2] P. Hoffman, A. Sullivan, K. Fujiwara. RFC 8499: DNS Terminology, January 2019. In-ternet Engineering Task Force (IETF). p. 3.

[3] P. Mockapetris. RFC 1034: Domain names - Concepts and facilities, November 1987. Internet Engineering Task Force (IETF). p. 7.

[4] C. Liu, P. Albitz. DNS and BIND. 5 ed. Gravenstein Highway North, Sebastopol: O’Reilly Media, inc; 2006. ISBN: 987-0-596-10057-5. p.11-40.

[5] P. Mockapetris. RFC 1035: Domain names – implementation and specification. Novem-ber 1987. Internet Engineering Task Force (IETF). p. 3-10, 35.

[6] C. Liu, M. Larson, R. Allen. DNS on Windows Server 2003. Gravenstein Highway North, Sebastopol: O’Reilly Media, inc; 2003. ISBN: 9780596523367. p. 72.

[7] Internet Systems Consortium, Inc. ("ISC"): BIND 9 Administrator Reference Manual, Chapter 1. Introduction. [Cited 2019 Mars 28] Available from:

https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch01.html

[8] S. Bradner. RFC 2026: The Internet Standards Process. October 1996. Internet Engi-neering Task Force (IETF).

[9] Internet Engineering Task Force (IETF). [Internet]. [Cited 2019 Mars 28] Available from: https://www.ietf.org/about/who/

[10] H. Alvestrand. RFC 3935: A Mission Statement for the IETF. October 2004. Internet Engineering Task Force (IETF). p. 1.

[11] RIPE Network Coordination Centre. [Internet]. [Cited 2019 Mars 29] Available from: https://www.ripe.net/

[12] The Domain Name System Operations Analysis and Research Center. [Internet] [Cited 2019 May 18] Available from: https://www.dnsoarc.net/

[13] Living Internet. Internet Request for Comments (RFC's) [Internet] Jan 7, 2000. [Cited 2019 Mars 29] Available from: https://www.livinginternet.com/i/ia_rfc.htm

(48)

34 | REFERENCES

[15] V. Pappas et. al. Impact of Configuration Errors on DNS Robustness. IEEE journal on selected areas in communications, Vol. 27, no. 3 April 2009. [Cited 2019 May 10] Availa-ble from: https://ieeexplore-ieee-org.focus.lib.kth.se/document/4808472

[16] Niels L. M. van Adrichem et al. A measurement study of DNSSEC misconfigurations, 2015. [Cited 2019 May 10] Available from:

https://security-informat-ics.springeropen.com/track/pdf/10.1186/s13388-015-0023-y

[17] D. Barr. RFC 1912: Common DNS Operational and Configuration Errors

. February 1996. The Pennsylvania State University. [Cited 2019 May 2] Available from: https://tools.ietf.org/html/rfc1912

[18] R. Elz et al. RFC 2182: Selection and Operation of Secondary DNS Servers. July 1997. [Cited 2019 May 2] Available from: https://tools.ietf.org/html/rfc2182

[19] P. Koch. Recommendations for DNS SOA Values. RIPE. June 1999. [Cited 2019 May 10] Available from: https://www.ripe.net/publications/docs/ripe-203

[20] M Santcroos, Olaf M. Kolkman. NLNet Labs. May 2007. [Cited 2019 May 10] Avail-able from: https://www.dns-school.org/Documentation/se-consult.pdf

[21] J. Loveless. DDoS attacks are costing business victims hard cash. Neustar, Inc. June 2017. [Cited 2019 May 10] Available from: https://www.home.neustar/blog/ddos-attacks-are-costing-business-victims-hard-cash

[22] A report from the 2nd Annual Global Symposium on DNS Security, Stability and Re-siliency called “Measuring the Health of the Domain Name System”. Available from: https://www.icann.org/en/topics/ssr/dns-ssr-symposium-report-1-3feb10-en.pdf

[23] R. Arends, R. Austein, M. Larson, D. Massey, S. Rose. RFC 4035: Protocol Modifica-tions for the DNS Security Extensions. March 2005. Telematica Instituut, ISV, VeriSign, Colorado State University, NIST.

[24] GitHub, Inc. [Internet]. [Cited 2019 Mars 29] Available from: https://github.com/zone-master/zonemaster

[25] GitHub, Inc. [Internet]. [Cited 2019 Mars 29] Available from: https://github.com/zone-master/zonemaster/blob/master/docs/specifications/tests/MasterTestPlan.md

[26] DENIC. Nameserver Predelegation Check Web Interface. [Internet]. [Cited 2019 Mars 29] Available from: https://www.denic.de/en/service/tools/na

[27] MxToolbox. DNS check. [Internet]. [Cited 2019 Mars 29] Available from: https://mxtoolbox.com/DNSCheck.aspx

(49)

[29] DNSViz. [Internet]. [Cited 2019 Mars 29] Available from: http://dnsviz.net/ [30] Internet.nl [Internet]. [Cited 2019 Mars 29] Available from: https://internet.nl/ [31] Knossos Domain Check [Internet]. [Cited 2019 Mars 29] Available from: http://www.knossos.net.nz/checkdomain.cgi

[32] Squish [Internet]. [Cited 2019 Mars 29] Available from: http://dns.squish.net/

[33] TrustTrees [Internet]. [Cited 2019 Mars 29] Available from: https://github.com/manda-toryprogrammer/TrustTrees

[34] Oxford action resource center (OARC) mailing lists [Internet]. [Cited 2019 Mars 21] Available from: https://www.dns-oarc.net/

[35] Internet Systems Consortium (ISC). BIND 9 Features. [Internet] [Cited 2019 April 17] Available from: https://www.isc.org/downloads/bind/bind-features/

[36] Don Moore. DNS server survey. May 23, 2004. [Internet] [Cited 2019 April 17] Avail-able from: http://mydns.bboy.net/survey

[37] J. Damas, F. Neves. RFC 5358: Preventing Use of Recursive Nameservers in Reflector Attacks. October 2008. [Cited 2019 May 17] Available from:

https://tools.ietf.org/html/rfc5358

[38] GitHub, Inc. DNSViz [Internet]. [Cited 2019 Mars 29] Available from: https://github.com/dnsviz/dnsviz/blob/master/dnsviz/analysis/errors.py

(50)

(51)

Appendix A

Appendix A lists the configuration and zone files from the created zones: exjobb.dnskurs.se and luke.exjobb.dnskurs.se.

Listing A.1: Complete configuration file of exjobb.dnskurs.se

Listing A.2: Complete zone file of exjobb.dnskurs.se

(52)

38 | APPENDIX A

Listing A.4: Complete configuration file of luke.exjobb.dnskurs.se

(53)

Appendix B

Appendix B shows all the tools test cases with descriptions together with referral status. These lists are cutouts from the tests specifications and does only show the parts of interest to this report, namely test description and if they refer or not.

B.1 Zonemaster tests

The table shows parts of the full test suite of Zonemaster [24]. Adress

Name server address must be globally routable - IANA Reverse DNS entry exists for name server IP address – No ref Reverse DNS entry matches name server name – RFC 1912 IPv6 address not part of bogon prefix - IANA

Basic

Perform input validation on the domain name – RFC 5890,1123,2782 The domain must have a parent domain – No ref

The child domain must have at least one working nameserver – No ref The child domain must have at least one working nameserver – No ref The child domain must have at least one working nameserver – No ref The Broken but functional test – No ref

Connectivity

UDP connectivity – RFC 1035 TCP connectivity – RFC 1035

Nameserver addresses on the same subnet – RFC 2182

Nameserver addresses are all on the same subnet – RFC 2182 Nameservers belong all to the same AS – RFC 2182

Consistency

(54)

40 | APPENDIX B

RNAME consistency – RFC 1034, 1035

Coherence of SOA with primary nameserver (SOA timers) – No ref Coherence of all other SOA-fields where SOA Serial is the same – No ref All authoritative nameservers reply with same set – RFC 1034, 1035 Consistency between glue and authoritative data - IANA

Coherence of SOA with primary nameserver (SOA MNAME) – RFC 1034, 1035

DNSSEC

Legal values for the DS hash digest algorithm – RFC 4035, 3658 and IANA DS must match a DNSKEY in the designated zone – RFC 4034, 4035, 4509 and IANA

Check for too many NSEC3 iterations – RFC 5155

Check for too short or too long RRSIG lifetimes – RFC 6781 Check for invalid DNSKEY algorithms – RFC 4034 and IANA Verify DNSSEC additional processing – RFC 4035

If there exists DNSKEY at child, the parent should have a DS – RFC 4034, 4035 RRSIG(DNSKEY) must be valid and created by a valid DNSKEY – RFC 4035 RRSIG(SOA) must be valid and created by a valid DNSKEY – RFC 4035 Zone contains NSEC or NSEC3 records – RFC 4034, 4035, 5155

If DS at parent, child zone must be signed – RFC 4035

Test for DNSSEC Algorithm Completeness (DS->DNSKEY->RRSIG) – No ref

Delegation

Minimum number of name servers – RFC 1034

Name servers must have distinct IP addresses – RFC 1034 No truncation of referrals – RFC 1035 and IANA

(55)

NS RR does not point to CNAME alias – RFC 1912 Existence of SOA – RFC 2181

Test whether the ANSWER for SOA is authoritative – RFC 2181 Parent glue name records present in child – RIPE 114

Nameserver

A name server should not be a recursor – RFC 2870, 5358 nameserver doesn't allow recursion – RFC 2870, 5358 test if server is recursive – RFC 2870, 5358

Test of EDNS0 support – RFC 6891

Test availability of zone transfer (AXFR) – RFC 5936 Same source address – RFC 2181

behaviour against AAAA query – RFC 4074 NS can be resolved – RFC 1035

Test upward referral – DNS-OARC Test QNAME case insensitivity - IETF Test QNAME case sensitivity – No ref

Syntax

There must be no illegal symbols in the domain name – RFC 1035, 1123, 2182, 3696

There must be no dash ('-') at the start or befinning of the domain name – RFC 1035, 1123, 2182, 3696

There must be no double dash ('--') in position 3 and 4 of the domain name – RFC 3696

The NS name must have a valid domain/hostname – RFC 952, 1123, 2182, 3696

(56)

42 | APPENDIX B

There must be no illegal characters in the SOA RNAME field – RFC 1035, 1912, 5322

There must be no illegal characters in the SOA MNAME field – RFC 952, 1123, 2182, 3696

The MX name must have a valid domain/hostname – RFC 952, 1123, 2182, 3696, 5321

Zone

Fully qualified master nameserver in SOA – RFC 952, 1035, 2181, 1996 SOA 'refresh' at least 6 hours – RFC 1035, 1912, 1996 and RIPE -203 SOA 'retry' lower than 'refresh' – RFC 1035, 1912

SOA 'retry' at least 1 hour – RFC 1035, 1912 and RIPE-203 SOA 'expire' at least 7 days – RFC 1035, 1912 and RIPE-203

SOA 'minimum' less than 1 day – RFC 1035, 1912, 2308 and RIPE-203 SOA master is not an alias – RFC 1035, 1912 and RIPE-203

MX is not an alias – RFC 2181, 5321 MX record present – RFC 2142, 5321 MX can be resolved – RFC 2142, 5321

(57)

B.2 DNSViz tests

The list was based on the open source project DNSViz and the file error.py [38]. The file has classes with attributes called description and reference, which in turn were extracted to conform the list. There were classes which had no descriptions and those were left out due to the complexity of analyzing class names.

1. The Signers Name field of the RRSIG RR (bar.) does not match the name of the zone containing the RRset (foo.). - RFC 4035, Sec. 5.3.1

2. The TTL of the RRSIG RR (10) does not match the TTL of the RRset it covers (50). - RFC 4035, Sec. 2.2

3. The TTL of the RRset (50) exceeds the value of the Original TTL field of the RRSIG RR covering it (10). - RFC 4035, Sec. 2.2

4. With a TTL of 86401 the RRSIG RR can be in the cache of a non-validating re-solver until 1 second after it expires at 2015-01-10 00:00:00. - RFC 4035, Sec. 5.3.3 5. The DNSKEY RR corresponding to the RRSIG RR has the REVOKE bit set. A

re-voked key cannot be used to validate RRSIGs. - RFC 5011, Sec. 2.1

6. The Signature Inception field of the RRSIG RR (2015-01-10 00:00:00) is 1 day in the future. - RFC 4035, Sec. 5.3.1

7. The Signature Expiration field of the RRSIG RR (2015-01-10 00:00:00) is 1 day in the past. - RFC 4035, Sec. 5.3.1

8. The value of the Signature Inception field of the RRSIG RR (2015-01-10 00:00:00) is within possible clock skew range (1 second) of the current time (2015-01-10 00:00:01). - RFC 4035, Sec. 5.3.1

9. The value of the Signature Expiration field of the RRSIG RR (2015-01-10

00:00:01) is within possible clock skew range (1 second) of the current time (2015-01-10 00:00:00). - RFC 4035, Sec. 5.3.1

10. The cryptographic signature of the RRSIG RR does not properly validate.- RFC 4035, Sec. 5.3.3

11. The length of the signature is 500 bits, but a GOST signature (DNSSEC algorithm 12) must be 512 bits long. - RFC 5933, Sec. 5.2

12. The length of the signature is 500 bits, but an ECDSA signature made with Curve P-256 (DNSSEC algorithm 13) must be 512 bits long.

13. The length of the signature is 500 bits, but an ECDSA signature made with Curve P-384 (DNSSEC algorithm 14) must be 768 bits long. - RFC 8080, Sec. 4

14. The length of the signature is 500 bits, but an Ed25519 signature (DNSSEC algo-rithm 15) must be 512 bits long.

15. The length of the signature is 500 bits, but an Ed448 signature (DNSSEC algorithm 16) must be 912 bits long.

16. The server(s) for the parent zone (baz.) responded with a referral instead of answer-ing authoritatively for the DS RR type. - RFC 4034, Sec. 5

17. DS records with digest type 1 (SHA-1) are ignored when DS records with digest type 2 (SHA-256) exist in the same RRset. - RFC 4509, Sec. 3

18. In the spiriRFC 4509, DS records with digest type 1 (SHA-1) might be ignored when DS records with digest type 2 (SHA-256) exist in the same RRset. - RFC 4509, Sec. 3

Evaluation of zonemaster– a DNS verification toolUtvärdering av zonemaster– verifieringsverktyg för DNS

Evaluation of zonemaster

– a DNS verification tool

Utvärdering av zonemaster

– verifieringsverktyg för DNS

IAN MARNE

NIKLAS WENNBERG

Evaluation of zonemaster

– a DNS verification tool

Utvärdering av zonemaster

– verifieringsverktyg för DNS

Niklas Wennberg

Ian Marne

Abstract

Sammanfattning

Acknowledgement

Table of contents

1 Introduction

2 Theory and background

3 Methodology

4 Results

5 Analysis and discussion

6 Conclusions

References

Appendix A

Appendix B