BIND Domain Name System

As explained in Section 3.5, the Domain Name System (DNS) is used to match IP addresses and host names. One important implementation of a DNS server in the Unix and Linux world is BIND (Berkeley Internet Name Domain) [ISC, 2007]. This section holds some notes about how an importer for BIND could be implemented.

The main BIND configuration file is located under /etc/named.conf, where global options such as paths are set and the zones are declared. Other features of BIND include the definition of access control lists to specifically allow or deny requests coming from certain IP addresses. The format of zone entries in the main file is shown in Listing 10, along with an example. A parser has to read the zones and handle the global options to locate the correct files with zone definitions.

Listing 10: Zone declaration in named.conf /* format:

zone <zone-name> <zone-class> { <zone-options>; [<zone-options>; ...] }; */ zone "unifr.ch" IN { type master; file "unifr.ch.zone"; allow-update { none; }; };

68 CHAPTER 7. IMPORTING EXISTING CONFIGURATION

The actual zones are stored in individual files, one for each zone. Listing 11 shows a typical zone definition. The main file tells the name of the zone for the match and the type attribute.

Listing 11: Example zone file unifr.ch.zone ; zone file for unifr.ch

@ IN SOA siuftesun11.unifr.ch. hostmaster.unifr.ch. ( 2007040800 ; serial 12h ; refresh 15m ; retry 3w ; expire 3h ; min_ttl ) IN NS siuftesun11.unifr.ch. IN MX 10 mail.unifr.ch. siufsrv81 IN A 134.21.201.101 siuftesun11 IN A 134.21.201.200 www IN CNAME siufsrv81

All remaining information is contained in the zone file. The first line states the authority primaryns for the domain and the adminmail in hostname notation (the at character ‘@’ is re- placed with a dot). The meaning of the numbers in the header section is explained in the com- ments in Figure 12. The header section is followed by a list of entries for actual name to IP mappings and other DNS information. The entries have the format match [ttl] class type [type-parameters]. The most important record types are listed here, a complete reference is found in [Aitchison, 2007].

match: The host name. If it is not an absolute name with a dot at the end, the domain of the zone is appended.

ttl: Optional entry to overwrite the default time to live from the start of authority header. class: In this context always IN, for Internet protocol.

type: Resource record type. Important are:

NS: Authoritative name server for the domain.

MX: Mail exchange server. The parameters specify the priority of the mail server. A: Entry for a hostname to IP mapping.

CNAME: Canonical name. Defines an alias name for a host. TXT: Additional text information associated with the domain. type-parameters: Some types have additional parameters.

A generic method to import DNS configuration would be to use the DNS protocol to start a zone transfer. For a zone transfer, a machine asks the DNS server responsible for a particular zone to transmit all zone data to it. Verinec could implement this part of the DNS protocol and ask the DNS servers for their zones.

Currently, there is no implementation for an importer of DNS configuration in Verinec. When implementing one, the first decision to make is whether to import DNS data over a zone transfer or by parsing configuration files of different implementations. This will depend on whether the information received in a zone transfer is as rich as that in the implementation-specific configuration files.

Part III

Verinec Prototype Implementation

Chapter 8

Verinec Implementation

The Verinec application has been designed with the different aspects of network management in mind discussed in the previous chapters. The main principle of Verinec is: configuration has to be verified before it is applied to devices. This implies not only test cases for the configuration. Proper distribution of configuration is also important. Validated configuration should never have to be manipulated “by hand”, but handled automatically by the NMS, as suggested in Chapter 6. The focus of Verinec lies on one class of network service interruption: misconfiguration. General discussion of misconfiguration and its implications are found in Section 2.3.

The architecture of the framework is joint work from the author of this thesis and from Dominik Jungo. The adaptation part and the configuration XML Schema has been implemented by the author, the verification part by Dominik Jungo. Different tasks where done in the form of Master and Bachelor theses at the University of Fribourg, under the supervision of the author. The authors of these theses are credited in the corresponding sections.

Figure 8.1: Screenshot of the Verinec GUI.

