کد:
http://articles.techrepublic.com.com/5100-10878_11-6182671.html
Takeaway: As if deploying a DNS server isn't complicated enough, deploying DDNS can be an even bigger chore. Having to deal with manually editing configuration files makes it worse. Jack Wallen shows how to easily configure DDNS in Linux using Webmin.

This article is also available as a TechRepublic download.


 Deploying Dynamic DNS sounds like an ominous task, and for many, it is. The idea of hand-editing configuration files is akin to chewing off one's arm. But Dynamic DNS doesn't have to be that difficult. In fact, it isn't when you enlist the help of one of the most powerful, user-friendly Linux administration tools available: Webmin. In this article, we'll see how to set up DDNS using Webmin.
What are Webmin and DDNS?

Webmin has been around for quite some time and has, understandably, become one of the most popular tools for Linux administrators. Its simplicity, reliability, and flexibility make it a sure bet when needing services up and running fast.
By default, Webmin does not have a module to handle Dynamic DNS. It covers static DNS well, but in order to get your DNS dynamic you'll have to first install a third-party module. There are a few third-party modules available for Dynamic DNS. The one I have chosen is the b9ddns Webmin module. This article will introduce you to the b9ddns module.
Author's note

This article does not attempt to dig deeply into BIND or DNS. DNS, in and of itself, requires a wealth of understanding and would be best served by reading a BIND specific article. In summary, DDNS allows clients to dynamically make entries in the DNS server's lookup tables. This is especially important for such things as Active Directory. Even though Windows has its own DDNS server, you may choose to host DNS on a separate platform.
Also note, this and all other DDNS modules for Webmin are simply GUI interfaces for configuring the numerous BIND options (for both static and Dynamic DNS) so understanding the BIND options you need for your network topology is crucial.
Installation

I am going to assume you have Webmin already installed on the server that will act as the Dynamic DNS server. On that server, open up your browser and download the Bind 9 Dynamic DNS module for Webmin. Now point your browser to the servers hosting DDNS and go to the Webmin control panel. You'll have to log in as the root user with the root users' password.
After you log in, expand the Webmin menu, as shown in Figure A. Press the Webmin Modules button.
Figure A

The information you see is just a summation of your server's hardware, OS, and Webmin version. Now select the Webmin Configuration link from the left navigation bar. In the right side of your browser, you'll see various configuration options, as shown in Figure B. Select the Webmin Modules link.
Figure B

Quite a few configuration options available for Webmin. Choose the Webmin Modules configuration option; this will open up the window that allows you to install modules, as seen in Figure C.
Figure C

You can use either the install from local file or install from uploaded file for our instance. Under Install Module, select From Uploaded File and press the Browse button. A new window, shown in Figure D, will open for you to navigate to the location of the b9ddns file you just downloaded.
Figure D

The GNOME Nautilus file choosing window should look familiar. Once you have located your file, press OK to return to the Webmin window. Now press the Install Module button and Webmin will do its thing.
When the installation finishes, expand the Servers menu. You'll see an entry for Bind 9 Dynamic DNS Server. Select the Bind 9 Dynamic DNS Server link to reveal the configuration options for your new DDNS server, as shown in Figure E.
Figure E

There are many similarities between the b9ddns module and the standard DNS module. It's not until you start poking around the module until you discover the true differences between b9ddns and the normal DNS Webmin modules.
Global options

One of the first configurations you'll want to take care of is Other DNS Name Servers. At first glimpse, you'll instantly see the difference between the b9ddns module and the DNS module as shown in Figure F. If not, Figure G will remind you of the standard DNS modules Other DNS Name Server configuration options.
Figure F

At first, you'll only see configuration for one server. Figure G

