In many home networking environments, the DSL or cable modem IP address is provided by DHCP and therefore changes from time to time. This can cause problems with the DNS zone files explained in Chapter 18, “Configuring DNS,” which assume the IP address of a server won't change continuously. It is for this reason that there are two broad types of DNS:

Static DNSThis is used when your ISP provides you with unchanging fixed or static Internet IP addresses. Your DNS server acts as the authoritative source of information for your my-site.com domain. You can consider static DNS as the “traditional” or “regular” form of DNS.Dynamic DNS (DDNS)Used when you get a changing dynamic Internet IP addresses via DHCP from your ISP. You will have to use the services of a third-party DNS provider to provide DNS information for your my-site.com domain.

This chapter will explain the details of dynamic DNS configuration.

Unlike DSL, most cable modem providers may not allow you to host sites at home by blocking inbound HTTP (TCP port 80) and SMTP mail (TCP port 25) while allowing most other TCP traffic through. Many DDNS providers are aware of this and provide a redirect service to bypass the problem. Under the system, Web queries first hit their servers on the regular TCP ports and then these servers automatically redirect the Web clients to use the IP address of your server on a different TCP port. Although this works well, it has disadvantages. The cost of the service can make hosting with a $10 /month virtual hosting service look very attractive, and many search engines do not index redirected pages.

The very first thing you need to do is to determine whether your ISP allows inbound connections on your DSL or cable modem line. The easiest way to do this is to phone them and ask, but in some cases they'll say no when in fact the answer is yes. Here is how you can test it out for yourself.

You need to do some basic setup tests before testing can begin.

1. Configure and start Apache on your Linux web server as described in Chapter 20, “The Apache Web Server.”
2. Connect your Linux server directly to your cable or DSL modem, and configure the Ethernet NIC for DHCP as described in Chapter 3, “Linux Networking.”.
3. Make sure you can ping your default gateway.
4. Use the ifconfig command to determine the new IP address of your Web server. (This command is explained Chapter 3 also.).
5. From the Linux Web server itself, try to TELNET to this IP address on port 80 as explained in Chapter 4, “Simple Network Troubleshooting.”

If you can, then you most likely have Apache configured correctly

You may be able to see web pages from the web server itself. Ask a friend somewhere else on the Internet to try to telnet to this IP address on port 80.

If port 80 works, then ask the friend to point a Web browser to the IP address and see whether a valid Web page appears. If your Linux server will eventually be placed behind a firewall, then adjust your network topology accordingly and test port 80 port forwarding to your Web server.

If the TELNET to port 80 fails, your ISP probably doesn't allow HTTP access to its networks. Configure your Web server to run on a different TCP port, preferably above 1024. The Apache httpd.conf file uses the listen directive to do this. Change it to your new value and restart httpd.

# httpd.conf listen directive, change "80" to some other value.

Listen 80

Test again with telnet on this new port. If it works, try the web browser test too. If the test port is 1234, then use the following URL:

[[http://server-ip-address:1234/|http://server-ip-address:1234]]

Note: If you are running iptables, remember to adjust the rules to match this new port, or stop iptables temporarily while doing this testing.

If you can get a connection with correctly displayed pages on a non standard port then you can additionally sign up for a redirect service with your DDNS provider as explained earlier.

If your Linux server will eventually be placed behind a firewall, then adjust your network topology accordingly. Let Apache run on port 80, and test port forwarding from the nonstandard port to port 80 on your Web server from the Internet.

One of the features of the curl troubleshooting utility is that it allows you download a Web page's HTML code to your screen without interpreting it. You can determine the external IP address of your router or firewall by logging onto your Linux Web server and issuing the curl command to query the DynDNS.org IP information server. In this case, you are interested in only the line that tells you what the server thinks your IP address is; use the grep command to extract just that part. In this example, the IP address is 24.4.97.110.

[root@bigboy tmp]# curl -s http://checkip.dyndns.org/ | grep -i address
<html><head><title>Current IP Check</title></head><body>Current IP Address: 24.4.97.110</body></html>
[root@bigboy tmp]#

Once you have decided to go ahead with DDNS you'll need to choose between the broad categories of Dynamic DNS service.

• Free Dynamic DNS: Your website name will be a sub domain of the DDNS provider's domain. For example if the DDNS provider's domain is isp.net, then your site will become my-site.my-isp.net. You can perform all the necessary steps on your DDNS service provider's Web site. Remember that this type of service may be undesirable for a company that wants to establish its own corporate identity. Another disadvantage is that you must rely on your DDNS provider staying in business or else you may lose your domain. When you own your own domain this worry largely goes away as you are fully in control of the DNS registration and renewal process.

Another disadvantage is that you must rely on your DDNS provider staying in business or else you may lose your domain. When you own your own domain this worry largely goes away as you are fully in control of the DNS registration and renewal process.

• Paid Customized DNS: You can register the domain name of your choice and still host your website on a DHCP line.

If you choose to create your own domain and use a paid DDNS service then you'll need to follow these steps:

1. Register your domains (such as my-site.com) with such companies as Verisign and RegisterFree.
2. Create an account with the DDNS provider and register your websites (sometimes called hosts) as part of your domain (as in www.my-site.com and mail.my-site.com) with them. Your DDNS registration process will provide you with a username and password which you'll need to use when configuring your DDNS client.
3. Update your domain information with your main DNS registrar (Verisign and RegisterFree) to tell them to direct queries to *.my-site.com to the DNS name servers of the DDNS provider.
4. Install a DDNS client on your web servers that continuously runs, only updating the DDNS provider's DNS servers with the most current DHCP IP address of the site whenever it detects a change.

Note: You should also be prepared for slower response times for your home-based site than if you were using a static IP and a regular DNS service.

All DDNS service providers require that you use a DDNS client on your web server that will periodically update the IP address information in your provider's DDNS record. The very popular one DDclient, for example, now comes in a RPM format.

As discussed in Chapter 2, “Introduction to Networking,” to conserve the limited number of IP addresses available for Internet purposes, most home router/firewalls use network address translation (NAT) to map a single, public, DHCP-obtained IP address to the many private IP addresses within your network.

NAT can fool the operation of some DDNS client software. In these cases, the software can report only the true IP address of the Linux box's NIC interface. If the Linux box is being protected behind a NAT router/firewall, then the NIC reports in its data stream to the DDNS provider a private IP address that no one can reach directly via the Internet. The reported value is therefore invalid.

Some DDNS providers use more intelligent clients, such as DDclient, that can be configured to let the DDNS provider record the public IP address from which the data stream is originating. Once this is done, you'll have to also configure your router/firewall to do port forwarding to make all HTTP traffic destined for the IP address of the router/firewall to be exclusively address translated using NAT and forwarded to a single server on your home network. If your firewall is Linux based, then the examples in Chapter 14, “Linux Firewalls Using iptables,” will be helpful. Many Web-based small office/home office (SOHO) firewalls have easy interfaces to configure port forwarding, please refer to your manufacturer's manual on how to do this

Most new SOHO router/firewalls have built in dynamic DNS clients for one or more of the major DDNS service providers. There is usually a Dynamic DNS web menu which will prompt for the name of the service provider and your DDNS username and password. With this support, there is no need to install software on your web server.

One of the most commonly used clients is DDclient, which can overcome the NAT limitations of DDNS by actually logging into your SOHO firewall to determine the latest IP address information. Like most RedHat and Fedora Linux software products, DDclient is available in the RPM format. (If you need a refresher on RPMs, consult Chapter 6, “Installing Linux Software.”) You can usually download the software from your DDNS provider, or you can find it at rpmfind.net. The RPM name usually starts with ddclient followed by a version number, as in ddclient-3.6.3-1.noarch.rpm.

The ddclient.conf file is usually installed completely commented out, but provides many configuration examples for the most popular DDNS providers.

The most important general parameters to configure are:

• Username: Your DDNS account's login name
• Password: Your DDNS account's password
• Use: The method used to determine the IP address to advertise to the DDNS server

Some important DDNS provider parameters are

• Server: The name of the DDNS provider's main DNS server
• Protocol: The methodology the DDNS client should use to communicate with the DDNS server
• Your domain: The domain to which your web server will belong

You can use the ddclient command to determine the best use parameter to use in the ddclient.conf file. In this example, only the use=web option gives a valid Internet IP address and should be considered as a first option:

[root@bigboy tmp]# ddclient -daemon=0 -query
use=if, if=lo address is 127.0.0.1
use=if, if=wlan0 address is 192.168.1.100
use=web, web=dyndns address is 97.158.253.26
[root@bigboy tmp]#

Take a look at a sample configuration. This example specifies a username of my-account-login-name and a password of my-account-password using the dyndns DDNS service provider's settings to track the Web site named mysite-example.dnsalias.com.

# General Parameter Section

login=my-account-login-name
password=my-account-password

# DDNS Provider Parameters Section

server=members.dyndns.org,              \
protocol=dyndns2                        \
mysite-example.dnsalias.com

You can add one of the following use lines to the General Parameter Section near the top of the file to define the method that will be used to determine the correct IP address:

• Query A Well Known Internet Server: The web method queries two well known servers run by DynDNS.org and DNSpark to determine the public Internet IP address of the web server running the DDclient software. This method is the simplest as it requires no further information and handles NAT correctly.

use=web

• Use The IP Address Of A Specific Server NIC : You can also use this option which will query the IP address of the DDclient web server's NIC interface of your choice. This is probably most valuable for servers connected directly to the Internet, and not via NAT

use=if, if=eth0

• Login To Your SOHO Firewall For Information: The ddclient.conf file has a list of use statements for various vendor's firewalls. If your model isn't listed, you can create your own parameters as outlined in the ddclient README file. This option is good for NAT environments where the “use=web” option isn't considered a good alternative.

After editing your configuration file you'll have to start ddclient as shown in the next section.

Managing the ddclient daemon is easy to do, but the procedure differs between Linux distributions. Here are some things to keep in mind.

1. Firstly, different Linux distributions use different daemon management systems. Each system has its own set of commands to do similar operations. The most commonly used daemon management systems are SysV and Systemd.
2. Secondly, the daemon name needs to be known. In this case the name of the daemon is ddclient.

Armed with this information you can know how to:

1. Start your daemons automatically on booting
2. Stop, start and restart them later on during troubleshooting or when a configuration file change needs to be applied.

For more details on this, please take a look at the “Managing Daemons” section of Chapter 6 “Installing Linux Software”

Note: Remember to configure your daemon to start automatically upon your next reboot.

The ddclient -force command will give you an immediate status of whether ddclient has updated your DDNS service provider correctly.

[root@zippy tmp]# ddclient -force
SUCCESS:  updating test.homelinux.org: good: IP address set to 123.7.265.123
[root@zippy tmp]#

If this fails, use the output of your /var/log/messages file and use it to help you correct any possible configuration errors.

The DDclient read-me and ddclient.conf files are good sources of information for doing custom configurations and troubleshooting. You can find the read-me file by using DDclient RPMs or the locate command.

Use the rpm command to get a list of installed DDclient files, one of which is the read-me file

[root@bigboy tmp]# rpm -ql ddclient
...
/usr/doc/ddclient-3.6.3/README
 ...
[root@bigboy tmp]#

Alternately, you can use the locate command to find all the DDclient files:

 [root@bigboy tmp]# locate ddclient | grep READ
/usr/doc/ddclient-3.6.3/README
/usr/doc/ddclient-3.6.3/README.cisco
[root@bigboy tmp]#

If the command doesn't work, try updating your locate database with the locate -u command followed by the locate ddclient command once more:

[root@bigboy tmp]# locate -u

Your DDNS service provider will typically force your entry to expire if it doesn't receive an update within a few months. The easiest way to solve this problem is to use the cron sample file that ddclient provides. Here's how to do it.

1. Use the rpm command to get a list of installed DDclient files, one of which is the cron file .

[root@bigboy tmp]# rpm -ql ddclient | grep cron /usr/share/doc/ddclient-3.7.1/sample-etc_cron.d_ddclient [root@bigboy tmp]#

2. Copy the file to the /etc/cron.d directory.

[root@bigboy tmp]# cp /usr/share/doc/ddclient-3.7.1/sample-etc_cron.d_ddclient /etc/cron.d/ddclient.cron

3. Edit the file and uncomment the cron entries,

[root@bigboy tmp]# vi /etc/cron.d/ddclient.cron

4. Restart cron.

[root@bigboy tmp]# systemctl restart crond.service

This simple modification will allow you to sleep at night without worrying whether ddclient is working correctly!

You can test your dynamic DNS by:

• Looking at the status page of your DNS provider and making sure the IP address that matches your www site is the same as your router/firewall's public IP address.
• Using the “host www.my-site.com” command from your Linux command prompt to determine whether you are getting a valid response. If you failed to add your host record, you will get an error message like:

[root@bigboy tmp]# host www.my-site.com

Server: 127.0.0.1
Address: 127.0.0.1#53

• * server can't find www.my-site.com: NXDOMAIN

This error could be because your domain hasn't propagated fully throughout the Internet. You can test to make sure everything is okay by forcing NS lookup to query the name servers directly. The example below queries the miniDNS name server ns1.minidns.net:

[root@bigboy tmp]# host www.my-site.com ns1.minidns.net
www.my-site.com has address 97.158.253.26
[root@bigboy tmp]#

Always remember that dynamic DNS works, but it is frequently unreliable as residential class broadband data circuits are not monitored, maintained, or managed as closely as business class lines. It is a good starting place to help you become familiar with Web hosting, but as your Web site becomes busier and more financially important to you, you may need to consider a regular data center far away from spilt coffee and the washing machine that always trips the circuit breakers.