This chapter begins with explaining the architecture of Verinec. Then, the Verinec configuration data format will be discussed. Network layout and node configuration are expressed in XML, according to an XML Schema definition. Several modules are built around the network definition.

8.1. ARCHITECTURE OF VERINEC 71

Each of the modules has a section in this chapter. To configure the real network, the adaptation module can automatically configure devices. There is an editor module to define and edit the network configuration. The verification module allows to check the configuration and simulate the network to test its behaviour. To create a network configuration from an existing network, the import module is used. It comprises a network scanner to automatically discover the layout of the network and a parser for configuration data of nodes. Chapter 9 illustrates the usage of Verinec from the point of view of a user (network administrator) on a real example.

8.1

Architecture of Verinec

Verinec is built around an abstract network definition. Its main elements are “nodes” (network ele- ments: computers, routers, appliances, etc.) and network connections between the node’s network interfaces. Each node can have configuration for services. The format will be described in Section 8.2, service configuration in Section 8.3. Named collections of nodes and network connections can be saved and loaded. The main application consists of a GUI to graphically visualise the network layout and a framework to work with the network elements. Figure 8.1 shows a screenshot of the application.

The work flow of the Verinec application is illustrated in Figure 8.2. Configuration from the real network can be imported using several methods. Once the abstract configuration of the network exists, it can be verified using rules and simulation. This provides feedback for an administrator to fix the errors in the editor. To deploy the new configuration to the real network, it is translated and distributed using an appropriate method. The automated configuration distribution has two advantages over manual configuration after the design process. Manual configuration is tedious for the administrator and a waste of time. The second and more important advantage is the security gain. Correctness verification would loose its significance if errors could be introduced in the process of configuring devices. Problems with the translation also cause feedback for the editor, for example when the abstract configuration uses features not supported by the target implementation. An added value of Verinec is the availability of a complete network description.

Network Definition Editor Import DescriptionSystem Verification Real network Adaptation Rules Design Guidelines Simulation Feedback Restriction analysis XSL Translator Distribute: File, SNMP,...

Traffic analysis and scanning Configuration file parser

Figure 8.2: The work flow of the Verinec application.

The Verinec application is built in a modular way. Various modules can be plugged into the GUI. The existing modules are introduced in this section and discussed in depth in Sections 8.4 to 8.8. Section 8.1.1 explains the module framework in order to extend Verinec with own modules. Avail- able modules are:

Editor: Provide the functionality to alter node configuration and network layout.

Adaptation: Translate the abstract XML configuration into implementation-specific format and distribute it.

72 CHAPTER 8. VERINEC IMPLEMENTATION

Verification: Test if a network fulfils specified requirements, using the simulator and rules on the XML documents. The network behaviour is simulated using the XML definition. Besides verifying the configuration, this module can also visualise the network simulation.

Import: Analyse network traffic and import configuration files to create abstract XML data for an existing network.

The graphical editor allows to edit the network. One can add and remove machines, interfaces and network connections. Configuration of Ethernet interfaces is supported with a graphical editor written by [Vogel, 2005]. Configuration of other services is not yet supported by graphical editors and must be done in source code. The usage of the editor from a network administrator side of view is explained in Chapter 9.

Verinec is more than just a network design tool. It is also capable of deploying the configuration to the target devices on the real network using the adaptation module. The configuration is transformed into an appropriate format and deployed by means of copying configuration files or using remote administration protocols. The adaptation module is discussed in Section 8.4.

To improve network reliability and security, Verinec incorporates a verification module. This module analyses the abstract configuration and contains a simulator to test the behaviour of the network. Requirement definitions allow to automatically test for the required network functionality. Using the testing module can reveal configurations errors before the setup of the productive devices is actually altered. Section 8.7 further explains the verification module.

For practical use, Verinec contains an import module to detect existing system setup and generate the abstract configuration. It uses traffic analysis to detect the network layout and parsers to import configuration files, use SNMP or similar methods. The vision is that an administrator can run Verinec and import her existing configuration and then deploy it on another machine running a different operating system and this other machine will behave exactly the same way the first one did. The import module is covered in Section 8.8.