The configuration options for the standard DNS server do not include EDNS, Incremental Transfers, or DNS key options. This configuration screen deals with the servers that BIND will communicate zone transfers to and from. As you can see, by default, there is only space for one server to be configured. Once you configure this first server, press Save and you'll be returned to the main module window. But if you select the Other DNS Name Servers configuration again you'll see space for another server.
This is very handy when your DDNS server needs to communicate to different servers in different ways. Let's say, for example, you have one server that is part of a large zone and another server that is part of a much smaller zone. It makes sense to employ use of the IXFER (incremental transfer) option on the larger zone to cut down on network traffic.
One of the oddities regarding this module is the use of Default. Often, as with the case of the request-ixfr option, there are only two options: Yes and No. If you have no idea what the default option is (in this case it is Yes), you may unwittingly leave default set, thinking the default options are always good for your systems. In this case, you could be wrong and your penalty will be a bottleneck in your network. So it is wise, when given the options Default, Yes, No, to chose either Yes or No.
You’ll notice in this configuration screen that there is a configuration for Use DNS Keys but there are no options. This is because no DNS Keys have been defined. You can use the gpg tool to generate your keys for the server. To find out how to do this, run the command man gpg from a terminal. You’ll have to export the generated key to each of your servers if you decide to use DNS Keys.
If you go back to the Other DNS Name Servers configuration aftercreating your DNS Key, your key will be listed, as shown in Figure H. Select that key and press the Save button.
Figure H

You can use a different key for each server; just make sure the right key is exported to the right server. Finally, here is a listing of the configuration options available in the Other DNS Name Servers configuration:

  • Server IP Address: The IP address of the DNS server the configuration is for.
  • Ignore Bogus Server: Servers can send out bogus DNS authority packets. If you do not select Yes for this option, your DDNS server will accept those bogus entries as real.
  • Use Extended DNS (EDNS) Options: Use the extended DNS protocol which allows more flags, labels, return codes. Defined by RFC 2671.
  • Transfer Format: You have two choices: Many Answers (the default and only supported by BIND 9) or One At A Time. The One At A Time format places a single record per message, whereas Many Answers places as many records as possible per message.
  • Maximum Transfers In: The maximum size (in bytes) allowed for each journal file. The default is unlimited.
  • Provide Incremental Zone Transfers: This defines if the DDNS server (the master) will respond to an IXFR request (only submit changes to the zone as opposed to the full details of the zone.) The default is yes.
  • Request Incremental Zone Transfers: Applies only to slave (secondary or client) zones and defines if a server will request IXFR (incremental transfer) or AXFR (full zone transfer.)

One of the module configurations that drastically differ is the Forwarding and Zone Transfers configuration. If you look at the Forwarding and Zone Transfers configuration from the original DNS module in Figure I and compare it to the same configuration in the b9ddns module in Figure J, you'll immediately see the difference.
Figure I

The original Forwarding and Zone Transfers configuration. Figure J

Forwarding and Zone Transfers, as seen from the DDNS module. Obviously, the biggest difference in the two configurations is that the DDNS module allows for the configuration of zone transfers both in and out. Also, the DDNS modules have configuration options for sending information to slaves. Let's take a look at these key configurations.
The first two configurations, Servers To Forward Queries To, and Lookup Directly If No Response From Forwardershould be fairly obvious. The next four configurations, dealing with Maximum Zone Transfer times, all set time outs for the transfer both in and out of data. The time values you see are defined in minutes, with a default time being 120 minutes.
The next configurations set up the Maximum amount of concurrent zone transfers in and out the server will accept (default is 10). The Zone Transfer Format is the same configuration option as used in the Other DNS configuration option (many or one at a time). Providing and requesting incremental zone transfers to slaves and from masters allow you to determine exactly how the DNS information will flow on your system.
Below those configurations, you can further detail the flow of information by allowing zone transfers only from specified servers. If you select the default, your master will receive zone transfers from all servers offering them, as long as the above Request option is selected. The final configuration is allowing your Master to notify Slaves of changes. Similar to the Zone Transfer configuration, you can declare which servers will be sent changes from the master.
Ports and Addresses

Another configuration that differs is the Ports and Addresses configuration. In the original DNS module, the configuration is titled Addresses and Topology. In the b9ddns module, the configuration is titled Ports and Addresses. But the configuration differs in more than just name alone: The b9ddns module allows the addition of Ipv6 configurations. That is the only difference; but, depending on your network, that could make a vast difference.
Miscellaneous Options

One area that holds some very important configurations is the Miscellaneous Options, as shown in Figures K and L.
Figure K

