Network Name Services


A Network Name Service is a mechanism by which a requesting client machine can inquire information about a network-available machine or service. In the following sections, we examine services available under SLES.

Samba

Usually, the Samba software is perceived to be a file and printer sharing application. For it to perform this task, however, a number of factors must be in place. It is not sufficient to simply place a machine on a network to have all its shareable resources automatically available to all.

Samba provides an environment called a domain within which machines can be registered. The domain is a network entity and is the main repository for all user and machine information. When a client machine requests a service from a target server, it must first inquire about the server. Using NetBEUI/NetBIOS protocols, a client can find a service provider's name and collect the necessary information to open a connection. After the target computer has been found, a connection request can be made for the resource in question. If the resource exists, the requestor's rights and privileges are checked, and access is either granted or denied. The user's credentials and access rights to the shared resource are stored within the Samba domain.

Service Location Protocol (SLP)

The Service Location Protocol (SLP) allows for a client to generate a network query and broadcast a request for a specific resource on a network. Hosts providing the service can answer the query and provide information as to their whereabouts. You can think of SLP as a decentralized network services name server. However, instead of resolving simple machine names, it provides a bridge between a requested service type and the available systems that provide the service.

The Misc option in YaST has an option called Installation Server. Selecting this function permits you to create an SLP distribution service for your SUSE installation media. You can select the protocol over which the media will be available (HTTP, FTP or NFS). After your installation media has been accepted by the system, subsequent installations can be pointed to this network resource instead of the local CD-ROM drive. Your installations will run more smoothly and not require the constant swapping of CDs.

SLP, however, is not restricted to software-kit distribution. It is also capable of providing network-wide knowledge of file and print servers and mail servers. Many of the applications provided with SLES are SLP aware. Running the SLP browser (which you access by selecting YaST, Network Services) allows you to look for available services on the network.

Domain Name Service (DNS)

The Domain Name Service (DNS) is a TCP/IP-based environment that permits the translation of text-based machine names into their target TCP/IP addresses.

A typical fully qualified domain name (FQDN) reference for a unique machine includes a machine name and a DNS zone to which it belongs. An example could be

 Hermes.UniversalExport.ca 

DNS is essentially a multitiered lookup system, not unlike a series of phone books, that can be used to convert a name into a number.

A phone number is read left to right: country code, area code, local phone number. To find an individual's number, you can look up his last name in the phone book, scroll down to the line with his first name, and find his number. Of course, this is the ideal case. In many cases, many towns are covered by the same phone book. You might also wind up with a number of individuals with the same name.

The case of finding a unique machine on the Internet and locating its address is similar. Instead of a phone book, you have a DNS server. A search for the preceding machine is performed on the local name server; if it recognizes the machine, the DNS server returns the requested information.

If the machine is not recognized, two things can happen. Just like a phone book for Lennoxville, Quebec, is the definitive guide to phone numbers there, a DNS server can be declared as the definitive source for a domain. If the target DNS server is the master server for the zone UniversalExport.ca, a message is returned to the users stating essentially "No such host."

If, on the other hand, the DNS server is not the master for the domain in question, it passes the information request to redefined "escalation" servers called forwarders. These new target DNS servers also have forwarders, and the query is passed along. Quite quickly, the DNS server with the authority to respond to the query supplies the answer.

In the case of an external machine inquiring about a machine name such as Athena.UniversalExport.ca, name resolution happens quite quickly. If only Pollux is the definitive DNS server for the UniversalExport.ca zone, the requesting machine's local DNS is unable to answer the query. Its DNS server asks its forwarder whether it can resolve UniversalExport.ca. If that does not work, a query for .ca will go out. Because this is a root domain, its DNS server knows by default the DNS server address for UniversalExport.ca. Pollux will be the target for the next query and will return the proper Internet-facing address.

Before you can set up your DNS server, you need to know the following information:

  • The name and address of your local name server (the one you are building).

  • The name of the zone you have acquired through your ISP/registrar. In our example, this would be UniversalExport.ca.

  • The address of the name server for your service provider or the IP address of a name server you would like your unresolved queries to go to.

  • The name of the various zones you want your name server to recognize. Of course, they must be names that you have the authority to resolve. Because we own UniversalExport.ca, we may decide to subdivide this into Marketing.UniversalExport.ca, Engineering.UniversalExport.ca, and so on.

  • If you will be processing mail, the IP addresses and names of your Internet-facing mail hosts.

After you have collected this information, you are ready to configure your DNS server. The simplest way to configure your DNS server is to use the YaST tool. Under Network Services, choose DNS Server. You then are presented with a wizard in which you must complete these three steps:

Configure forwarders.

Set up DNS zones.

Tune the server's startup behavior and decide whether you want to enter the Expert Configuration menus.

The forwarders and startup steps are fairly straightforward. The startup options simply define whether DNS should be started when the system boots up. Forwarders are name servers that are used to further process a DNS request should the local DNS server be unable to answer a query. Typically, they would be external DNS servers associated with your ISP.

