Collective Mining | Corporate Presentation - May 2024
Sauron system implementation and deployment for DNS management
1. Master in Open Source Software
Final master degree thesis
Sauron system implementation and
deployment for DNS management at UdL
Author: Advisor:
Gerard Bosch Monserrate Dr. Carles Mateu Pi˜ol
n
September 28, 2011
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 1 / 31
2. 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 work
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 2 / 31
3. Introduction and objectives
Outline
FLOSS project: data and
1 Introduction and objectives statistics
2 Involved Technologies 5 BIND server
DNS Overview
DHCP LDAP: Dynamic backend
6 Testing environment
3 University IT infrastructure 7 System deployment
Architecture overview
Data synchronisation
Infrastructure management
Process launching and
4 Sauron scheduling
System overview 8 Conclusions and future work
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 3 / 31
4. Introduction and objectives
Introduction
Sauron? DNS? What. . .
A distributed mechanism to translate (resolve) host names to IP
address is required.
DNS system was published at late 80s.
DNS: a critical networking resource.
An organisation can be responsible (authoritative) for their nodes.
Typical zone files are not practical.
Intra-organisation delegation and management is sometimes required.
Sauron provides benefits to current DNS management.
Why?
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 4 / 31
5. Introduction and objectives
Introduction
Sauron? DNS? What. . .
A distributed mechanism to translate (resolve) host names to IP
address is required.
DNS system was published at late 80s.
DNS: a critical networking resource.
An organisation can be responsible (authoritative) for their nodes.
Typical zone files are not practical.
Intra-organisation delegation and management is sometimes required.
Sauron provides benefits to current DNS management.
Why?
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 4 / 31
6. Introduction and objectives
Introduction
Sauron? DNS? What. . .
A distributed mechanism to translate (resolve) host names to IP
address is required.
DNS system was published at late 80s.
DNS: a critical networking resource.
An organisation can be responsible (authoritative) for their nodes.
Typical zone files are not practical.
Intra-organisation delegation and management is sometimes required.
Sauron provides benefits to current DNS management.
Why?
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 4 / 31
7. Introduction and objectives
Introduction
Sauron? DNS? What. . .
A distributed mechanism to translate (resolve) host names to IP
address is required.
DNS system was published at late 80s.
DNS: a critical networking resource.
An organisation can be responsible (authoritative) for their nodes.
Typical zone files are not practical.
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 as
IP addresses.
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 4 / 31
8. Introduction and objectives
Introduction
Sauron? DNS? What. . .
A distributed mechanism to translate (resolve) host names to IP
address is required.
DNS system was published at late 80s.
DNS: a critical networking resource.
An organisation can be responsible (authoritative) for their nodes.
Typical zone files are not practical.
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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 4 / 31
9. Introduction and objectives
Introduction
Sauron? DNS? What. . .
A distributed mechanism to translate (resolve) host names to IP
address is required.
DNS system was published at late 80s.
DNS: a critical networking resource.
An organisation can be responsible (authoritative) for their nodes.
Typical zone files are not practical.
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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 4 / 31
10. Introduction and objectives
Introduction
Sauron? DNS? What. . .
A distributed mechanism to translate (resolve) host names to IP
address is required.
DNS system was published at late 80s.
DNS: a critical networking resource.
An organisation can be responsible (authoritative) for their nodes.
Typical zone files are not practical.
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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 4 / 31
11. Introduction and objectives
Introduction
Sauron? DNS? What. . .
A distributed mechanism to translate (resolve) host names to IP
address is required.
DNS system was published at late 80s.
DNS: a critical networking resource.
An organisation can be responsible (authoritative) for their nodes.
Typical zone files are not practical.
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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 4 / 31
12. Involved Technologies
Outline
FLOSS project: data and
1 Introduction and objectives statistics
2 Involved Technologies 5 BIND server
DNS Overview
DHCP LDAP: Dynamic backend
6 Testing environment
3 University IT infrastructure 7 System deployment
Architecture overview
Data synchronisation
Infrastructure management
Process launching and
4 Sauron scheduling
System overview 8 Conclusions and future work
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 5 / 31
13. 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 resolution
mechanism —which was based in a host table file:
Problems
Traffic and load.
Consistency.
Name collision possibility.
Solutions
Decentralisation (distributed system).
Delegation.
Hierarchical name space.
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 6 / 31
14. 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 resolution
mechanism —which was based in a host table file:
Problems
Traffic and load.
Consistency.
Name collision possibility.
Solutions
Decentralisation (distributed system).
Delegation.
Hierarchical name space.
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 6 / 31
15. 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 resolution
mechanism —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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 6 / 31
16. Involved Technologies DNS
Name space example
“.”
Root
Delegation
com cat es net TLD
udl terra SLD
alumnes diei eps Subdomains
correu www Hosts
A domain name is read in reverse order: starting from leaf until root node.
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 7 / 31
17. 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 human
intervention.
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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 8 / 31
18. University IT infrastructure
Outline
FLOSS project: data and
1 Introduction and objectives statistics
2 Involved Technologies 5 BIND server
DNS Overview
DHCP LDAP: Dynamic backend
6 Testing environment
3 University IT infrastructure 7 System deployment
Architecture overview
Data synchronisation
Infrastructure management
Process launching and
4 Sauron scheduling
System overview 8 Conclusions and future work
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 9 / 31
19. 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 on
those 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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 10 / 31
20. 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 on
those 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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 10 / 31
22. 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 via
helpdesk every required change.
2 System administration staff receives assistances and manually
performs required changes on servers.
This 2 level process increases complexity and impacts on overall
management efficiency.
Sauron gets rid of this chained process and allows direct operation over
DNS and DHCP data in a controlled fashion.
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 12 / 31
23. 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 via
helpdesk every required change.
2 System administration staff receives assistances and manually
performs required changes on servers.
This 2 level process increases complexity and impacts on overall
management efficiency.
Sauron gets rid of this chained process and allows direct operation over
DNS and DHCP data in a controlled fashion.
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 12 / 31
24. 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 via
helpdesk every required change.
2 System administration staff receives assistances and manually
performs required changes on servers.
This 2 level process increases complexity and impacts on overall
management efficiency.
Sauron gets rid of this chained process and allows direct operation over
DNS and DHCP data in a controlled fashion.
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 12 / 31
25. Sauron
Outline
FLOSS project: data and
1 Introduction and objectives statistics
2 Involved Technologies 5 BIND server
DNS Overview
DHCP LDAP: Dynamic backend
6 Testing environment
3 University IT infrastructure 7 System deployment
Architecture overview
Data synchronisation
Infrastructure management
Process launching and
4 Sauron scheduling
System overview 8 Conclusions and future work
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 13 / 31
26. Sauron System overview
Overview
Sauron is a scalable Open Source system for the management of name
servers, DHCP and hosts.
It was developed at University of Jyvaskyla to manage hosts, allowing
rights delegation.
It is GPLv2 licensed.
Some features
Web interface with user/group access and constraints that allows
concurrent operation.
Auto-generation of BIND and DHCP configuration files with
consistency check.
Fine-grained constraint control.
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 14 / 31
27. 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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 15 / 31
28. BIND server
Outline
FLOSS project: data and
1 Introduction and objectives statistics
2 Involved Technologies 5 BIND server
DNS Overview
DHCP LDAP: Dynamic backend
6 Testing environment
3 University IT infrastructure 7 System deployment
Architecture overview
Data synchronisation
Infrastructure management
Process launching and
4 Sauron scheduling
System overview 8 Conclusions and future work
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 16 / 31
29. BIND server Overview
Overview
BIND is de facto standard implementation of Internet name servers and it
is Open Source.
Originally written from graduated students of Berkeley University at
mid-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 at
start-up.
Since version 9.1 comes with a simplified database API.
It has been widely criticised for its security problems, specially in early
versions.
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 17 / 31
30. 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 API
provided by BIND:
LDAP driver is shipped as stable.
It provides good performance and replication capabilities.
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 18 / 31
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 API
provided 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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 18 / 31
32. Testing environment
Outline
FLOSS project: data and
1 Introduction and objectives statistics
2 Involved Technologies 5 BIND server
DNS Overview
DHCP LDAP: Dynamic backend
6 Testing environment
3 University IT infrastructure 7 System deployment
Architecture overview
Data synchronisation
Infrastructure management
Process launching and
4 Sauron scheduling
System overview 8 Conclusions and future work
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 19 / 31
33. Testing environment
Simulation and testing
System has been deployed in a virtualized environment simulating UdL
systems and network architecture.
VirtualBox was the software package chosen since it is Open Source and is
available for Linux hosts.
Deployed servers
Internal servers:
DNS3 (dns3.udl.net)
DHCP (dns3.udl.net)
Sauron (sauron.udl.net)
External servers:
Gardeny (gardeny.udl.cat)
Let’s see a diagram about this testing environment. . .
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 20 / 31
34. Testing environment
Simulation and testing
System has been deployed in a virtualized environment simulating UdL
systems and network architecture.
VirtualBox was the software package chosen since it is Open Source and is
available for Linux hosts.
Deployed servers
Internal servers:
DNS3 (dns3.udl.net)
DHCP (dns3.udl.net)
Sauron (sauron.udl.net)
External servers:
Gardeny (gardeny.udl.cat)
Let’s see a diagram about this testing environment. . .
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 20 / 31
36. System deployment
Outline
FLOSS project: data and
1 Introduction and objectives statistics
2 Involved Technologies 5 BIND server
DNS Overview
DHCP LDAP: Dynamic backend
6 Testing environment
3 University IT infrastructure 7 System deployment
Architecture overview
Data synchronisation
Infrastructure management
Process launching and
4 Sauron scheduling
System overview 8 Conclusions and future work
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 22 / 31
37. 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.
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 23 / 31
38. 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.
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 23 / 31
39. 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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 23 / 31
40. System deployment
BIND-LDAP system architecture
SAURON
Sauron server hosts
PROVIDER
directory master copy
(provider). internal
Every name server hosts a
external
directory’s read-only replica
PUSH
(consumer). (syncrepl over TLS)
PUSH
(syncrepl over TLS)
DNS
DNS 1 DNS n external
CONSUMER CONSUMER CONSUMER
internal internal external
DNS DNS DNS
...
LDAP LDAP LDAP
query query query
BIND BIND BIND
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 24 / 31
41. System deployment
BIND-LDAP system architecture
SAURON
1 Consumers binds to
PROVIDER
provider.
2 Provider send notification internal
(PUSH) on changes. . .
external
3 . . . consumers starts data PUSH
synchronisation. (syncrepl over TLS)
PUSH
(syncrepl over TLS)
DNS
DNS 1 DNS n external
CONSUMER CONSUMER CONSUMER
internal internal external
DNS DNS DNS
...
LDAP LDAP LDAP
query query query
BIND BIND BIND
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 24 / 31
42. System deployment
BIND-LDAP system architecture
SAURON
1 Consumers binds to
PROVIDER
provider.
2 Provider send notification internal
(PUSH) on changes. . .
external
3 . . . consumers starts data PUSH
synchronisation. (syncrepl over TLS)
PUSH
(syncrepl over TLS)
DNS
DNS 1 DNS n external
Provider is authenticated with a
certificate and communication is CONSUMER CONSUMER CONSUMER
ciphered. internal internal external
DNS DNS DNS
...
LDAP LDAP LDAP
query query query
BIND BIND BIND
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 24 / 31
43. System deployment Data synchronisation
Zone-data sync
Problem
No suitable utility is shipped with BIND (bind-sdb) to sync zone files with
LDAP.
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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 25 / 31
44. System deployment Data synchronisation
Zone-data sync
Problem
No suitable utility is shipped with BIND (bind-sdb) to sync zone files with
LDAP.
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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 25 / 31
45. System deployment Data synchronisation
Zone-data sync
Problem
No suitable utility is shipped with BIND (bind-sdb) to sync zone files with
LDAP.
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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 25 / 31
46. System deployment Data synchronisation
Zone-data sync
Problem
No suitable utility is shipped with BIND (bind-sdb) to sync zone files with
LDAP.
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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 25 / 31
47. System deployment Process launching and scheduling
Launching
A launcher script has been written to start the data generation and
synchronisation 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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 26 / 31
48. Conclusions and future work
Outline
FLOSS project: data and
1 Introduction and objectives statistics
2 Involved Technologies 5 BIND server
DNS Overview
DHCP LDAP: Dynamic backend
6 Testing environment
3 University IT infrastructure 7 System deployment
Architecture overview
Data synchronisation
Infrastructure management
Process launching and
4 Sauron scheduling
System overview 8 Conclusions and future work
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 27 / 31
49. Conclusions and future work
Conclusions and future work
DNS is one of the most important resources for the Internet
operation.
Using Sauron an organisation can improve the DNS management.
Several Open Source solutions has been integrated and developed to
achieve this goal.
LDAP provides an interesting storage schema for DNS data.
Although BIND is the most deployed Internet name server, utilities
and 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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 28 / 31
50. Conclusions and future work
Conclusions and future work
DNS is one of the most important resources for the Internet
operation.
Using Sauron an organisation can improve the DNS management.
Several Open Source solutions has been integrated and developed to
achieve this goal.
LDAP provides an interesting storage schema for DNS data.
Although BIND is the most deployed Internet name server, utilities
and 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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 28 / 31
51. 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 (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 29 / 31
52. License
License
This slides and the project report is licensed under Creative Commons
CC-BY-NC-SA.
Sauron patches developed are licensed with the same Sauron’s license:
GPLv2. Developed scripts written to integrate and deploy Sauron are
licensed under GPLv3.
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 30 / 31
53. Thanks for your time!
Questions?
Gerard Bosch (gerard.bosch@gmail.com) Sauron implementation and deployment September 28, 2011 31 / 31