The top portion of the Miscellaneous Options configuration. Figure L

The bottom section of the Miscellaneous Options configuration. Recursive lookups

Probably one of the most critical configurations for your DDNS server is held within the recursive lookups window. I'll give an example of how it works:
Let's say you're a local DNS server and you need information on the address of the server chimp.simian.monkeybusiness.net. The first thing you do is send broad queries to a root DNS server about the .net domain. The root DNS server returns to you information about the simian.monkeybusiness.net domain. You now know where the simian.monkeybusiness.net domain is so you can send queries to the simian.monkeybusiness.net domain to find the exact location of the server chimp. Since simian.monkeybusiness.net is an authoritative server for the monkeybusiness.net domain, it can respond with the exact IP address of the chimp server. Now you, the local server, can cache the address of chimp.simian.monkeybusiness.net so that when clients on your network request that address, they will have the address right away.
That is a recursive lookup.
Because of both security issues and performance hits, only use recursive lookups for domains your server is authoritative for. If you choose to allow recursive lookups, only allow them from specific addresses or domains. If you enable recursion, then any DNS server outside of your domain can hit your master server with a recursive search. There are instances when this could be necessary. Say, for example, another network has to communicate with yours. If the master DNS server on the other network needs recursive lookups to locate specific machines, then allow that specific server to do recursive lookups.
Another useful configuration with the Miscellaneous Options deals with blackhole lists. A blackhole list is a list of IP addresses that should be avoided. In the Blackhole Queries to and from section of Miscellaneous Options you have two options: Default and Listed. The Default option is None, which does you no good if you know of addresses to avoid. In order to list those addresses press the Listed options and enter the addresses in the available text area. Notice the Webmin module does not differentiate between to and from addresses; they are all included in the same listing.
Caching

Finally we deal with negative and positive caching TTL. This is probably one of the most important configurations for you Dynamic DNS server. What these configurations do is tell your DNS server how long to retain both positive (positive answers to queries) and negative (negative answers to queries) caching.
For example, if your DNS server queries simian.monkeybusiness.net for chimp and is returned a positive answer (an IP address), your DNS server will cache that address for the time defined in this configuration. The same holds true for negative answers (say, if your DNS server is told there is no match for chimp.simian.monkeybusiness.net). The default for this option is seven days.
Of course, a network can change a lot in seven days. If you find yourself having a lot of problems with clients resolving names, you might want to change this option to a much short period (on both positive and negative caching).
Entropy sources

Another security issue is entropy source. If you look back to Figure K, you'll notice a configuration labeled Entropy Source For Server. The DNS server requires a source of entropy in order to perform certain DNS Security (DNSSEC) operations. These operations require random devices which, by default, are found in /dev/random or can use the random-device option from named.conf(syntax for this option is random-device quoted_string). If you decide to use the random-device BIND option, enter your string in the Options text field.
Controlling the name server

Finally one of the last things to take care of -- also one of the biggest differences between controlling DNS and DDNS in Webmin -- is to start the BIND server. If you take a look at Figure L, you'll notice that not only can you stop and start the BIND server, but you can also flush the cache, reload different zones, and reconfigure the name server on various servers. This is one of the functions of the b9ddns module that will aid in a successful DDNS server.
Figure L

You'll know at a glance that your named server is running by looking here. There are many reasons that a DDNS server may need to have its cache flushed. One of the most obvious reasons is when networks change topology (or server change IP addresses). Without flushing a cache, the clients (or servers) will have no idea where the new locations are. Of course, you'll have set the server to flush its cache in the Miscellaneous Options under the Negative and Positive Cache TTL. But being able to flush the server's cache instantly will come in handy. Having the ability to instantly flush said cache will help keep your network from trying to send requests to servers that have changed addresses.
Final thoughts

Dynamic DNS is one of the more complex topics in networking. Having a thorough understanding of BIND is probably one of the more time-consuming practices you'll undertake. But having the ability to get your DDNS server up and running with the help of Webmin will ease that burden quite a bit. Now that you have an understanding of some of the more important aspects of b9ddns, you can implement this module into your own network topology



موضوعات مشابه: