Collection: Windows Server 2003 (2)

Difference betweenw SUS and WSUS

SUS did a great job of keeping Windows up to date, but WUS will be able to 

update other products such as Microsoft Office, Exchange Server and ISA Server.

Eventually, WUS will be able to keep all current Microsoft server products

up to date.

Comparison of Windows Server 2003 Editions

Standard Edition:  4-GB RAM Maximum

Enterprise Edition:  32-GB RAM Maximum, 64-bit Support for Intel Itanium-based, Hot Add Memory

Datacenter Edition:  64-GB RAM Maximum, 64-bit Support for Intel Itanium-based, Hot Add Memory

Web Edition:  2-GB RAM Maximum

In Active Directory a single server always holds at least three directory partitions:

• The schema
• The configuration (replication topology and related metadata)
• One or more per-domain directory partitions (subtrees containing domain-specific objects in the directory)

The KCC and Replication Topology 

The Knowledge Consistency Checker (KCC) uses site link configuration information to enable and optimize replication traffic by generating a least-cost replication topology. Within a site, for each directory partition, the KCC builds a ring topology that tries to set a maximum number of hops (3) between any two domain controllers. Between sites, the KCC creates a spanning tree of all intersite connections. Therefore, adding sites and domains increases the processing that is required by the KCC.

Bridgehead Servers

When domain controllers for the same domain are located in different sites, at least one bridgehead server per directory partition and per transport (IP or SMTP) replicates changes from one site to a bridgehead server in another site. A single bridgehead server can serve multiple partitions per transport and multiple transports. Replication within the site allows updates to flow between the bridgehead servers and the other domain controllers in the site. Bridgehead servers help to ensure that the data replicated across WAN links is not stale or redundant. 

DNS

Domain Name System.

DNS requirement for Active Directory.

  SRV records. SRV Records are the locator records within DNS that allow clients to locate an Active Directory domain controller or global catalog.

What is the difference between DNS and NetBIOS?

  Now, to subject. Computer may have many "names", and two main name groups of names computers have is a "DNS" names and a "NetBIOS"        names.

The "NetBIOS" name is a name you assign to your computer using system->network identification->network ID. This     name is displayed in you "network neighborhood" and generally used in local networks to identify computers.
The "DNS" name is a name given to machine in internet. This name is a synonym to machine IP (because IP is\s not human-friendly). "DNS" name is stored in special internet services (so-called "DNS" servers), not at the computer itself. Generally, computer can be shut off, but it's DNS name will be available and produce correct IP.
For example, if I install OS to new computer and call it "EYE", it will have a NetBIOS name "EYE", and, connecting it to my local network; i can access it in "network neighborhood". But, from the internet, i can't access to it using "EYE" name, and instead i must use its IP - for example - 113.54.25.14. But if i need over users to access it from internet using a human-friendly name, i pay amount of money to sertain organization, and they register a name for it - for example - "www.GregorTheEye.com". Then, user can access my machine using this name, for     example,writing:

ping  www.GregorTheEye.com
or     telnet www.GregorTheEye.com
So, we have 2 names for machine - NetBIOS name and DNS name.
In my local network, following commands will be valid:
ping  113.54.25.14
ping  EYE
ping  www.GregorTheEye.com

  Third command will be valid ONLY if my computer is conected to internet.
