ed note: this is an overview of basic memcached use case, and how memcached clients work
Two plucky adventurers, Programmer and Sysadmin, set out on a journey. Together they make websites. Websites with webservers and databases. Users from all over the Internet talk to the webservers and ask them to make pages for them. The webservers ask the databases for junk they need to make the pages. Programmer codes, Sysadmin adds webservers and database servers.
One day the Sysadmin realizes that their database is sick! It's spewing bile and red stuff all over! Sysadmin declares it has a fever, a load average of 20! Programmer asks Sysadmin, "well, what can we do?" Sysadmin says, "I heard about this great thing called memcached. It really helped livejournal!" "Okay, let's try it!" says the Programmer.
Our plucky Sysadmin eyes his webservers, of which he has six. He decides to use three of them to run the 'memcached' server. Sysadmin adds a gigabyte of ram to each webserver, and starts up memcached with a limit of 1 gigabyte each. So he has three memcached instances, each can hold up to 1 gigabyte of data. So the Programmer and the Sysadmin step back and behold their glorious memcached!
"So now what?" they say, "it's not DOING anything!" The memcacheds aren't talking to anything and they certainly don't have any data. And NOW their database has a load of 25!
Our adventurous Programmer grabs the pecl/memcache client library manual, which the plucky Sysadmin has helpfully installed on all SIX webservers. "Never fear!" he says. "I've got an idea!" He takes the IP addresses and port numbers of the THREE memcacheds and adds them to an array in php.

$MEMCACHE_SERVERS = array(
    "10.1.1.1", //web1
    "10.1.1.2", //web2
    "10.1.1.3", //web3
);

Then he makes an object, which he cleverly calls '$memcache'.

$memcache = new Memcache();
foreach($MEMCACHE_SERVERS as $server){
    $memcache->addServer ( $server );
}

Now Programmer thinks. He thinks and thinks and thinks. "I know!" he says. "There's this thing on the front page that runs SELECT * FROM hugetable WHERE timestamp > lastweek ORDER BY timestamp ASC LIMIT 50000; and it takes five seconds!" "Let's put it in memcached," he says. So he wraps his code for the SELECT and uses his $memcache object. His code asks:
Are the results of this select in memcache? If not, run the query, take the results, and PUT it in memcache! Like so:

$huge_data_for_frong_page = $memcache->get("huge_data_for_frong_page");
if($huge_data_for_frong_page === false){
    $huge_data_for_frong_page = array();
    $sql = "SELECT * FROM hugetable WHERE timestamp > lastweek ORDER BY timestamp ASC LIMIT 50000";
    $res = mysql_query($sql, $mysql_connection);
    while($rec = mysql_fetch_assoc($res)){
        $huge_data_for_frong_page[] = $rec;
    }
    // cache for 10 minutes
    $memcache->set("huge_data_for_frong_page", $huge_data_for_frong_page, 600);
}
// use $huge_data_for_frong_page how you please

