sauron system implementation and deployment for dns management
TRANSCRIPT
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
1 Introduction and objectives
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
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 3 / 31
Introduction and objectives
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?
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 4 / 31
Introduction and objectives
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?
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 4 / 31
Introduction and objectives
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?
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 4 / 31
Introduction and objectives
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?
Mainly because humans cannot deal with large sequence numbers such asIP addresses.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 4 / 31
Introduction and objectives
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?
Most of services are configured using domain names.
Final user doesn’t understand about IP.
Resource’s IP address could even change.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 4 / 31
Introduction and objectives
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?
Error prone
Doesn’t provide concurrent modification capabilities. . .
. . . neither delegation rights schema.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 4 / 31
Introduction and objectives
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?
Wide environments =⇒ several IT staff in charge of each part.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 4 / 31
Introduction and objectives
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?
Provides a friendly user interface with user-based permissions.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 4 / 31
Involved Technologies
Outline
1 Introduction and objectives
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
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 5 / 31
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!
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 6 / 31
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!
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 6 / 31
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!
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 6 / 31
Involved Technologies DNS
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 7 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 8 / 31
University IT infrastructure
Outline
1 Introduction and objectives
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
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 9 / 31
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)
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 10 / 31
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)
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 10 / 31
University IT infrastructure Architecture overview
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
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 11 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 12 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 12 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 12 / 31
Sauron
Outline
1 Introduction and objectives
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
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 13 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 14 / 31
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 $
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 15 / 31
BIND server
Outline
1 Introduction and objectives
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
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 16 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 17 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 18 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 18 / 31
Testing environment
Outline
1 Introduction and objectives
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
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 19 / 31
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. . .
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 20 / 31
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. . .
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 20 / 31
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
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 21 / 31
System deployment
Outline
1 Introduction and objectives
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
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 22 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 23 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 23 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 23 / 31
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)
PUSH(syncrepl over TLS)
. . .
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 24 / 31
System deployment
BIND-LDAP system architecture
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
PUSH(syncrepl over TLS)
PUSH(syncrepl over TLS)
. . .
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 24 / 31
System deployment
BIND-LDAP system architecture
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
PUSH(syncrepl over TLS)
PUSH(syncrepl over TLS)
. . .
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 24 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 25 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 25 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 25 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 25 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 26 / 31
Conclusions and future work
Outline
1 Introduction and objectives
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
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 27 / 31
Conclusions and future work
Conclusions and future work
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 28 / 31
Conclusions and future work
Conclusions and future work
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 28 / 31
Conclusions and future work
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 29 / 31
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.
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 30 / 31
Thanks for your time!
Questions?
Gerard Bosch ([email protected]) Sauron implementation and deployment September 28, 2011 31 / 31