|
HP OpenVMS Systems Documentation |
|
>
Compaq TCP/IP Services for OpenVMS
|
| Previous | Contents |
After starting the server, run the NTPQ program with the -n switch to avoid distractions because of name resolution problems. Use the peer command to display a list showing the status of configured peers and other clients trying to access the server. After operating for a few minutes, the display should look similar to the following:
NTPQ> peer
remote refid st t when poll reach delay offset jitter
=====================================================================
-isipc6.cairn.ne .GPS1. 1 u 18 64 377 65.592 -5.891 0.044
+saicpc-isiepc2. pogo.udel.edu 2 u 241 128 370 10.477 -0.117 0.067
+uclpc.cairn.net pogo.udel.edu 2 u 37 64 177 212.111 -0.551 0.187
*pogo.udel.edu .GPS1. 1 u 95 128 377 0.607 0.123 0.027
|
The host names or addresses shown in the remote column correspond to the server and peer entries listed in the configuration file; however, the DNS names might not agree if the names listed are not the canonical DNS names. The refid column shows the current source of synchronization; the st column shows the stratum; the t column shows the type ( u = unicast, m = multicast, l = local, - = don't know); and the poll column shows the poll interval in seconds. The when column shows the time (in seconds) since the peer was last heard, and the reach column shows the status of the reachability register (in octal) (see RFC 1305). The remaining entries show the latest delay, offset, and jitter (in milliseconds). Note that in NTP Version 4 what used to be the dispersion column has been replaced by the jitter column.
The symbol at the left margin displays the synchronization status of each peer. The currently selected peer is marked with an asterisk (*), while additional peers that are not currently selected but are designated acceptable for synchronization are marked with a plus sign (+). Peers marked with * and + are included in the weighted average computation to set the local clock; the data produced by peers marked with other symbols are discarded.
Additional details for each peer can be determined by the following procedure. First, use the associations command to display an index of association identifiers, as shown in the following example:
NTPQ> associations ind assID status conf reach auth condition last_event cnt =========================================================== 1 50252 f314 yes yes ok outlyer reachable 1 2 50253 f414 yes yes ok candidat reachable 1 3 50254 f414 yes yes ok candidat reachable 1 4 50255 f614 yes yes ok sys.peer reachable 1 |
Each line in this display is associated with the corresponding line in the preceding peer display. The assID column shows the unique identifier for each mobilized association, and the status column shows the peer status word (in hexadecimal), as defined in the NTP specification.
Next, use the readvar command and the respective assID identifier to display a detailed synopsis for the selected peer, as shown in the following example:
NTPQ> readvar 50253 status=f414 reach, conf, auth, sel_candidat, 1 event, event_reach, srcadr=saicpc-isiepc2.cairn.net, srcport=123, dstadr=140.173.1.46, dstport=123, keyid=3816249004, stratum=2, precision=-27, rootdelay=10.925, rootdispersion=12.848, refid=pogo.udel.edu, reftime=bd11b225.133e1437 Sat, Jul 8 2000 13:59:01.075, delay=10.550, offset=-1.357, jitter=0.074, dispersion=1.444, reach=377, valid=7, hmode=1, pmode=1, HPoll=6, ppoll=7, leap=00, flash=00 ok, org=bd11b23c.01385836 Sat, Jul 8 2000 13:59:24.004, rec=bd11b23c.02dc8fb8 Sat, Jul 8 2000 13:59:24.011, xmt=bd11b21a.ac34c1a8 Sat, Jul 8 2000 13:58:50.672, filtdelay= 10.45 10.50 10.63 10.40 10.48 10.43 10.49 11.26, filtoffset= -1.18 -1.26 -1.26 -1.35 -1.35 -1.42 -1.54 -1.81, filtdisp= 0.51 1.47 2.46 3.45 4.40 5.34 6.33 7.28, |
A detailed explanation of the fields in this display are beyond the scope of this manual; however, most variables defined in the NTP Version 3 specification RFC 1305 are available, along with others defined for NTP Version 4. This example was chosen to illustrate one of the most complex configurations involving symmetric modes. As the result of debugging experience, the names and values of these variables might change from time to time.
A useful indicator of miscellaneous problems is the flash value, which reveals the state of the various sanity tests on incoming packets. There are currently eleven bits, one for each test, numbered from right to left, which is for test 1. If the test fails, the corresponding bit is set to 1 and 0. If any bit is set following each processing step, the packet is discarded.
The three lines identified as filtdelay , filtoffset , and filtdisp reveal the round-trip delay, clock offset and dispersion for each of the last eight measurement rounds (all in milliseconds). Note that the dispersion, which is an estimate of the error, increases as the age of the sample increases. From these data, it is usually possible to determine the incidence of severe packet loss, network congestion, and unstable local clock oscillators. Every case is unique; however, if one or more of the rounds show large values or change radically from one round to another, the network is probably congested or experiencing loss.
Once the server has set the local clock, it continuously tracks the discrepancy between local time and NTP time and adjusts the local clock accordingly. This adjustment consists of two components: time and frequency. Adjustments to time and frequency are determined automatically by the clock discipline algorithm, which functions as a hybrid phase/frequency feedback loop. The behavior of this algorithm is controlled carefully to minimize residual errors resulting from normal network jitter and frequency variations of the local clock hardware oscillator. However, when started for the first time, the algorithm may take some time to converge on the intrinsic frequency error of the host machine.
The state of the local clock itself can be determined using the readvar statement (without the argument), as shown in the following example:
NTPQ> readvar status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg, version="ntpd 4.0.99j4-r Fri Jul 7 23:38:17 GMT 2002 (1)", processor="i386", system="FreeBSD3.4-RELEASE", leap=00, stratum=2, precision=-27, rootdelay=0.552, rootdispersion=12.532, peer=50255, refid=pogo.udel.edu, reftime=bd11b220.ac89f40a Sat, Jul 8 2002 13:58:56.673, poll=6, clock=bd11b225.ee201472 Sat, Jul 8 2002 13:59:01.930, state=4, phase=0.179, frequency=44.298, jitter=0.022, stability=0.001, hostname="barnstable.udel.edu", publickey=3171372095, params=3171372095, refresh=3172016539 |
An explanation of most of these variables is in the RFC 1305 specification. The most useful variables are clock , which shows when the clock was last adjusted, and reftime , which shows when the server clock of refid was last adjusted. The mean millisecond time offset ( phase ) and deviation ( jitter ) monitor the clock quality, and the mean PPM frequency offset ( frequency ) and deviation ( stability ) monitor the clock stability and serve as useful diagnostic tools. NTP operators have found that these data represent useful environment and hardware alarms. If the motherboard fan or some hardware bit malfunctions, the system clock is usually the first to reflect these problems.
When nothing seems to happen in the peer display after several minutes, it might indicate a network problem. One common network problem is an access-controlled router on the path to the selected peer, or an access-controlled server using methods described in the Access Control Options section. Another common problem is that the server is down or is running in unsynchronized mode because of a local problem. Use the NTPQ program to look at the server variables in the same way you look at your own.
B.8.1.3 Special Problems
The frequency tolerance of computer clock oscillators can vary widely,
>
Appendix C
Configuring and Managing BIND Version 9
The Domain Name System (DNS) maintains and distributes information about Internet hosts. DNS consists of a heirarchical database containing the names of entities on the Internet, the rules for delegating authority over names, and mail routing information; and the system implementation that maps the names to Internet addresses.
In OpenVMS environments, DNS is implemented by the Berkeley Internet Name Domain (BIND) software. Compaq TCP/IP Services for OpenVMS implements a BIND server based on the Internet Software Consortium's (ISC) BIND Version 9.
This chapter contains the following topics:
This section serves as a review only and assumes you are acquainted with the InterNIC, that you applied for an IP address, and that you registered your domain name. You should also be familiar with BIND terminology, and you should have completed your preconfiguration planning before using this chapter to configure and manage the BIND software.
If you are not familiar with DNS and BIND, see the
Compaq TCP/IP Services for OpenVMS Concepts and Planning guide. If you need more in-depth knowledge, see
O'Reilly's DNS and BIND, Fourth Edition. You can find the
BIND 9 Adminstrator Reference Manual at
http://www.isc.org/
.
C.1.1 How the Resolver and Name Server Work Together
BIND is divided conceptually into two components: a resolver and a name server. The resolver is software that queries a name server; the name server is the software process that responds to a resolver query.
Under BIND, all computers use resolver code, but not all computers run the name server process.
The BIND name server runs as a distinct process called TCPIP$BIND. On
UNIX systems, the name server is called
named
(pronounced name-dee). Name servers are typically classified as master
(previously called primary), slave (previously called secondary), and
caching-only servers, depending on their configurations.
C.1.2 Common BIND Configurations
You can configure BIND in several different ways. The most common configurations are resolver-only systems, master servers, slave servers, forwarder servers, and caching-only servers. A server can be any of these configurations or can combine elements of these configurations.
Servers use a group of database files containing BIND statements and resource records. These files include:
A configuration file, TCPIP$BIND.CONF, contains statements that pull
all the database files together and governs the behavior of the BIND
server.
C.1.2.1 Master Servers
A master server is the server from which all data about a domain is derived. Master servers are authoritative, which means they have complete information about their domain and that their responses are always accurate.
To provide central control of host name information, the master server loads the domain's information directly from a disk file created by the domain administrator. When a new system is added to the network, only the database on the master server needs to be modified.
A master server requires a complete set of configuration files: zone,
reverse domain, configuration, hint, and loopback files.
C.1.2.2 Slave Servers
Slave servers receive authority and their database from the master server.
A particular domain's database file is called a zone file; copying this file to a slave server is called a zone file transfer. A slave server assures that it has current information about a domain by periodically transferring the domain's zone file. Slave servers are also authoritative for their domain.
Configuring a slave server is similar to configuring a master server. The only difference is that, for the slave server, you need to provide the name of the master server from which to transfer zone data.
If you create a master, slave, or forwarder server for the same domain on which your local host resides, you should reconfigure your BIND resolver so that it uses this system (LOCALHOST) as its name server. |
Slave servers require a configuration file, a hint file, and loopback
files.
C.1.2.3 Caching-Only Servers
Caching-only servers get the answers to all name service queries from other name servers. Once a caching server receives an answer to a query, it saves the information and uses it in the future to answer queries itself. Most name servers cache answers and use them in this way but a caching-only server depends on this for all its server information. It does not keep name server database files as other servers do. Caching-only servers are nonauthoritative, which means that their information is secondhand and can be incomplete.
Caching-only servers require a hint file and loopback files.
C.1.2.4 Forwarder Servers
The forwarding facility can be used to create a large, sitewide cache on a few servers, thereby reducing traffic over links to external name servers. Forwarder servers process requests that slave servers cannot resolve locally (for example, because they do not have access to the Internet).
Forwarding occurs on only those queries for which the server is not authoritative and for which it does not have the answer in its cache.
A master or slave server specifies a particular host to which requests outside the local zone are sent. This is a form of Internet courtesy that limits the number of hosts that actually communicate with the root servers listed in the ROOT.HINT file.
If you configure a forwarder server, you must provide the name of the
host to which requests outside your zones of authority are forwarded.
C.2 Security Considerations
BIND Version 9 provides the following security enhancements:
Access control lists (ACLs) are address match lists that you can set up and name for use in configuring the following options:
Using ACLs, you can control who can access your name server without cluttering your configuration files with huge lists of IP addresses.
It is a good idea to use ACLs and to control access to your server. Limiting access to your server by outside parties can help prevent unwanted use of your server.
Here is an example of how to apply ACLs properly:
// Set up an ACL named "bogusnets" that will block RFC1918 space,
// which is commonly used in spoofing attacks.
acl bogusnets { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24;
224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16;
};
// Set up an ACL called our-nets. Replace this with the real IP numbers.
acl our-nets { x.x.x.x/24; x.x.x.x/21; };
options {
...
...
allow-query { our-nets; };
allow-recursion { our-nets; };
...
blackhole { bogusnets; };
...
};
zone "example.com" {
type master;
file "example_com.db";
allow-query { any; };
};
|
This example allows recursive queries of the server from the outside, unless recursion has been previously disabled. For more information about how to use ACLs to protect your server, see Section C.5.2.
| Previous | Next | Contents |