Programmer pushes code. Sysadmin sweats. BAM! DB load is down to 10! The website is pretty fast now. So now, the Sysadmin puzzles, "What the HELL just happened!?" "I put graphs on my memcacheds! I used cacti, and this is what I see! I see traffic to one memcached, but I made three :(." So, the Sysadmin quickly learns the ascii protocol and telnets to port 11211 on each memcached and asks it:
Hey, 'get huge_data_for_front_page' are you there?
The first memcached does not answer...
The second memcached does not answer...
The third memcached, however, spits back a huge glob of crap into his telnet session! There's the data! Only once memcached has the key that the Programmer cached!
Puzzled, he asks on the mailing list. They all respond in unison, "It's a distributed cache! That's what it does!" But what does that mean? Still confused, and a little scared for his life, the Sysadmin asks the Programmer to cache a few more things. "Let's see what happens. We're curious folk. We can figure this one out," says the Sysadmin.
"Well, there is another query that is not slow, but is run 100 times per second. Maybe that would help," says the Programmer. So he wraps that up like he did before. Sure enough, the server loads drops to 8!
So the Programmer codes more and more things get cached. He uses new techniques. "I found them on the list and the faq! What nice blokes," he says. The DB load drops; 7, 5, 3, 2, 1!
"Okay," says the Sysadmin, "let's try again." Now he looks at the graphs. ALL of the memcacheds are running! All of them are getting requests! This is great! They're all used!
So again, he takes keys that the Programmer uses and looks for them on his memcached servers. 'get this_key' 'get that_key' But each time he does this, he only finds each key on one memcached! Now WHY would you do this, he thinks? And he puzzles all night. That's silly! Don't you want the keys to be on all memcacheds?
"But wait", he thinks "I gave each memcached 1 gigabyte of memory, and that means, in total, I can cache three gigabytes of my database, instead of just ONE! Oh man, this is great," he thinks. "This'll save me a ton of cash. Brad Fitzpatrick, I love your ass!"
"But hmm, the next problem, and this one's a puzzler, this webserver right here, this one runing memcached it's old, it's sick and needs to be upgraded. But in order to do that I have to take it offline! What will happen to my poor memcache cluster? Eh, let's find out," he says, and he shuts down the box. Now he looks at his graphs. "Oh noes, the DB load, it's gone up in stride! The load isn't one, it's now two. Hmm, but still tolerable. All of the other memcacheds are still getting traffic. This ain't so bad. Just a few cache misses, and I'm almost done with my work. So he turns the machine back on, and puts memcached back to work. After a few minutes, the DB load drops again back down to 1, where it should always be.
"The cache restored itself! I get it now. If it's not available it just means a few of my requests get missed. But it's not enough to kill me. That's pretty sweet."
So, the Programmer and Sysadmin continue to build websites. They continue to cache. When they have questions, they ask the mailing list or read the faq again. They watch their graphs. And all live happily ever after.
Author: Dormando via IRC. Edited by Brian Moon for fun. Further fun editing by Emufarmers.

REFERENCES
http://code.google.com/p/memcached/wiki/TutorialCachingStory

In this article, we will describe a design for a fault-tolerant (redundant) DHCP + DNS solution on Linux.
Design criteria:

• Failure of one DHCP server should not prevent Clients from obtaining a valid IP address.
• Failure of one DNS server should not prevent Clients from executing DNS queries.
• The design should allow for Dynamic DNS updates.

Contents [hide] 1 Design Overview 2 Fault-Tolerant DHCP Service 3 Fault-Tolerant DNS Service 3.1 DNS Master / Slave 3.2 DNS Multi-Master 3.3 Design Decision 4 Operational Issues 4.1 Managing combined Static and Dynamic DNS 5 Navigation

[edit] Design Overview

In the image below, you can see the design involving DNS Master / Slave as well as DHCP Primary / Secondary servers.
The sequence of events is as follows:

1. The Client initiates a DORA (Discover, Offer, Request, Accept) communications sequence with the DHCP servers.
2. Depending on the Client MAC address, one of the DHCP servers will respond with a DHCP_OFFER.
3. The Client obtains an IP address as well as additional network settings.
4. The DHCP server communicates the new lease to its partner.
5. The DHCP server sends a DNS update to the DNS Master server.
6. The DNS Slave server(s) are kept in sync using DNS Zone Transfers.

[edit] Fault-Tolerant DHCP Service

In this design, we will use the ISC DHCP daemon. One of the features includes a DHCP Primary / Secondary failover configuration, consisting of exactly 2 DHCP servers.
The DHCP servers share a pool of IP addresses, and keep the lease database for this pool in sync between them. If one DHCP server fails, the remaining server will continue to issue IP addresses. This guarantees uninterrupted service to the Clients.

• See Also: HOWTO Configure DHCP failover

[edit] Fault-Tolerant DNS Service

In this design, we will use the ISC DNS daemon. There are two ways to achieve fault tolerance:

1. Master / Slave configuration
2. Multi-Master configuration

[edit] DNS Master / Slave

DNS Master / Slave configuration is fairly straightforward. All zone data is kept on the DNS Master. The Master is configured to allow zone transfers from the DNS Slaves. Each DNS Slave performs zone transfers to obtain the most recent DNS information from the DNS Master.
Clients obtain a list of DNS servers through DHCP. If a DNS server fails, the Client will attempt to contact one of the remaining DNS servers. This guarantees uninterrupted DNS resolution service to the clients.
If the DNS Master fails, the situation becomes more severe. The DHCP servers communicate their updates only to the DNS Master server. In case of an outage, Dynamic DNS updates could be lost. One possible solution is the use of a DNS Multi-Master configuration.

[edit] DNS Multi-Master

DNS Multi-Master configuration is more complicated to configure and maintain than a Master / Slave configuration.
In case of a DNS server failure, both DNS Query and DNS Update services remain operational.