And   from the   internet,    valid commands        are:
ping  113.54.14
ping  www.GregorTheEye.com
As you can see, NetBIOS name is not available from internet.
The main difference between NetBIOS name and DNS name is that DNS name will be available only if computer is connected to the internet and has its name registered on it. NetBIOS name will be always available to computers        that  directly     connected to        target       one.
To get DNS name, you must send a request to DNS server (its IP is written in the system registry if you computer is connected to internet). If DNS server is unavailable, it will take default timeout time to discover this. If it's available, DNS server will return you human-friendly name of target machine if it's exist in database.
To obtain a NetBIOS name, you must send UDP packet to target machine and wait for response. Because UDP is not a guaranteed-to-deliver protocol, response may ot came, came corrupted, came many times etc. Your program must patiently wait for response (it's not from 137 port - you must SEND UDP packet to 137 port of target machine, but response will be returned to the port you specify. Only Win95 no OSR2 has a bug there response always returns to port 137).

What is Aging and Scavenging:

DNS servers running Windows Server 2003 support aging and scavenging features. These features are provided as a mechanism for performing cleanup and removal of stale resource records (RRs), which can accumulate in zone data over time.

With dynamic update, RRs are automatically added to zones when computers start on the network. However, in some cases, they are not automatically removed when computers leave the network. For example, if a computer registers its own host (A) RR at startup and is later improperly disconnected from the network, its host (A) RR might not be deleted. If your network has mobile users and computers, this situation can occur frequently.

If left unmanaged, the presence of stale RRs in zone data might cause some problems. The following are examples:

• If a large number of stale RRs remain in server zones, they can eventually take up server disk space and cause unnecessarily long zone transfers.
• DNS servers loading zones with stale RRs might use outdated information to answer client queries, potentially causing the clients to experience name resolution problems on the network.
• The accumulation of stale RRs at the DNS server can degrade its performance and responsiveness.
• In some cases, the presence of a stale RR in a zone could prevent a DNS domain name from being used by another computer or host device.

To solve these problems, the DNS Server service has the following features:

• Time stamping, based on the current date and time set at the server computer, for any RRs added dynamically to primary-type zones. In addition, time stamps are recorded in standard primary zones where aging/scavenging is enabled.
  For RRs that you add manually, a time stamp value of zero is used, indicating that they are not affected by the aging process and can remain without limitation in zone data unless you otherwise change their time stamp or delete them.
• Aging of RRs in local data, based on a specified refresh time period, for any eligible zones.
  Only primary type zones that are loaded by the DNS Server service are eligible to participate in this process.
• Scavenging for any RRs that persist beyond the specified refresh period.

How to configure Aging and Scavenging

   Using the Windows interface

1.   Open DNS.

2.   In the console tree, right-click the applicable DNS server, and then click  Set Aging/Scavenging for all zones.

3.   Select the Scavenge stale resource records check box.

4.   Modify other aging and scavenging properties as needed.

    What is reverse lookup zone:

In most DNS lookups, clients typically perform a forward lookup, which is a search based on the DNS name of another computer as stored in an address (A) resource record. This type of query expects an IP address as the resource data for the answered response.

DNS also provides a reverse lookup process, enabling clients to use a known IP address during a name query and look up a computer name based on its address. A reverse lookup takes the form of a question, such as "Can you tell me the DNS name of the computer that uses the IP address 192.168.1.20?"

DNS was not originally designed to support this type of query. One problem for supporting the reverse query process is the difference in how the DNS namespace organizes and indexes names and how IP addresses are assigned. If the only method to answer the previous question was to search in all domains in the DNS namespace, a reverse query would take too long and require too much processing to be useful.

To solve this problem, a special domain, the in-addr.arpa domain, was defined in the DNS standards and reserved in the Internet DNS namespace to provide a practical and reliable way to perform reverse queries. To create the reverse namespace, subdomains within the in-addr.arpa domain are formed using the reverse ordering of the numbers in the dotted-decimal notation of IP addresses.

This reversed ordering of the domains for each octet value is needed because, unlike DNS names, when IP addresses are read from left to right, they are interpreted in the opposite manner. When an IP address is read from left to right, it is viewed from its most generalized information (an IP network address) in the first part of the address to the more specific information (an IP host address) contained in the last octets.

For this reason, the order of IP address octets must be reversed when building the in-addr.arpa domain tree. The IP addresses of the DNS in-addr.arpa tree can be delegated to companies as they are assigned a specific or limited set of IP addresses within the Internet-defined address classes.

Finally, the in-addr.arpa domain tree, as built into DNS, requires that an additional resource record (RR) type — the pointer (PTR) RR — be defined. This RR is used to create a mapping in the reverse lookup zone that typically corresponds to a host (A) named RR for the DNS computer name of a host in its forward lookup zone.

   Round Robin in DNS

Round robin is a local balancing mechanism used by DNS servers to share and distribute network resource loads. You can use it to rotate all resource record (RR) types contained in a query answer if multiple RRs are found.

By default, DNS uses round robin to rotate the order of RR data returned in query answers where multiple RRs of the same type exist for a queried DNS domain name. This feature provides a simple method for load balancing client use of Web servers and other frequently queried multihomed computers.

If round robin is disabled for a DNS server, the order of the response for these queries is based on a static ordering of RRs in the answer list as they are stored in the zone (either its zone file or Active Directory).

Example: Round-robin rotation

A forward lookup-type query (for all A RRs that match a DNS domain name) is made for a multihomed computer (multihomed.example.microsoft.com) that has three IP addresses. Separate A RRs are used to map the host's name to each of these IP addresses in the zone. In the stored example.microsoft.com zone, the RRs appear in this fixed order:

multihomed   IN  A  10.0.0.1

multihomed   IN  A  10.0.0.2

multihomed   IN  A  10.0.0.3

The first DNS client that queries the server to resolve this host's name receives the list in default order. When a second client sends a subsequent query to resolve this name, the list is rotated as follows:

multihomed   IN  A  10.0.0.2

multihomed   IN  A  10.0.0.3

multihomed   IN  A  10.0.0.1

Restricting round-robin rotation for selected RR types

By default, DNS will perform round-robin rotation for all RR types. You can specify that certain RR types are not to be round-robin rotated in the registry. There is a registry entry called DoNotRoundRobinTypes (REG_SZ) with a string value containing a list of RR types. By modifying this entry, you turn off round-robin rotation for specific RR types. For example, to prevent round-robin rotation for A, PTR, SRV, and NS record types, you would enter the following value for the registry entry:

a ptr srv ns

Restricting round-robin rotation for all RR types

The default setting for round-robin rotation is contained in the registry entry RoundRobin (REG_DWORD). By default, this entry's value is 1, rotating all RR types except those listed in the DoNotRoundRobinTypes registry entry. If the value of RoundRobin is set to 0, then no RR types will be round-robin rotated.

   What are DNS Zone?

A DNS zone is the contiguous portion of the DNS domain name space over which a DNS server has authority, or is authoritative. A zone is a portion of a namespace . it is not a domain. A domain is a branch of the DNS namespace. A DNS zone can contain one or more contiguous domains. A DNS server can be authoritative for multiple DNS zones. A noncontiguous namespace cannot be a DNS zone.

A zone contains the resource records for all of the names within the particular zone. Zone files are used if DNS data is not integrated with Active Directory. The zone files contain the DNS database resource records which define the zone. If DNS and Active Directory are integrated, then DNS data is stored in Active Directory.

The different types of zones used in Windows Server 2003 DNS are listed below:

·         Primary zone

·         Secondary zone

·         Active Directory-integrated zone

·         Reverse lookup zone

·         Stub zone

A primary zone is the only zone type that can be edited or updated because the data in the zone is the original source of the data for all domains in the zone. Updates made to the primary zone are made by the DNS server that is authoritative for the specific primary zone. You can also back up data from a primary zone to a secondary zone.

A secondary zone is a read-only copy of the zone that was copied from the master server during zone transfer. In fact, a secondary zone can only be updated through zone transfer.

An Active Directory-integrated zone is a zone that stores its data in Active Directory. DNS zone files are not needed. This type of zone is an authoritative primary zone. Zone data of an Active Directory-integrated zone is
replicated during the Active Directory replication process. Active Directory-integrated zones also enjoy the security features of Active Directory.

A reverse lookup zone is an authoritative DNS zone. These zones are mainly used to resolve IP addresses to resource names on the network. A reverse lookup zone can be either of the following zones:

·         Primary zone

·         Secondary zone

·         Active Directory-integrated zone

A stub zone is a new Windows Server 2003 feature. Stub zones only contain those resource records necessary to identify the authoritative DNS servers for the master zone. Stub zones therefore contain only a copy of a zone, and are used to resolve recursive queries and iterative queries:

·         Iterative queries: The DNS server provides the best answer it can. This can be:

o    The resolved name

o    A referral to a different DNS server

·         Recursive queries: The DNS server has to reply with the requested information, or with an error. The DNS server cannot provide a referral to a different DNS server

Stub zones contain the following information:

·         Start of Authority (SOA) resource records of the zone.

·         Resource records that list the authoritative DNS servers of the zone

·         Glue address (A) resource records that are necessary for contacting the authoritative servers of the zone.

Zone delegation occurs when you assign authority over portions of the DNS namespace to subdomains of the DNS namespace. You should delegate a zone under the following circumstances:

·         You want to delegate administration of a DNS domain to a department or branch of your organization.

·         You want to improve performance and fault tolerance of your DNS environment . you can distribute DNS database management and maintenance between several DNS servers.

DNS Zone Transfer

A zone transfer can be defined as the process that occurs to copy the resource records of a zone on the primary DNS server to secondary DNS servers. Zone transfer enables a secondary DNS server to continue handling queries if the primary DNS server fails. A secondary DNS server can also transfer it zone data to other secondary DNS servers, who are beneath it in the DNS hierarchy. In this case, the secondary DNS server is regarded as the master DNS server to the other secondary servers.

The zone transfer methods are:

· Full transfer: When you configure a secondary DNS server for a zone, and start the secondary DNS server, the secondary DNS server requests a full copy of the zone from the primary DNS server. A full transfer is performed of all the zone information. Full zone transfers tend to be resource intensive. This disadvantage of full transfers has led to the development of incremental zone transfers.

· Incremental zone transfer: With an incremental zone transfer, only those resource records that have since changed in a zone are transferred to the secondary DNS servers. During zone transfer, the DNS databases on the primary
DNS server and the secondary DNS server are compared to determine whether there are differences in the DNS data. If the DNS data of the primary and secondary DNS servers are the same, zone transfer does not take place. If the DNS data of the two servers are different, transfer of the delta resource records starts. This occurs when the serial number on the primary DNS server database is higher than that of secondary DNS server.s serial number. For incremental zone transfer to occur, the primary DNS server has to record incremental changes to its DNS database. Incremental zone transfers require less bandwidth than full zone transfers.

· Active Directory transfers: These zone transfers occur when Active Directory-integrated zones are replicated to the domain controllers in a domain. Replication occurs through Active Directory replication.

Understanding DNS Resource Records (RRs)

The DNS database contains resource records (entries) that are used to resolve name resolution queries sent to the DNS server. Each DNS server contains the resource records (RRs) it needs to respond to name resolution queries for the portion of the DNS namespace for which it is authoritative. There are different types of resource records.

While there are various resource records that contain different information or data, there are a few required fields that each particular resource record has to contain:

·Owner; the DNS domain that contains the resource record

·TTL (Time to Live); indicates the time duration that DNS servers can cache resource record information,
prior to discarding the information. This is however an optional resource records field.

·Class; is another optional resource records field. Class types were used in earlier implementations of the
DNS naming system, and are no longer used these days.

·Type; indicates the type of information contained by the resource record.

· Record-Specific Data; a variable length field that further defines the function of the resource. The format
of the field is determined by Class and Type.

Delegation records and glue records can also be added to a zone. These records are used to delegate a subdomain into a separate zone.

·Delegation records: These are Name Space (NS) resource records in a parent zone. The delegation record specifies the parent zone as being authoritative for the delegated zones.

·Glue records: These are A type resource records for the DNS server who is authoritative for delegated zone.

The more important resource records are discussed now. This includes the following:

·Start of Authority (SOA), Name Server (NS), Host (A), Alias (CNAME), Mail exchanger (MX), Pointer (PTR), Service location (SRV)

Start of Authority (SOA) Resource Record

This is the first record in the DNS database file. The SOA record includes information on the zone property information, such as of the primary DNS server for the zone, and version information.

The fields located within the SOA record are listed below:

·Source host; the host for who the DNS database file is maintained

·Contact e-mail; e-mail address for the individual who is responsible for the database file.

·Serial number; the version number of the database.

·Refresh time; the time that a secondary DNS server waits, while determining whether database updates have been made, that have to be replicated via zone transfer.

·Retry time; the time for which a secondary DNS server waits before attempting a failed zone transfer again.

·Expiration time; the time for which a secondary DNS server will continue to attempt to download zone information. Old zone information is discarded when this limit is reached.

·Time to live; the time that the particular DNS server can cache resource records from the DNS database file.

Name Server (NS) Resource Record

The Name Server (NS) resource record provides a list of the authoritative DNS servers for a domain, as well authoritative DNS server for any delegated subdomains. Each zone must have one (or more) NS resource records at the zone root. The NS resource record indicates the primary and secondary DNS servers for the zone defined in the SOA resource record. This in turn enables other DNS servers to look up names in the domain.

Host (A) Resource Record

The host (A) resource record contains the IP address of a specific host, and maps the FQDN to this 32-bit IPv4 addresses. Host (A) resource records basically associates the domain names of computers (FQDNs) or hosts names to their associated IP addresses. Because a host (A) resource record statically associates a host name to a specific IP address, you can manually add these records to zones if you have machines who have statically assigned IP addresses.

The methods which are used to add host (A) resource records to zones are:

·Manually add these records, using the DNS management console.

·You can use the Dnscmd tool at the command line to add host (A) resource records.

·TCP/IP client computers running Windows 2000, Windows XP or Windows Server 2003 use the DHCP Client service to both register their names, and update their host (A) resource records.

Alias (CNAME) Resource Record

Alias (CNAME) resource records ties an alias name to its associated domain name. Alias (CNAME) resource records are referred to as canonical names. By using canonical names, you can hide network information from the clients who connect to your network. Alias (CNAME) resource records should be used when you have to rename a host that is defined in a host (A) resource record in the identical zone.

Mail exchanger (MX) Resource Record

The mail exchanger (MX) resource record provides routing for messages to mail servers and backup servers. The mail MX resource record provides information on which mail servers processes e-mail for the particular domain name. E-mail applications therefore mostly utilize MX resource records.

A mail exchanger (MX) resource record has the following parameters:

·Priority

·Mail server

The mail exchanger (MX) resource record enables your DNS server to work with e-mail addresses where no specific mail server is defined. A DNS domain can have multiple MX records. MX resource records can therefore also be used to provide failover to different mail servers when the primary server specified is unavailable. In this case, a server preference value is added to indicate the priority of a server in the list. Lower server preference values specify higher preference.

Pointer (PTR) Resource Record

The pointer (PTR) resource record points to a different resource record, and is used for reverse lookups to point to A resource records. Reverse lookups resolve IP addresses to host names or FQDNs.

You can add PTR resource records to zones through the following methods:

·Manually add these records, using the DNS management console.

·You can use the Dnscmd tool at the command line to add PTR resource records.

Service (SRV) Resource Records

Service (SRV) resource records are typically used by Active directory to locate domain controllers, LDAP servers, and global catalog servers. The SRV records define the location of specific services in a domain. They associate the location of a service such as a domain controller or global catalog server; with details on how the particular service can be contacted.

The fields of the service (SRV) resource record are explained below:

· Service name

· The protocol used

· The domain name associated with the SRV records.

· The port number for the particular service

· The Time to Live value

· The class

· The priority and weight.

· The target specifying the FQDN of the particular host supporting the service

The Zone Database Files

 

If you are not using Active Directory-integrated zones, the specific zone database files that are used for zone data are:

·Domain Name file: When new A type resource records are added to the domain, they are stored in this file. When a zone is created, the Domain Name file contains the following:

o A SOA resource record for the domain

o A NS resource record that indicates the name of the DNS server that was created.

· Reverse Lookup file: This database file contains information on a reverse lookup zone.

· Cache file: This file contains a listing of the names and addresses of root name servers that are needed for resolving names which are external to the authoritative domains.

· Boot file: This file controls the startup behavior of the DNS server. The boot file supports the commands listed below:

o Directory command; this command defines the location of the other files specified in the Boot file.

o Primary command; defines the domain for which this particular DNS server has authority.

o Secondary; specifies a domain as being a secondary domain.

o Cache command; this command defines the list of root hints used for contacting DNS servers for the root domain

DNS TTL

TTL is an acronym for Time To Live and refers to the capability of the DNS servers to cache DNS records. It represents the amount of time that a DNS record for a certain host remains in the cache memory of a DNS server after the latter has located the host's matching IP address.
By specifying TTL settings for a particular domain's DNS records, webmasters define the frequency of website content updates. The longer the TTL value is, the faster the domain resolution time periods will be. The TTL value can be set from one to several hours, if you are not planning any changes to your domain's DNS records in the meantime. If you need to make such changes, you will have to decrease the TTL value entry to several minutes to avoid any outdated data on your website.