Dns zone types. Reverse domain names (reverse DNS) and their place in the operation of a mail server
In domains Windows information DNS stores the services required for systems to operate. And the majority of problems in the functioning of a domain (directory service) are associated precisely with incorrect setting DNS service administrators. Therefore, it is worth considering the DNS server in more detail.DNS terms
DNS (Domain Name System Domain Name System) is a name resolution service for networks based on the TCP/IP protocol.
DNS zones
A DNS zone is a portion of a namespace for which a DNS server can perform name resolution operations. There are forward and reverse lookup zones, which in practice are called forward and reverse lookup zones for convenience.
The forward zone allows you to obtain its IP address by the system name, the reverse zone “gives out” information about the host name by the IP address. Therefore, if you need to find out its address by the computer name, then they talk about direct name resolution. If they want to get a computer name from an IP address, then in this case reverse name resolution occurs. Strictly speaking, if it is registered in DNS direct resolution name, then the reverse must also be registered.
Lack of reverse name resolution is a fairly common mistake on the Internet. Typically, the owners of the forward zone of a given domain and the reverse zone that corresponds to this name are different people(organizations), so when registering new DNS records, people often forget to create a corresponding reverse zone record.
In fact, direct zones correspond to domains of some level. For example, the ask.ru zone allows you to resolve all name requests related to the ask.ru domain.
To resolve reverse names in the domain itself top level The in-addr.arpa zone has been created. Reverse lookup zone names are formed by adding three octets of the network address to the left of this name in reverse order. For example, for the network 195.161.192.0/24, the reverse zone name would be 192.161.195.in-addr.arpa.
In most cases, the lack of registration in the reverse zone does not interfere normal operation online. However, it can also lead to errors in cases where it is necessary to set the server name by IP address. For example, when exchanging email messages, it is now customary to check that the server belongs to the domain on behalf of which it transmits mail. If reverse name resolution is not carried out, the system may be refused to accept mail.
Primary and secondary zones
U records created DNS must have one "master". For all records to be correct, they must be entered on the same DNS server. In this case, the primary zone is said to be located on such a DNS server. For fault tolerance, you can create copies of this zone on other servers: such zones will be called secondary zones. The secondary zone contains the same records as the primary zone, but changes cannot be made to it or new records can be added. These operations can only be done for the primary zone.
Zone name servers
For each primary zone, you can create as many copies as you like on other servers. Typically, DNS server settings include special notification mechanisms that ensure synchronization of records in the primary zone and its copies on secondary servers. But, if this is not prohibited by the DNS server settings, you can create a secondary zone on your server, the updates of which will be carried out according to a certain schedule. As a result, the records of such a copy may no longer be current. Therefore, it is customary to define name servers for a domain whose information is “official.” Such servers are called NS records of the corresponding domain. Typically, two or three NS servers are created for each domain. If a response to a name resolution request is received from the NS server, then it is considered authorized; other servers return unauthorized responses.
This does not mean that incorrect data is returned in this case. The DNS server will resolve the client's request based on the data from its copy only if the data is not out of date. But if the lifetime of records on the name server was set, for example, to a week, then in the event of changes being made to the primary zone, you must be prepared for the fact that even before a week after changing the information on the NS server, other DNS servers may return hundred. Windows domain 2000 and using the DNS zone. integrated with the directory service, changes can be made to any DNS server in that zone.
Valid values
That is, you will be faced with a situation where some systems have already received the correct name data, while others have not. Therefore, before the intended change of DNS records, it is necessary to reduce their lifetime and wait a period equal to the old lifetime. This will reduce the period of such uncertainty in name resolution. After completing the configuration operation, you should return to the old values to reduce the load on the network and DNS servers. If you suspect that the copy of DNS records on the DNS server is out of date, you should perform a cache flush operation for the appropriate zone. To do this, you need to enable the option to display additional parameters in the server management console, find the desired zone among the cache structure and clear it. The next time a request is made for data from this zone, the server will download a copy from the DNS server to which requests are forwarded. Therefore, this operation also does not guarantee obtaining an up-to-date copy of the records. When considering problem situations, you should find out official resources addresses of NS servers of this domain and check the records using the utility nslookup, connecting to the corresponding NS server.
To update DNS records on client computers, you must clear the DNS record cache (ipconfig /flushdns).
Transfer of zones
This is the name of the special operation of copying all records of a given zone from one DNS server to another. For security reasons, zone transfers are usually only allowed to a list of DNS server IP addresses predefined by the system administrator. If the zone transfer operation is disabled, then you will not be able to create a secondary zone on your DNS server for this domain.
Zone delegation
If, for example, a direct zone for a domain is created on the DSN server test.local, then the record about the third level domain level3.test.local must be contained on the same server. If geographically the domain level3.test.local is removed from the main domain, then maintaining records in its zone on the DNS server becomes not very convenient. It is easier to instruct the administrator of this domain to make changes to DNS records themselves, for which the process of zone delegation is used. When a zone is delegated, the DNS server creates a record in itself indicating that name resolution requests for that zone should be forwarded to another DNS server to which the zone has been delegated.
Stub zone (stub zone)
When delegating a zone to original server information about the MS server of the delegated zone is saved. Since the administrator of a delegated zone can change its DNS records, he can also change the NS server records. If the appropriate change is not made to the server that is performing the delegation, the name resolution process will be broken (the primary server will still send requests to the address that no longer exists, resulting in an incorrect response). For correction similar situation V Windows DNS server Server 2003 introduced stub zones. When a stub zone is created, the NS records of the delegated zone are defined in it. Moreover, if the administrator of the delegated zone changes these records, then the corresponding changes are made to the records of the stub zone. As a result, the integrity of the name resolution process is guaranteed.
Point zone
The top-level domain, as already written, is usually called “dot”. If you create a “dot” zone in DNS, this will actually mean that this server is the root in the DNS structure, i.e. it must independently resolve any name queries. If this DNS server cannot resolve the name, then its response will be that such a host does not exist.
If necessary, forwarding DNS queries to other servers, the dot zone should be deleted, after which it will be possible to configure forwarding of DNS requests.
Types of requests
There are two types of queries for name resolution in DNS: iterative and recursive. An iterative query is used to obtain from the DNS server to which it is sent the best answer that can be obtained without contacting other DNS servers. A recursive query requires the DNS server to perform all operations to resolve the name. Typically, a zone with this name is created when you install the directory service and at the same time configure the DNS server.
DNS Name Resolution Procedure
DNS name resolution sequence. The process of determining a name using iterative queries is quite labor intensive. You need to find an NS server for a given domain and then request data from it for the required name. Typically, clients “entrust” all these operations to DNS servers by sending them a recursive request. The DNS server looks up its own cache of names after receiving a recursive query. If he finds the desired entry and it is not yet out of date, then this value is returned to the client. If there is no entry, the server attempts to find a nameserver for the domain contained in the request. To find such a server, a request is always sent to the root server, information on the first-level domain is obtained from it, information about the NS servers of the second-level domain is obtained by a request to the first-level domain, etc. After this, an iterative request is sent to the NS server of the corresponding domain. Naturally, most of the information from the root domains is already cached on this server. As a result, requests “do not reach” the root servers, but the name resolution chain itself is always executed from the root to the current domain. Typically, administrators of local DNS servers configure their server to forward name resolution requests to a particular DNS server (usually the ISP's DNS server). Thus, the entire name resolution procedure will be performed by another server. Since powerful Internet servers usually have a significantly larger cache and best channel connection to the global network, then in this way a decrease in response time and a decrease in traffic is achieved.
Direct View needed to resolve domain names to IP addresses, reverse lookup– to resolve IP addresses in domain names.
Each network segment must have a reverse lookup zone. Specifically, if you have subnets 192.168.10.0, 192.168.11.0, and 192.168.12.0, you should have three reverse lookup zones.
The standard reverse lookup zone name is made up of the network ID in reverse order and the suffix in-addr.arpa. The reverse lookup zones from the previous example would be called 10.168.192. in-addr.arpa, 11.168.192.in-addr.arpa and 12.168.192.in-addr.arpa. Reverse and forward lookup zone recordings must be synchronized. If synchronization fails in the domain, authentication may fail.
To create a reverse lookup zone, follow these steps:
1. Open the console DNS Manager and connect to the desired server.
2. Click right click server element and select the command Create a new zone (New Zone). Will open New-Zone Wizard. Click Next.
3. If you are setting up a primary server integrated with Active Directory, set the switch Primary Zone and make sure the checkbox is checked . If you do not want to integrate DNS into Active Directory, select the radio button Primary Zone and uncheck the box Store The Zone In Active Directory. Click Next.
4. If you are configuring a reverse lookup zone for a secondary server, select the radio button Secondary Zone and click Next.
5. If you are integrating a zone with Active Directory, choose one of the following replication strategies:
For all DNS servers in this forest (That is All DNS Servers In This Forest) This is an extensive replication strategy. Remember that an Active Directory forest includes all domain trees that share directory data with the current domain.
For all DNS servers in this domain (That is All DNS Servers In This Domain) Select this strategy to replicate DNS information within the current domain and its child domains.
For all domain controllers in this domain (That is All Domain Controllers In This Domain) Select this strategy if you want to replicate DNS information to all domain controllers within the current domain and its child domains. Although this strategy allows for wider replication DNS information within a domain, not every domain controller is a DNS server (you don't need to configure every domain controller as a DNS server).
6. Set the switch Reverse Lookup Zone. Click Next.
7. Specify for which addresses you want to create a reverse lookup zone (IPv4 or IPv6) and click Next. Perform one of the following actions:
If you are setting up for IPv4, enter the network ID for the reverse lookup zone. The values you enter determine the default name for the reverse lookup zone. Click Next.
If you are setting up for IPv6, enter the network prefix for the reverse lookup zone. Zone names are automatically generated based on the values you enter. Depending on the prefix entered, you can create up to eight zones. Click Next.
8. If you are setting up a basic or additional server, not integrated with Active Directory, specify the zone file name. The default file name for the DNS zone database should already be entered. Leave it unchanged or enter a new name. Click Next.
9. Select whether to allow dynamic updates. You have three options:
Allow Only Secure Dynamic Updates If your zone is Active Directory integrated, you can use ACLs to limit which clients can perform dynamic updates. If you select this switch, only clients with authenticated computer accounts and approved ACLs can dynamically update resource records.
Allow Both Nonsecure And Secure Dynamic Updates Select this switch to allow any client to update its resource records in DNS when changes occur.
Do Not Allow Dynamic Updates This switch disables dynamic DNS updates. It should only be used if the zone is not integrated with Active Directory.
After installing reverse lookup zones, you need to ensure that delegation is processed correctly for the zone. Connect with information department or your ISP to verify zone registrations in the parent domain.
The Domain Name System is the basis modern Internet. People do not want to bother themselves with remembering the set of numbers 63.245.217.105, but want the computer to connect them to the specified node using the name mozilla.org. This is what DNS servers do: they translate people's requests into something they can understand. digital format. However, in some cases, a reverse IP address → DNS name conversion may be required. Such names will be discussed below.
What is it for?
Having a correctly configured rDNS address is absolutely necessary to send messages from your own server corporate mail. Almost all mail servers will reject the message at the start of the session if your server's IP address does not have an entry in the reverse DNS zone. The reason for failure by the remote mail server will most likely be indicated as follows:
550-"IP address has no PTR (address to name) record in the DNS, or when the PTR record does not have a matching A (name to address) record. Pls check and correct your DNS record."
or
550-There"s no corresponding PTR for your IP address (IP-address), which is 550 required. Sorry, bye.
or simply
550 Your IP has no PTR Record
The number 550 in all three cases is standard code postal SMTP server a reporting about critical error, which insurmountably prevents further work within this mail session. It must be said that in general all errors of the 500 series are critical and it is impossible to continue sending mail after they appear. The text explains the reason for the refusal in more detail and states that the administrator mail server- the recipient configured it to check whether the sending mail server has an entry in the reverse DNS zone (rDNS) and if it is missing, the receiving server is obliged to refuse the sender a connection (SMTP errors 5XX series).
How to set up and use?
Only the owner of the corresponding block of IP addresses to which this zone corresponds has the rights to configure a reverse DNS zone. As a rule, this owner is the provider, who owns his own autonomous system. Learn more about registering your autonomous system(AS) and IP address block can be read in this article. In short, to register a reverse DNS zone, the operator of an IP address block must register in his personal account on the RIPE website, an object of type “domain”, specify the address of DNS servers that will support the rDNS zone and configure support for a zone like 3.2.1.in-addr.arpa on them. A pointer, a PTR record, is responsible for resources in the reverse zone. This is where requests go to resolve the IP address into a host name.
If you are not the happy owner of an autonomous system, then setting up rDNS for an IP address or mail server addresses for you begins and ends with a request to the support service of the provider or hoster. In both cases, the name of the IP address of the mail server, and especially the corporate mail server, should be given meaningfully.
Examples of good names for a mail server:
mail.domain.ru
mta.domain.ru
mx.domain.ru
Examples of bad names:
host-192-168-0-1.domain.ru
customer192-168-0-1.domain.ru
vpn-dailup-xdsl-clients.domain.ru
and the like. Such names are highly likely to be filtered as being assigned to client computers on which a mail server cannot be installed, and therefore spam is sent from them.
You can and should successfully use queries to reverse DNS zones immediately after starting the mail server. To do this, you only need to make small setup BY. In different mail servers, setting up rDNS checking is done differently:
reject_unknown_client
verify = reverse_host_lookup
In the Exgange Server snap-in, go to the Servers section, then select the server in the expanded list, select Protocols, then SMTP protocol, in the right window, select the SMTP server and click right key mouse select from the Properties list. Next, Delivery tab → Perform reverse DNS lookup on incoming messages
Now all messages from IP addresses that do not have a reverse DNS record (PTR type records) will be rejected, and the flow of spam will be significantly reduced. Perhaps this is the simplest, most effective and least resource-intensive of all spam filtering methods: reverse DNS checking cuts off the vast majority of spam sent from infected computers of ordinary users that make up spammers’ botnets.
When republishing an article, installing an active indexed hyperlink to the source - site site is required!
A zone is a database containing authoritative information about a region of the DNS namespace. When you install a DNS server with a domain controller, a DNS zone is automatically created to support the Active Directory domain. If the DNS server was installed on a domain controller, domain member server, or standalone server, zones must be created and configured manually.
This lesson describes how to create and configure a zone and provides the information needed to correctly configure a zone.
Creating zones
Zone DNS is a database containing records thatassociate names with addresses in the described region of the DNS namespace. Althoughto answer name queries, the DNS server can use cachedinformation from other servers, he is authorized to respond to requests only inlocally controlled area. For any scope of the DNS namespace,represented by a domain name (for example, google .ru), there is only oneauthoritative source of zone data.
If you need to create a new zone on the DNS server, you can use the New Zone Wizard in the DNS Manager. To launch the wizard, right-click the server icon in the DNS Manager console tree and use the New Zone command.
The New Zone Wizard contains next pages configurations:
■ Zone Type;
■ Zone replication area, integrated V Active Directory (Active Directory Zone Replication Scope);
■ Forward or Reverse Lookup Zone;
■ Zone Name;
■ Dynamic update (Dynamic Update).
The following sections describe the configuration concepts associated with these five wizard pages.
Selecting a zone type
On the Zone Type page of the New Zone Wizard, you can choose to create a primary zone, a secondary zone, or a stub zone. By creating a primary or stub zone on a domain controller, you can store zone data in Active Directory.
* Main areas
The most common type of DNS zone is the Primary zone. It provides the source read/write data that grants the local DNS server the authority to respond to DNS namespace scope DNS queries.
The local DNS server that manages the primary zone serves as the primary source of data about that zone. The server stores a master copy of zone data in a local file or in Active Directory Domain Services (AD DS). If the zone is saved to a file rather than to Active Directory, the default file name is zone_name.dns and is stored in the %systemroot%\System 32\Dns folder on the server.
*Additional zones
Provides an authoritative, read-only copy of the primary zone or one additional zone.
Secondary zones provide the ability to reduce the amount of DNS query traffic in areas of the network where zone data is heavily queried and used. In addition, if the server that manages the main zone is unavailable, additional zone can provide name resolution until the primary server becomes available again.
The source zones from which additional zones receive information are called master zones, and the data copying procedures that ensure zone information is regularly updated are called zone transfers. A master zone can be a main zone or another additional zone. A master zone can be assigned to an additional zone being created in the New Zone Wizard. Because a secondary zone is a copy of the primary zone managed by another server, it cannot be stored in Active Directory.
* Stub zones
Similar to a secondary zone, but contains resource records necessary to identify authoritative DNS servers in the main zone. Stub zones are often used to allow a parent zone (for example, google .ru) to use an updated list of name servers available in a delegated child zone (for example: translate .google .ru). They also serve to improve name resolution and simplify DNS administration.
* Storing zones inActiveDirectory
When you create a primary zone or a stub zone on a domain controller, on the Zone Type page of the wizard, you can select the option to save the zone in Active Directory. Active Directory-integrated zone data is automatically replicated to Active Directory according to the settings selected on the Active Directory Zone Replication Scope page. Thanks to this option, there is no need to configure zone transfer to additional servers.
Integrating a DNS zone into Active Directory provides several benefits. First, because Active Directory services perform zone replication, there is no need to configure a separate DNS zone transfer mechanism between the primary and secondary servers. Multiple network replication automatically provides fault tolerance and improved performance due to the availability of multiple read/write primary servers. Second, Active Directory allows you to update and replicate individual properties of resource records on DNS servers. Because many complete resource records are not transferred, the load on network resources during zone transfer. Finally, Active Directory-integrated zones also provide optional dynamic update security requirements, which can be configured on the Dynamic Update page of the New Zone Wizard.
NOTE: Read-only domain controllers and zones integrated with Active Directory
On traditional domain controllers, a copy of the zone is granted read/write permission. On read-only domain controllers (RODCs), the zone copy is assigned read-only permission.
* Standard zones
When you create a zone on a domain controller, the option to save the zone in Active Directory on the Zone Type page is selected by default. However, you can clear this checkbox and create a so-called standard zone. On a server that is not a domain controller, you can only create standard zones, and the checkbox on this page is grayed out.
Unlike an Active Directory-integrated zone, a standard zone stores its data in text file on the local DNS server. Additionally, if you use standard zones, you can configure only the primary copy with read and write permissions for the zone data. All other copies of the zone (additional zones) are assigned read-only permission.
The standard zone model assumes a single point of failure for the writable version of the zone. If the main zone is unavailable on the network, no changes can be made to the zone. However, requests for names in a zone may not be interrupted while additional zones are available.
Selecting the zone replication scope integrated inActiveDirectory
On the Active Directory Zone Replication Scope page of the New Zone Wizard, you can select the domain controllers on your network to save zone data to. This page appears only when you select the option to save the zone and Active Directory. The zone replication scope selection options determine the domain controllers among which zone data will be replicated.
This page provides the following options:
■ Zone persistence on all domain controllers, which are also DNS servers, throughout the entire Active Directory forest;
■ Zone persistence on all domain controllers that also serve as DNS servers and local domain Active Directory;
■ Preservation of the zone on all domain controllers and the local Active Directory domain (used for compatibility with Windows 2000);
■ Preserves the zone on all specified domain controllers and the scope of the custom Active Directory directory partition.
These options are described in more detail in the second topic.
Creating Forward and Reverse Lookup Zones
On the Forward or Reverse Lookup Zone page of the New Zone Wizard, you must select the type of zone to be created; Forward Lookup Zone or Reverse Lookup Zone.
In forward lookup zones, DNS servers map FQDNs to IP addresses. In reverse lookup zones, DNS servers map IP addresses to FQDNs. Thus, forward lookup zones respond to requests to resolve FQDNs to IP addresses, and reverse lookup zones respond to requests to resolve IP addresses to FQDNs. Note that forward lookup zones are named according to the D NS domain names for which permission is executed, for example google .com. Reverse lookup zones are named in reverse order of the first three octets of the address space for which name resolution is provided, plus an additional in-addr.arpa tag. For example, if you resolve names for the 192.168.1.0/24 subnet, the reverse lookup zone will be named 1.168.192.in-addr.arpa. In the forward lookup zone, the individual database record that maps a host name to an address is called a record node(A). In a reverse lookup zone, the individual database entry that maps an IP address to a hostname is called pointer or PTR record.
The operating principle of my forward and reverse lookups is demonstrated in the figure.
Live View Zone
Reverse Lookup Zone
NOTE: DNS Server Setup Wizard
You can use the Configure A DNS Server Wizard to create forward and reverse lookup zones simultaneously. To start the wizard, in the DNS Manager console tree, right-click the server icon and choose Configure A DNS Server.
Selecting a zone name
On the Zone Name page of the New Zone Wizard, you can select a name for the forward lookup zone to be created. Reverse lookup zones are given special names based on the range of IP addresses for which they are authoritative.
If you are creating a zone for name resolution in an Active Directory domain, it is best to specify a zone name that matches the Active Directory domain name. For example, if an organization contains two Active Directory domains named google.ru and translate.google.ru, the name resolution infrastructure must include two zones named after those domain names.
If you are creating a zone for a DNS namespace that is not in an ActiveDirectory environment, you must specify the organization's Internet domain name, such as wikipedia .org.
NOTE: AdditionDNS server per domain controller
To add a DNS server to existing controller domain, usually a copy of the primary zone is added to provide name resolution in the local Active Directory domain. To do this, you simply create a zone whose name matches the name of an existing zone in the local Active Directory domain. The new zone will be populated with data from other DNS servers in the domain.
Configuring dynamic update settings
Client DNS computers can register and dynamically update their resource records using a DNS server. By default, DNS clients with static IP addresses update host (A or AAAA) and pointer (PTR) records, while DNS clients that are DHCP clients only update host records. In the environment working group The DHCP server updates the pointer entries on behalf of the DHCP client whenever the IP configuration is updated.
For dynamic DNS updates to succeed, the zone in which clients register or update records must be configured to accept dynamic updates. There are two types of this update:
■ Safeupdate (Secureupdates)
Allows you to perform registration only from computers in the Active Directory domain and update only from the computer that initially performed the registration.
■ Unsafeupdates (Nonsecureupdates)
Allows you to update from any computer.
On the Dynamic Update page of the New Zone Wizard, you can allow secure, insecure dynamic updates, or disable updates altogether for the zone you are creating.
Analyzing Built-in Resource Records
When you create a new zone, two types of records are automatically created. First, such a zone always includes an initial SOA (Start Of Authority) zone record that defines the basic properties of the zone. In addition, new zones contain at least one NS (Name Server) record that specifies the name of the zone's authoritative server(s). The following describes the functions of these two resource records.
Initial zone entries
When loading a zone, the DNS server uses the zone's SOA (Start Of Authority) record to determine the basic properties and authorities of the zone. These parameters also characterize the frequency of zone transfers between the main and secondary servers. Double-clicking an SOA entry opens the Start Of Authority (SOA) tab of the zone properties dialog box.
■ Serialnumber (Serial Number)
This text field on the Initial Zone Record (SOA) tab contains the revision number of the zone file. The number specified here increases each time the resource records in the zone change. It can also be increased manually using the Increment button.
If zones are configured to perform zone transfers to one or more secondary servers, those secondary servers periodically query the primary server for the zone serial number. These requests are called SOA requests. If the SOA request receives a primary zone serial number that is equal to the secondary zone serial number, the transfer fails. If the zone serial number on the main server is greater than the corresponding value on the requesting secondary server, the latter initiates a zone transfer.
NOTE: Transferring zones on the main server
Clicking the Increment button initiates zone transfer.
■ Basicserver (PrimaryServer)
■ ResponsibleResponsible Person
This field is where you enter the Responsible Person (RP) name that corresponds to the zone administrator's domain mailbox. The name entered in this field must always end with a period. The default name is hostmaster.
■ Intervalupdates (Refresh Interval)
The value in this field determines how long the secondary DNS server waits before requesting a zone update on the primary server. After the update interval expires, the secondary DNS server queries the primary server for a copy of the current SOA record. After receiving the response, the secondary DNS server compares the serial number of the current SOA record of the primary server (specified in the response) with serial number your local SOA entry. If these values differ, the secondary DNS server requests a zone transfer from the primary DNS server. The default update interval is 15 minutes.
■ IntervalRetry Interval
■ TermexpiresAfter (Expires After)
The value in this field determines the amount of time that the secondary server continues to perform DNS client queries without contacting the primary server. After this time, the data is considered unreliable. The default setting for this setting is one day.
■ Minimumtermlife TTL (Minimum (Default)TTL)
TTL values do not apply to resource records in authoritative zones. And these zones use the lifetime of the resource write cache on non-authoritative servers for TTL values. The DNS server that cached the resource record from the previous request resets that record, but the TTL of the record has expired.
■ Term life(TTL)records(TTL For This Record)
The value specified in this field determines the lifetime of the current SOA entry. This value replaces the default value specified in the previous field.
Nameserver records
The name server (NS) record specifies the authoritative server for the zone. When creating a zone in Windows Server 2008, each server that manages a master copy of an Active Directory-integrated zone will receive own entry NS in the new default zone. When you create a standard primary zone, the local server NS record will be added by default.
For servers that manage additional zones, you must manually add NS records to the master copy of the zone.
NS records are created using a different procedure than when creating other types of resource records. To add NS records, in DNS Manager, double-click any existing entry NS. The Name Servers tab of the zone properties dialog box opens. On the Name Servers tab, click the Add button to add the FQDN and IP address of the server that manages the secondary zone of the local primary zone. By adding new server, click OK - a new NS record will appear in DNS Manager indicating this server.
NOTE: Enable transmission to additional zones
The secondary zone does not recognize this entry as a valid name server as long as it contains a valid copy of the zone data. For an additional zone to receive this data, zone transfers must be enabled for that server on the Zone Transfers tab of the zone's properties dialog box. This tab is described in more detail in the next topic.
Below is an example of an entry created in a standard zone file:
@NS dns1.lucernepublishing.com.
The @ symbol represents the zone defined by the SOA entry in the zone file. Then full record maps the domain wikipedia.org to the DNS server dns1.wikipedia.org.
Creating Resource Records
In addition to SOA and NS records, several other resource records are automatically created. For example, during the installation of a new DNS server, when the server is designated as a domain controller, many Active Directory Domain Services (AD DS) SRV records are created automatically in the locally managed zone. In addition, through dynamic updating, many DNS clients automatically register host (A and AAAA) and pointer (PTR) records in the zone by default.
Although many resource records are created automatically, enterprise environments typically require some resource records to be created manually, such as MX (Mail Exchangers) for mail servers, aliases (CNAME) for web and application servers, and host records for servers and clients , which cannot perform their own updates.
To manually add a resource record for a zone, in the DNS Manager console, right-click the zone icon and select the type of record to create from the context menu.
After you select an entry from the context menu, a dialog box opens where you can specify the entry name and the computer associated with it. Note that only host records associate a computer name with an IP address. Most record types associate a service name or alias with the original host record. Thus, the MX record relies on the presence of the SRV node 12.nwtraders .msft in the record's area.
Post types
The following are common resource records that are created manually:
■ node (AorALAA);
■ nickname (CNAME);
■ mailexchanger (MX);
■ pointer (PTR);
■ locationservices (SRV).
Knot (A or AAAA)
For most networks, the bulk of the resource records in the zone database are host resource records. These records are used in a zone to associate computer names (hostnames) with IP addresses.
Even with dynamic updates enabled for zones, some host entry scenarios will require you to manually add entries to the zone. In the figure below, Contoso, Inc. uses the domain name contoso.com in the public namespace and internal Active Directory domain. In this case, the public web server, www.contoso.com, is located outside the Active Directory domain and only makes updates to the public authoritative DNS server, contoso.com. But internal clients forward their DNS requests to internal DNS servers. Because the www .contoso .com A record is not dynamically updated on internal DNS servers, it is added manually so that internal clients can resolve names and connect to the public Web server.
Host entries can be added manually if the network uses a UNIX server. For example, Fabrikam, Inc. has in its private network one Active Directory domain named fabrikam,com. This network also includes the UNIX server App1.fabrikam, com, which runs important application to carry out the daily operations of the company. Since UNIX servers cannot perform dynamic updates, you will have to manually add the App1 server host record to the DNS server that manages the fabrikam.com zone. Otherwise, users will not be able to connect to the application server by specifying its FQDN.
Nickname (CNAME)
These entries are sometimes called canonical names. They allow multiple names to be used to refer to a single node. For example, well-known server names (ftp, www) are typically registered using CNAME records. These records map the hostnames corresponding to their services to the actual record of the AComputer that controls the service.
■ When you want to rename a node specified in the A record of the same zone.
■ When the group name of a known server (such as www) needs to be resolved into the group individual computers(each containing individual A records) providing the same service (for example, a group of redundant web servers).
Postal exchanger (MX)
These records are used by applications Email to localize the mail server in the zone. They allow you to match the domain name specified in the email address with the record of the Computer that controls the mail server in the domain. Thus, this record type allows the DNS server to handle email addresses that do not have a mail server specified.
Often MX records are created to provide failover to another mail server in case the preferred server is unavailable.
Multiple servers are assigned preference values. The lower this value, the higher the server's preference order.
NOTE: Symbol @
IN in this example The @ symbol represents the local domain name contained in the email address.
PointerPTR
This entry is used only in reverse lookup zones to support the reverse lookup that occurs when resolving IP addresses to hostnames or FQDNs. Reverse lookups are performed on the root zones of the in -addr .arpa domain. PTR records can be added to zones manually or automatically.
Below is an example text representation in a zone file of a PTR record created in DNS Manager that maps the IP address 192.168.0.99 to the hostname server 1.google.ru:
99 PTRserver 1.google.ru.
NOTE: Record number 99PRT
In the reverse lookup zone, the last octet of the IPv 4 address is equivalent to the hostname. Therefore, the number 99 represents the name assigned to the node inside the 0.168.192.in -addr .arpa zone. This zone corresponds to the 192.168.0.0 subnet.
Service locationSRV
Posts SRV is used to indicate the location of services in a domain. Client Applications Using SRV, DNS can retrieve the SRV records of application servers.
An application that uses SRV is Windows Server 2008 Active Directory. Service network login Netlogon uses SRV records to locate domain controllers by searching for an Active Directory Lightweight Directory Access Protocol (LDAP) domain. DNS to improve fault tolerance or troubleshoot network services.
InclusionDNS for resolutionWINS
On the WINS tab of the zone properties window, you can specify the WINS server that the DNS Server service will contact to look up names that are not found by DNS queries. When you specify a WINS server on the WINS tab of the Forward Lookup Zone Properties dialog box, a special WINS entry is added to that zone that references that WINS server. When you specify a WINS server on the WINS tab of the reverse lookup zone properties dialog box, a special WINS -R entry is added to the zone to identify that WINS server.
For example, if a DNS client requests the name ClientZ .contoso .com and the preferred DNS server cannot find the answer from normal sources (cache, local zone data, and by polling other servers), the server requests the name CLIENTZ . on the WINS server specified in the WINS record. If the WINS server responds to the query, the DNS server returns its response to the client.
Cleaning and deleting obsolete records
Time stamps are used in DNS to track the age of dynamically registered resource records. Stale record purging is the process of removing obsolete records with timestamps. Clearing can only be performed if timestamps are used. Time stamps and scrubbing work together to remove old recordings that may have accumulated in a zone over time. By default, timestamps and scrubbing are disabled.
Enable cleaning
To enable scrubbing for an individual zone, you must enable the feature at the server level and the zone level.
To enable server-level scavenging, in the DNS Manager console tree, right-click the server icon and use the Set Aging /Scavenging For All Zones command. Then, in the Server Aging / Scavenging Properties dialog box that opens, select the Scavenge Stale Resource Records check box. Although this setting enables server-level timestamping and cleanup for all new zones, it does not enable timestamping and cleanup of existing Active Directory-integrated zones.
To enable them, click OK, and then in the Server Aging/Scavenging Confirmation dialog box that opens, select the check box to apply these settings to existing Active Directory-integrated zones.
To enable timestamps and zone-level cleanup, open Zone Properties, and then on the General tab, click the Aging button. In the Zone Aging/Scavenging Properties dialog box that opens, select the Scavenge Stale Resource Records check box.
Timestamps The DNS server performs scavenging using the timestamps that are set on the resource records in the zone. Active Directory-integrated zones set timestamp values for dynamically logged entries by default before scrubbing is enabled. However, basic standard zones set timestamps for dynamically logged entries in the zone only after scrubbing is enabled. Resource records created manually for all zone types are assigned a timestamp of 0; this means that their age will not be determined.— this is the time between the last stamp update and its possible next update. Blocking prevents the server from processing unnecessary updates and reduces the amount of traffic. The default blocking interval is 7 days.
■ Modificationintervalupdates
The update interval is the interval between the earliest time the timestamp was updated and the earliest time record cleanup began. After the blocking and updating intervals have expired, entries may be removed from the zone. By default, the interval is 7 days. Therefore, if timestamps are enabled, dynamically logged resource records may be deleted after 14 days.
Performing a cleanup
Cleaning is performed in the zone automatically or manually. To automatically perform cleanup, you must enable automatic deletion of obsolete resource records on the Advanced tab of the DNS server properties dialog box.
If this option is not enabled, you can manually perform zone cleanup by right-clicking the server icon in the DNS Manager console tree and using the Scavenge Stale Resource Records command.
GlobalNames zone
Enabled in Windows Server 2008 new component, which allows all DNS clients in an Active Directory forest to use names from the same label, such as Mail, to connect to server resources. This component is useful if the default DNS suffix lookup list for DNS clients does not allow users to quickly (or at all) connect to a resource using that single-label name.
The DNS server in Windows Server 2008 allows you to create a GlobalNames zone. By default, the GlobalNames zone does not exist, but by deploying a zone with this name, you can provide access to selected resources using single-label names without using WINS. Typically, single-label names are assigned to important and widely used servers that are already assigned static IP addresses. GlobalNames on remote server, instead of a dot, enter the name of the remote server.
■ CreationGlobalNames zones
The next step in deploying the GlobalNames zone is to create a zone for the DNS server that serves as the Windows Server 2008 domain controller. The GlobalNames zone is not a special type of zone, but rather an Active Directory-integrated forward lookup zone called GlobalNames. When you create a zone, choose to replicate zone data for all DNS servers in the forest. This option is located on the Active Directory-integrated zone replication scope page (to enable single-label name resolution, create a resource alias (CNAME) record in the GlobalNames zone. The name assigned to each CNAME record represents the single-label name that users can use to connect to a resource. Note that each CNAME record specifies a host record in another zone.
For the mail server to function properly, it is important to have a properly configured zone. Setting up a DNS zone is one of the preparatory operations before deploying a mail server, and the performance of the email system directly depends on it.
Incorrect settings can result in mail being unable to be delivered to your mail server or recipient servers rejecting your mail. Indeed, if your zone records do not contain information about the mail server, where should mail be sent? To grandpa's village? You can, of course, ask your provider to configure the DNS zone, but it is better to do it yourself.
What do we need? A dedicated IP address (let's say 11.22.33.44), which you must obtain from your provider. A domain name (for example example.com) can be registered with any registrar or their partner. When registering with a partner, check whether he provides access to DNS zone management, otherwise you will have to spend Extra time, nerves and money to transfer the domain to the registrar.
If you already have a domain and, most likely, a website operates on it, check if it is possible DNS management zone from the hosting provider's panel, otherwise it is better to transfer the domain to the registrar; to do this, contact the provider's support.
So, we have a domain. What records does its DNS zone contain? Firstly, this is an SOA record - a description of the zone. We will not analyze all the entries in detail, this is beyond the scope of our article, but it is necessary to have a general understanding of them. There should also be two NS records pointing to name servers ( DNS servers) serving this domain, these will be the registrar's servers or the hosting provider.
The first record to be added will be the A record or name record. It should point to the IP address of your server if you decide to serve all requests to the domain yourself or to the IP address of the hosting provider if you decide to host your website. When hosting a website with a hoster, the domain is usually delegated to its DNS server (the corresponding NS records are registered) and an A record will be created automatically when parking the domain.
This option is most common, but if necessary, you can always create an A record yourself. This entry has the form:
example.com. IN A 22.11.33.44
In our example, 22.11.33.44 is the address of our hosting provider where the site is located. Pay attention to the dot at the end of the name, this indicates that the name is absolute; in the absence of a dot, the name is considered relative and the domain name from SOA is added to it. You can check the entry with the command nslookup.
For the mail server to work, you need to create an MX record, which should point to our mail server. To do this, let's create a record:
example.com. IN MX 10 mail.example.com.
You can also simply write:
example.com. IN MX 10 mail
Example.com will be automatically added to this name (without a dot at the end). The number 10 determines the server priority; the lower it is, the higher the priority. By the way, the DNS zone may already contain an MX record like:
example.com. IN MX 0 example.com.
Typically, this entry is automatically created by the hosting provider when hosting the site; it needs to be deleted.
Now let's create an A record for mail.example.com
mail.example.com. IN A 11.22.33.44
Now all mail for the example.com domain will be sent to the mail host with the address 11.22.33.44, i.e. your mail server, while at the same time the example.com site will continue to work on the provider’s server at 22.11.33.44.
The question may arise: why can’t you immediately specify the IP address of the mail server in the MX record? In principle it is possible, some people do it, but it does not comply with DNS specifications.
You can also make aliases for a mail server like pop.example.ru And smtp.example.ru. Why is this necessary? This will allow the client not to depend on the features of your infrastructure, having specified the settings once. Let's say that your company has grown and allocated a separate mail server to serve external clients. mail1, all you need to do is change two DNS records, clients will not even notice that they are working with a new server. To create aliases, CNAME type records are used:
Pop IN CNAME mail.example.com.
smtp IN CNAME mail.example.com.
At this point, setting up the forward DNS zone can be considered complete; the most interesting thing remains - the reverse zone. The reverse zone is managed by the provider that issued you the IP address and you cannot manage it yourself (unless you are the owner of a block of IP addresses). But you need to add at least one entry to the reverse zone. As we wrote in the previous article, many mail servers check PTR records (reverse zone records) for the sending server, and if they are absent or do not match the sender’s domain, the letter will be rejected. Therefore, ask your provider to add an entry like this for you:
44.33.22.11.in-addr.arpa. IN PTR mail.example.com.
A bit strange looking, isn't it? Let's look at the PTR record structure in more detail. For reverse name resolution, a special top-level domain in-addr.arpa is used. This is done in order to use the same software mechanisms for forward and reverse name conversion. The fact is that mnemonic names are written from left to right, and IP addresses are written from right to left. So mail.example.com. means that host mail is in the domain example, which is in the top-level domain com., 11.22.33.44 means that host 44 is in subnet 33, which is part of subnet 22, belonging to the network 11. To maintain a uniform order, PTR records contain a backwards IP address supplemented with the top-level domain in-addr.arpa.
You can also check MX and PTR records with the command nslookup using an additional parameter -type=MX or -type=PTR
And of course, we should not forget that any changes in DNS zones do not occur instantly, but over the course of several hours or even days, necessary for changes to propagate throughout the global DNS system. This means that although your mail server will start working 2 hours after making changes, your partner may not send mail to you for a longer time.