[edit] Design Decision

For our design, it is sufficient if DNS Queries from Clients remain operational. We will choose the DNS Master / Slave approach here as it is less complex, and still satisfies the design criteria.

• See Also: HOWTO Configure Dynamic DNS

how

[edit] Operational Issues

[edit] Managing combined Static and Dynamic DNS

Dynamic DNS is an all-or-nothing feature. If DDNS is enabled for a specific DNS zone, it should no longer be edited manually - your changes may be corrupted or overwritten. This often conflicts with existing systems management practices.
There are two approaches to avoid potential DNS corruption issues when managing a combined Static / Dynamic DNS environment:

Create a separate DNS zone for Dynamic DNS records

Static DNS records can still be managed in their own zone (example.local) as usual. Dynamic DNS records will be managed automatically in a separate DNS (sub-)domain, like "ddns.example.local".

Keep all DNS records in one Dynamic zone

All entries, both static and dynamic, are in the same DNS zone (example.local). Static entries should be managed using the "nsupdate" utility - this means that system management practices and tooling may need to be changed.

In this design, we will use a single Dynamic zone. Static entries will be managed using the "nsupdate" utility.

HOWTO Configure DHCP failover

From Consultancy.EdVoncken.NET

The ISC DHCP server currently supports failover using a maximum of 2 servers: primary and secondary. This is an active/active setup; a simple form of load balancing is used to spread the load across both servers.
In this example, we'll be setting up failover DHCP on two servers, 192.168.123.1 and 192.168.123.2. These servers also run DNS and NTP. Dynamic clients will get an address in the range 192.168.123.100-199. Static leases are defined for several networked devices.
Since the ISC DHCP server allows the use of "include-files" in the configuration, we will use them to help keep the configurations simple and in sync across servers.

Contents [hide] 1 Installation 2 Configuration 2.1 Failover parameters 2.2 Subnet declaration 2.3 Dynamic DNS 2.4 Static leases 3 Overall configuration 3.1 Configuring /etc/dhcpd.conf on the Primary 3.2 Configuring /etc/dhcpd.conf on the Secondary 4 Miscellaneous 4.1 SElinux considerations 4.2 Firewall settings 4.3 Starting the service 5 References 6 See Also 7 Navigation

[edit] Installation

Install the following package, for example using yum:

dhcp

This example is based on version dhcp-3.0.5-18.el5.

[edit] Configuration

The configuration consists of several sections, each stored in a separate file to make maintenance easier.

[edit] Failover parameters

For the Primary, define the following failover parameters in /etc/dhcpd.conf_primary:

##########################
 # DHCP Failover, Primary #
 ##########################
 
 failover peer "example" {                   # Failover configuration
        primary;                             # I am the primary
        address 192.168.123.1;               # My IP address
        port 647;
        peer address 192.168.123.2;          # Peer's IP address
        peer port 647;
        max-response-delay 60;
        max-unacked-updates 10;
        mclt 3600;
        split 128;                           # Leave this at 128, only defined on Primary
        load balance max seconds 3;
 }

For the Secondary, define the following failover parameters in /etc/dhcpd.conf_secondary:

############################
 # DHCP Failover, Secondary #
 ############################
 
 failover peer "example" {                   # Fail over configuration
        secondary;                           # I am the secondary
        address 192.168.123.2;               # My ip address
        port 647;
        peer address 192.168.123.1;          # Peer's ip address
        peer port 647;
        max-response-delay 60;
        max-unacked-updates 10;
        mclt 3600;
        load balance max seconds 3;
 }

[edit] Subnet declaration

Write a subnet declaration using our failover pool in /etc/dhcpd.conf_subnet. This section is identical on Primary and Secondary:

subnet 192.168.123.0 netmask 255.255.255.0  # zone to issue addresses from
 {
       pool {
               failover peer "example";      # Pool for dhcp leases with failover bootp not allowed
               deny dynamic bootp clients;
               range 192.168.123.100 192.168.123.190;
       }
       pool {                                # Accomodate our bootp clients here; no replication and failover
               range 192.168.123.191 192.168.123.199;
       }
       allow unknown-clients;
 
       authoritative;
 
       option routers             192.168.123.254;
       option subnet-mask         255.255.255.0;
       option broadcast-address   192.168.123.255;
       option domain-name         "example.local.";
       option domain-name-servers 192.168.123.1, 192.168.123.2;
       option ntp-servers         192.168.123.1, 192.168.123.2;
       option netbios-node-type   8;
 
       default-lease-time         300;
       max-lease-time             600;
 
       filename                   "/pxelinux.0";
       next-server                192.168.123.1;
 }

