How to Configure DNS Server Settings in Windows 2008

When you install the DNS server role on a Windows Server 2008 or Windows Server 2008 R2 computer, the DNS Manager Microsoft Management Console (MMC) snap-in is automatically installed, providing you with all the tools required to manage and administer DNS. When you install AD DS the DNS zones needed for administering DNS in the AD DS domain are added to your DNS installation. This section introduces you to server-specific settings that you can configure

from the DNS server’s Properties dialog box.

From the DNS Manager snap-in, right-click the DNS server and choose Properties to display the dialog box shown in image below. This dialog box enables you to configure a comprehensive range of server-specific properties. The more important properties are discussed in this section.

 

Forwarding

The act of forwarding refers to the relaying of a DNS request from one server to another one when the first server is unable to process the request. This is especially useful in resolving Internet names to their associated IP addresses. By using a forwarder, the internal DNS server passes off the act of locating an external resource, thereby reducing its processing load and network bandwidth. The use of forwarding is also helpful for protecting internal DNS servers from access by unauthorized Internet users. It works in the following manner:

Step 1. A client issues a request for a fully qualified domain name (FQDN) on a zone for which its preferred DNS) server is not authoritative (for example, an Internet domain such as http://www.google.com).

Step 2. The local DNS server receives this request but has zone information only for the internal local domain and checks its list of forwarders.

Step 3. Finding the IP address of an external DNS server (such as one hosted by the company’s ISP), it forwards the request to the external server (forwarder).

Step 4. The forwarder attempts to resolve the required FQDN. Should it not be able to resolve this FQDN, it forwards the request to another forwarder.

Step 5. When the forwarder is able to resolve the FQDN, it returns the result to the internal DNS server by way of any intermediate forwarders, which then returns the result to the requesting client.

You can specify forwarders from the Forwarders tab of the DNS server’s Properties dialog box, as shown in Figure 4-2. Click Edit to open the Edit Forwarders dialog box shown in Figure 4-3. In the space provided, specify the IP address of a forwarder and click OK or press Enter. The server will resolve this IP address to its FQDN and display these in the Forwarders tab. You can also modify the sequence in which the forwarding servers are contacted by using the Up and Down command buttons, or you can remove a forwarding server by selecting it and clicking Delete.

You can also specify forwarders from the command line by using the dnscmd command. Open an administrative command prompt and use the following command syntax:

dnscmd ServerName /ResetForwarders MasterIPaddress … [/TimeOut Time] [/Slave]

The parameters of this command are as follows:

■ ServerName: Specifies the DNS hostname of the DNS server. You must include this parameter; use a period to specify the local computer.

■ /ResetForwarders: Indicates that you are configuring a forwarder.

■ MasterIPaddress …: Specifies a space-separated list of one or more IP addresses of DNS servers to which queries are forwarded.

■ /TimeOut: Specifies a timeout setting in seconds.

■ /Slave: Determines whether the DNS server uses recursion when querying for the domain name specified by ZoneName.

Conditional Forwarders

You can configure a DNS server as a conditional forwarder. This is a DNS server that handles name resolution for specified domains only. In other words, the local DNS server will forward all the queries that it receives for names ending with a specific domain name to the conditional forwarder. This is especially useful in situations where users in your company need access to resources in another company with a separate AD DS forest and DNS zones, such as a partner company. In such a case, specify a conditional forwarder that directs such queries to the DNS server in the partner company while other queries are forwarded to the Internet. Doing so reduces the need for adding secondary zones for partner companies on your DNS servers.

The DNS snap-in provides a Conditional Forwarders node where you can specify forwarding information. Use the following procedure to specify conditional forwarders:

Step 1. Right-click the Conditional Forwarders node and choose New Conditional Forwarder

Step 2. Type the DNS domain that the conditional forwarder will resolve and the IP address of the server that will handle queries for the specified domain.

Step 3. If you want to store the conditional forwarder information in AD DS, select the check box provided and choose an option in the drop-down list that specifies the DNS servers in your domain or forest that will receive the conditional forwarder information. Then click OK.

Information for the conditional forwarder you have configured is added beneath the Conditional Forwarders node in the DNS Manager snap-in. Name queries for the specified DNS domain will now be forwarded directly to this server.

Root Hints

Whenever a DNS server is unable to resolve a name directly from its own database or with the aid of a forwarder, it sends the query to a server that is authoritative for the DNS root zone. Recall from Chapter 2 that the root is the topmost level in the DNS hierarchy. The server must have the names and addresses of these servers stored in its database to perform such a query. These names and addresses are known as root hints, and they are stored in the cache.dns file, which is found at %systemroot%system32dns. This is a text file that contains NS and A records for every available root server.

When you first install DNS on a server connected to the Internet, it should download the latest set of root hints automatically. You can verify that this has occurred by checking the Root Hints tab of the server’s Properties dialog box. You should see a series of FQDNs with their corresponding IP addresses.

If your internal DNS server does not provide access to Internet name resolution, you can improve network security by configuring the root hints of the internal DNS servers to point to the DNS servers that host your root domain and not to Internet root domain DNS servers. To modify the configuration on this tab, perform one or more of the following actions:

■ Click Add to display the New Name Server Record dialog box, from which you can manually type the FQDNs and IP addresses of one or more authoritative name servers.

■ Select an entry and click Edit to display the Edit Name Server Record dialog box, which enables you to modify it or add an additional IP address to an existing record.

■ Select an entry and click Remove to remove a record.

■ Click Copy from Server to copy a list of root hints from another DNS server. Type the DNS name or IP address in the dialog box that appears. This action is useful if your server was not connected to the Internet at the time DNS was installed.

■ Although this is not a recommended action, you can also edit the cache.dns file using a text editor such as Notepad.

NOTE: You can also use the Configure a DNS Server Wizard to configure root hints for your server. Right-click your server in the console tree of the DNS Manager snap-in and choose Configure a DNS Server. Then select the Configure root hints only (recommended for advanced users only) option from the Select Configuration Action page of the wizard.

Configuring Zone Delegation

As you have seen, you can divide your DNS namespace into a series of zones. You can delegate management of these zones to another location or workgroup within your company by delegating the management of the respective zone. Configuring zone delegation involves creating delegation records in other zones that point to the authoritative DNS servers for the zone being delegated. Doing so enables you to transfer authority as well as providing correct referral to other DNS servers and clients utilizing these servers for name resolution.

The Zone Delegation benefits:

■ You can delegate the administration of a portion of your DNS namespace to another office or department in your company.

■ You can subdivide your zone into smaller zones for load balancing of DNS traffic among multiple servers. This also enables improved DNS name resolution performance and fault tolerance.

■ You can extend the namespace by adding additional subdomains for purposes such as adding new branch offices or sites.

You can use the New Delegation Wizard to create a zone delegation. The wizard uses the information you supplied to create name server (NS) and host (A or AAAA) resource records for the delegated subdomain. Perform the following procedure:

Step 1. Right-click the parent zone in the console tree of DNS Manager and

choose New Delegation. This starts the New Delegation Wizard.

Step 2. Click Next and then enter the name of the delegated subdomain.

Step 3. As shown in next screenshot, the wizard appends the parent zone name to form the FQDN of the domain being delegated. Click Next and then click Add.

Step 4. In the New Name Server Record dialog box, type the FQDN and IP address of the DNS server that is authoritative for the subdomain and then click OK. Repeat if necessary to add additional authoritative DNS servers.

Step 5. The servers you’ve added are displayed on the Name Servers page of the wizard. When finished, click Next and then click Finish.

You can also use the dnscmd utility to perform zone delegation from the command line. Open an administrative command prompt and use the following command:

dnscmd ServerName /RecordAdd ZoneName NodeName [/Aging] [/OpenAcl] [Ttl] NS {HostName|FQDN}

Debug Logging

The DNS server also supports debug logging of packets sent to and from the DNS server to a text file named dns.log. This file is stored in the %systemroot%system32dns folder. To configure logging, right-click the server in the DNS Manager snap-in and choose Properties. Click the Debug Logging tab to receive the dialog box.

By default, no logging is configured. Select the Log packets for debugging check box, which makes all other check boxes available.

To view the DNS log, first stop the DNS service by right-clicking the DNS server in DNS Manager and choosing All Tasks > Stop. Then open the log in either Notepad or WordPad. When you are finished, restart the DNS service by right clicking the DNS server and choosing All Tasks > Start.

Event Logging

The Event Logging tab of the DNS server’s Properties dialog box enables you to control how much information is logged to the DNS log, which appears in Event Viewer. You can choose from one of the following options:

■ No events: Suppresses all event logging (not recommended).

■ Errors only: Logs error events only.

■ Errors and warnings: Logs errors and warnings only.

■ All events: Logs informational events, errors, and warnings. This is the default. Choosing either the Errors only or Errors and warnings option might be useful to reduce the amount of information recorded to the DNS event log.

DNS Security Extensions

DNS in itself is vulnerable to certain types of intrusions such as spoofing, man-in-the-middle, and cache-poisoning attacks. Because of this, DNS Security Extensions (DNSSEC) was developed to add additional security to the DNS protocol. Outlined in Requests for Comments (RFCs) 4033, 4034, and 4035, DNSSEC is a suite of DNS extensions that adds security to the DNS protocol by providing origin authority, data integrity, and authenticated denial of existence. Although an older form of DNSSEC was used in Windows Server 2003 and the first iteration of Windows Server 2008, DNSSEC has been updated completely according to the specifications in the just-mentioned RFCs. The newest form of DNSSEC is available for Windows Server 2008 R2 and Windows 7 only.

DNSSEC enables DNS servers to use digital signatures to validate responses from other servers and resolvers. Signatures are stored in a new type of resource record called DNSKEY within the DNS zone. On resolving a name query, the DNS server includes the appropriate digital signature with the response, and the signature is validated by means of a preconfigured trust anchor. A trust anchor is a preconfigured public key associated with a specific zone. The validating server is configured with one or more trust anchors. Besides DNSKEY, DNSSEC adds RRSIG, NSEC, and DS resource records to DNS. You can view zones that are signed with DNSSEC in the DNS Manager tool, and you can view the trust anchors from the Trust Anchors tab of the DNS server’s Properties dialog box.

To specify a trust anchor, click Add. Provide the information requested in the New Trust Anchor dialog box, including its name and public key value, and then click OK. The public key value must be formatted as a Base64 encoding value; for more information on the public key, refer to http://www.rfc-archive.org/getrfc.php?rfc=4034 Doing so adds the trust anchor to the Trust Anchors tab and enables its use for signing DNS query responses.

Advanced Server Options

The Advanced tab of the DNS server’s Properties dialog box contains a series of options that you should be familiar with.

Server Options

The Server options section of this dialog box contains the following six options, the last three of which are selected by default:

■ Disable recursion: Prevents the DNS server from forwarding queries to other DNS servers, as described later in this section. Select this check box on a DNS server that provides resolution services only to other DNS servers because unauthorized users can use recursion to overload a DNS server’s resources and thereby deny the DNS Server service to legitimate users.

■ BIND secondaries: During zone transfer, DNS servers normally utilize a fast transfer method that involves compression. If UNIX servers running a version of Berkeley Internet Name Domain (BIND) prior to 4.9.4 are present, zone transfers will not work. These servers use a slower uncompressed data transfer method. To enable zone transfer to these servers, select this check box.

■ Fail on load if bad zone data: When selected, DNS servers will not load zone data that contains certain types of errors. The DNS service checks name data using the method selected in the Name Checking drop-down list on this tab.

■ Enable round robin: Enables round robin, as described later in this section.

■ Enable netmask ordering: Prioritizes local subnets so that when a client queries for a hostname mapped to multiple IP addresses, the DNS server preferentially returns an IP address located on the same subnet as the requesting client.

■ Secure cache against pollution: Cache pollution takes place when DNS query responses contain malicious items received from nonauthoritative servers. This option prevents attackers from adding such resource records to the DNS cache. The DNS servers ignore resource records for domain names outside the domain to which the query was originally directed. For example, if you sent a query for que.com and a referral provided a name such as windows-scripting.info, the latter name would not be cached when this option is enabled.

Round Robin

Round robin is a load-balancing mechanism used by DNS servers to distribute name resolution activity among all available DNS servers. If multiple A or AAAA resource records are found in a DNS query (for example, on a multihomed computer), round robin sequences these resource records randomly in repeated queries for the same computer. An example in which round robin is useful is a situation where you have multiple terminal servers in a server farm that users access for running applications. DNS uses round robin to randomize the sequence in which users accessing the terminal servers reach given servers.

By default, round robin is enabled on Windows Server 2008 R2 DNS servers. You can verify or modify this setting from the Advanced tab of the DNS server’s Properties dialog box already shown in Figure 4-10. Select or clear the check box labeled Enable round robin as required.

SharePoint Security – Authentication

SharePoint Server 2010 on Windows Server 2008 R2 has a lot of possible of authentication scenarios. You are no longer limited to the basic, unfriendly authentication types.  The key is to fully understand the possible security scenarios for authentication, so you will be able to plan the every service security in very detail. In this article I will cover the SharePoint authentication methods, which are obviously very based on the Windows Server 2008 R2 since that is the OS SharePoint runs on.

Authentication Methods for SharePoint Sites

There are three general types of authentication for SharePoint you should know about. The first two types of authentication modes in SharePoint 2010 are Claims Based Authentication (which is new in SharePoint Server 2010) and Classic Mode Authentication (known from previous SharePoint and other Microsoft systems as well). I will start with a short overview of them.

Authentication selection window during the new application creation

Windows Authentication
This is the native, classic type of authentication in Windows systems. There are several methods of Windows Authentication we should mention here:
· Anonymous Authentication: this method allows external and unauthorized users to access the resources. No credentials are required in this method. This method is mostly used for Internet-enabled sites in SharePoint for Internet Sites licensing.
· Basic Authentication: It is a basic Windows method of Authentication, which is insecure and I recommend NOT TO use it. The authorization credentials are sent in clear-text, without any encryption which nowadays is extremely easy to snoop by attacker. This type of authentication should only be used in case of compatibility issues (with browsers, web proxies or firewalls) and only with a secure SSL certificate that will encrypt the sensitive network traffic. Sometimes, old software deployed in the enterprise requires using Basic Authentication (like old monitoring software) – if you’ll ever come into similar situation, try to use SSL with Basic Authentication to encrypt the traffic “manually”.
· Digest Authentication: It is a method similar to Basic Authentication, but it gives you more security because the credentials are encrypted and there is no way to intercept the credentials along the way in the traffic route.
· Certificate Authentication: This method offers the public key certificate mapping authorization. SSL encryption is used for this authentication method. It is not recommended to use this type of authentication over internet traffic.
· NTLM Authentication: It is native for most Microsoft applications (including SharePoint) method of authentication, which is secure and encrypts credentials before they are sent in the network. If you want to move your entire network authentication to Kerberos, you will have to disable NTLM because on most systems it is default authentication method.
· Negotiate Authentication: You can use it with either NTLM or Kerberos authentication (with Kerberos as default). On the client side you have to provide SPN (Service Principal Name) and UPN (User Principal Name) for the account.
Forms Based Authentication
This kind of authentication works with the identity management systems. In SharePoint, it will show up as a typical form authentication where you have two fields (login and password) to enter your credentials. This type of authentication is often used by extranet sites. You can get the users credentials to forms from LDAP based containers, SQL Database or custom, external sources of third party software and credential databases. Forms based authentication fully uses ASP .NET role providers.

Basic Forms Based Authentication form in SharePoint application
Now let me give you an overview of Forms-Based authentication types:
· Lightweight Directory Access Protocol (LDAP) – it can be Active Directory, ADAM or ADFS user/security database.
· Database Based (by default SQL) authentication – in this type of authentication you store permissions in a MS SQL database (or other compatible database system – then you have to install the database native client drivers compatible with ASP .NET).
· Custom, Third Party membership / Role Provider – for most external systems you need to register custom membership provider in web.config file of your forms-enabled application. It hasn’t changed much since MOSS 2007.
Forms Based Authentication can only be enabled in Claims-based applications.
SAML Token Based Authentication
It is the authentication known as Claims Based in SharePoint 2010. It supports Windows Identity Foundation and uses .NET framework entities for Claims Based Authentication. SAML Tokens includes Active Directory Federation Services (available in Windows Server 2008 Enterprise), Windows Live ID authentication and most third party providers. SAML token authentication includes an identity provider security token service (IP-STS), which issues SAML tokens for the users and is used for authorization of these users. If you configure your SharePoint application to authenticate using IP-STS, then that application becomes a relying party STS (RP-STS), which can receive SAML tokens.
Implementing SAML token based infrastructure to your SharePoint farm is a difficult task that requires lot of planning. You need to define identity claim for each user (for example e-mail address as user-identifier), define Claim mappings, create authentication providers to import token-signing certificate, specify a realm that is associated with SAML-Token based SharePoint applications, and finally create a SharePoint application configured to use the SAML-Token enabled authentication provider.
SharePoint Application Zones
SharePoint site application zones define the logical paths for accessing the same web applications. Each web application can include up to five zone definitions. By default, when you create a new web application in SharePoint, it uses the zone named “default”. You can add more zones by extending the web application and use the remaining zones called: intranet, extranet, internet or custom.
In the previous SharePoint versions you could use zones to setup Windows Authentication and Forms authentication to one web application. In the SharePoint 2010 you can only create Windows authentication for Classic Mode authentication, so in this mode using multiple zones will give you the possibility to authenticate from up to five different Active Directory stores. In the Claims Mode web applications you can setup multiple authentication methods for different zones, but if you only want to setup Windows Authentication (from one Active Directory store) and one Forms Authentication (for example from SQL Database user store) – you can do this from single web application zone (for example “default” zone) and you don’t need to extend the web application unless you need to use more than one AD store and Forms store.

Windows Server 2008 R2 DNSSEC–Secure DNS Connections

Introduction

With the upcoming insurgence of IPv6, accessing computers through DNS names will be more important than ever. While those of us who have been working with IPv4 for many years have found it fairly easy to remember a great number of IPv4 addresses using the dotted quad system of IP network numbering, the fact is that the IPv6 address space is so large, and the hexadecimal format is so complex, that it is likely that only a handful of very dedicated nerds will be able to remember the IP addresses of more than a few computers on their networks. After all, each IPv6 address is 128 bits long – four times as long as an IPv4 address. This is what provides for the much larger address space to accommodate the growing number of hosts on the Internet, but it also makes it more difficult for us to remember addresses.

The Problem: Non-secure Nature of the DNS Database

Given the increasing reliance on DNS that is sure to result, we are going to need a way to make sure that the entries in the DNS database are always accurate and reliable – and one of the most effective ways for us to ensure this is to make sure that our DNS databases are secure. Up until recently, DNS had been a relatively non-secure system, with a large number of assumptions made to provide a basic level of trust.

Due to this non-secure nature, there are many high profile instances where the basic trust has been violated and DNS servers have been hijacked (redirecting the resolution of DNS names to rogue DNS servers), DNS records spoofed, and DNS caches poisoned, leading users to believe they are connecting to legitimate sites when in fact they have been led to a web site that contains malicious content or collects their information by pharming. Pharming is similar to phishing, except that instead of following a link in email, users visit the site on their own, using the correct URL of the legitimate site, so they think they’re safe. But the DNS records have been changed to redirect the legitimate URL to the fake, pharming site.

The Solution: Windows Server 2008 R2 DNSSEC

One solution you can use on your intranet to secure your DNS environment is to use the Windows Server 2008 R2 DNSSEC. DNSSEC is a collection of extensions that improve the security of the DNS protocols. These extensions add origin authority, data integrity and authenticated denial of existence to DNS. The solution also adds several new records to DNS, including DNSKEY, RRSIGN, NSEC and DS.

How DNSSEC works

What DNSSEC does is allow all the records in the DNS database to be signed, with a method similar to that used for other digitally signed electronic communications, such as email. When a DNS client issues a query to the DNS server, it returns the digital signatures of the records that it returns. The client, which has the public key of the CA that signed the DNS records, is then able to decrypt the hashed value (signature) and validate the responses. In order to do this, the DNS client and server are configured to use the same trust anchor. A trust anchor is a preconfigured public key associated with a particular DNS zone.

DNS database signing is available for both file based (non-Active Directory integrated) and Active Directory integrated zones, and replication is available to other DNS servers that are authoritative for the zones in question.

The Windows 2008 R2 and Windows 7 DNS clients are configured, by default, as non-validating, security-aware, stub resolvers. When this is the case, the DNS client allows the DNS server to perform validation on its behalf, but the DNS client is able to accept the DNSSEC responses returned from the DNSSEC enabled DNS server. The DNS client itself is configured to use the Name Resolution Policy Table (NRPT) to determine how it should interact with the DNS server. For example, if the NRPT indicates that the DNS client should secure the connection between the DNS client and server, then certificate authentication can be enforced on the query. If security negotiations fail, it is a strong indication that there is a trust issue in the name resolution process, and the name query attempt will fail. By default, when the client returns to the DNS query response to the application that made the request, it will only return this information if the DNS server has validated the information.

Ensuring Valid Results

So there are really two methods that are used to ensure that the results of your DNS queries are valid. First, you need to ensure that the DNS servers that your DNS clients connect to are actually the DNS servers you want the DNS clients to connect to – and that they are not rogue or attacker DNS servers that are sending spoofed responses. IPsec is an effective way to ensure the identity of the DNS server. DNSSEC uses SSL to confirm that the connection is secure. The DNS server authenticates itself via a certificate that is signed by a trusted issuer (such as your private PKI).

Keep in mind that if you have IPsec enforced server and domain isolation in force, you must exempt TCP and UDP ports 53 from the policy. Otherwise, IPsec policy will be used instead of certificate based authentication. This will cause the client to fail certificate validation from the DNS server and the secure connection will not be established.

Signed zones

DNSSEC also signs zones, using offline signing with the dnscmd.exe tool. This results in a signed zone file. The signed zone file contains the RRSIG, DNSKEY, DNS and NSEC resource records for that zone. After the zone is signed, it has to be reloaded using the dnscmd.exe tool or the DNS manager console.

One limitation of signing zones is that dynamic updates are disabled. Windows Server 2008 R2 enables DNSSEC for static zones only. The zone must be resigned each time a change is made to the zone, which may severely limit the utility of DNSSEC in many environments.

The Role of Trust Anchors

Trust anchors were mentioned earlier. DNSKEY resource records are used to support trust anchors. A validating DNS server must include at least one trust anchor. Trust anchors also apply only to the zone that they are assigned. If the DNS server hosts several zones, then multiple trust anchors are used.

The DNSSEC enabled DNS server performs validation for a name in a client query as long as the trust anchor is in place for that zone. The client doesn’t need to be DNSSEC aware for the validation to take place, so that non-DNSSEC aware DNS clients can still use this DNS server to resolve names on the intranet.

NSEC/NSEC3

NSEC and NSEC3 are methods that can be used to provide authenticated denial of existence for DNS records. NSEC3 is an improvement on the original NSEC specification that allows you to prevent “zone walking”, which allows an attacker to retrieve all the names in the DNS zone. This is a powerful tool that attackers can use to reconnoiter your network. This capability is not available in Windows Server 2008 R2, as only support for NSEC is included.

However, there is limited support for NSEC3:

• Windows Server 2008 R2 can host a zone with NSEC that has NSEC3 delegations. However, the NSEC3 child zones are not hosted on Windows DNS servers
• Windows Server 2008 R2 can be a non-authoritative DNS server configured with a trust anchor for a zone that is signed with NSEC and has NSEC3 child zones.
• Windows 7 clients can use a non-Microsoft DNS server for DNS name resolution when that server is NSEC3 aware
• When a zone is signed with NSEC, you can configure the Name Resolution Policy Table to not require validation for the zone. When you do this, the DNS server will not perform validation and will return the response with the Active Directory bit clear

Deploying DNSSEC

To deploy DNSSEC, you will need to do the following:

• Understand the key concepts of DNSSEC
• Upgrade your DNS servers to Windows Server 2008 R2
• Review zone signing requirements, choose a key rollover mechanism, and identify the secure computers and DNSSEC protected zones
• Generate and backup the keys that sign your zones. Confirm that DNS is still working and answering queries after signing the zones
• Distribute your trust anchors to all non-authoritative servers that will perform DNS validation using DNSSEC
• Deploy certificates and IPsec policy to your DNS server
• Configure the NRPT settings and deploy IPsec policy to client computers

For more information on deploying a secure DNS designing using Windows Server 2008 R2, go here.

Summary

In this article, we provided a high level overview of DNSSEC and discussed the reasons that securing your DNS infrastructure is important to your organization. Windows Server 2008 R2 introduces new features that help make your DNS infrastructure more secure than ever, through the combined used of signed DNS zones, SSL secured connections to trusted DNS servers, and IPsec authentication and encryption. In a future article, we’ll take apart the DNSSEC solution in more detail and look at the specifics of the new resource records, the signing process, and the client/server interactions that take place between a DNSSEC client and server