How can I setup DNS and DHCP services on OpenLinux[tm] Server Release 3.1.1
by Federico G. Cigognini
Version 1.1
Contents
Objectives
The aim of this Back Office Solution Cookbook is to guide System
Administrators through the process of configuring two of the most
important services in IP Local Area Networks: Domain Name System (DNS)
and Dynamic Host Configuration Protocol (DHCP).
This Cookbook should allow the reader to understand the concepts behind
these two network services, and be able to setup a
Caldera OpenLinux Server 3.1.1 system to serve on a Local Area Network.
Moreover, by describing the procedures to configure clients, a simple
small-scale network can be setup in a short period of time.
Introduction
DNS
IP (or Internet Protocol) networks, like any other network, work on the
principle that each node (whether it is a workstation, network printer, or
a router) has a unique identifier. Specifically to IP, this identifier
is a 4-byte quantity (in the case of IPv4) known as the "IP Address," usually
represented in a human readable form as a series of four, 1 to 3 digit
numbers, separated by periods (or full-stops), as in:
192.168.100.1
The IP address is used to access a specific node on the network and its
functionality, for instance to print a document if it is a network printer.
On a small network it is quite easy to remember each node's IP address,
however as the size of the network increases, so does the complexity of
remembering bare numbers. For this reason almost all operating systems that
support IP networking also allow users to maintain a local database which
associates names, much easier to remember than numbers, with IP addresses.
This local database usually consists of a file called "hosts," and allows
accessing nodes on the network via their name rather than IP address,
eg.
# ftp fred
This solution has a limitation. Take for example a network with ten
nodes, eight of which are either workstations or servers. These will each
need to have a copy of the "hosts" database with their own, and the other
nine nodes' name <-> address associations. If an eleventh node is added to the
network, it will need to have its own copy of the "hosts" database, and
once an IP address is assigned to it, the other machines' "hosts" databases
will need to be modified to reflect this change. Maintenance of the "hosts"
databases increases, and manageability decreases, exponentially with the
addition of nodes on the network.
The Domain Name System (DNS) solves this limitation by providing a central
name <-> address association database. Each node on the network can be
instructed to query a central DNS server for the IP address associated to
a name (a process known as Resolution), rather than looking it up in
its internal "hosts" database. A change on the one DNS server will reflect
on all the nodes on the network, increasing manageability.
DHCP
The number of IP addresses available is limited (especially IPv4 addresses),
and unless the addresses used are private1
each one has an associated cost. For this reason, if a network doesn't have a
constant number of nodes, it may be desirable to have multiple hosts
"share" a single IP address. Obviously a single IP address cannot
be shared by two nodes at the same time, but if one node is taken off the
network, and its IP address is vacant, it may be desirable to have another
node that has just been placed on the network use that address.
The Dynamic Host Configuration Protocol (DHCP) provides a means of
"leasing" a range (or pool) of IP addresses. The most
common application of DHCP is on networks where a number of laptops are
added and removed throughout the day. In this case, the laptop user is
not concerned what the machine's IP address is, so long as services on
the network can be accessed for as long as required.
This document provides simple steps to configure Caldera OpenLinux
Server 3.1.1 systems to provide both DNS and DHCP services, also describing
how client systems can be configured to take advantage of these services.
The client systems currently covered are:
- Microsoft Windows 9x, ME, NT 4, 2000, XP
- Caldera OpenLinux Workstation 3.1.1
Other systems may have different configuration processes, for those systems
consulting the relative documentation is advisable.
Requirements
Hardware
The use of Caldera OpenLinux Server 3.1.1 to provide the services documented
in this Back Office Cookbook does not require additional hardware, other
than that used for any network server.
In order to test the configurations detailed below, at least one client system
is needed. The client system should be networked, the sanity of the network
infrastructure and client's connectivity to the server should be tested
before attempting to follow these instructions.
NOTE: Although neither DNS and DHCP are dependent on the protocol
at the Data Link Layer (Layer 2) of the ISO/OSI Reference Model
(eg. Ethernet, Token Ring, FDDI), the configurations detailed in this document
have only been tested on an Ethernet network. 2
Software
The main assumption made in this Back Office Solutions Cookbook is that the
system in use is a "standard" Caldera OpenLinux Server 3.1.1 which
has been installed with either "All Packages" or the "Network Server"
profiles. A "standard" Caldera OpenLinux Server 3.1.1 system
is one on which all packages installed are those distributed on the
Caldera OpenLinux Server 3.1.1 media. No previous attempt should have
been made to configure either of the services described in this
Back Office Solutions Cookbook. Any system that does not fall into
this classification may fail to produce expected results.
Names of packages used to test the configurations outlined in this
Back Office Solutions Cookbook and their respective versions are listed in
the table below. These packages should be installed on the system to
be configured.
Package availability and the respective versions can be checked with the
following command:
# rpm -q <package name>
Required Packages |
Package Name |
Version |
bind |
8.2.3-5 |
bind-doc |
8.2.3-5 |
bind-utils |
8.2.3-5 |
dhcp |
3.0b2pl9-10 |
dhcp-server |
3.0b2pl9-10 |
webmin |
0.89-4 |
In order to access the Webmin[tm] configuration framework log onto KDE and select
K -> Webmin
Alternatively start up a Netscape or Konqueror browser and point it to the URL:
https://<system name>:1000/
where <system name> is the name of the Caldera Open Linux 3.1.1 system.
Preparation
Understanding of the requirements depends on the reader's knowledge of the
basic concepts of IP networking. The documentation listed in the
Background Reading section, should be consulted
before proceeding.
All the necessary information should be gathered and the following criteria met.
- | No other DHCP server should be on the same
network as the test machine. |
A DHCP client generally sends a broadcast request requesting for an
IP address to be leased to it. The presence of multiple DHCP servers
on a single network may yield unpredictable results. |
- | DHCP clients and servers should be on the same
physical network segment. |
Although this is not mandatory for either DNS or DHCP
configuring DHCP services over bridged networks may be a complicated
exercise, extending beyond the scope of this exercise. |
A checklist of the most common details that need to be known in advance is
also provided to assist in the preparation process, however more information
may be required depending on the specifics of the site.
DNS Checklist |
|
Domain Name |
|
eg. fredsdom.com |
|
Network Address |
. |
. |
. |
|
eg. 192.168.100.0 |
|
Client 1 IP Address |
. |
. |
. |
|
eg. 192.168.100.10 |
|
Client 1 Hostname |
|
eg. joe |
|
Client 2 IP Address |
. |
. |
. |
|
eg. 192.168.100.11 |
|
Client 2 Hostname |
|
eg. anne |
... |
|
Client n IP Address |
. |
. |
. |
|
eg. 192.168.100.n |
|
Client n Hostname |
|
eg. clientn |
|
DHCP Checklist |
|
DNS Server IP Address |
. |
. |
. |
|
eg. 192.168.100.1 |
|
DNS Server Subnet Mask |
. |
. |
. |
|
eg. 255.255.255.0 |
|
DNS Server Broadcast Address |
. |
. |
. |
|
eg. 192.168.100.255 |
|
First Address for Clients to Use |
. |
. |
. |
|
eg. 192.168.100.64 |
|
Last Address for Clients to Use |
. |
. |
. |
|
eg. 192.168.100.123 |
|
Default Gateway |
. |
. |
. |
|
eg. 192.168.100.254 |
|
Default Lease Duration |
|
eg. 14000 seconds |
|
Maximum Lease Duration |
|
eg. 36000 seconds |
|
NOTE: One further assumption made in this Back Office Cookbook is that
all the nodes are on a private network, protected against external access
by a firewall.
Background Reading
A brief description is provided for each service, however a previous
understanding of the basics is advisable.
Online Resources
http://pclt.cis.yale.edu/pclt/COMM/TCPIP.HTM
Introduction to TCP/IP (Yale University)
ftp://fddisunsite.oit.unc.edu/pub/docs/unix-tutorials/courses/dns.ps
The Domain Name Service (1992, University of West Ontario)
UnixWare 7 - Configuring Domain Name System (DNS) servers
(Caldera International Inc.)
Books
O'Reilly - TCP/IP Networking 2nd ed.
DNS - Domain Name System
This section describes the steps required to configure a Caldera OpenLinux Server 3.1.1
system as a name server (a server that provides DNS services). Networks managed
by name servers are subdivided into logical groups called "zones."
A zone can be used to associate a domain name (eg. fredsdom.com) to one or
more network subnets (eg. 192.168.100/24, 192.168.200/24, 192.168.300/24)
and vice versa, and a Name server can be configured to manage the zone according
to network layout and requirements.
There are different types of name servers, depending on how they manage a zone:
- Primary/Master -
A name server that is responsible for carrying out name resolution duties
for all nodes in a zone;
- Secondary/Slave -
A name server that acts as a backup for a primary name server, perhaps for
resilience, or for load-balancing;
- Forwarding-only/Caching-only -
A name server that forwards requests for a specific zone to another name server
maintaining a temporary cache which it will use to reply to further queries;
- Stub -
A name server that generally handles requests for a certain zone, but
forwards requests for its sub-zones (or child-zones) to a delegated name server;
A name server is not limited to one type (i.e. managing one zone). In fact the
majority of name servers active on the Internet manage multiple zones.
This document will focus on each type individually (where possible),
providing respective configuration examples.
Server-side Setup
DNS is a client-server communications mechanism. This section focuses on
how to setup a Caldera OpenLinux Server 3.1.1 to serve DNS services.
For the purpose of clarity, the following sample configuration will be used
throughout the examples:
Servers
Domain (1): fredsdom.com
Network Address (1): 192.168.100.0
Primary Name Server's Name: ns1.fredsdom.com
Primary Name Server's IP Address: 192.168.100.1
Secondary Name Server's Name: ns2.fredsdom.com
Secondary Name Server's IP Address: 192.168.100.2
Domain (2): uk.fredsdom.com
Network Address (2): 192.168.200.0
Domain Primary Name Server IP Address: 192.168.200.1
Clients
IP Address Node 1: 192.168.100.10
Hostname Node 1: joe.fredsdom.com
IP Address Node 2: 192.168.100.11
Hostname Node 2: anne.fredsdom.com
IP Address Node 3: 192.168.100.20
Hostname Node 3: printer1.fredsdom.com
IP Address Node 4: 192.168.200.15
Hostname Node 4: joe.uk.fredsdom.com
NOTE: For the Webmin sections, DNS server configuration can be accessed
by clicking on the Servers tab, and selecting the
"BIND DNS Server" option. When configuring a
"BIND DNS Server" for the first time Webmin requests whether the
name server should be:
- Setup for internal non-internet use only - recommended if the name server is located in
- Setup as an internet name server, and root server information downloaded;
- Setup as an internet name server, but using Webmin's older root
server information;
Each section begins with a line that states which of these three options
has been selected. When requested, select the option indicated, then
click on the
"Create Primary Configuration File and Start Nameserver"
pushbutton once. If the page does not refresh automatically, click on the
browser's "Reload" button to access the main configuration page.
The numbered steps begin from this page.
|
Configuring a Primary/Master Name Server
A primary name server stores a local copy of the DNS records for a
specific zone and answers queries for that zone
Step-by-Step Configuration (Webmin)
- "Setup nameserver for internal non-internet use only"
- Webmin will by default create two zones: "Root" and "127.0.0"
These are listed in the Existing DNS Zones section
- The "127.0.0" zone is required
- If this server needs to submit queries for the resolution of
names on other domains on the Internet, the "Root" zone
is also required, as it defines the list of public servers on the
Internet that answer queries for the root (or ".")
domain. If this is not required, the zone can be deleted by:
- Clicking on the Root zone icon
- Clicking on the Delete button in the
"Edit Root Zone" page
- Confirming by clicking on the Delete button in the
"Delete Zone" page
- Create the primary zone by clicking on "Create a new master zone"
- Create a "Forward" zone first (Names to Address)
- Fill in the appropriate information:
|
Domain name / Network |
fredsdom.com |
The domain name of this zone |
Records file |
Automatic |
Specifies the location of the name server's database
files |
Master server |
ns1.fredsdom.com |
the fully qualified domain name of the master name
server (hostname.domain) |
Add NS record for master server? |
Checked |
Adds a DNS record of type NS (Name Server) to
the database |
Email address |
root@ns1.fredsdom.com |
e-mail address of the person in charge of maintaining
the name server's configuration and who can be contacted in
case of problems |
Use zone template? |
No |
Requires zone templates to be created. The procedure is not
currently described in this document |
IP address for template records |
<Blank> |
May be used in conjunction with zone templates |
Refresh time |
10800 seconds |
Defines how long secondary/caching name servers will
keep this zone's records in their cache before refreshing
them |
Transfer retry time |
3600 seconds |
Defines the interval between a secondary/caching name
server's attempts to download a copy of this zone in case
the download fails |
Expiry time |
604800 seconds |
Defines how long the records will be considered valid by
a secondary/caching name server. After this time, that
name server will need to refresh its cache. If the refresh
fails, the caching name server will respond to queries by
indicating the data is no longer valid |
Default time-to-live |
38400 seconds |
Similar to the Expiry time but if the data cannot
be refreshed, the secondary/caching name server will reply
using its cached data (up to the Expiry time) |
- Once this is done, click on the "Create" button
- Create a "Reverse" zone (Address to Name)
- In the Edit Master Zone page, click on
"Return to zone list"
- The Existing DNS Zones section should now contain a
zone for the newly created domain (fredsdom.com)
- Click on "Create a new master zone"
- This time, select a zone type of "Reverse"
- Fill in the appropriate details:
|
Domain name / Network |
192.168.100 |
The network address. IMPORTANT NOTE: Only the
network part of the address should be entered, without
trailing dots, or zeros |
The remaining fields should be
filled in just as they were for the "Forward"
zone ... |
- Populate the primary zone
- In the Edit Master Zone page, click on
"Return to zone list"
- The Existing DNS Zones section should now contain both
the "Forward" and "Reverse" zones
- Click on the "Forward" zone to edit it
- In the Edit Master Zone page, click on "Address"
to start adding name -> address mappings
- Add the first record (this should be the name server's
information)
|
Name |
ns1.fredsdom.com |
The name of the node in question. NOTE: if the fully
qualified domain name (hostname.domain) is entered, it will be used. If only
the host part of the name is entered, the default domain name
will be automatically appended. |
Time-to-Live |
<Default> |
This specific record's time-to-live |
Address |
192.168.100.1 |
The node's IP Address |
Update reverse? |
Yes |
This automatically updates the "Reverse" zone,
adding an address -> name record |
- Click on the "Create" button to submit the entry.
The page should be refreshed, and the new record should be
listed below the data data entry box. If the page does not refresh
(nothing seems to happen) click on the browser's
"Refresh" button
- Repeat until all nodes have been added. Once the list is
complete, click on "Return to record types"
- Generally it may be desirable for certain nodes to have aliased
names. For example the name server itself, ns1.fredsdom.com could
also act as the mail server. Assigning an aliased name
mailer1.fredsdom.com to ns1.fredsdom.com would allow future changes
in the network infrastructure (eg. a new dedicated machine) to be
reflected in just a name server change. To add an alias:
- Click on "Name Alias"
- Fill in the form as appropriate
- Click on the "Create" button
- Once the list is complete, return to the previous page by
clicking on "Return to record types"
- An e-mail sent to nsadmin@ns.fredsdom.com will result in the
mail agent performing a name server lookup for the machine
ns.fredsdom.com. Once the name is resolved into an
IP address, the agent will attempt to connect directly to that
node and submit the e-mail to its nsadmin user. However,
the case of e-mail being sent to the user nsadmin@fredsdom.com
is different, as fredsdom.com is a domain name. The mail agent
will need to know where to send all e-mail for that domain, and to do
so a specific lookup for the domain's mail server record is carried out.
To add a mail server (or "mail exchange") record:
- Click on "Mail Server"
- In the Mail Server Records page fill in the fields:
|
Name |
fredsdom.com. |
The mail domain name of this zone.
IMPORTANT NOTE: note that the domain ends with a dot
("."). The domain entered in this field must
have a trailing dot |
Time-to-live |
<Default> |
The record's time to live |
Mail Server |
mail.fredsdom.com. |
The fully qualified domain name of the mail server (hostname.domain).
IMPORTANT NOTE: note that the fully qualified domain name must end with a dot
("."). Alternatively only the hostname part (without the dot) can be used,
in which case the default domain will be appended automatically |
Priority |
10 |
There may be more than one mail servers for one domain,
for resilience. The priority defines the
order in which these should be attempted (lowest number =>
higher priority => first attempted) |
- Click on "Create" to submit the changes
- Click on "Return to record types" once all mail
servers have been configured
- Now there should be sufficient information to run the server as the
primary name server for the fredsdom.com domain
- Click on "Return to zone list" to return to the
main BIND DNS Server configuration page
- Click on the "Apply Changes" button to submit the
changes and (re)start the name service
Configuring a Secondary/Slave Name Server
A secondary name server obtains a copy of the DNS records for a specific
zone form that zone's primary name server. This is most useful for
resilience, in case the primary name server suffers downtime
Step-by-Step Configuration (Webmin)
- "Setup nameserver for internal non-internet use only"
- Webmin will by default create two zones: "Root" and "127.0.0"
These are listed in the Existing DNS Zones section
- The "127.0.0" zone is required
- If this server needs to submit queries for the resolution of
names on other domains on the Internet, the "Root"
zone is also required, as it defines the list of public servers
on the Internet that answer queries for the root
(or ".") domain. If this is not required, the zone
can be deleted by:
- Clicking on the Root zone icon
- Clicking on the Delete button in the
"Edit Root Zone" page
- Confirming by clicking on the Delete button in the
"Delete Zone" page
- Create the secondary zone by clicking on "Create a new slave zone"
- Create a "Forward" zone first (Names to Address)
- Fill in the appropriate information:
|
Domain name / Network |
fredsdom.com |
The domain name of this zone |
Records file |
Automatic |
Specifies the location of the name server's database
files |
Master servers |
192.168.100.1 |
The IP address of the primary server |
- Click on the "Create" button to create the new zone
- At this stage a form to define the zone options should be
displayed in the lower section of the Edit Slave Zone form
- The fields are:
|
Master servers |
192.168.100.1 |
This field should contain the same data entered in the
previous form, i.e. the IP address of the zone's primary
domain name server |
Maximum transfer time |
Default |
The exchange of records between name servers occurs in
"transfers." If a transfer takes
longer than the time specified in this field to complete
it is forcibly terminated. The default is 120 minutes,
2 hours |
Records file |
/var/named/... ...fredsdom.com.hosts |
Should now display the pathname of the records file.
NOTE: This field should not normally be changed |
Check names? |
Default |
The server can check domain names based upon their
expected client contexts. The meanings of this field's
values are:
- ignore - no checking is done
- warn - checking is done, non compliance is logged
- fail - checking is done, non compliance is logged,
and the offending data is rejected
|
Notify slaves of changes ? |
Default |
This field makes sense if there is a hierarchy of name
servers. If this was a primary name server, it could
be instructed to inform its secondary (slave) name servers
of changed zones |
Allow updates from.. |
Default |
Specifies which hosts are allowed to submit Dynamic DNS
updates. By default, all updates will be rejected |
Allow transfers from.. |
Default |
This field can be used to list the IP addresses of name
servers that are allowed to receive record transfers from
this server. This can be used for security reasons. For
example to prevent other name servers from obtaining
records which would otherwise be "private," or
from slowing access to the server by flooding it with
transfer requests
|
Allow queries from.. |
Default |
Specifies which servers are allowed to submit queries to
this name server |
Also notify slaves.. |
<empty> |
Can be used to define a list of IP addresses of servers that
will be notified when a fresh zone is loaded |
- Save the configuration by clicking on "Save"
- As is the case for a primary name server, a "Reverse"
zone needs to be created by clicking on
"Create a new slave zone"
|
All fields should be filled in
as for the forward zone, with the exception of |
Domain name / Network |
192.168.100 |
The network address. IMPORTANT NOTE: Only the
network part of the address should be entered, without
trailing dots, or zeros |
- Once more options should be displayed in the lower section of
the Edit Slave Zone form. These should be filled as
the forward slave zone, and the changes applied by clicking on
the "Save" button
NOTE: the "Reverse Address" and
"Name Server" links, should display a number, (0) at
this stage. Once the configuration is committed by clicking on the
"Apply Changes" button in the BIND DNS Server form
the numbers should change respectively to the number of host reverse
entries, and name server entries in the primary server's database.
The same applies for the forward slave zone
- To verify that the zone transfer has occurred successfully, after
allowing sufficient time for the transfer to complete (this may
vary considerably depending on the number of records and the link
between the servers) click on the forward zone
("fredsdom.com") and check that the records of various
types have been populated
Configuring a Forwarding-only/Caching-only Name Server
A forwarding/caching-only name server is very useful in reducing traffic
across different branches of a network. Each time a query is sent to a
forwarding name server it will first attempt to reply using its cache
and if the information is not available (or the cache is "cold")
it queries another server higher up the hierarchy.
Another application for a forwarding name server may be in networks that
don't have direct access to the Internet, but resolution of external
names is still desirable
Step-by-Step Configuration (Webmin)
- "Setup as an internet name server, but use Webmin's older root server information"
- Webmin will by default create two zones: "Root" and "127.0.0"
These are listed in the Existing DNS Zones section
- Both these zones are required and should not be deleted
- Create the forwarding zone by clicking on "Create a new forward zone"
- Create a "Forward" zone first (Names to Address)
- Fill in the appropriate information:
|
Domain name / Network |
othersdom.com |
The domain name of the forwarding zone |
Master servers |
10.18.5.94 |
The IP addresses of the name servers this system will have
to query can be listed here. These need to be reachable
and configured to allow forwarding |
- Click on the "Create" button to create the new zone
- The Edit Forward Zone form should now be displayed
- The fields in the zone options are:
|
Master servers |
10.18.5.94 |
This field should reflect the entries made in the previous
form and may be used to modify the values |
Try other servers? |
Default |
This field has meaning only if the list of Master servers
has been populated. If set to Yes, the name server will
only ever forward queries to other name servers |
Check names? |
Default |
The server can check domain names based upon their
expected client contexts. The meanings of this field's
values are:
- ignore - no checking is done
- warn - checking is done, non compliance is logged
- fail - checking is done, non compliance is logged,
and the offending data is rejected
|
- Click on "Save" to submit the changes. The
"othersdom.com" zone should now be listed in the main
BIND DNS Server form
- Create the "Reverse" zone by clicking on
"Create a new forward zone"
- The reverse zone fields need to be filled in:
|
All fields should be filled in
as for the forward zone, with the exception of |
Domain name / Network |
10.18.5 |
The network address of the zone that corresponds to the
domain "othersdom.com"
IMPORTANT NOTE: Only the network part of the
address should be entered, without trailing dots, or
zeros |
- Click on "Create" to submit
- The "zone options" should be filled just as the
"Forward" zone, and submitted by clicking on
"Save"
- The changes should finally be made active by clicking on
"Apply Changes" in the BIND DNS Server form
Configuring a Stub Name Server
Certain networks can be quite large, spanning across several sites. A
company that has for example offices in the United States of America
the United Kingdom, and Australia may want to create different DNS zones,
"us.fredsdom.com" - "uk.fredsdom.com" -
"au.fredsdom.com" and delegate the name resolution for each
zone to a different name server. One or more central servers visible to
the company would then reroute queries to the zones' respective name
servers. This section describes how a stub zone can be created to
provide this functionality
Step-by-Step Configuration (Webmin)
- "Setup nameserver for internal non-internet use only"
- Webmin will by default create two zones: "Root" and "127.0.0"
These are listed in the Existing DNS Zones section
- The "127.0.0" zone is required
- If this server needs to submit queries for the resolution of
names on other domains on the Internet, the "Root" zone
is also required, as it defines the list of public servers on the
Internet that answer queries for the root (or ".")
domain. If this is not required, the zone can be deleted by:
- Clicking on the Root zone icon
- Clicking on the Delete button in the
"Edit Root Zone" page
- Confirming by clicking on the Delete button in the
"Delete Zone" page
- Create the zone by clicking on "Create a new stub zone"
- Create a "Forward" zone first (Names to Address)
- Fill in the appropriate information:
|
Domain name / Network |
uk.fredsdom.com |
The domain name of the stub zone |
Records file |
Automatic |
The files that will contain the name server's records
for this zone |
Master servers |
192.168.200.1 |
The IP address of the primary, secondary and additional
domain name servers for the zone |
- Click on "Create" to submit the details
- The Edit Forward Zone form should now be displayed
- The fields in the zone options are:
|
Master servers |
192.168.200.1 |
This field should reflect the entries made in the previous
form and may be used to modify the values |
Maximum transfer time |
Default |
The exchange of records between name servers occurs in
so called "transfers." If a transfer takes
longer than the time specified in this field to complete
it is forcibly terminated. The default is 120 minutes,
2 hours |
Records file |
/var/named/...
...uk.fredsdom.com.host |
The files that will contain the name server's records
for this zone |
Check names? |
Default |
The server can check domain names based upon their
expected client contexts. The meanings of this field's
values are:
- ignore - no checking is done
- warn - checking is done, non compliance is logged
- fail - checking is done, non compliance is logged,
and the offending data is rejected
|
Notify slaves of changes ? |
Default |
This field makes sense if there is a hierarchy of name
servers. If this was a primary name server, it could
be instructed to inform its secondary (slave) name servers
of changed zones |
Allow updates from.. |
Default |
Specifies which hosts are allowed to submit Dynamic DNS
updates. By default, all updates will be rejected |
Allow transfers from.. |
Default |
This field can be used to list the IP addresses of name
servers that are allowed to receive record transfers from
this server. This can be used for security reasons. For
example to prevent other name servers from obtaining
records which would otherwise be "private," or
from slowing access to the server by flooding it with
transfer requests
|
Allow queries from.. |
Default |
Specifies which servers are allowed to submit queries to
this name server |
Also notify slaves.. |
<empty> |
Can be used to define a list of IP addresses of servers that
will be notified when a fresh zone is loaded |
- Save the configuration by clicking on "Save"
- As is the case for a primary name server, a "Reverse"
zone needs to be created by clicking on
"Create a new stub zone"
|
All fields should be filled in
as for the forward zone, with the exception of |
Domain name / Network |
192.168.200 |
The network address of the stub zone. IMPORTANT NOTE: Only the
network part of the address should be entered, without
trailing dots, or zeros |
- Once more options should be displayed in the lower section of
the Edit Stub Zone form. These should be filled as
the forward slave zone, and the changes applied by clicking on
the "Save" button
- Finally click "Apply Changes" in the
BIND DNS Server form
Client-side Setup
This section describes the steps necessary to configure Windows
and Linux clients to take advantage of a DNS server on the network. The
main assumption made at this stage is that TCP/IP networking has already
been configured and works correctly, but no name server has been
configured. To verify this it is sufficient to ping a
machine on the network by its IP address, from a shell or the command
line interpreter (COMMAND.COM or CMD.EXE).
NOTE: Before proceeding with the configuration and testing, please
ensure that any Firewalling/Filtering software on the client is turned off.
The Operating System or product specific documentation can be consulted
later for information on how to fine-tune the Firewalling/Filtering
software to allow DNS resolution to work
Microsoft Windows clients
Windows 9x, ME
|
- Click on Start -> Settings -> Control Panel
- Double-click on Network
|
|
- Select "TCP/IP -> <network adapter>"
(where <network adapter> is the description
of the LAN card) and click on Properties
- Click on the DNS Configuration tab. All fields in
the form should be grayed out
|
|
- Click on "Enable DNS" It should now be possible to
modify the fields
- Fill in the "Host" and "Domain" fields
respectively with the client's own hostname, and the
DNS domainname
- If a DNS server is available, enter its IP address in
"DNS Server Search Order" and click on Add to
add it to the list. If the client has access to
multiple name servers these can all be added as detailed. The
first listed will be queried first
- It may be useful to enter the DNS domainname in the
"Domain Suffix Search Order" field. This will make
it possible to access nodes on the network by using only the
hostname, rather than having to specify the fully qualified
domain name (hostname.domain).
The order is also relevant. For example, a client
in the "uk.fredsdom.com" zone would want to have
"uk.fredsdom.com" listed first and
"fredsdom.com" second. This way, when trying to
contact the node "joe," the resolver would attempt
to contact "joe.uk.fredsdom.com" first.
Enter the first domain name, click on Add, repeat for
all required domains, then OK all
- Restart Windows when prompted to
|
Windows NT 4
The following steps require administrator privileges. The reader should
log onto the Windows NT 4 server with the "Administrator"
account (or equivalent)
|
- Click on Start -> Settings -> Control Panel
- Double-click on Network
|
|
- Click on the Protocols tab
- Select "TCP/IP Protocol" and click Properties
|
|
- Click on the DNS tab
- Fill in the "Host" and "Domain" fields
respectively with the client's own hostname, and the
DNS domainname
- Click on Add in the
"DNS Service Search Order" enter the name
server's IP address and confirm. If the client has access to
multiple name servers these can all be added as detailed. The
first listed will be queried first, order can be changed by
using the Up and Down buttons
- It may be useful to enter the DNS domainname in the
"Domain Suffix Search Order" field. This will make
it possible to access nodes on the network by using only the
hostname, rather than having to specify the fully qualified
domain name (hostname.domain).
The order is also relevant. For example, a client
in the "uk.fredsdom.com" zone would want to have
"uk.fredsdom.com" listed first and
"fredsdom.com" second. This way, when trying to
contact the node "joe," the resolver would attempt
to contact "joe.uk.fredsdom.com" first.
Enter the first domain name, click on Add, repeat for
all required domains
- Click OK to submit. Once in the Protocols
properties click on the Bindings tab to ensure that
the bindings are recreated
- Click on OK to confirm
- Reboot the system
|
Windows 2000, XP
The procedures to setup Windows 2000 and Windows XP systems to use DNS
are very similar. A few differences may be noticed in the dialogs, but
overall one description should fit all.
The steps require administrator privileges. The reader should
log onto the Windows 2000/XP server with the "Administrator"
account (or equivalent).
|
- Right-Click on My Network Places and select Properties
- Right-Click on Local Area Connection and select Properties
|
|
- Select "Internet Protocol (TCP/IP)" and click on Properties
- Click on the General tab. All fields referring to DNS in
the form should be grayed out
|
|
- Click on "Use the following DNS server addresses:"
It should now be possible to modify the fields
- Fill in the "Preferred DNS server"
and "Alternate DNS server" fields with the primary and
secondary name servers' IP addresses, then click on
Advanced...
|
|
- Click on the DNS tab. This should list the name servers
entered in the previous form
- It may be useful to enter the DNS domainname in the
"Append these DNS suffixes" list. This will make
it possible to access nodes on the network by using only the
hostname, rather than having to specify the fully qualified
domain name (hostname.domain).
The order is also relevant. For example, a client
in the "uk.fredsdom.com" zone would want to have
"uk.fredsdom.com" listed first and
"fredsdom.com" second. This way, when trying to
contact the node "joe," the resolver would attempt
to contact "joe.uk.fredsdom.com" first.
Click on "Append these DNS suffixes (in order)"
- Click on Add, enter the first domain name
and confirm, repeat for all required domains
- OK all, there should be no need to restart Windows
|
Linux clients
The current section describes how to configure a Caldera OpenLinux 3.1.1
system (whether Workstation or Server) to act as a DNS client, and
take advantage of the domain name service configured through this
Cookbook.
Step-by-Step Configuration (Webmin)
- To access DNS client via the Webmin framework click on the
Hardware tab, in the main form
- Select "Network Configuration"
- Select "DNS Client"
- Fill in the fields as detailed:
|
Hostname |
<empty> |
This field should contain the client's own fully
qualified domain name (hostname.domain) |
Resolution Order |
Hosts - DNS |
This field defines the order and resources the client
will search through in order to resolve hostnames and
IP addresses. Possible values are
values are:
- Hosts - Look in the file called "/etc/hosts"
- DNS - Query the Domain Name System
- NIS - Use NIS (if configured)
- NIS+ - Use NIS+ (if configured)
|
DNS servers |
192.168.100.1 |
This group of fields should contain IP addresses
of the name servers to query |
Search domains |
Listed.. - fredsdom.com |
It may be useful to enter the DNS domain name in the list.
This will make it possible to access nodes on the network
by using only the hostname, rather than having to specify
the fully qualified domain name (hostname.domain).
The order is relevant. For example, a client in the
"uk.fredsdom.com" zone would want to have
"uk.fredsdom.com" listed first and
"fredsdom.com" second. This way, when trying to
contact the node "joe," the resolver would attempt
to contact "joe.uk.fredsdom.com" first. |
- Click on "Save" to commit the changes
Testing the Configuration
The steps in this section are simple ways to check that the configuration
has been successful. A DNS server can be tested by configuring it as a
client to itself and following the instructions for
Linux Clients.
Microsoft Windows Clients
|
- Click on Start -> Run
- On Windows 9x clients type command, on
Windows NT, 2000, XP type cmd to access
the command line (DOS)
- Try to ping other nodes on the network, first
using their IP address, then using the hostnames
|
Linux Clients
|
- Click on the Terminal icon in the "Panel" to
start up a Terminal window
- Try to ping other nodes on the network, first
using their IP address, then using the hostnames
|
|
- Use nslookup to test the resolution
- On the command line type nslookup
- If the client can communicate with the name server,
the DNS server's IP address and name will be shown
and a prompt displayed
- Try formulating a few queries by setting the record types
to
- A for Name -> Address
- PTR for Address -> Name
- NS for the name server records
- CNAME for the alias records
- MX for mail records
eg.
> set type=A
> ns1
|
DHCP - Dynamic Host Configuration Protocol
This section focuses on how to configure a Caldera OpenLinux Server 3.1.1
system as a DHCP server (a server that provides dynamic host configuration
services)
Server-side Setup
Like DNS, DHCP is a client-server communications mechanism. This section
focuses on how to setup a Caldera OpenLinux Server 3.1.1 to manage a pool
of IP addresses that can be assigned to clients. DHCP can also be used to
provide the clients with information relative to other services on the
local area network (for example the IP address of a name server or the
default gateway). This section covers the additional services that are
used most often.
The following sample configuration will be used throughout the examples:
Server
Domain (1): fredsdom.com
Network Address (1): 192.168.100.0
Primary Name Server's Name: ns1.fredsdom.com
Primary Name Server's IP Address: 192.168.100.1
Secondary Name Server's Name: ns2.fredsdom.com
Secondary Name Server's IP Address: 192.168.100.2
Clients
Domain (2): uk.fredsdom.com
Network Address (2): 192.168.200.0
Domain Primary Name Server IP Address: 192.168.200.1
IP Address Node 1: 192.168.100.10
Hostname Node 1: joe.fredsdom.com
IP Address Node 2: 192.168.100.11
Hostname Node 2: anne.fredsdom.com
IP Address Node 3: 192.168.100.20
Hostname Node 3: printer1.fredsdom.com
Hardware Address Node 3:00:30:C1:57:70:71
Default Gateway: 192.168.100.254
The OpenLinux DHCP server has the ability to manage both single and
"shared" network configurations (whereby multiple subnets share
the same physical network).
NOTE: For the Webmin sections, DHCP server configuration can be
accessed by clicking on the Servers tab, and selecting the
"DHCP Server" option.
|
Single Network Configuration
Step-by-Step Configuration (Webmin)
-
Initially no subnets, shared networks or hosts should be
configured.
- Configure the subnet by clicking on "Add a new subnet"
- Fill in the subnet details:
|
Network address |
192.168.100.0 |
The full network address for the subnet |
Netmask |
255.255.255.0 |
The subnet mask |
Address ranges |
<empty> |
This field may be required in setups where multiple
subnets are covered. For the purpose of this exercise
it can be ignored |
Dynamic BOOTP ? |
No |
BOOTP is an older protocol for serving dynamic IP
addresses and configuration to clients. Enabling
this option allows clients that are not DHCP enabled,
but BOOTP capable, to obtain an address from the pool.
NOTE: BOOTP clients are usually assigned an IP
address based on their MAC address. This would require
a static mapping to be configured. With Dynamic BOOTP
this mapping is not required, the DHCP server will
assign an available address from the pool |
Shared network |
<None> |
This field is only required if there are other subnets
sharing the same physical network |
Default Lease time |
14000 |
This defines the duration of the lease, i.e. how long
the assigned client can keep the IP address for before
it expires. The client can request for the lease to be
extended, up to a maximum time defined by the
Maximum Lease time |
Boot filename |
None |
Some network clients can download their boot code
(or firmware) from a server on the network. This field
specifies the path relative to a remote distribution
tree for the file |
Maximum Lease time |
36000 |
The maximum time that a lease will be allowed to last for |
Boot file server |
This server |
The BOOTP server can either redirect clients to a server
that stores the boot code or serve it itself |
Server name |
Default |
Clients can be configured to send DHCP requests to a
specific server. In this scenario, upon receipt of a
DHCP request the server will match the name within
the packet with this and respond if it is its own name.
Otherwise the request will be ignored |
Lease length for BOOTP clients |
Forever |
Usually, once an address is assigned to a BOOTP client,
it belongs to that client forever (even if it is down,
the address cannot be given to any other).
This option allows the server to associate a duration to
Dynamic BOOTP leases. The server will internally manage
the address by checking if the BOOTP client is still using
it. If this is the case, the counter will be reset
(extending the lease), otherwise the address will be
made available for another requester |
Lease end for BOOTP clients |
Never |
This field can be used to define a specific time when all
Dynamic BOOTP leases will expire. In some cases it may make
sense for this to occur, thus freeing the used up addresses
|
Dynamic DNS enabled ? |
No |
Traditionally DNS entries statically define mappings between
name and IP address. With Dynamic DNS, the hostname can be
automatically mapped to the dynamically assigned IP address |
Dynamic DNS domain name |
Default |
The domain name part that will be appended to the client's
host name to create the fully qualified domain name (hostname.domain) |
Dynamic DNS reverse domain |
Default |
This field is normally not required. Defaults to
"in-addr.arpa" |
Dynamic DNS hostname |
From client |
This field may be used to override a host's
Dynamic DNS entry. Usually the hostname entered in the DDNS
is the client's hostname (if it supports this functionality)
|
Hosts directly in this subnet |
<empty> |
This will be filled in and explained later |
Groups directly in this subnet |
<empty> |
This field will be explained later |
- Click on "Create" to add the subnet
- Define the client configuration options by clicking on the newly
created subnet, and on "Edit Client Options" in the
Edit Subnet form
- Fill in the required fields:
|
Client hostname |
Default |
This is only required in case the options apply to one
specific client |
Default routers |
192.168.100.254 |
Specifies the IP address of the default gateway |
Subnet mask |
255.255.255.0 |
The network mask |
Broadcast address |
192.168.1.255 |
The Broadcast IP address |
Domain name |
fredsdom.com |
The domain name part that will be appended to the client's
host name to create the fully qualified domain name (hostname.domain) |
DNS servers |
192.168.100.1 192.168.100.2 |
A whitespace delimited list of name server IP addresses
that can be use by the clients for hostname resolution
(in order of preference) |
Time servers |
Default |
If there are RFC868 compliant time servers on the network
with which the clients can synchronize their clocks, this
field can be used to specify their IP addresses.
NOTE: These are different to NTP Time servers.
Clients need special configuration in order to use this
functionality. The client's Operating System documentation
should be consulted for information on how to enable this
capability |
Log servers |
Default |
This option is for Diskless clients. It is used to specify
the IP addresses of MIT-LCS UDP log servers
(see the Diskless Client HOWTO mentioned in the
References and Further Reading
section) |
Swap servers |
Default |
For Diskless clients, this specifies the IP addresses for
swap servers (in order of preference) |
Root disk path |
Default |
Specifies the path where the Diskless client's root disk is
located |
NIS domain |
Default |
If an NIS domain exists, this field can be used to specify
its name, so that clients can join it (if configured to do
so) |
NIS servers |
Default |
This field can be used to specify a list of NIS servers
available to the client |
Font servers |
Default |
If X Window System font servers are available to the clients
these can be listed here |
XDM servers |
Default |
This can be used to specify the list of X Display Managers
the clients can query to obtain XDMCP sessions |
Static routes |
Default |
If static routes need to be defined for the client, these
can be specified here in the form of destination gateway
address couples eg. 192.168.101.0 192.168.100.254.
NOTE: The default route (0.0.0.0) cannot be specified
here |
NTP servers |
Default |
If NTP time servers exist on the network, or public ones are
to be used by the clients, this field can be used to list
them in order of preference |
NetBIOS name servers |
Default |
This option is particularly useful on networks with lots of
Windows clients. A list of (WINS) NetBIOS name servers
can be specified here in order of preference |
NetBIOS scope |
Default |
For NetBIOS over TCP/IP, if a NetBIOS scope is
specified here, this will be appended to all NetBIOS
names in order to isolate the NetBIOS traffic to just
those nodes that have the same scope. If Windows
clients need to log onto a Windows DOMAIN, only
a Windows DOMAIN Controller with the same
NetBIOS scope will be able to authenticate them |
NetBIOS node type |
Default |
This field can be used to instruct NetBIOS clients (such as
Windows clients) that are configurable, on which method
to use for name resolution. Valid options are:
- 1 - B-node: Broadcast - no WINS
- 2 - P-node: Peer - WINS only
- 4 - M-node: Mixed - broadcast, then WINS
- 8 - H-node: Hybrid - WINS, then broadcast
(see RFC1001/RFC1002 for further information)
|
- Submit the changes by clicking on the "Save" button
-
Create a pool of addresses that can be leased out by clicking on
"Add an address pool" in the
"Address Pools for Subnet" section
- The details to provide are:
|
Address ranges |
192.168.100.32-192.168.100.63 |
This field specifies the lower and upper bounds of the
address pool range. In the example give, 32 addresses out
of the 255 available in the subnet subnet have been assigned
to the DHCP pool |
Dynamic BOOTP |
No |
This field may be used to override the global subnet option,
enabling Dynamic BOOTP only for this address pool |
Clients to allow |
all clients |
see Clients to deny |
Clients to deny |
|
When the DHCP server receives a request this can
be honoured or denied, depending on the permit lists defined
in the Clients to allow/deny fields. If the allow
list is populated, only requests from clients in that list
will be honoured. If the deny list is populated, requests
from all clients except those listed will be honoured. If
both lists are populated, requests will be honoured from
allowed clients that are not present in the deny list. The
list can contain any or combinations of the following
keywords:
- known clients - clients that have a host entry in the
DHCP server's configuration
- unknown clients - clients that do not have a host
entry in the DHCP server's
configuration
- members of "class" - clients that are members
of a class defined in DHCP server's
configuration
- dynamic bootp clients - BOOTP clients
- authenticated clients - clients that have been
successfully authenticated using the
DHCP authentication protocol
(not currently supported)
- unauthenticated clients - clients that fail DHCP
authentication
(not currently supported)
- all clients - any requesting client
|
The remaining fields may be used
to override the global subnet options. A description of each
parameter is provided in the section dedicated to the
Subnet details form |
- In some cases it may be necessary, or preferable, to assign fixed
IP addresses to specific DHCP clients, for example on a network
where Dynamic DNS is not available. Under these circumstances it is
acceptable for clients to have different IP addresses (and
therefore different DNS entries), but network printers should
always have the same address and hostname.
To create this "semi-static" mapping, click on
"Add a new host" in the Edit Subnet form
- Fill in the details for the hosts:
|
Host name |
printer1 |
|
Hardware Address |
"ethernet" - 00:30:C1:57:70:71 |
The node's Hardware (MAC) address and typology. (Details
on how to gather this information vary from device to device.
These details should be found in the device's operating
manuals)
|
Fixed IP address |
192.168.100.20 |
The IP address that needs to be assigned to this node |
The remaining fields may be used
to override the global subnet and/or pool options. A description
of each parameter is provided in the section dedicated to the
Subnet details form |
- Click on "Create" to submit the entry
- The Edit Subnet form should now contain the newly added
node in the field titled
"Hosts directly in this subnet."
- Once the configuration is saved by clicking on "Save"
in this form the DHCP service can be started via the
"Start Server" button in the main configuration form
Client-side Setup
This section details the steps necessary to configure Windows
and Linux clients to take advantage of a DHCP server on the network. The
main assumption made at this stage is that TCP/IP networking has been
tested by configuring the clients with static IP addresses and verifying
that connectivity is functioning. To verify this it is sufficient
to ping a machine on the network by its IP address, from a
shell or the command line interpreter (COMMAND.COM or CMD.EXE)
NOTE: Before proceeding with the configuration and testing, please
ensure that any Firewalling/Filtering software on the client is turned off.
The Operating System or product specific documentation can be consulted
later for information on how to fine-tune the Firewalling/Filtering
software to allow DHCP to work
Microsoft Windows clients
Windows 9x, ME
|
- Click on Start -> Settings -> Control Panel
- Double-click on Network
|
|
- Select "TCP/IP -> <network adapter>"
(where <network adapter> is the description
of the LAN card) and click on Properties
- Click on the IP Address tab
|
|
- Click on "Obtain an IP address automatically"
- If a DNS server is available on the network, click on
the DNS Configuration tab. All fields in the form
should be grayed out
|
|
- Click on "Enable DNS" It should now be possible to
modify the fields
- Fill in the "Host" and "Domain" fields
respectively with the client's own hostname, and the
DNS domainname
- The DHCP server has been configured to pass the remaining
information to the client, so no other field should need
editing
- OK all and restart Windows when prompted to
|
Windows NT 4
The following steps require administrator privileges. The reader should
log onto the Windows NT 4 server with the "Administrator"
account (or equivalent)
|
- Click on Start -> Settings -> Control Panel
- Double-click on Network
|
|
- Click on the Protocols tab
- Select "TCP/IP Protocol" and click Properties
|
|
- Click on the IP Address tab
- Click on "Obtain an IP address from a DHCP server"
- When prompted, confirm the intention to use DHCP
|
|
- If a DNS server is available to this client, click on
the DNS tab
- Fill in the "Host" and "Domain" fields
respectively with the client's own hostname, and the
DNS domainname
- The DHCP server has been configured to pass the remaining
information to the client, so no other field should need
editing
- Click on OK to confirm
- Reboot the system
|
Windows 2000, XP
The procedures to setup Windows 2000 and Windows XP systems to use DHCP
are very similar. A few differences may be noticed in the dialogs, but
overall one description should fit all.
The steps require administrator privileges. The reader should
log onto the Windows 2000/XP server with the "Administrator"
account (or equivalent).
|
- Right-Click on My Network Places and select Properties
- Right-Click on Local Area Connection and select Properties
|
|
- Select "Internet Protocol (TCP/IP)" and click on Properties
- Click on the General tab
|
|
- Select "Obtain an IP address automatically"
- Select "Obtain DNS server address automatically"
- Click on the Advanced... button
|
|
- The "IP address" box should display
"DHCP Enabled"
- OK all, there should be no need to restart Windows
|
Linux clients
The current section describes how to configure a Caldera OpenLinux 3.1.1
system (whether Workstation or Server) to act as a DHCP client, and
take advantage of dynamic configuration options provided by the server
Step-by-Step Configuration
The following steps require administrator privileges. The reader should
log onto the K Desktop Environment with the "root" account
(or equivalent)
|
- Click on K -> Control Center
|
|
- Select System -> Network -> Interfaces
- Click the name of the network interface (usually "eth0")
- Click on "Dynamic Addresses with DHCP"
- Ensure that the interface is enabled
- Click on Save and Apply to make the
configuration active
|
Testing the Configuration
Brief steps will be listed throughout this section, to verify that
the dynamic configuration provided through DHCP has been successful
Microsoft Windows Clients
|
- Click on Start -> Run
- On Windows 9x clients type command, on
Windows NT, 2000, XP type cmd to access
the command line (DOS)
- Type ipconfig /all to list the configuration of the
network interface. IP Address, subnet mask and default
gateway should correspond to those setup in the DHCP
server configuration
|
|
- Some Windows 95 clients do not have the ipconfig
command
- Click on Start -> Run
- Type winipcfg and check the configuration
details
|
Linux Clients
|
- Click on the Terminal icon in the "Panel" to
start up a Terminal window
- Type ifconfig -a to obtain details of
the interface configuration. IP Address, netmask, broadcast
address should match those setup in the DHCP server's
configuration
- Type cat /etc/resolv.conf to check if the
DNS configuration has been setup correctly (if provided)
- Type netstat -nr to check that the routers have
been configured correctly
|
DNS and DHCP Combined
Dynamic DNS (DDNS)
The Caldera OpenLinux Server 3.1.1 DHCP daemon has been built without
DDNS support. This feature is therefore not currently supported
References and Further Reading
DNS
Online Resources
http://www.dns.net/dnsrd/
DNS Resources Directory
http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html
DNS HOWTO
Books
O'Reilly - DNS and Bind 4th ed.
DHCP
Online Resources
http://www.caldera.com/support/docs/openlinux/3.1/OLsag/index.html
Caldera OpenLinux System Administration Guide
http://www.isc.org/products/DHCP/dhcp-v3.html
ISC Dynamic Host Configuration Protocol (DHCP)
Books
Prentice Hall - The DHCP Handbook, 1/e
General
Online Resources
http://www.ietf.org/rfc.html
IETF Request for Comments Repository
http://www.caldera.com/LDP/HOWTO/Diskless-HOWTO.html
Diskless Nodes HOW-TO document for Linux
Books
Notes
-
Some IP addresses are reserved for private use, and are not routable over
the Internet. These are all the addresses in the:
10.xxx.yyy.zzz (Class A)
172.16.yyy.zzz (Class B)
192.168.yyy.zzz (Class C)
For further information, see the Further Reading section.
-
DHCP works at the Media Access Control (MAC) sub-layer. As Ethernet
transmits data octets (including the MAC address) LSB first, and Token
Ring/FDDI transmit MSB first, the DHCP server needs to be aware of and
capable of managing this difference.
Feedback
What did you find particularly helpful in this cookbook? Are there mistakes
in this documentation?
Could it be organized more usefully? Did we leave out information you
need, or include unnecessary material? If so, please tell us.
To help us implement your suggestions please email:
olbo@caldera.com
including relevant details, such as cookbook title and section
name.
NOTE: We cannot provide technical support via the above alias.
For answers to technical questions, please contact your Caldera Support
Provider or visit
http://www.caldera.com/support
for details of support offerings that are available to you.
Thank you.
Copyright © 2002, Caldera International. All Rights Reserved Worldwide.
Caldera International assumes no responsibility for the accuracy or completeness
of the information in this document. The use of this information or the
implementation of any of these techniques is a customer responsibility
and depends upon the customer's ability to evaluate and integrate them
into the customer's operational environment. Information in this document
is subject to change without notice, and does not imply a commitment on
the part of Caldera.
Caldera, the Caldera logos and OpenLinux are trademarks or registered
trademarks of Caldera International, Inc. in the U.S.A. and other countries.
Linux is a registered trademark of Linus Torvalds. All other brand and product
names are trademarks or registered marks of the respective owners.