Note: the manpage for dhcpd.conf(5) states that dynamic BOOTP leases are not compatible with failover.
Therefore, BOOTP should be disabled in in pools using failover.

[edit] Dynamic DNS

If you are configuring Dynamic DNS, write the settings in /etc/dhcpd.conf_subnet. This section is identical on Primary and Secondary:

ddns-update-style interim;
 ddns-updates on;
 ddns-domainname "example.local."; 
 ignore client-updates;
 
 # Forward zone for DNS updates
 zone example.local
 {
       primary 192.168.123.1;                # update the primary DNS
       key ddns-update;                      # key to use for the update
 }
 
 # Reverse zone for DNS updates
 zone 123.168.192.in-addr.arpa
 {
       primary 192.168.123.1;                # update the primary DNS
       key ddns-update;                      # key for update
 }

Note: for security reasons, DNS updates need to be "signed" using a public/private key mechanism.
The "key ddns-update" statement specifies that DHCP will use a key named "ddns-update" during update requests.
For more information on this key, please refer to HOWTO Configure Dynamic DNS.

[edit] Static leases

For more flexible IP address management, configure all devices to use DHCP and set up static leases for these devices.
In /etc/dhcpd.conf_static, create all static leases that you may need (outside of the DHCP/BOOTP range!). Again, this section is identical on Primary and Secondary:

# Axis Security Camera
 host cam-reception {
       hardware ethernet 00:40:12:c0:ff:ee;
       fixed-address 192.168.123.200;
 }
 
 # Axis Security Camera
 host cam-fireexit {
       hardware ethernet 00:40:fe:ed:fa:ce;
       fixed-address 192.168.123.201;
 }
 
 # Axis Security Camera
 host cam-frontdoor {
       hardware ethernet 00:40:de:ad:be:ef;
       fixed-address 192.168.123.202;
 }

[edit] Overall configuration

The configuration of the Primary and Secondary DHCP servers is mostly identical, except for the Failover parameters. By keeping the sub-configurations in sync across servers (perhaps using rsync), maintenance is reduced to a minimum.
The overall configuration file, /etc/dhcpd.conf, is only slightly different on Primary and Secondary.

[edit] Configuring /etc/dhcpd.conf on the Primary

# DHCP Server - Configuration file for Primary
 #
 # File $Id: dhcpd.conf,v 1.21 2009/07/09 16:26:57 root Exp root $
 
 # Global configuration
 set vendorclass = option vendor-class-identifier;
 
 # Dynamic DNS Updates
 include "/etc/ddns-update.dnskey";
 include "/etc/dhcpd.conf_ddns";
 
 # DHCP Failover, Primary
 include "/etc/dhcpd.conf_primary";
 
 # Subnet declaration
 include "/etc/dhcpd.conf_subnet";
 
 # Static IP addresses
 include "/etc/dhcpd.conf_static";
 
 # EOF

[edit] Configuring /etc/dhcpd.conf on the Secondary

# DHCP Server - Configuration file for Secondary
 #
 # File $Id: dhcpd.conf,v 1.9 2009/07/09 16:31:20 root Exp root $
 
 # Global configuration
 set vendorclass = option vendor-class-identifier;
 
 # Dynamic DNS Updates
 include "/etc/ddns-update.dnskey";
 include "/etc/dhcpd.conf_ddns";
 
 # DHCP Failover, Secondary
 include "/etc/dhcpd.conf_secondary";
 
 # Subnet declaration
 include "/etc/dhcpd.conf_subnet";
 
 # Static IP addresses
 include "/etc/dhcpd.conf_static";
 
 # EOF

[edit] Miscellaneous

[edit] SElinux considerations

By default, SELinux policy does not allow the BIND daemon (named) to write to files labeled with the name_zone_t type, which is used for master zone files. The zone files should be stored under /var/named/chroot/var/named/data or /var/named/chroot/var/named/dynamic.

# restorecon -R -v /var/named/chroot/var/named/data
 # restorecon -R -v /var/named/chroot/var/named/dynamic

This will reset the zone files to the named_cache_t type, hopefully solving the "SELinux is preventing named (named_t) "unlink"" error messages.

[edit] Firewall settings