Determining which queries are passed to forwarders is done through defining zones. A zone is a definition of a domain of computers for which the local name server is responsible.

A master zone identifies the current DNS server as the definitive source for information on the identified domain. Queries for that domain are either resolved locally, or a failure is sent back to a client.

Slave zones tell the local DNS server which other DNS servers in the organization are responsible for name resolution for the requested domain. Requests for such domains are forwarded to the identified DNS server.

Queries to DNS that are unresolved by the local zone information are passed along to the identified forwarders for processing. By specifying a hierarchy of DNS server, you can control which domains are available to your queries and which are not.

The zone editing stage, however, can require some time to configure properly. There are five main tabs in the Zone Editor, and each tab represents a specific type of record: Basics, NS Record, MX Record, SOA, and Records.

The Basics tab describes who is allowed to extract bulk information from the zone. These bulk queries are called zone transfers and are typically not allowed. By dumping the content of a zone, an attacker could learn a great deal about the architecture of your network. If working from a compromised machine within your organization, an attacker could quickly learn about machines resident on your network by simply browsing the DNS entries. It is preferable to leave this setting at None to disallow all types of zone transfers.

The NS Record tab represents the name servers that are responsible for resolving queries to this zone. Though typically only one record is sufficient, a second redundant server could be listed here.

The MX Record tab identifies the zone's mail servers. SMTP mail servers that are forwarding mail to your domain will query the MX records to know which hosts they should be delivering the mail to. Typically, the servers pointed to are not the actual mail servers for an organization. MX records exposed to the Internet are usually perimeter hosts used to accept mail, scan them for viruses and spam, and forward acceptable mail to the internal servers.

The SOA record is known as the "Start of Authority" record for a zone. On the SOA tab, the authoritative server can place stale date ranges on server names, maintain updated serial numbers, and set expiry information on records. The values provided are standard values in common use. This allows for a name passed along to a query to remain in the requestor's cache for a fixed period of time. If a server is moved to a different IP address, the stale date on the requestor's client will force a rediscovery of the new proper address within the described period. This is done to ensure that remote information is kept relatively up to date.

On the last tab, Records, you can define the names and addresses of actual servers on the network. In addition to MX- and NS-type records, the YaST tool allows you to define A and CNAME entries. An A-type record relates the name of a machine with its numeric IP equivalent. A CNAME-type record allows you to define an alias for a machine. As you will see later in the section on the HTTP server, machine alias records can be used to have a single host service multiple web environments.

NOTE

Many more DNS record types are available than those listed in the YaST tool. For a complete list of these record types, refer to RFC 1035. Specifics on all RFCs can be found at http://www.faqs.org/rfcs/.


After you have configured your zones, you can start the DNS service and test your handiwork. Here are a couple of tests you may want to try:

 Castor:~ # host -l UniversalExport.ca UniversalExport.ca name server Athena.UniversalExport.ca. Castor.UniversalExport.ca has address 192.168.1.245 Pollux.UniversalExport.ca has address 192.168.1.244 Hermes.UniversalExport.ca has address 192.168.1.243 Castor:~ # host Hermes.UniversalExport.ca Hermes.UniversalExport.ca has address 192.168.1.243 

The -l option request a dump of all the known DNS entries for the requested domain. It is important to control which machines can request a zone transfer of your domain. Only other name servers in your environment should be able to do this. Allowing unrestricted access to zone transfers allows an attacker to get a full list of your machines. It also exposes all your published machines to reconnaissance scans. If you embed the purpose of your machine in the machine name (for example, web1.universalexport.ca), an attacker can concentrate on the appropriate attacks for the specific server.

At this point, you should be able to add your entire server environment to your DNS. Machines within your network can be made to point to your DNS server IP address for name resolution. For all zones for which your server is not capable of resolving, your DNS will forward the request and transparently retrieve the answer. How to quickly set all your workstations to point to your DNS is the topic for the next section.

Dynamic Host Configuration Protocol (DHCP)

In most organizations, the number of desktop workstations greatly outnumbers the complement of the server farm. In a tightly controlled production environment, your ability to assign IP addresses to machines is governed by many factors: whether they are Internet facing, in a particular lab or DMZ, or possibly a server that can be reached only from within the organization. After you have selected the IP address, you can create a DNS entry to allow the clients to connect to the machine by name. The same process applies to all machines that offer services to other machines.

In the case of standalone desktops, there are few, if any, reasons why they should be communicating directly among themselves. Therefore, it is often unwise to register each and every machine in DNS. Furthermore, as the organization grows, maintaining the list of which machine has which address is a horrendous task.

The Dynamic Host Configuration Protocol (DHCP) alleviates many of the problems discussed here. You can use DHCP to provide to requesting workstations all the TCP/IP information they need to be able to function on the network.

