Network Services Windows 2012 - DNS
At one time, I discovered for myself a simple truth: if you want to remember something, conduct a summary (even when reading a book), and if you want to consolidate and systematize, bring it to people (write an article). Therefore, after two years of work in system integration (a field that I used to be a system administrator, I considered it as a cornucopia for the pumping thirsty specialists) when I realized that knowledge was gradually replaced by documentation editing and configuration skills on manuals and instructions to maintain Forms I started writing articles about basic things. For example, here is about DNS. Then I did it more for myself, but I thought - suddenly someone will come in handy.
Service in modern networks, if not key, then one of those. Those for whom the DNS service is not new, can easily skip the first part.
1. Basic information
2. A little about the format of the DNS message
3. TCP and UDP
4. DNS in Windows Server 2008 and 2012
5. DNS and Active directory
6. Sources of information
')
(no anchors, so the content is without links)
DNS is a database containing, in the main, information about the mapping of the names of network objects to their IP addresses. "Basically" - because there and some more information is stored. Or rather, resource records (Resource Records - RR) of the following types:
And this is the very mapping of the symbolic name of the domain to its IP address.
AAAA is the same as A, but for IPv6 addresses.
CNAME - Canonical NAME - a pseudonym. If you need a server with an unreadable name, such as nsk-dc2-0704-ibm, on which the corporate portal is spinning, responding also to the portal name, you can create another type A record for it, with the name portal and the same IP address. But then, in the case of changing the IP address (anything happens), you will need to recreate all such records again. And if you make a CNAME named portal pointing to nsk-dc2-0704-ibm, then you won't have to change anything.
MX - Mail eXchanger - pointer to the mail exchanger. Like CNAME, it is a symbolic pointer to an already existing record of type A, but in addition to the name it also contains priority. There may be several MX records for one mail domain, but first of all mail will be sent to the server for which a lower value is specified in the priority field. If it is unavailable - to the next server, etc.
NS - Name Server - contains the name of the DNS server responsible for this domain. Naturally for each record of type NS there should be a corresponding record of type A.
SOA - Start of Authority - indicates which of the NS servers stores reference information about this domain, contact information of the person responsible for the zone, storage timings of information in the cache.
SRV is a pointer to the server, the holder of a service (used for AD services and, for example, for Jabber). In addition to the server name contains such fields as Priority (priority) - similar to MX, Weight (weight) - used for load balancing between servers with the same priority - clients select a server randomly with a probability based on weight and Port Number is the port number, where the service "listens" to requests.
All of the above record types are found in the forward lookup zone of the DNS. There is also a reverse lookup zone - there are stored PTR records - PoinTeR - the record is opposite to type A. It stores the mapping of the IP address to its symbolic name. Required for processing reverse requests - determining the host name by its IP address. Not required for DNS operation, but needed for various diagnostic tools, as well as for some types of antispam protection in mail services.
In addition, the zones themselves that store information about the domain are of two types (classically):
The main (primary) - is a text file containing information about the hosts and services of the domain. The file can be edited.
Additional (secondary) is also a text file, but, unlike the main file, it cannot be edited. Tightened automatically from the server storing the main zone. Increases availability and reliability.
To register a domain on the Internet, it is necessary that at least two DNS servers store information about it.
In Windows 2000, this type of zone appeared as integrated into AD - the zone is not stored in a text file, but in the AD database, which allows it to replicate to other domain controllers along with AD, using its replication mechanisms. The main advantage of this option is the ability to implement secure dynamic DNS registration. That is, only computers that are members of a domain can create records about themselves.
In Windows 2003, there was also a stub zone - a stub zone . It stores information only about DNS servers that are authoritative for this domain. That is, NS records. This is similar in meaning to conditional forwarding , which appeared in the same version of Windows Server, but the list of servers to which requests are sent is updated automatically.
It is clear that a single DNS server does not know about all domains on the Internet. Therefore, when receiving a request to an unknown address, for example, metro.yandex.ru, the following sequence of iterations is initiated:
The DNS server refers to one of the Internet root servers that store information about the authorized holders of the first-level or zone domains (ru, org, com, etc.). He informs the client about the received address of the authorized server.
The client contacts the ru ruler with the same request.
The DNS server of the RU zone looks for the corresponding entry in its cache and, if it does not find it, returns to the client the address of the server that is authoritative for the second-level domain - in our case, yandex.ru
The client accesses DNS yandex.ru with the same request.
Yandex DNS returns the desired address.
Such a sequence of events is rare in our time. Because there is such a thing as a recursive query — this is when the DNS server to which the client initially turned, performs all iterations on behalf of the client and then returns the ready response to the client, and also keeps the received information in the cache. Support for recursive queries can be disabled on the server, but most servers support it.
The client, as a rule, makes a request that has the “recursion required” flag.
The message consists of a 12-byte header followed by 4 variable-length fields.
The header consists of the following fields:
Identification - in this field a certain identifier is generated by the client, which is then copied into the corresponding field of the server's response so that you can understand to which request the answer came.
Flags is a 16-bit field divided into 8 parts:
The following four 16-bit fields indicate the number of points in the four variable-length fields that complete the recording. In a request, the number of questions is usually 1, and the remaining three counters are 0. In the response, the number of answers is at least 1, and the remaining two counters can be either zero or non-zero.
Example (obtained using WinDump when executing the ping www.ru command ):
The first line is the query: the name of my PC, 51036 is the randomly selected send port, 53 is the previously known DNS server port, 36587 is the request identifier, + - “recursion is required”, A is a type A write request, the question mark means that request, not answer. In brackets - the length of the message in bytes.
The second line is the server response: to the specified source port with the specified request ID. The response contains one RR (DNS resource record), which is a response to the request, 2 authority records and 5 some additional records. The total response length is 196 bytes.
There is a rumor that DNS works over UDP (port 53). This is indeed the default - requests and responses are sent via UDP. However, the above-mentioned presence of a TC (Truncated) flag in the message header. It is set to 1 if the response size exceeds 512 bytes — the limit for the UDP response — which means it was cut off and only the first 512 bytes came to the client. In this case, the client repeats the request, but already via TCP, which, due to its specificity, can safely transfer large amounts of data.
Also, transfer of zones from main servers to additional servers is carried out via TCP, since in this case much more than 512 bytes are transmitted.
In Windows 2008, the following features appeared:
In very large organizations with extremely large areas that use Active Directory Domain Services for storing DNS data, restarting the DNS server can last an hour or more while DNS data is retrieved from the directory service. At the same time, the DNS server is not available for servicing client requests all the time while the loading of Active Directory Domain Services zones lasts.
The DNS server running Windows Server 2008 now loads the zone data from Active Directory Domain Services in the background during a reboot, thereby allowing it to process requests for data from other zones. When you start the DNS server, the following actions are performed:
Since the zone load task is performed in separate streams, the DNS server can process requests during zone loading. If the DNS client requests data for a host in a zone that is already loaded, the DNS server responds with the data (or, if appropriate, a negative response). If the query is made for a node that is not yet loaded into memory, the DNS server reads the node data from Active Directory Domain Services and updates the list of node records accordingly.
Internet Protocol Version 6 (IPv6) defines addresses that are 128 bits long, as opposed to IP version 4 (IPv4) addresses, which are 32 bits long.
DNS servers running Windows Server 2008 now fully support both IPv4 addresses and IPv6 addresses. The dnscmd command-line tool also accepts addresses in both formats. The forwarding server list can contain both IPv4 addresses and IPv6 addresses. DHCP clients can also register IPv6 addresses along with (or instead of) IPv4 addresses. Finally, DNS servers now support the ip6.arpa domain namespace for reverse mapping.
LLMNR name resolution
DNS client computers can use the Link-local Multicast Name Resolution name resolution (also called the DNS multicast system or mDNS) to resolve names on a local network segment where the DNS server is not available. For example, when a subnet is isolated from all DNS servers on the network due to router failure, clients on that subnet that support LLMNR name resolution can still resolve names using a peer-to-peer scheme before reconnecting to the network.
In addition to resolving names in the event of a network failure, LLMNR may also be useful when deploying peer-to-peer networks, for example, in airport lounges.
The changes in Windows 2012 regarding DNS have affected mainly the DNSSEC technology (ensuring DNS security by adding digital signatures to DNS records), in particular, providing dynamic updates that were not available when DNSSEC was enabled in Windows Server 2008.
Active Directory relies heavily on DNS. With it, domain controllers are looking for each other to replicate. With its help (and services Netlogon) clients define domain controllers for authorization.
To ensure the search, in the process of raising the role of the domain controller on the server, its Netlogon service registers the corresponding A and SRV records in DNS.
SRV records logged by the Net Logon service:
_ldap._tcp.DnsDomainName
_ldap._tcp.SiteName._sites.DnsDomainName
_ldap._tcp.dc._msdcs.DnsDomainName
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName
_ldap._tcp.pdc._msdcs.DnsDomainName
_ldap._tcp.gc._msdcs.DnsForestName
_ldap._tcp.SiteName._sites.gc._msdcs. Dnsforestname
_gc._tcp.DnsForestName
_gc._tcp.SiteName._sites.DnsForestName
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName
_kerberos._tcp.SiteName._sites.DnsDomainName
_kerberos._tcp.dc._msdcs.DnsDomainName
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName
_kpasswd._tcp.DnsDomainName
_kpasswd._udp.DnsDomainName
The first part of the SRV record identifies the service that the SRV record points to. The following services exist:
_ldap - Active Directory is an LDAP-compatible directory service with domain controllers that act as LDAP servers. _Ldap SRV records identify LDAP servers on the network. These servers can be Windows Server 2000+ domain controllers or other LDAP servers;
_kerberos - _kerberos SRV records identify all key distribution centers (KDCs) in the network. They can be domain controllers with Windows Server 2003 or other KDC servers;
_kpassword — identifies the kerberos password change servers on the network;
_gc is an entry relating to the global catalog function in Active Directory.
In the _mcdcs subdomain, only Microsoft Windows Server domain controllers are registered. They make and main records and records in this subdomain. Non-Microsoft services only make master records.
Records that contain the site identifier SiteName are needed in order for the client to find a domain controller for authorization in his site, and not to log in to another city through slow channels.
DomainGuid - global domain identifier. The record containing it is needed in case the domain is renamed.
When a user logs in, the client initiates a DNS locator, using a Remote Procedure Call (RPC) by the NetLogon service. As the initial data, the computer name, domain name and site name are transferred to the procedure.
The service sends one or more requests using the DsGetDcName () API.
The DNS server returns the requested list of servers, sorted according to priority and weight. The client then sends an LDAP request using UDP port 389 for each of the entry addresses in the order they were returned.
All available domain controllers respond to this request, reporting their health.
After detecting a domain controller, the client establishes an LDAP connection with it to gain access to Active Directory. As part of their dialogue, the domain controller determines to which site the client is located, based on its IP address. And if it turns out that the client didn’t apply to the nearest DC, but, for example, recently moved to another site and habitually requested DC from the old one (information about the site is cached on the client as a result of the last successful login), the controller sends him the name of his (client) new site. If the client has already tried to find a controller in this site, but to no avail, he continues to use the one found. If not, a new DNS request is initiated with an indication of the new site.
The Netlogon service caches information about the location of the domain controller, so as not to initiate the entire procedure every time a DC is accessed. However, if a “non-optimal” DC is used (located in another site), the client clears this cache after 15 minutes and initiates searches again (in an attempt to find its optimal controller).
If the computer does not have information about its site in the cache, it will contact any domain controller. In order to prevent this behavior, you can configure NetMask Ordering on DNS. Then the DNS will issue a list of DCs in such a way that the controllers located on the same network as the client are first.
Example: Dnscmd / Config / LocalNetPriorityNetMask 0x0000003F will specify the subnet mask 255.255.255.192 for the priority DCs. The default mask is 255.255.255.0 (0x000000FF)
www.hardline.ru/4/49/1236/1630-25.html
www.inadmin.ru/2010/02/26/dns-internet-domain
minergimn.ru/statii/16-adwin2003132
technet.microsoft.com/ru-ru/library/cc728909.aspx
support.microsoft.com/kb/247811/en-us?fr=1
Service in modern networks, if not key, then one of those. Those for whom the DNS service is not new, can easily skip the first part.
Content:
1. Basic information
2. A little about the format of the DNS message
3. TCP and UDP
4. DNS in Windows Server 2008 and 2012
5. DNS and Active directory
6. Sources of information
')
(no anchors, so the content is without links)
1. Basic information
DNS is a database containing, in the main, information about the mapping of the names of network objects to their IP addresses. "Basically" - because there and some more information is stored. Or rather, resource records (Resource Records - RR) of the following types:
And this is the very mapping of the symbolic name of the domain to its IP address.
AAAA is the same as A, but for IPv6 addresses.
CNAME - Canonical NAME - a pseudonym. If you need a server with an unreadable name, such as nsk-dc2-0704-ibm, on which the corporate portal is spinning, responding also to the portal name, you can create another type A record for it, with the name portal and the same IP address. But then, in the case of changing the IP address (anything happens), you will need to recreate all such records again. And if you make a CNAME named portal pointing to nsk-dc2-0704-ibm, then you won't have to change anything.
MX - Mail eXchanger - pointer to the mail exchanger. Like CNAME, it is a symbolic pointer to an already existing record of type A, but in addition to the name it also contains priority. There may be several MX records for one mail domain, but first of all mail will be sent to the server for which a lower value is specified in the priority field. If it is unavailable - to the next server, etc.
NS - Name Server - contains the name of the DNS server responsible for this domain. Naturally for each record of type NS there should be a corresponding record of type A.
SOA - Start of Authority - indicates which of the NS servers stores reference information about this domain, contact information of the person responsible for the zone, storage timings of information in the cache.
SRV is a pointer to the server, the holder of a service (used for AD services and, for example, for Jabber). In addition to the server name contains such fields as Priority (priority) - similar to MX, Weight (weight) - used for load balancing between servers with the same priority - clients select a server randomly with a probability based on weight and Port Number is the port number, where the service "listens" to requests.
All of the above record types are found in the forward lookup zone of the DNS. There is also a reverse lookup zone - there are stored PTR records - PoinTeR - the record is opposite to type A. It stores the mapping of the IP address to its symbolic name. Required for processing reverse requests - determining the host name by its IP address. Not required for DNS operation, but needed for various diagnostic tools, as well as for some types of antispam protection in mail services.
In addition, the zones themselves that store information about the domain are of two types (classically):
The main (primary) - is a text file containing information about the hosts and services of the domain. The file can be edited.
Additional (secondary) is also a text file, but, unlike the main file, it cannot be edited. Tightened automatically from the server storing the main zone. Increases availability and reliability.
To register a domain on the Internet, it is necessary that at least two DNS servers store information about it.
In Windows 2000, this type of zone appeared as integrated into AD - the zone is not stored in a text file, but in the AD database, which allows it to replicate to other domain controllers along with AD, using its replication mechanisms. The main advantage of this option is the ability to implement secure dynamic DNS registration. That is, only computers that are members of a domain can create records about themselves.
In Windows 2003, there was also a stub zone - a stub zone . It stores information only about DNS servers that are authoritative for this domain. That is, NS records. This is similar in meaning to conditional forwarding , which appeared in the same version of Windows Server, but the list of servers to which requests are sent is updated automatically.
Iterative and recursive queries.
It is clear that a single DNS server does not know about all domains on the Internet. Therefore, when receiving a request to an unknown address, for example, metro.yandex.ru, the following sequence of iterations is initiated:
The DNS server refers to one of the Internet root servers that store information about the authorized holders of the first-level or zone domains (ru, org, com, etc.). He informs the client about the received address of the authorized server.
The client contacts the ru ruler with the same request.
The DNS server of the RU zone looks for the corresponding entry in its cache and, if it does not find it, returns to the client the address of the server that is authoritative for the second-level domain - in our case, yandex.ru
The client accesses DNS yandex.ru with the same request.
Yandex DNS returns the desired address.
Such a sequence of events is rare in our time. Because there is such a thing as a recursive query — this is when the DNS server to which the client initially turned, performs all iterations on behalf of the client and then returns the ready response to the client, and also keeps the received information in the cache. Support for recursive queries can be disabled on the server, but most servers support it.
The client, as a rule, makes a request that has the “recursion required” flag.
2. A little about the format of the DNS message
The message consists of a 12-byte header followed by 4 variable-length fields.
The header consists of the following fields:
DNS message format
Identification - in this field a certain identifier is generated by the client, which is then copied into the corresponding field of the server's response so that you can understand to which request the answer came.
Flags is a 16-bit field divided into 8 parts:
- QR (message type), 1-bit field: 0 indicates the request, 1 indicates the response.
- opcode ( opcode ), 4-bit field. Normal value is 0 (standard query). Other values ​​are 1 (inverse request) and 2 (server status request).
- AA is a 1-bit flag that means “authoritative answer”. The DNS server has permissions for this domain in the questions section.
- TC is a 1-bit field that means truncated. In the case of UDP, this means that the full size of the response exceeded 512 bytes, but only the first 512 bytes of the response were returned.
- RD is a 1-bit field that means “recursion desired”. The bit may be set in the request and then returned in the response. This flag requires the DNS server to process this request itself (i.e., the server must determine the required IP address itself, and not return the address of another DNS server), which is called a recursive query. If this bit is not set and the requested DNS server does not have an authoritative response, the requested server will return a list of other DNS servers that need to be addressed in order to receive a response. This is called an iterative query. We will look at examples of both types of queries in the following examples.
- RA is a 1-bit field that means “recursion is possible” (recursion available). This bit is set to 1 in the response if the server supports recursion. We will see in our examples that most DNS servers support recursion, with the exception of a few root servers (horse servers are not able to process recursive requests due to their workload).
- 0 - This 3-bit field must be 0.
- rcode is a 4-bit return code field. Typical values ​​are 0 (no errors) and 3 (name errors). The name error is returned only from the authoritative DNS server and means that the domain name specified in the request does not exist.
The following four 16-bit fields indicate the number of points in the four variable-length fields that complete the recording. In a request, the number of questions is usually 1, and the remaining three counters are 0. In the response, the number of answers is at least 1, and the remaining two counters can be either zero or non-zero.
Example (obtained using WinDump when executing the ping www.ru command ):
IP KKasachev-nb.itcorp.it.ru.51036 > ns1.it.ru.53: 36587+ A? www.ru. (24)IP ns1.it.ru.53 > KKasachev-nb.itcorp.it.ru.51036: 36587 1/2/5 A 194.87.0.50 (196)The first line is the query: the name of my PC, 51036 is the randomly selected send port, 53 is the previously known DNS server port, 36587 is the request identifier, + - “recursion is required”, A is a type A write request, the question mark means that request, not answer. In brackets - the length of the message in bytes.
The second line is the server response: to the specified source port with the specified request ID. The response contains one RR (DNS resource record), which is a response to the request, 2 authority records and 5 some additional records. The total response length is 196 bytes.
3. TCP and UDP
There is a rumor that DNS works over UDP (port 53). This is indeed the default - requests and responses are sent via UDP. However, the above-mentioned presence of a TC (Truncated) flag in the message header. It is set to 1 if the response size exceeds 512 bytes — the limit for the UDP response — which means it was cut off and only the first 512 bytes came to the client. In this case, the client repeats the request, but already via TCP, which, due to its specificity, can safely transfer large amounts of data.
Also, transfer of zones from main servers to additional servers is carried out via TCP, since in this case much more than 512 bytes are transmitted.
4. DNS in Windows Server 2008 and 2012
In Windows 2008, the following features appeared:
Background loading zones
In very large organizations with extremely large areas that use Active Directory Domain Services for storing DNS data, restarting the DNS server can last an hour or more while DNS data is retrieved from the directory service. At the same time, the DNS server is not available for servicing client requests all the time while the loading of Active Directory Domain Services zones lasts.
The DNS server running Windows Server 2008 now loads the zone data from Active Directory Domain Services in the background during a reboot, thereby allowing it to process requests for data from other zones. When you start the DNS server, the following actions are performed:
- all zones to be loaded are determined;
- root links are loaded from files or AD DS storage;
- all zones with file support are loaded, that is, zones stored in files, and not in Active Directory Domain Services;
- processing of requests and remote procedure calls (RPC) begins;
- One or more threads are created to load zones stored in Active Directory Domain Services.
Since the zone load task is performed in separate streams, the DNS server can process requests during zone loading. If the DNS client requests data for a host in a zone that is already loaded, the DNS server responds with the data (or, if appropriate, a negative response). If the query is made for a node that is not yet loaded into memory, the DNS server reads the node data from Active Directory Domain Services and updates the list of node records accordingly.
IPv6 address support
Internet Protocol Version 6 (IPv6) defines addresses that are 128 bits long, as opposed to IP version 4 (IPv4) addresses, which are 32 bits long.
DNS servers running Windows Server 2008 now fully support both IPv4 addresses and IPv6 addresses. The dnscmd command-line tool also accepts addresses in both formats. The forwarding server list can contain both IPv4 addresses and IPv6 addresses. DHCP clients can also register IPv6 addresses along with (or instead of) IPv4 addresses. Finally, DNS servers now support the ip6.arpa domain namespace for reverse mapping.
DNS client changes
LLMNR name resolution
DNS client computers can use the Link-local Multicast Name Resolution name resolution (also called the DNS multicast system or mDNS) to resolve names on a local network segment where the DNS server is not available. For example, when a subnet is isolated from all DNS servers on the network due to router failure, clients on that subnet that support LLMNR name resolution can still resolve names using a peer-to-peer scheme before reconnecting to the network.
In addition to resolving names in the event of a network failure, LLMNR may also be useful when deploying peer-to-peer networks, for example, in airport lounges.
The changes in Windows 2012 regarding DNS have affected mainly the DNSSEC technology (ensuring DNS security by adding digital signatures to DNS records), in particular, providing dynamic updates that were not available when DNSSEC was enabled in Windows Server 2008.
5. DNS and Active directory
Active Directory relies heavily on DNS. With it, domain controllers are looking for each other to replicate. With its help (and services Netlogon) clients define domain controllers for authorization.
To ensure the search, in the process of raising the role of the domain controller on the server, its Netlogon service registers the corresponding A and SRV records in DNS.
SRV records logged by the Net Logon service:
_ldap._tcp.DnsDomainName
_ldap._tcp.SiteName._sites.DnsDomainName
_ldap._tcp.dc._msdcs.DnsDomainName
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName
_ldap._tcp.pdc._msdcs.DnsDomainName
_ldap._tcp.gc._msdcs.DnsForestName
_ldap._tcp.SiteName._sites.gc._msdcs. Dnsforestname
_gc._tcp.DnsForestName
_gc._tcp.SiteName._sites.DnsForestName
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName
_kerberos._tcp.SiteName._sites.DnsDomainName
_kerberos._tcp.dc._msdcs.DnsDomainName
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName
_kpasswd._tcp.DnsDomainName
_kpasswd._udp.DnsDomainName
The first part of the SRV record identifies the service that the SRV record points to. The following services exist:
_ldap - Active Directory is an LDAP-compatible directory service with domain controllers that act as LDAP servers. _Ldap SRV records identify LDAP servers on the network. These servers can be Windows Server 2000+ domain controllers or other LDAP servers;
_kerberos - _kerberos SRV records identify all key distribution centers (KDCs) in the network. They can be domain controllers with Windows Server 2003 or other KDC servers;
_kpassword — identifies the kerberos password change servers on the network;
_gc is an entry relating to the global catalog function in Active Directory.
In the _mcdcs subdomain, only Microsoft Windows Server domain controllers are registered. They make and main records and records in this subdomain. Non-Microsoft services only make master records.
Records that contain the site identifier SiteName are needed in order for the client to find a domain controller for authorization in his site, and not to log in to another city through slow channels.
DomainGuid - global domain identifier. The record containing it is needed in case the domain is renamed.
How is the DC searching process?
When a user logs in, the client initiates a DNS locator, using a Remote Procedure Call (RPC) by the NetLogon service. As the initial data, the computer name, domain name and site name are transferred to the procedure.
The service sends one or more requests using the DsGetDcName () API.
The DNS server returns the requested list of servers, sorted according to priority and weight. The client then sends an LDAP request using UDP port 389 for each of the entry addresses in the order they were returned.
All available domain controllers respond to this request, reporting their health.
After detecting a domain controller, the client establishes an LDAP connection with it to gain access to Active Directory. As part of their dialogue, the domain controller determines to which site the client is located, based on its IP address. And if it turns out that the client didn’t apply to the nearest DC, but, for example, recently moved to another site and habitually requested DC from the old one (information about the site is cached on the client as a result of the last successful login), the controller sends him the name of his (client) new site. If the client has already tried to find a controller in this site, but to no avail, he continues to use the one found. If not, a new DNS request is initiated with an indication of the new site.
The Netlogon service caches information about the location of the domain controller, so as not to initiate the entire procedure every time a DC is accessed. However, if a “non-optimal” DC is used (located in another site), the client clears this cache after 15 minutes and initiates searches again (in an attempt to find its optimal controller).
If the computer does not have information about its site in the cache, it will contact any domain controller. In order to prevent this behavior, you can configure NetMask Ordering on DNS. Then the DNS will issue a list of DCs in such a way that the controllers located on the same network as the client are first.
Example: Dnscmd / Config / LocalNetPriorityNetMask 0x0000003F will specify the subnet mask 255.255.255.192 for the priority DCs. The default mask is 255.255.255.0 (0x000000FF)
Information sources:
www.hardline.ru/4/49/1236/1630-25.html
www.inadmin.ru/2010/02/26/dns-internet-domain
minergimn.ru/statii/16-adwin2003132
technet.microsoft.com/ru-ru/library/cc728909.aspx
support.microsoft.com/kb/247811/en-us?fr=1
Source: https://habr.com/ru/post/214439/
All Articles