Your firewall should allow inbound traffic on 69/UDP, 69/TCP and 647/TCP. Sample entries for /etc/sysconfig/iptables:

# DHCP server
 -A INPUT -p udp -m udp --dport 69 -j ACCEPT
 -A INPUT -p tcp -m tcp --dport 69 -j ACCEPT
 -A INPUT -m state --state NEW -m tcp -p tcp --dport 647 -j ACCEPT

[edit] Starting the service

On both DHCP Primary and Secondary, run the following commands as root:

# chkconfig dhcpd on
 # service dhcpd start

[edit] References

• DHCP manual pages: dhcpd.conf(5), dhcpd-options(5)
• How To Set Up DHCP Failover On Centos 5.1
• https://fedorahosted.org/managing-confined-services/wiki/ContentSpecification

HOWTO Configure Dynamic DNS

From Consultancy.EdVoncken.NET

In this example, we will set up a DNS Master and DNS Slave server, on 192.168.123.1 and 192.168.123.2 respectively.
The configuration will also allow for Dynamic DNS updates from our DHCP servers.

Contents [hide] 1 Installation 2 Configuration 2.1 DNS Keys 2.2 DNS Master configuration 2.3 DNS Slave configuration 2.4 DNS Zone files 3 Miscellaneous 3.1 Client configuration 3.2 Using nsupdate to add or remove DNS entries 3.2.1 Adding a host (A and PTR records) 3.2.2 Deleting a host (A and PTR records) 3.2.3 Adding a mail-host (MX records) 3.2.4 Deleting a mail-host (MX records) 3.3 Debugging 3.4 Starting the service 4 References 5 See Also 6 Navigation

[edit] Installation

Install the following packages, for example using yum:

bind
 bind-chroot
 bind-utils

This example is based on bind-9.3.4-10.P1.el5_3.1.

[edit] Configuration

The configuration and data files for the chroot()-ed BIND DNS server can be found under /var/named/chroot/. Under /etc, you will find a symlink pointing to /var/named/chroot/etc/named.conf.

[edit] DNS Keys

For Dynamic DNS to work, the updates need to be "signed" using a transaction key. Since this is a symmetric key, it has to be shared between DNS and DHCP. It must be protected to prevent unauthorized changes being made to your DNS zones. The key has to be available on both DHCP servers. Generate the key as follows:

# cd /tmp
 # dnssec-keygen -a HMAC-MD5 -b 512 -n HOST ddns-update

These commands generate a set of .key and .private files in the current working directory. Move these files to a better name and location:

# mv Kddns-update.*.key /etc/ddns-update.key
 # cat /etc/ddns-update.key 
 ddns-update. IN KEY 512 3 157 K3EaOD3IysiC/D7lIXp+4hrYGDLyIq6la[...]9oE4kZ3O1ZFxKSMHfwG5YvUkYE7gxMHCmCg==
 
 # mv Kddns-update.*.private /etc/ddns-update.private
 # cat /etc/ddns-update.private 
 Private-key-format: v1.2
 Algorithm: 157 (HMAC_MD5)
 Key: K3EaOD3IysiC/D7lIXp+4hrYGDLyIq6la[...]9oE4kZ3O1ZFxKSMHfwG5YvUkYE7gxMHCmCg==

Note that the actual private and public keys are identical for HMAC-MD5. This is normal. The .key and .private files are needed by the nsupdate utility, later on.
We now need create a configuration file in a different format, for use by the DHCP and DNS servers- we will call this file /etc/ddns-update.dnskey. The syntax is identical to the /etc/rndc.key file. We need to set the key name and the key value properly:

# cat /etc/ddns-update.dnskey 
 key "ddns-update" {
       algorithm hmac-md5;
       secret "K3EaOD3IysiC/D7lIXp+4hrYGDLyIq6la[...]9oE4kZ3O1ZFxKSMHfwG5YvUkYE7gxMHCmCg==";
 };

Make sure it has the proper ownership and permissions:

# ls -l /etc/ddns-update.dnskey
 -rw-r----- 1 root named 145 Jul  9 12:25 ddns-update.dnskey

On the Primary DHCP / Master DNS server, the key needs to be available both as /etc/ddns-update.dnskey (for DHCP) and /var/named/chroot/etc/ddns-update.dnskey (for DNS). Creating a symlink will not work due to the SElinux policy; you will have to copy the file instead, so each copy has its own SElinux context:

