-
Notifications
You must be signed in to change notification settings - Fork 2
DNS generation in NetReg has seen several changes in the last six months. The biggest change is that our DNS generation now has two methods: static zone files, or dynamic DNS update. The motivation for this change is that we would like to offer dynamic update for dynamically assigned IP addresses. Long term, we will allow the registration of a so-called "global dynamic" address. NetReg was designed around our long-standing policy of requiring static registration for every machine. As we add dynamic IP pools to many subnets around campus, users registering a machine to the "global dynamic" pool would be able to have a hostname follow their active IP address, by updates from the DHCP server as the IP address is assigned or expired.
Below we'll explain both methods of updating your DNS servers. We recommend that you NOT use the same DNS server groups to serve both static and dynamic zones.
Static zones are fairly straightforward: the machine running NetReg will generate a file containing all resource records that belong in the zone. The zone serial will be automatically incremented by the zonefile generation script dns.pl. The static zone files are generated in $NRHOME/etc/zone-gen. The generation script then calls the dns-xfer.pl script. dns-xfer copies all applicable zonefiles to the respective master DNS server. This copy routine is done via SSH (using the rsync utility).
Periodically another script runs on the master DNS server to load new zone files. BIND 8 and later use the DNS NOTIFY protocol to then inform secondary servers of the new zonefiles, and a transfer is initiated.
So the progression of the zonefiles is:
- dns.pl writes $NRHOME/etc/zone-gen/ZONENAME.zone (so the zone EXAMPLE.ORG is written to the file .../zone-gen/EXAMPLE.ORG.zone.
- dns-xfer.pl copies the appropriate zones from zone-gen/.zone to $NRHOME/etc/zone-xfer/.zone.
- dns-xfer.pl executes rsync (which then calls scp) and copies the zone files from the NetReg host (zone-xfer directory) to the master DNS server (the $NRHOME/etc/zone-xfer directory on the DNS server).
- update-zones.sh on the DNS server copies the zone from $NRHOME/etc/zone-xfer to $DNSZONEDIR. (You need to update the DNSZONEDIR variable in update-zones.sh.)
- The nameserver is reloaded by update-zones.sh and picks up the new zone information, informing the secondaries.
- The secondaries transfer the zone information from the master servers (done via the standard DNS XFER protocol; no special configuration is required.)
A note of caution before jumping into dynamic zone update: we are currently only testing this method of updating zones. We do NOT recommend you use this on mission-critical zones. We'd be interested in feedback, positive or negative, regarding your use of dynamic zone update.
Moving a zone from your static nameserver group to a dynamic group is a complicated process. The problem is really that our method of updating nameserver configurations and zone information is too efficient: you want the new zone information to propogate to the dynamic group (and have the current zone contents available) prior to your static servers dropping the zone (so that you have no interruption in DNS service.)
To this end, we've created a step-by-step guide to moving zones. This will require manual intervention, but should guarantee no interruption in service. Note when we say "pin", we mean that you should chown the files in question to root, or some other user (in this case, NOT the user that generates the files. At CMU, 'netreg' writes the files, so in 'pinning' we change the owner to root, and 'unpin' by changing it back to 'netreg'. Basically we want the files to be unchangeable by the normal means. Assume $ZONE refers to the zone that is moving from static to dynamic.
- In $NRHOME/etc/zone-xfer PIN: the zonefile for $ZONE, the zonefile for the parent zone, and the configuration files for the static master and static slaves (named.conf.$HOSTNAME).
- Change $ZONE's nameservers in NetReg to the dynamic zone NSs, add the appropriate keys to the DDNS Auth field (can be done earlier), and add the zone to your DDNS server group. Do NOT add ddns:ena to the DDNS Auth field yet.
- Run force-dns out of support-bin (or just wait until the zones are re-generated). In any case, wait for the zone regen.
- Wait for the nameserver configuration files to work their way out to the DDNS nameservers.
- Copy $NRHOME/etc/zone-gen/$ZONE.zone and the to the zone directory on your DDNS master nameserver, and reload the master. At this point the DDNS servers should be serving the zone (you can verify with:
- % dig axfr $ZONE @NS where NS refers to your DDNS nameserver.
- Add ddns:ena to the DDNS auth field of $ZONE.
- force-dns again; verify it is succeeding (basically, if you see an nsupdate process on the NetReg server for more than a few seconds, something is failing)
- Verify the zone is being served from the DDNS servers again.
- Unpin all the files.
- Again, watch the propogation and verify the static servers drop the zone from their configs, the parent zone is pushed out to direct requests to the DDNS servers, etc.
From the NetReg registrations and subnet information, a configuration file for the ISC DHCP server can be generated. Note that the DHCP server configuration is far more complicated than DHCP configuration. While it's fairly easy to specify options on a global, subnet, or machine basis, many DHCP features are inaccessible. This is simply because they are complicated constructs. If you need features beyond those that we generate by default, feel free to talk with us about the best way to add them to NetReg. Our general goal is to make NetReg as generic as possible and allow complete administration from the Web interface.
That being said, we write the DHCP server configuration files by writing:
- General, automatic options (such as server-identifier, etc.)
- Auxiliary information from DNS (update keys, if used)
- DHCP failover configuration, if configured. Note that we do not support more than one failover pair. However, once service groups are extended to include the ability to group subnets and zones, it will be fairly easy to use a service group with attributes and subnet members to have more than one pair.
- Global DHCP options
- Subnet configuration information (inside a subnet share as appropriate)
-
- Basic parameters (base address and netmask) specified in configuring the subnet
-
- Subnet DHCP Options
-
- Dynamic pools -- We do not support a general mechanism for setting pool options (ie, one pool for certain machines/users, etc.). Pool statements are generated directly from machines registered on the subnet with mode "pool". We coalesce adjacent IP addresses into a single block definition (ie 10.1.1.4-10.1.1.42).
-
- A class that matches hardware addresses (for subnets with pools configured)
- All registered machines with mode 'dynamic' are added as subclasses to the pool matching hardware address. We add the ddns-hostname and domain-name options to match the machine's hostname, unless these options are specified as DHCP options of the machine. The DHCP options of the machine are added here.
- All registered machines with mode 'static' are added in fixed-address statements. We then add the DHCP options of the machine in the fixed-address blocks.
Historically our network has been solely fixed ("static") addresses. Thus, with 20,000+ hosts, our DHCP configuration file is on the order of 2-3MB. Currently this configuration file is written three times per hour on our NetReg server. The generated configurations are then rsync'ed to the DHCP servers. They check for new configurations every five minutes (by running the generate.sh script). Once a new configuration is installed in /etc/dhcpd.conf, the rundhcpd program notices the change and restarts the DHCP server.
Our DHCP servers are relatively old machines: Sun Ultra 1's with 128-256MB of RAM. They handle our load adequately (most subnets have 1 day leases; areas that we encourage dynamic addressing have 3-4 hour leases). However, our up-to-thrice-hourly restarts are not insignificant. Thus, we were very happy to move to a failover configuration; there should be very few cases of no service to DHCP clients in this configuration.
The parameters of building the DHCP configuration files are all configurable in CMU/Netdb/config.pm. By default the files are written as $NRHOME/etc/dhcp-gen/dhcpd.conf.$HOSTNAME. We generate one file for each $HOSTNAME. Each member of your DHCP server service (configured in Config.pm) will get a configuration file. If the File Type attribute is 'Dynamic', we'll write one with the subclasses and pools. If the File Type attribute is 'Static', it will not contain this information.
Once generated, the files are rsync'ed to the appopriate servers, after being copied to $NRHOME/etc/dhcp-xfer. Our generate.sh script runs via cron every five minutes on the DHCP servers.
The services area is still under some development, so the exact output may change over time. However, the current output format is a single file that contains every service. This file is written as: $NRHOME/etc/service-gen/services.sif. The file format is similar to the format of ISC BIND's named.conf or the ISC DHCP server dhcpd.conf. Hash marks ('#') mark comments. Blocks are contained in braces: { and }. We'll give an overview of the current blocks that are output.
The design of this file is to provide an extensible, easily parseable format. In theory the file could be written as separate components, perhaps as applicable to certain services. However, this file is not currently publicly distributed at CMU (since it contains DDNS update keys), so we have no reason to separate it at this time. If you are interested in separate files, please talk to us about development of some standardized methods.
The sif-header block prefixes the entire file. The contents of this block are not currently used, but we created the header for future use. It's fairly self-explanatory; an example is:
sif-header { originator NetReg; timestamp 1010293741; time-formatted Sun Jan 6 00:09:01 2002; };
Every machine that exists as a member of a service group will have a block added in the services file. This will provide basic machine information that could be used by services. With the desire to allow subnets, zones, or other NetReg entities to become members of service groups, we expect similar blocks will be generated for those members.
An example machine block is below. The 'id' and 'version' fields are the NetReg table ID and version. The IP address field is represented as an unsigned 32-bit integer (see CMU/Netdb/helper.pm:long2dot for help converting to the standard dotted-quad format.) The respective TTL fields are for the DNS TTLs; a value of 0 is used to indicate "default" (inherits from the DNS zone). "Created" is the date and time the actual record was created.
machine DHCP1.NET.CMU.EDU { id 6635; version 20010825004103; ip_address 2147615746; mac_address 080020811637; host_name_ttl 0; ip_address_ttl 0; created 2000-08-12 12:39:49; flags ; };
The "meat" of the services file is the output of the actual service groups. Service attributes are added as attr ;. For maximum versatility, we are planning on changing this to a format: attr = ;. Additionally, we are planning on enclosing the service name in quotations. Members of the group are added as member blocks. As we add additional service membership types, we will need to indicate the type of member.
So, basically, this is a format which currently works, but will be changing soon. Below is the service block for our DHCP servers. The "File Type" attribute specifies whether the DHCP configuration file for the machine will contain dynamic pools, allowed dynamic machines, etc. In our case, dhcp1 and weh-ns are failover peers for both our dynamic pools and fixed-address ("static") machines. dhcp2 provides redundant service for fixed-addresses, so it does not get any pool information. netmon does not actually provide DHCP service; instead it needs the full dynamic DHCP configuration to generate graphs of utilization, etc.
service dhcp.net.cmu.edu type DHCP Server Pool { description The main campus DHCP service.; version 20011129155545;
attr Dynamic Secondary Port 520; attr Dynamic Master Port 519; member DHCP1.NET.CMU.EDU { attr Dynamic Failover master; attr File Type dynamic; }; member DHCP2.NET.CMU.EDU { attr File Type static; }; member WEH-NS.NET.CMU.EDU { attr Dynamic Failover secondary; attr File Type dynamic; }; member NS.FS.ANDREW.CMU.EDU { attr File Type static; }; member NETMON.NET.CMU.EDU { attr Dynamic Failover neither; attr File Type dynamic; }; };
DNS and DHCP require an easy mechanism for transferring files from your NetReg machine to the various servers. We use the rsync utility, with configuration done from CMU::Netdb::config (see above as well). We also use SSH as the underlying transport mechanism. It's fairly easy to configure.
We use RSA keypairs for authenticating the SSH connection. You will need an unused user account on your DHCP and DNS servers. We use the ftp user mostly because it was easy to setup in our environment (with a centrally maintained passwd file, etc.). We recommend you just add another user, possible netreg.
- Generate an RSA keypair by doing:
-
- % ssh-keygen -C netreg -f xfer
- When asked for a passphrase, just hit enter twice.
- You should then have two files: xfer and xfer.pub.
- Copy xfer to $NRHOME/etc/.identity-xfer on your NetReg machine (or some other file, and edit the RSYNC_RSH variable in Netdb/config.
- % chown netreg:netreg $NRHOME/etc/.identity-xfer
- % chmod 400 $NRHOME/etc/.identity-xfer
Then, on all of your DNS/DHCP servers:
- Add the new user account as per above (we'll call the username $USER and the user home directory $USERHOME)
- % mkdir $USERHOME/.ssh; chown $USER $USERHOME/.ssh; chmod 755 $USERHOME/.ssh
- Copy the xfer.pub file from above to $USERHOME/.ssh/authorized_keys
- % chown $USER $USERHOME/.ssh/authorized_keys; chmod 644 $USERHOME/.ssh/authorized_keys
Finally, on each DNS and DHCP server you'll need to create a skeleton NetReg home directory. You should do:
- % mkdir $NRHOME; mkdir $NRHOME/etc
- For DNS servers:
- % mkdir $NRHOME/etc/zone-xfer; chown $USER $NRHOME/etc/zone-xfer
- For DHCP servers:
- % mkdir $NRHOME/etc/dhcp-xfer; chown $USER $NRHOME/etc/dhcp-xfer
[ Contents | First Page | Previous Page | Home | Next Page | Last Page ]
[ 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 ]
Copyright © Carnegie Mellon University 2000-2003. All rights reserved.