Now you need to make sure that you can do a host query on all your home network's PCs and get their correct IP addresses. This is very important if you are running a mail server on your network, because sendmail typically relays mail only from hosts whose IP addresses resolve correctly in DNS. NFS, which is used in network-based file access, also requires valid reverse lookup capabilities.
This is an example of a zone file for the 192.168.1.x network. All the entries in the first column refer to the last octet of the IP address for the network, so the IP address 192.168.1.100 points to the name bigboy.my-site.com.
Notice how the main difference between forward and reverse zone files is that the reverse zone file only has PTR and NS records. Also the PTR records cannot have CNAME aliases.
Filename
192-168-1.zone
;
; Zone file for 192.168.1.x
;
$TTL 3D
@ IN SOA www.my-site.com. hostmaster.my-site.com. (
200303301 ; serial number
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
NS www ; Nameserver Address
100 PTR bigboy.my-site.com.
103 PTR smallfry.my-site.com.
102 PTR ochorios.my-site.com.
105 PTR reggae.my-site.com.
32 PTR dhcp-192-168-1-32.my-site.com.
33 PTR dhcp-192-168-1-33.my-site.com.
34 PTR dhcp-192-168-1-34.my-site.com.
35 PTR dhcp-192-168-1-35.my-site.com.
36 PTR dhcp-192-168-1-36.my-site.com.
I included entries for addresses 192.168.1.32 to 192.168.1.36, which are the addresses the DHCP server issues. SMTP mail relay wouldn't work for PCs that get their IP addresses via DHCP if these lines weren't included.
You may also want to create a reverse zone file for the public NAT IP addresses for your home network. Unfortunately, ISPs won't usually delegate this ability for anyone with less than a Class C block of 256 IP addresses. Most home DSL sites wouldn't qualify.
What You Need To Know About NAT And DNS
The previous examples assume that the queries will be coming from the Internet with the zone files returning information related to the external 97.158.253.26 address of the Web server.
What do the PCs on your home network need to see? They need to see DNS references to the real IP address of the Web server, 192.168.1.100, because NAT won't work properly if a PC on your home network attempts to connect to the external 97.158.253.26 NAT IP address of your Web server.
Don't worry. BIND has a way around this called views. The views feature allows you to force BIND to use predefined zone files for queries from certain subnets. This means it's possible to use one set of zone files for queries from the Internet and another set for queries from your home network.
Here's a summary of how it's done:
1) Place your zone statements in the /etc/named.conf file in one of two views sections. The first section is called internal and lists the zone files to be used by your internal network. The second view called external lists the zone files to used for Internet users.
For example; you could have a reference to a zone file called my-site.zone for lookups related to the 97.158.253.X network which Internet users would see. This /etc/named.conf entry would be inserted in the external section. You could also have a file called my-site-home.zone for lookups by home users on the 192.168.1.0 network. This entry would be inserted in the internal section. Creating the my-site-home.zone file is fairly easy: Copy it from the my-site.zone file and replace all references to 97.158.253.X with references to 192.168.1.X.
2) You must also tell the DNS server which addresses you feel are internal and external. To do this, you must first define the internal and external networks with access control lists (ACLs) and then refer to these lists within their respective view section with the match-clients statement. Some built-in ACLs can save you time:
•
o localhost: Refers to the DNS server itself
o localnets: Refers to all the networks to which the DNS server is directly connected
o any: which is self explanatory.
Note: You must place your localhost, 0.0.127.in-addr.arpa and "." zone statements in the internal views section. Remember to increment your serial numbers!
Here is a sample configuration snippet for the /etc/named.conf file I use for my home network. All the statements below were inserted after the options and controls sections in the file.
// ACL statement
acl "trusted-subnet" { 192.168.17.0/24; };
view "internal" { // What the home network will see
match-clients { localnets; localhost; "trusted-subnet"; };
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
// IPv6 Support
zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
type master;
file "named.ip6.local";
allow-update { none; };
};
// Prevents lookups for broadcast addresses ending in ".255"
zone "255.in-addr.arpa" IN {
type master;
file "named.broadcast";
allow-update { none; };
};
// Prevents lookups for network addresses ending in ".0"
zone "0.in-addr.arpa" IN {
type master;
file "named.zero";
allow-update { none; };
};
zone "1.168.192.in-addr.arpa" IN {
type master;
file "192-168-1.zone";
allow-update { none; };
};
zone "my-site.com" {
type master;
notify no;
file "my-site-home.zone";
allow-query { any; };
};
zone "another-site.com" {
type master;
notify no;
file "another-site-home.zone";
allow-query { any; };
};
};
view "external" { // What the Internet will see
match-clients { any; };
recursion no;
zone "my-site.com" {
type master;
notify no;
file "my-site.zone";
allow-query { any; };
};
zone "another-site.com" {
type master;
notify no;
file "another-site.zone";
allow-query { any; };
};
};
In this example I included an ACL for network 192.168.17.0 /24 called trusted-subnet to help clarify the use of ACLs in more complex environments. Once the ACL was defined, I then inserted a reference to the trusted-subnet in the match-clients statement in the internal view. So in this case the local network (192.168.1.0 /24), the other trusted network (192.168.17.0), and localhost get DNS data from the zone files in the internal view. Remember, this is purely an example. The example home network doesn't need to have the ACL statement at all as the built in ACLs localnets and localhost are sufficient. The network won't need the trusted-subnet section in the match-clients line either.
Loading Your New Configuration Files
To load your new configuration files, first make sure your file permissions and ownership are okay in the /var/named directory.
[root@bigboy tmp]# cd /var/named
[root@bigboy named]# ll
total 6
-rw-r--r-- 1 named named 195 Jul 3 2001 localhost.zone
-rw-r--r-- 1 named named 2769 Jul 3 2001 named.ca
-rw-r--r-- 1 named named 433 Jul 3 2001 named.local
-rw-r--r-- 1 root root 763 Oct 2 16:23 my-site.zone
[root@bigboy named]# chown named *
[root@bigboy named]# chgrp named *
[root@bigboy named]# ll
total 6
-rw-r--r-- 1 named named 195 Jul 3 2001 localhost.zone
-rw-r--r-- 1 named named 2769 Jul 3 2001 named.ca
-rw-r--r-- 1 named named 433 Jul 3 2001 named.local
-rw-r--r-- 1 named named 763 Oct 2 16:23 my-site.zone
[root@bigboy named]#
The configuration files above will not be loaded until you issue the proper command to restart the named process that controls DNS, but be sure to increment your configuration file serial number before doing this.
[root@bigboy tmp]# service named restart
Take a look at the end of your /var/log/messages file to make sure there are no errors.
Make Sure Your /etc/hosts File Is Correctly Updated
Chapter 3, "Linux Networking", explains how to correctly configure your /etc/hosts file. Some programs, such as sendmail, require a correctly configured /etc/hosts file even though DNS is correctly configured.
Configure Your Firewall
The sample network assumes that the BIND name server and Apache Web server software run on the same machine protected by a router/firewall. The actual IP address of the server is 192.168.1.100, which is a private IP address. You'll have to use NAT for Internet users to be able to gain access to the server via the chosen public IP address, namely 97.158.253.26. If your firewall is a Linux box, you may want to consider taking a look at Chapter 14, "Linux Firewalls Using iptables", describes how to do the network address translation and allow DNS traffic through to your name server.
Fix Your Domain Registration
Remember to edit your domain registration for my-site.com, or whatever it is, so that at least one of the name servers is your new name server (97.158.253.26 in this case). Domain registrars, such as VeriSign and RegisterFree, usually provide a Web interface to help you manage your domain.
Once you've logged in with the registrar's username and password, you'll have take two steps:
1) Create a new name server record entry for the IP address 97.158.253.26 to map to ns.my-site.com or www.my-site.com or whatever your name server is called. (This screen prompts you for both the server's IP address and name.)
2) Assign ns.my-site.com to handle your domain. This screen will prompt you for the server name only.
Sometimes, the registrar requires at least two registered name servers per domain. If you only have one, then you could either create a second name server record entry with the same IP address, but different name, or you could give your Web server a second IP address using an IP alias, create a second NAT entry on your firewall and then create the second name server record entry with the new IP address, and different name.
It normally takes about three to four days for your updated DNS information to be propagated to all 13 of the world's root name servers. You'll therefore have to wait about this amount of time before starting to notice people hitting your new Web site.
You can use the chapter's troubleshooting section to test specific DNS servers for the information they have on your site. You'll most likely want to test your new DNS server, which should be up to date, plus a few well known ones, which should have delayed values.
Troubleshooting BIND
One of the most common culprits of BIND problems is incorrectly located chroot files. If you have the BIND chroot package installed, make sure the configuration files are located in the chroot directory.
Here's quick list of symptoms that indicate your files may not be located correctly
• The named daemon starts without loading any zone files. Here is a sample of the /var/log/messages file which shows that named doesn't load them.
Nov 9 17:35:41 bigboy named[1157]: starting BIND 9.2.3 -u named -t /var/named/chroot
Nov 9 17:35:41 bigboy named[1157]: using 1 CPU
Nov 9 17:35:41 bigboy named[1157]: loading configuration from '/etc/named.conf'
Nov 9 17:35:41 bigboy named[1157]: listening on IPv4 interface lo, 127.0.0.1#53
Nov 9 17:35:41 bigboy named[1157]: listening on IPv4 interface eth0, 10.41.32.71#53
Nov 9 17:35:41 bigboy named[1157]: command channel listening on 127.0.0.1#953
Nov 9 17:35:41 bigboy named[1157]: command channel listening on ::1#953
Nov 9 17:35:41 bigboy named[1157]: running
• Restarting named gives rndc "connect failed" messages:
[root@bigboy tmp]# service named restart
Stopping named: rndc: connect failed: connection refused
[ OK ]
Starting named: [ OK ]
[root@bigboy tmp]#
• The chroot files are empty
[root@bigboy tmp]# cat /var/named/chroot/etc/named.conf
[root@bigboy tmp]# cat /var/named/chroot/etc/rndc.key
[root@bigboy tmp]#
To correctly relocate the files:
1) Copy the /etc/rndc.* and /etc/named.conf files to the /var/named/chroot/etc/ directory
[root@bigboy tmp]# cp -f /etc/rndc.* /var/named/chroot/etc/
[root@bigboy tmp]# cp /etc/named.conf /var/named/chroot/etc/
2) Restart named twice, it should now shutdown correctly without error the second time.
[root@bigboy tmp]# service named restart
Stopping named: rndc: connect failed: connection refused
[ OK ]
Starting named: [ OK ]
[root@bigboy tmp]# service named restart
Stopping named: [ OK ]
Starting named: [ OK ]
[root@bigboy tmp]#
3) Check your /var/log/messages file for the loading of the zone files.
...
...
Nov 9 17:36:34 bigboy named[1180]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
Nov 9 17:36:34 bigboy named[1180]: zone localhost/IN: loaded serial 42
Nov 9 17:36:34 bigboy named[1180]: running
Nov 9 09:36:35 bigboy named: named startup succeeded
...
...
General Troubleshooting Steps
Once this is completed, you can continue with the following troubleshooting steps:
1) Determine whether your DNS server is accessible on DNS UDP/TCP port 53. Lack of connectivity could be caused by a firewall with incorrect, permit, NAT, or port forwarding rules to your DNS server. Failure could also be caused by the named process being stopped. It is best to test this from both inside your network and from the Internet.
Troubleshooting with TELNET is covered in Chapter 4, "Simple Network Troubleshooting".
2) Linux status messages are logged to the file /var/log/messages. Use it to make sure all your zone files are loaded when you start BIND/named. Check your /etc/named.conf file if they fail to do so. (Linux logging is covered in Chapter 5, "Troubleshooting Linux with syslog".
Feb 21 09:13:13 bigboy named: named startup succeeded
Feb 21 09:13:13 bigboy named[12026]: loading configuration from '/etc/named.conf'
Feb 21 09:13:13 bigboy named[12026]: no IPv6 interfaces found
Feb 21 09:13:13 bigboy named[12026]: listening on IPv4 interface lo, 127.0.0.1#53
Feb 21 09:13:13 bigboy named[12026]: listening on IPv4 interface wlan0, 192.168.1.100#53
Feb 21 09:13:13 bigboy named[12026]: listening on IPv4 interface eth0, 172.16.1.100#53
Feb 21 09:13:14 bigboy named[12026]: command channel listening on 127.0.0.1#953
Feb 21 09:13:14 bigboy named[12026]: zone 0.0.127.in-addr.arpa/IN: loaded serial 1997022700
Feb 21 09:13:14 bigboy named[12026]: zone 1.16.172.in-addr.arpa/IN: loaded serial 51
Feb 21 09:13:14 bigboy named[12026]: zone 1.168.192.in-addr.arpa/IN: loaded serial 51
Feb 21 09:13:14 bigboy named[12026]: zone simiya.com/IN: loaded serial 2004021401
Feb 21 09:13:14 bigboy named[12026]: zone localhost/IN: loaded serial 42
Feb 21 09:13:14 bigboy named[12026]: zone simiya.com/IN: loaded serial 200301114
Feb 21 09:13:14 bigboy named[12026]: running
3) Use the host (nslookup in Windows) command for both forward and reverse lookups to make sure the zone files were configured correctly.
If this fails, try:
• Double check for your updated serial numbers in the modified files and also inspect the individual records within the files for mistakes.
• Ensure there isn't a firewall that could be blocking DNS traffic on TCP and/or UDP port 53 between your server and the DNS server.
• Use the dig command to determine whether the name server for your domain is configured correctly.
Here is an example of querying DNS server ns1.my-site.com for the IP address of www.linuxhomenetworking.com. (You can also replace the name server's name with its IP address.)
[root@bigboy tmp]# host www.linuxhomenetworking.com ns1.my-site.com
Using domain server:
Name: ns1.my-site.com
Address: 192.168.1.100#53
Aliases:
www.linuxhomenetworking.com has address 65.115.71.34
[root@bigboy tmp]#
Here is an example of querying your default DNS server for the IP address of www.linuxhomenetworking.com. As you can see, the name of the specific DNS server to query has been left off the end. Failure in this case could be due not only to an error on your BIND configuration or domain registration but also to an error in your DNS client's DNS server entry in your Linux /etc/resolv.conf file or the Windows TCP/IP properties for your NIC.
[root@bigboy tmp]# host www.linuxhomenetworking.com
www.linuxhomenetworking.com has address 65.115.71.34
[root@bigboy tmp]#
4) You can also use the dig command to determine whether known DNS servers on the Internet have received a valid update for your zone. (Remember if you decide to change the DNS servers for your domain that it could take up to four days for it to propagate across the Internet.)
The format for the command is:
dig
The name server is optional. If you specify a name server, then dig queries that name server instead of the Linux server's default name server. It is sometimes good to query both your name server, as well as a well known name server such as ns1.yahoo.com to make sure your DNS records have propagated properly. The dig command only works with fully qualified domain names only, because it doesn't refer to the /etc/resolv.conf file.
This command uses the local DNS server for the query. It returns the SOA record information and the addresses of the domain's DNS servers in the authority section.
[root@bigboy tmp]# dig linuxhomenetworking.com SOA
...
...
;; AUTHORITY SECTION:
linuxhomenetworking.com. 3600 IN NS ns1.myisp.net.
linuxhomenetworking.com. 3600 IN NS ns2.myisp.net.
;; ADDITIONAL SECTION:
ns1.myisp.net. 3600 IN A 65.115.70.68
ns2.myisp.net. 3600 IN A 65.115.70.69
...
...
[root@bigboy tmp]#
Here is a successful dig using DNS server ns1.yahoo.com for the query. As before, it returns the SOA record for the zone.
[root@bigboy tmp]# dig ns1.yahoo.com linuxhomenetworking.com SOA
...
...
;; AUTHORITY SECTION:
linuxhomenetworking.com. 3600 IN NS ns2.myisp.net.
linuxhomenetworking.com. 3600 IN NS ns1.myisp.net.
;; ADDITIONAL SECTION:
ns1.myisp.net. 3600 IN A 65.115.70.68
ns2.myisp.net. 3600 IN A 65.115.70.69
...
...
[root@bigboy tmp]#
Sometimes your SOA dig will fail. This command uses the DNS server ns1.yahoo.com for the query. In this case the authority section doesn't know of the domain and points to the name server for the entire .com domain at VeriSign.
[root@bigboy tmp]# dig ns1.yahoo.com linuxhomeqnetworking.com SOA
...
...
;; QUESTION SECTION:
;linuxhomeqnetworking.com. IN SOA
;; AUTHORITY SECTION:
com. 0 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1077341254 1800 900 604800 900
...
...
[root@bigboy tmp]#
Possible causes of failure include:
• Typographical errors. In this case the misspelling "linuxhomeqnetworking.com" was entered on the command line.
• Incorrect domain registration.
• Correct domain registration, but there is a lag in the propagation of the domain information across the Internet. Delays of up to four days are not uncommon.
• A firewall could be blocking DNS traffic on TCP and/or UDP port 53 between your server and the DNS server.
Migrating Your Web Site In-House
It is important to have a detailed migration plan if you currently use an external company to host your Web site and wish to move the site to a server at home or in your office. At the very least your plan should include these steps:
1. There is no magic bullet that will allow you to tell all the caching DNS servers in the world to flush their caches of your zone file entries. Your best alternative is to request your existing service provider to set the TTL on my-site.com in the DNS zone file to a very low value, say one minute. As the TTL is usually set to a number of days, it will take at least three to five days for all remote DNS servers to recognize the change. Once the propagation is complete, it will take only one minute to see the results of the final DNS configuration switch to your new server. If anything goes wrong, you can then revert to the old configuration, knowing it will rapidly recover within minutes rather than days.
2. Set up your test server in house. Edit the /etc/hosts file to make www.my-site.com refer to its own IP address, not that of the www.my-site.com site that is currently in production. This file is usually given a higher priority than DNS, therefore the test server will begin to think that www.my-site.com is really hosted on itself. You may also want to add an entry for mail.my-site.com if the new Web server is going to also be your new mail server.
3. Test your server based applications from the server itself. This should include mail, Web, and so on.
4. Test the server from a remote client. You can test the server running as www.my-site.com even though DNS hasn't been updated. Just edit your /etc/hosts file on your Web browsing Linux PC to make www.my-site.com map to the IP address of the new server. In the case of Windows, the file would be C:\WINDOWS\system32\drivers\etc\hosts. You may also want to add an entry for mail.my-site.com if the new Web server is going to also be your new mail server. Your client will usually refer to these files first before checking DNS, hence you can use them to predefine some DNS lookups at the local client level only.
5. Once testing is completed, coordinate with your Web hosting provider to update your domain registration's DNS records for www.my-site.com to point to your new Web server. As the TTLs were set to one minute previously, you'll be able to see results of the migration within minutes.
6. Once complete, you can set the TTL back to the original value to help reduce the volume of DNS query traffic hitting your DNS server.
7. Fix your /etc/hosts files by deleting the test entries you had before.
8. You may also want to take over your own DNS. Edit your my-site.com DNS entries with VeriSign, RegisterFree or whoever you bought your domain from to point to your new DNS servers.
Remember, you don't have to host DNS or mail in-house, this could be left in the hands of your service provider. You can then migrate these services in-house as your confidence in hosting becomes greater.
Finally, if you have concerns that your service provider won't cooperate, then you could explain to the provider that you want to test its failover capabilities to a duplicate server that you host in-house. You can then decide whether the change will be permanent once you have failed over back and forth a few times.
DHCP Considerations For DNS
If you have a DHCP server on your network, you'll need to make it assign the IP address of the Linux box as the DNS server it tells the DHCP clients to use. If your Linux box is the DHCP server, then you may need to refer to Chapter 8, "Configuring the DHCP Server".
Simple DNS Security
DNS can reveal a lot about the nature of your domain. You should take some precautions to conceal some of the information for the sake of security.
Zone Transfer Protection
The host command does one DNS query at a time, but the dig command is much more powerful. When given the right parameters it can download the entire contents of your domain's zone file.
In this example, the AFXR zone transfer parameter is used to get the contents of the my-site.com zone file.
[root@smallfry tmp]# dig my-site.com AXFR
; <<>> DiG 9.2.3 <<>> my-site.com AXFR
;; global options: printcmd
my-site.com. 3600 IN SOA www.my-site.com. hostmaster.my-site.com. 2004110701 3600 3600 3600 3600
my-site.com. 3600 IN NS ns1.my-site.com.
my-site.com. 3600 IN MX 10 mail.my-site.com.
192-168-1-96.my-site.com. 3600 IN A 192.168.1.96
192-168-1-97.my-site.com. 3600 IN A 192.168.1.97
192-168-1-98.my-site.com. 3600 IN A 192.168.1.98
bigboy.my-site.com. 3600 IN A 192.168.1.100
gateway.my-site.com. 3600 IN A 192.168.1.1
localhost.my-site.com. 3600 IN A 127.0.0.1
mail.my-site.com. 3600 IN CNAME www.my-site.com.
ns1.my-site.com. 3600 IN CNAME www.my-site.com.
ntp.my-site.com. 3600 IN CNAME www.my-site.com.
smallfry.my-site.com. 3600 IN A 192.168.1.102
www.my-site.com. 3600 IN A 192.168.1.100
my-site.com. 3600 IN SOA www.my-site.com. hostmaster.my-site.com. 2004110701 3600 3600 3600 3600
;; Query time: 16 msec
;; SERVER: 192.168.1.100#53(192.168.1.100)
;; WHEN: Sun Nov 14 20:21:07 2004
;; XFR size: 16 records
[root@smallfry tmp]#
This may not seem like an important security threat at first glance, but it is. Anyone can use this command to determine all your server's IP addresses and from the names determine what type of server it is and then launch an appropriate cyber attack.
In a simple home network, without master and slave servers, zone transfers should be disabled. You can do this by applying the allow-transfer directive to the global options section of your named.conf file.
options {
allow-transfer {none;};
};
Once applied, your zone transfer test should fail.
[root@smallfry tmp]# dig my-site.com AXFR
...
...
; <<>> DiG 9.2.3 <<>> my-site.com AXFR
;; global options: printcmd
; Transfer failed.
[root@smallfry tmp]#
Selectively Disabling Recursion
Your caching DNS server can unknowingly participate in a form of DDoS attack if recursive lookups are globally allowed.
Say for example that for political, religious, competitive or otherwise malicious reasons your web site is targeted for an attack. First, a hacker breaks into the authoritative DNS server for a sub domain, like my-web-site.org, and adds a large TXT record to the sub domain. The hacker then sends thousands of queries to unsecured caching DNS servers requesting the TXT record, but there is a catch. The queries use a false source IP address that corresponds to the IP address of the DNS server for your website. The queries are small, but the responses are amplified by the size of the TXT information, and your DNS server quickly becomes overwhelmed by the flurry of replies. Without DNS, your web site goes off the air. For the administrator of the caching DNS servers, the additional load of the queries can be unnoticeable, but when multiplied by thousands of other poorly configured servers, the attack on your site becomes lethal.
The allow-recursion directive placed in the options section of your named.conf file can be used to restrict the networks to which recursive lookups are allowed. In this example an ACL is also used to limit lookups to localhost and the 192.168.1.0/24 network.
acl "recursive_subnets" {
192.168.1.0/24;
localhost;
};
options {
allow-recursion { "recursive_subnets"; };
};
Note: This does not restrict forward or reverse lookups defined by the zone files on the server. The server will answer all queries for my-web-site.org if it owns that domain, but it won't respond to queries for servers in another domain such as google.com.
Naming Convention Security
Your my-site.com domain will probably have a www and a mail subdomain, and they should remain obvious to all. You may want to adjust your DNS views so that to external users, your MySQL database server doesn't have the letters "DB" or "SQL" in the name, or that your firewall doesn't have the letters "FW" in its name either. This may good for ease of reference within the company, but to the Internet these names provide rapid identifiaction of the types of malicious exploits a hacker could use to break in. Web site security refers to anything that helps to guarantee the availability of the site, this is just one of many methods you can use.
Conclusion
DNS management is a critical part of the maintenance of any Web site. Fortunately, although it can be a little complicated, DNS modifications are usually infrequent, because the IP address of a server is normally fixed or static. This is not always the case. There are situations in which a server's IP address will change unpredictably and frequently, making DNS management extremely difficult. Dynamic DNS was created as a solution to this and is explained in Chapter 19, "Dynamic DNS".
No comments:
Post a Comment