# cp /etc/ddns-update.dnskey /var/named/chroot/etc/
 # ls -lZ /etc/ddns-update.dnskey /var/named/chroot/etc/ddns-update.dnskey 
 -rw-r-----  root root  root:object_r:etc_t              /etc/ddns-update.dnskey
 -rw-r-----  root named root:object_r:named_conf_t       /var/named/chroot/etc/ddns-update.dnskey

[edit] DNS Master configuration

On the Master, we will define all zones that we are authoritative for. We will also allow DNS updates to these zones from our DHCP servers.

# ISC BIND Configuration File
 #
 # Purpose:
 #   Configure BIND as caching/forwarding nameserver with authority
 #   for local networks as well as support for Dynamic DNS Updates
 #
 # File $Id: named.conf,v 1.4 2009/07/07 12:59:12 root Exp root $
 
 options {
       directory "/etc";
       pid-file "/var/run/named/named.pid";
       forwarders {
               // Put your ISP's DNS servers here
               66.159.123.200;
               66.159.123.201;
       };
       allow-query { localhost; localnets; };
 };
 
 # Key used by DHCP servers for Dynamic DNS Updates
 include "/etc/ddns-update.dnskey";
 
 zone "example.local" {
       type master;
       file "/var/named/data/example.local.zone";
       allow-transfer { 192.168.123.2; };
       allow-update { key "ddns-update"; };
 };
 
 zone "123.168.192.in-addr.arpa" {
       type master;
       file "/var/named/data/192.168.123.zone";
       allow-transfer { 192.168.123.2; };
       allow-update { key "ddns-update"; };
 };
 
 # EOF

SELinux Note: On the DNS Master, use the "data" sub-directory to store zone files.
Otherwise, you will see errors while trying to create journal files on the Master.

[edit] DNS Slave configuration

You can have multiple DNS Slave servers. Each will perform a zone transfer regularly, keeping the data in sync.
Dynamic DNS updates, originating from our DHCP servers are sent to the DNS Master only.

# ISC BIND Configuration File
 #
 # Purpose:
 #   Configure BIND as caching/forwarding slave nameserver
 #
 # File $Id: named.conf,v 1.4 2009/07/08 02:02:19 root Exp $
 
 options {
       directory "/etc";
       pid-file "/var/run/named/named.pid";
       forwarders {
               // Put your ISP's DNS servers here
               66.159.123.200;
               66.159.123.201;
       };
       allow-query { localhost; localnets; };
       allow-notify { 192.168.123.2; };
 };
 
 # Dynamic DNS Updates are only sent to the Primary DNS
 
 zone "example.com" {
       type slave;
       masters { 192.168.123.1; };
       file "/var/named/slaves/example.com.zone";
 };
 
 zone "123.168.192.in-addr.arpa" {
       type slave;
       masters { 192.168.123.1; };
       file "/var/named/slaves/192.168.123.zone";
 };

The "allow-notify" option prevents BIND from generating error messages as it apparently tries to notify itself of updates. Go figure ;-)
SELinux Note: On the DNS Slave, use the "slaves" sub-directory to store data from the DNS Master.
Otherwise, you will get a "permission denied" error on the Slave while trying to transfer the zones from the Master.

[edit] DNS Zone files

On the DNS Master, we create a minimal set of zone files (forward and reverse zones). Entries will be managed either by DHCP or nsupdate.
/var/named/data/example.local.zone:

 ; DO NOT EDIT MANUALLY - use the "nsupdate" utility to prevent data loss
 ;
 $ORIGIN example.local.
 $TTL 86400 ; 1 day
 @  IN SOA ns1.example.local. hostmaster.example.local. (
     2009074711 ; serial
     7200       ; refresh (2 hours)
     300        ; retry (5 minutes)
     604800     ; expire (1 week)
     60         ; minimum (1 minute)
     )
   IN NS ns1.example.local.
   IN NS ns2.example.local.
 ns1  IN A 192.168.123.1
 ns2  IN A 192.168.123.2

/var/named/data/192.168.123.zone:

 ; DO NOT EDIT MANUALLY - use the "nsupdate" utility to prevent data loss
 ;
 $ORIGIN 123.168.192.in-addr.arpa.
 $TTL 86400 ; 1 day
 @  IN SOA ns1.example.local. hostmaster.example.local. (
     2009074711 ; serial
     7200       ; refresh (2 hours)
     300        ; retry (5 minutes)
     604800     ; expire (1 week)
     60         ; minimum (1 minute)
     )
   IN NS ns1.example.local.
   IN NS ns2.example.local.
 1  IN PTR ns1.example.local.
 2  IN PTR ns2.example.local.

