Sauron system implementation and deployment for DNS management

Master in Open Source Software

Final master degree thesis

Sauron system implementation and

deployment for DNS management at UdL

Author:Gerard Bosch Monserrate

Advisor:Dr. Carles Mateu Pinol

September 28, 2011

Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 1 / 31

Outline

1 Introduction and objectives

2 Involved Technologies

3 University IT infrastructure

4 Sauron

5 BIND server

6 Testing environment

7 System deployment

8 Conclusions and future workGerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 2 / 31

Introduction and objectives

Outline


2 Involved TechnologiesDNSDHCP

3 University IT infrastructureArchitecture overviewInfrastructure management

4 SauronSystem overview

FLOSS project: data andstatistics

5 BIND serverOverviewLDAP: Dynamic backend

6 Testing environment7 System deployment

Data synchronisationProcess launching andscheduling

8 Conclusions and future work



Introduction

Sauron? DNS? What. . .

A distributed mechanism to translate (resolve) host names to IPaddress is required.

I DNS system was published at late 80s.

DNS: a critical networking resource.

An organisation can be responsible (authoritative) for their nodes.I Typical zone files are not practical.I Intra-organisation delegation and management is sometimes required.

Sauron provides benefits to current DNS management.

Why?



Introduction







Why?



Introduction







Why?



Introduction







Why?

Mainly because humans cannot deal with large sequence numbers such asIP addresses.



Introduction







Why?

Most of services are configured using domain names.

Final user doesn’t understand about IP.

Resource’s IP address could even change.



Introduction







Why?

Error prone

Doesn’t provide concurrent modification capabilities. . .

. . . neither delegation rights schema.



Introduction







Why?

Wide environments =⇒ several IT staff in charge of each part.



Introduction







Why?

Provides a friendly user interface with user-based permissions.


Involved Technologies

Outline











Involved Technologies DNS

Domain Name System (DNS)

DNS is an address resolution system born from ARPAnet at late 80s.

Was designed to solve scalability problems of previous name resolutionmechanism —which was based in a host table file:

Problems

Traffic and load.

Consistency.

Name collision possibility.

Solutions

Decentralisation (distributed system).

Delegation.

Hierarchical name space.

Makes networks more responsive to changes!






Problems

Traffic and load.

Consistency.


Solutions


Delegation.








Problems

Traffic and load.

Consistency.


Solutions


Delegation.





Name space example

“.”

com cat es net

epsalumnes diei

wwwcorreu

udl

Root

TLD

SLD

Subdomains

Hosts

terra

Delegation

A domain name is read in reverse order: starting from leaf until root node.


Involved Technologies DHCP

Dynamic Host Configuration Protocol (DHCP)

Protocol designed to simplify management of hosts in large environments.Allows hosts to auto-configure network parameters without humanintervention.

Some features

Client/server protocol.

Auto-negotiation of network address and other parameters.

Dynamic address allocation (allows to reuse addresses).

3 operational modes

Automatic allocation.

Manual allocation.

Dynamic allocation.


University IT infrastructure

Outline











University IT infrastructure Architecture overview

Architecture

UdL network will be presented from the DNS point of view.

Some university network-related data. . .

Owns 5 public C class IP networks.

Owns 2 public domains: udl.cat and udl.es.

Makes use of a private domain: udl.net.

Network is physically split up in 5 campuses.

Network is logically divided in VLANs and subnets: we will focus only onthose ones affected by DNS/DHCP.

Disposes of 3 internal (or stealth) name servers and 2 external ones.

A little more detail. . .

VLAN �Intranet�: 10.0.0.0/8 (internal network)

VLAN �Aules�: 172.16.0.0/16 (students network)

other non-routable networks (not relevant for our aim)



Architecture

UdL network will be presented from the DNS point of view.

Some university network-related data. . .

Owns 5 public C class IP networks.

Owns 2 public domains: udl.cat and udl.es.

Makes use of a private domain: udl.net.

Network is physically split up in 5 campuses.

Network is logically divided in VLANs and subnets: we will focus only onthose ones affected by DNS/DHCP.

Disposes of 3 internal (or stealth) name servers and 2 external ones.

A little more detail. . .

VLAN �Intranet�: 10.0.0.0/8 (internal network)

VLAN �Aules�: 172.16.0.0/16 (students network)

other non-routable networks (not relevant for our aim)



Logical network map

CESCA

193.144.8.0/24

193.144.10.0/24

193.144.9.0/24

DMZ193.144.12.0/25

Intranet10.0.0.0/8

Aules172.16.0.0/16

.129

.1

.1

.1

.226

.130

.132

.0.0.2

.0.0.1

.10.10.12.225

.20.1

.1

193.144.12.128/29

Sauron

.1

Residència192.168.0.0/24

193.144.11.0/24

.69.1.1

DNS1

.69.1.11

DNS2

.69.1.12

.20.10

DNS3 +DHCP

193.144.12.224/29


University IT infrastructure Infrastructure management

DNS and DHCP management

Currently the management of hosts is carried out with 2-levels procedure:

1 IT support staff in charge of user computer management, send viahelpdesk every required change.

2 System administration staff receives assistances and manuallyperforms required changes on servers.

This 2 level process increases complexity and impacts on overallmanagement efficiency.

Sauron gets rid of this chained process and allows direct operation overDNS and DHCP data in a controlled fashion.


















Sauron

Outline











Sauron System overview

Overview

Sauron is a scalable Open Source system for the management of nameservers, DHCP and hosts.

It was developed at University of Jyvaskyla to manage hosts, allowingrights delegation.

It is GPLv2 licensed.

Some features

Web interface with user/group access and constraints that allowsconcurrent operation.

Auto-generation of BIND and DHCP configuration files withconsistency check.

Fine-grained constraint control.


Sauron FLOSS project: data and statistics

Project statistics

Source code

Perl 18119 lines (87.62%)Bash 2558 lines (12.37%)

COCOMO model (personcost=32000$/year, overhead=40%)

Total lines of code: 20.678

Development effort,Person-Years (Person-Months): 4.81 (57.74)

Schedule estimate, Years (Months): 0.97 (11.68)

Estimated Avg. Num. of Developers: 4.95

Total Estimated Cost to Develop: 61.592 $


BIND server

Outline











BIND server Overview

Overview

BIND is de facto standard implementation of Internet name servers and itis Open Source.

Originally written from graduated students of Berkeley University atmid-80s and rewritten from scratch by Paul Vixie team 20 years later.

Is licensed with a permissive license: ISC license.

BIND uses an in-memory backend, reading data from zone files atstart-up.

Since version 9.1 comes with a simplified database API.

It has been widely criticised for its security problems, specially in earlyversions.


BIND server LDAP: Dynamic backend

BIND dynamic backend

Advantages

Dynamic data loading =⇒ reloads are no longer required.

Get rid of slave servers and zone transfers.

Get rid of cryptic zone files.

Allow third-party data management.

Better data access control including permissions.

Some drivers was written some time ago using Simplified Database APIprovided by BIND:

LDAP driver is shipped as stable.

It provides good performance and replication capabilities.

. . . thus it has been chosen as BIND persistence backend.


BIND server LDAP: Dynamic backend

BIND dynamic backend

Advantages

Dynamic data loading =⇒ reloads are no longer required.

Get rid of slave servers and zone transfers.

Get rid of cryptic zone files.

Allow third-party data management.

Better data access control including permissions.

Some drivers was written some time ago using Simplified Database APIprovided by BIND:

LDAP driver is shipped as stable.

It provides good performance and replication capabilities.

. . . thus it has been chosen as BIND persistence backend.


Testing environment

Outline











Testing environment

Simulation and testing

System has been deployed in a virtualized environment simulating UdLsystems and network architecture.

VirtualBox was the software package chosen since it is Open Source and isavailable for Linux hosts.

Deployed servers

Internal servers:I DNS3 (dns3.udl.net)I DHCP (dns3.udl.net)I Sauron (sauron.udl.net)

External servers:I Gardeny (gardeny.udl.cat)

Let’s see a diagram about this testing environment. . .


Testing environment

Simulation and testing

System has been deployed in a virtualized environment simulating UdLsystems and network architecture.

VirtualBox was the software package chosen since it is Open Source and isavailable for Linux hosts.

Deployed servers

Internal servers:I DNS3 (dns3.udl.net)I DHCP (dns3.udl.net)I Sauron (sauron.udl.net)

External servers:I Gardeny (gardeny.udl.cat)

Let’s see a diagram about this testing environment. . .


Testing environment

Testing environmentDesktop PC

WAN

DNS3

eth0 (.69.1.12)

eth1 (.20.1)

eth2 (.69.12)

eth0

Laptop PC

192.168.0.0/16

eth1

eth2

Gardeny

eth0 (n/u)

eth1 (10.0.0.2)

eth2 (.10.2)

(home network)

Aules172.16.0.0/16

Intranet10.0.0.0/8

eth0 Sauron

eth0(10.69.1.100)

eth1 (.69.100)

wlan0192.168.0.0/16

= Virtual Machine

(home network)

.1.4

.1.3

<DHCP>

.1.1


System deployment

Outline











System deployment

Overview

To deploy the whole system, integration of every component is required.

Components

Name servers (BIND).

Dynamic backend for BIND servers (LDAP directory).

DHCP server.

Sauron server.

Each name server owns its own directory.

Let’s see a diagram showing the architectural components of the system.


System deployment

Overview


Components



DHCP server.

Sauron server.




System deployment

Overview


Components



DHCP server.

Sauron server.




System deployment

BIND-LDAP system architecture

Sauron server hostsdirectory master copy(provider).

Every name server hosts adirectory’s read-only replica(consumer).

internalDNS

CONSUMER

BIND

LDAPquery

DNS 1

PROVIDER

SAURON

internal

external

internalDNS

CONSUMER

BIND

LDAPquery

DNS n

externalDNS

CONSUMER

BIND

LDAPquery

DNS external

PUSH(syncrepl over TLS)


. . .


System deployment


1 Consumers binds toprovider.

2 Provider send notification(PUSH) on changes. . .

3 . . . consumers starts datasynchronisation.

internalDNS

CONSUMER

BIND

LDAPquery

DNS 1

PROVIDER

SAURON

internal

external

internalDNS

CONSUMER

BIND

LDAPquery

DNS n

externalDNS

CONSUMER

BIND

LDAPquery

DNS external



. . .


System deployment


1 Consumers binds toprovider.

2 Provider send notification(PUSH) on changes. . .

3 . . . consumers starts datasynchronisation.

Provider is authenticated with acertificate and communication isciphered. internal

DNS

CONSUMER

BIND

LDAPquery

DNS 1

PROVIDER

SAURON

internal

external

internalDNS

CONSUMER

BIND

LDAPquery

DNS n

externalDNS

CONSUMER

BIND

LDAPquery

DNS external



. . .


System deployment Data synchronisation

Zone-data sync

Problem

No suitable utility is shipped with BIND (bind-sdb) to sync zone files withLDAP.

Solution

Write from scratch a program that parses zone files and synchronise(mirroring) data with LDAP: syncldapzone.pl

How it works. . .1 Delete from directory no longer existing entries.2 Update common entries from local changes.

1 Delete no longer existing attributes.2 Update common attributes from local values.3 Add locally new attributes.

3 Commit locally new entries.



Zone-data sync

Problem


Solution







Zone-data sync

Problem


Solution







Zone-data sync

Problem


Solution






System deployment Process launching and scheduling

Launching

A launcher script has been written to start the data generation andsynchronisation process: sauron-launcher.sh

Tasks

Sauron execution: config. files generation.

Checking for errors in generation.

Copy configurations to remote targets.

Process log generation.

Archive of configs. and logs in a tarball and perform rotation.

This process is scheduled with CRON to run every few minutes.


Conclusions and future work

Outline













DNS is one of the most important resources for the Internetoperation.

Using Sauron an organisation can improve the DNS management.

Several Open Source solutions has been integrated and developed toachieve this goal.

LDAP provides an interesting storage schema for DNS data.

Although BIND is the most deployed Internet name server, utilitiesand documentation to use a database backend are not up to date.

Future work

Add support for IPv6 on Sauron.

Test the system in a real production environment.




DNS is one of the most important resources for the Internetoperation.

Using Sauron an organisation can improve the DNS management.

Several Open Source solutions has been integrated and developed toachieve this goal.

LDAP provides an interesting storage schema for DNS data.

Although BIND is the most deployed Internet name server, utilitiesand documentation to use a database backend are not up to date.

Future work

Add support for IPv6 on Sauron.

Test the system in a real production environment.



Conclusions

Personal benefits

DNS/DHCP system and operation study.

LDAP protocol and directory study.

Code digging, bug tracking and bug fixing.

System integration, use of dynamic (script) languages.

FLOSS project analysis methodologies.

Exploration of technical and standard definition bibliography.

Management of virtual environments and servers.


License

License

This slides and the project report is licensed under Creative CommonsCC-BY-NC-SA.

Sauron patches developed are licensed with the same Sauron’s license:GPLv2. Developed scripts written to integrate and deploy Sauron arelicensed under GPLv3.


Thanks for your time!

Questions?


Sauron system implementation and deployment for DNS management

Investor Relations

current dns management

intraorganisation delegation

sauron implementation

objectives introductionsauron

resolve host names

gerard bosch monserrate

gerard bosch ger

typical zone