In the discussion that follows, we examine a case in which all the internal address space is contained behind a firewall that is capable of Network Address Translation (NAT). We leave up to you the size of your internal subnet, your choice of Class B or Class C, and the way it will be subdivided. If your environment is different and you have a registered range of valid real-world IP addresses, the same concepts will apply.

NOTE

Private subnets are explained further in RFC 1918 and RFC 1466. You can find a copy of these RFCs at http://www.faqs.org/rfcs/.

Many companies ship their small business or home router firewalls with a 192.168.x.0/25 subnet preconfigured. Such devices can address as many as 254 machines. Larger companies may opt to use a Class A or B address space if they contain more machines.

Choosing the number of internal private subnets is important because it will govern how "flat" your network is. Selecting multiple smaller subnets may be beneficial in segregating traffic and identifying the origin of spurious traffic.


The bare minimum TCP/IP information a machine requires to talk locally on a network is an IP address and arguably a subnet mask. With this information, all the machines in the current network and the same subnet can be reached by an IP address.

For a machine to talk to machines outside the current subnet, it requires an address for a gateway. The gateway works like a bridge and contains the necessary routing information to target the outbound packet to the appropriate destination. With this additional piece of information, a PC can now talk to other subnets, but only by using the IP address of the target.

The final piece that will allow a client workstation to talk to machines by name is called the Domain Name Server (DNS), which was discussed previously. When you define the IP address of a DNS server, the local machine can translate a fully qualified domain name to a unique IP. Conversations are now possible on a name basis.

In summary, for a PC to function properly on a network, the following information is required:

  • IP address and subnet mask

  • A gateway address

  • An IP address for DNS servers

After you have defined these pieces of information, you are ready to configure your DHCP server. You can start the DHC configuration utility by starting YaST and selecting Network Services and then DHCP Server.

In the initial configuration, you are asked which network card will be providing the DHCP service.

The second step asks you for default gateway and name server IP addresses. You also are prompted for the following information:

  • Domain name This is your registered domain name. It will be appended to the workstation's name when it is configured. It will also be the default zone DNS queries will append to requests. In this way, a client can specify a server by name and not require the fully qualified domain name (for example, you can use Athena instead of Athena.UniversalExport.ca).

  • Time server This information allows the client to point to the corporate time server. Identifying the time server is important for a number of protocols and is a good practice. It makes tracking down network events easier and reduces the number of support calls about clocks being out of sync and mail arriving at a PC before the PC's clock reaches the Sent time.

  • Print server If you have a corporate print server, you can identify it here.

  • WINS server This information allows your machine to automatically register into the Windows Internet Naming Service (WINS). Using this service, machine-user and IP information is collected in a central location to help reduce network queries. WINS uses NetBIOS naming services and is available under Samba/Windows.

The third and final step in the initial setup is to specify a range of TCP/IP addresses available for distribution. The range you choose here can be based on many factors. Single subnet sites may reserve the first 30 addresses for servers, the next 15 addresses for printers, and the rest for dynamic allocation. Other options include having your servers in a subnet, printers and network devices in another, and workstations in yet a third. After you make this decision, you will be required to enter a lower and upper IP address to define the DHCP range.

After configuring, you will be able to start your DHCP server. Changing a client's configuration to permit DHCP and restarting the network services should be all that is required. Your client should now have a valid address in the appropriate pool of addresses.

DHCP allows for the quick configuration of workstations. It also alleviates the tedious task of keeping track of machine-IP pairings. If these pairing are still required, DHCP provides added functionality whereby a network card's MAC address can be registered and matched to a unique IP. Though this is still a tedious task, the data is maintained in the DHCP server itself. It is therefore impossible to allocate the same address twicesomething a spreadsheet or paper system is known for.

The MAC address reservation scheme is also useful for quarantine purposes. A questionable machine discovered on the network could have its MAC address reservation point to a quarantine subnet. Such a subnet can be configured not to interact with other subnets, causing the end user to contact the help desk. The help desk staff can then deal with the infected machine without requiring hours of checking from cubicle to cubicle.

DNS and DHCP

You can perform additional configuration steps to more closely tie DNS and DHCP together. Both of these applications are LDAP aware. If a corporate LDAP directory exists, it is possible for these applications to store their information within the structures provided.

An additional feature that has not been discussed here is the linking of information collected by DHCP with the capabilities of DNS. You might want to populate the DNS database with the names and IP addresses of DHCP. SLES allows you to do this using DynamicDNS. This option permits the passing of information from the DHCP server to the DNS server. Auto-registration of the machine name and domain is performed in the DNS environment. This permits hosts to have dynamic IP addresses while retaining the capability to be accessed by name when required.



    SUSE LINUX Enterprise Server 9 Administrator's Handbook
    SUSE LINUX Enterprise Server 9 Administrators Handbook
    ISBN: 067232735X
    EAN: 2147483647
    Year: 2003
    Pages: 134

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net