[edit] Miscellaneous

[edit] Client configuration

On RHEL/CentOS/Fedora clients, you should edit /etc/sysconfig/network-scripts/ifcfg-eth0 and set the DHCP_HOSTNAME variable to the short hostname of your machine. The client will now send its hostname to the DHCP server during IP address negotiation. The DHCP_HOSTNAME is used for updating Dynamic DNS. Sample:

# Sample Network Device
 DEVICE=eth0
 HWADDR=00:16:de:ad:be:ef
 ONBOOT=yes
 BOOTPROTO=dhcp
 DHCP_HOSTNAME=demo01

[edit] Using nsupdate to add or remove DNS entries

[edit] Adding a host (A and PTR records)

# nsupdate -k /etc/ddns-update.key
 > update add gateway.example.local 38400 A 192.168.123.254
 > 
 > update add 254.123.168.192.in-addr.arpa. 38400 PTR gateway.example.local.
 >
 > quit

Note: The empty line is necessary, it sends the update to DNS. Since we are adding records to two different zones, we need to send two separate updates.

[edit] Deleting a host (A and PTR records)

# nsupdate -k /etc/ddns-update.key 
 > update delete gateway.example.local IN A 192.168.123.254
 > 
 > update delete 254.123.168.192.in-addr.arpa PTR gateway.example.local.
 > 
 > quit

[edit] Adding a mail-host (MX records)

The domain "example.local" wishes to use "mail.example.local" as their primary mail host.
We first need to add the standard A and PTR records for the mailhost (TTL 86400 seconds), followed by the MX record for the domain:

# nsupdate -k /etc/ddns-update.key 
 > update add mail.example.nl 86400 IN A 192.168.123.25
 > 
 > update add 25.123.168.192.in-addr.arpa. 86400 PTR mail.example.local.
 > 
 > update add example.local 86400 MX 10 mail.example.local.
 > 
 > quit

Note: The mailhost should of course be accessible from the Internet and use a routable IP address instead of an RFC1918 address.
Verify the results using 'dig':

# dig example.local MX
 
 ; <<>> DiG 9.3.4-P1 <<>> example.local MX
 ;; global options:  printcmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15733
 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
 
 ;; QUESTION SECTION:
 ;example.local.   IN MX
 
 ;; ANSWER SECTION:
 example.local.  86400 IN MX 10 mail.example.local.
 
 ;; AUTHORITY SECTION:
 example.local.  86400 IN NS ns2.example.local.
 example.local.  86400 IN NS ns1.example.local.
 
 ;; ADDITIONAL SECTION:
 mail.example.local. 86400 IN A 192.168.123.25
 ns1.example.local. 86400 IN A 192.168.123.1
 ns2.example.local. 86400 IN A 192.168.123.2
 
 ;; Query time: 1 msec
 ;; SERVER: 127.0.0.1#53(127.0.0.1)
 ;; WHEN: Fri Jul 31 11:34:29 2009
 ;; MSG SIZE  rcvd: 134

[edit] Deleting a mail-host (MX records)

If we wish to remove the mail-host, just delete the MX, A and PTR records:

# nsupdate -k /etc/ddns-update.key 
 > update delete example.local MX 10 mail.example.local.
 > 
 > update delete mail.example.local IN A 192.168.123.25
 > 
 > update delete 25.123.168.192.in-addr.arpa PTR mail.example.local.
 > 
 > quit

Note: Mail may continue to be delivered to the old mailhost until the TTL expires!

[edit] Debugging

During development, you may want to enable some extra logging in /etc/named.conf:

logging {
       channel update_debug {
               file "/var/named/data/named-update.log";
               severity  debug 3;
               print-category yes;
               print-severity yes;
               print-time     yes;
       };
 
       channel security_info    {
               file "/var/named/data/named-auth.log";
               severity  debug 3;
               print-category yes;
               print-severity yes;
               print-time     yes;
       };
 
       category update { update_debug; };
       category security { security_info; };
 };

[edit] Starting the service

On both Master and Slave DNS, start the BIND nameserver:

# chkconfig named on
 # service named start

HOWTO Manage Dynamic DNS with nsupdate

