Wake Forest University switched from a public class B network to a private, switched class A network. We used to have one set of DNS data and 50 DHCP subnets. The new network needed public and private DNS records and over 850 DHCP subnets. We had to keep track of the IP addresses allocated for each building. Networking prepared an Excel spreadsheet documenting the networks, but our manual process of editing configuration files wasn't going to work anymore.
LDAP is an established tool for managing users. We wanted to use LDAP to manage our server and network configurations.
If we used the dNSZone schema and ISC DNS's LDAP back-end, every query would go to LDAP. We couldn't control named.conf. Existing tools weren't sufficient: we wanted to centralize data without increasing network traffic or making LDAP a 24x7 service.
Perl scripts pull LDAP information for DHCP and DNS configuration files.
We create private DNS information through views. Hosts are public if their LDAP record has a public address or a static NAT address. Dynamic zones are created for DHCP networks.
Import scripts parse the Networking team's Excel files. Web scripts let administrators add host names and IPs to LDAP. Tools verify that LDAP data isn't stale or malformed. We can generate authoritative reports about our servers and see who last modified a record.
Our LDAP configuration data is mostly private; only a few authorized accounts have access.
For our networks, we inherit from the NIS ipNetwork schema. All networks are in the "wfuIpNetwork" objectclass. DHCP networks are also "wfuIpDHCPNetwork" objects; static networks are "wfuIpStaticNetwork" objects. We store IP ranges, subnets, netmasks, gateway, location, and description for each network. The "cn" attribute stores the CIDR, which lets us "read" the distinguished name: "cn=10.2.1.0/24,ou=DHCP,ou=ipNetworks,dc=wfu,dc=edu".
Our hosts are "wfuIpHost" objects, based on the NIS ipHost schema. We use the ipHostNumber, description, location, and manager attributes. The "cn" attribute stores DNS names. DNs includes the hosts' group, so their purpose is obvious: "cn=example.wfu.edu,ou=Servers,ou=ipHosts,dc=wfu,dc=edu".
Complex DNS information is stored in our "dNSZones" subtree. Miscellany configuration data, like a list of our DNS views, is kept in our "Apps" subtree.
Our authoritative network and host configuration data is stored only once, in LDAP, and is queried and updated through web tools, import scripts, and configuration file generators.
John Borwick