From Consultancy.EdVoncken.NET

Contents [hide] 1 A and PTR records 1.1 Adding a host (A and PTR records) 1.2 Deleting a host (A and PTR records) 2 MX records 2.1 Adding a mail-host 2.2 Deleting a mail-host 3 Service (SRV) records 3.1 Adding SRV records for your IPA Server 4 Navigation

[edit] A and PTR records

[edit] Adding a host (A and PTR records)

# nsupdate -k /etc/ddns-update.key > update add gateway.example.local 38400 A 192.168.123.254 > > update add 254.123.168.192.in-addr.arpa. 38400 PTR gateway.example.local. > > quit Note: The empty line is necessary, it sends the update to DNS. Since we are adding records to two different zones, we need to send two separate updates.

[edit] Deleting a host (A and PTR records)

# nsupdate -k /etc/ddns-update.key > update delete gateway.example.local IN A 192.168.123.254 > > update delete 254.123.168.192.in-addr.arpa PTR gateway.example.local. > > quit

[edit] MX records

[edit] Adding a mail-host

The domain "example.local" wishes to use "mail.example.local" as their primary mail host.
We first need to add the standard A and PTR records for the mailhost (TTL 86400 seconds), followed by the MX record for the domain:
# nsupdate -k /etc/ddns-update.key > update add mail.example.nl 86400 IN A 192.168.123.25 > > update add 25.123.168.192.in-addr.arpa. 86400 PTR mail.example.local. > > update add example.local 86400 MX 10 mail.example.local. > > quit Note: The mailhost should of course be accessible from the Internet and use a routable IP address instead of an RFC1918 address.
Verify the results using 'dig':
# dig example.local MX  ; <<>> DiG 9.3.4-P1 <<>> example.local MX  ;; global options: printcmd  ;; Got answer:  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15733  ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3  ;; QUESTION SECTION:  ;example.local. IN MX  ;; ANSWER SECTION: example.local. 86400 IN MX 10 mail.example.local.  ;; AUTHORITY SECTION: example.local. 86400 IN NS ns2.example.local. example.local. 86400 IN NS ns1.example.local.  ;; ADDITIONAL SECTION: mail.example.local. 86400 IN A 192.168.123.25 ns1.example.local. 86400 IN A 192.168.123.1 ns2.example.local. 86400 IN A 192.168.123.2  ;; Query time: 1 msec  ;; SERVER: 127.0.0.1#53(127.0.0.1)  ;; WHEN: Fri Jul 31 11:34:29 2009  ;; MSG SIZE rcvd: 134

[edit] Deleting a mail-host

If we wish to remove the mail-host, just delete the MX, A and PTR records:
# nsupdate -k /etc/ddns-update.key > update delete example.local MX 10 mail.example.local. > > update delete mail.example.local IN A 192.168.123.25 > > update delete 25.123.168.192.in-addr.arpa PTR mail.example.local. > > quit Note: Mail may continue to be delivered to the old mailhost until the TTL expires!

[edit] Service (SRV) records

[edit] Adding SRV records for your IPA Server

After installing the IPA Server ("apollo" in this example), you should add some service-records to DNS for IPA discovery. The installer leaves a sample DNS zone file in /tmp. This is how I added the relevant records using nsupdate:
# nsupdate -k /etc/ddns-update.key > update add _ldap._tcp.example.local. 86400 IN SRV 0 100 389 apollo > > update add _kerberos._tcp.example.local. 86400 IN SRV 0 100 88 apollo > > update add _kerberos._udp.example.local. 86400 IN SRV 0 100 88 apollo > > update add _kerberos-master._tcp.example.local. 86400 IN SRV 0 100 88 apollo > > update add _kerberos-master._udp.example.local. 86400 IN SRV 0 100 88 apollo > > update add _kpasswd._tcp.example.local. 86400 IN SRV 0 100 464 apollo > > update add _kpasswd._udp.example.local. 86400 IN SRV 0 100 464 apollo > > quit

[edit] Navigation

• HOWTO Design a fault-tolerant DHCP + DNS solution
  • HOWTO Configure DHCP failover
  • HOWTO Configure Dynamic DNS
  • HOWTO Manage Dynamic DNS with nsupdate

[edit] References

• http://www.howtoforge.com/how-to-set-up-dhcp-failover-on-centos5.1
• http://www.revsys.com/writings/quicktips/bind-permission.html
• http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/
• http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html