Local domain name. Understanding Active Directory Domains


In rare cases, a domain services administrator may be faced with the task of renaming the current domain. The reasons may be different, but such a situation is quite possible. Despite the fact that this task cannot be called trivial, but occasionally you have to deal with it, it is extremely important to do everything correctly, since otherwise the outcome of events can be critically dangerous, up to a completely non-functional corporate infrastructure. So, later in this article, you will learn about the prerequisites for this operation, some restrictions, and how you can rename your domain. Before we begin, a strong request: do not perform these steps in your production environment until you have successfully renamed your test domain in your lab environment. Let's begin.

Prerequisites

Before you start renaming your domain, be sure to consider the following information:

  • Active Directory forest functional level. You can perform domain renaming tasks only if all domains in the forest are equipped with at least the Windows Server 2003 operating system (in this case there are no restrictions on editions). Moreover, the functional level must be raised to at least the level of Windows Server 2003. That is, if you have the Windows Server 2000 functional level selected in your forest, then the following operation will simply become impossible;
  • Domain location. An Active Directory forest can have different levels of domains. That is, there can be either a separate domain, or the forest can include child domains. If you change the location of the domain controller within the forest, you will have to create a trust relationship;
  • DNS zone. Even before performing the domain rename operation, you need to create a new DNS zone;
  • Administrative Credentials. To perform a domain rename operation, you must be logged on with an administrative account that is a member of the Enterprise Admins group;
  • Distributed File System (DFS) servers. If you have deployed DFS services or configured roaming profiles in your corporate environment, note that the DFS root servers must be running, at a minimum, Windows Server 2000 SP3 or higher operating systems;
  • Incompatibility with Microsoft Exchange servers. The most unpleasant moment is that if a Microsoft Exchange Server 2003 Service Pack 1 mail server is deployed in your Active Directory forest, then the domain renaming will be performed without any problems, but the user account under which the domain renaming process itself will be performed must Be a member of the Full Exchange Administrator group. All newer mail servers (including Exchange Server 2016) are not compatible with domain rename operations.

Also note that while you are renaming the domain, you must freeze all upcoming Active Directory forest configuration activities. In other words, you must ensure that your forest configuration does not change until the domain rename operation is completely completed (you will see detailed information about this action below). These operations include: creating or deleting domains within your Active Directory forest, creating or deleting application directory partitions, adding or deleting domain controllers in the forest, creating or deleting a directly established trust, and adding or deleting attributes that will be replicated to the global catalog.

Just in case, I would also advise you to make a full backup of the system state on each domain controller in the Active Directory forest. If this task is performed, this precaution will definitely not be superfluous.

If your infrastructure meets the above-mentioned requirements and all required backups have been made, you can begin the domain renaming process.

Active Directory Domain Rename Process

First, to check the original name of your domain, you can open the system properties window. As you can see in the corresponding illustration, my domain is called “Biopharmaceutic.local”:

Rice. 1. Checking the original Active Directory domain name

Now you should create a new DNS zone “biopharm.local” so that after the domain rename is successfully completed, your member servers and clients can easily join the new domain name. To do this, open " DNS Manager» ( DNS Manager) and being in " Direct viewing area» ( Forward Lookup Zone) select the option to create a new zone. Essentially, the zone is created as usual: on the first page of the New Zone Wizard, read the introductory information and move on to the second page. On the zone type page, select the primary zone ( Primary Zone) and make sure that the option to save the zone in Active Directory is activated. On the zone replication scope page, you should leave the default option selected - " For all DNS servers running on domain controllers in this domain: Biopharmaceutic.local» ( To all DNS servers running on domain controllers in this domain: Biopharmaceutic.local). On the zone name page, you should specify the new domain name (biopharm.local), and on the dynamic update page, also leave the option " Allow only secure dynamic updates (recommended for Active Directory)» ( Allow only secure dynamic updates (recommended for Active Directory)), which is selected by default. You can see several stages of creating a new zone below:

Rice. 2. Create a new DNS zone

The next step in renaming the domain is to generate a description of the current state of the forest. Essentially, this is the first domain rename operation that will use a command line utility Rendom. This utility will generate a text description of your current forest structure in the form of an XML file named Domainlist.xml. This file contains a list of all domain directory partitions as well as application directory partitions that are in your Active Directory forest. Each entry for each domain and application directory partition is delimited by XML tags And. Moreover, each entry contains data that includes the globally unique object identifier (GUID) of the partition's root object, the DNS name of the domain or application directory, and the NetBIOS name for the domain.

To create such a file, open a command prompt under the appropriate account and run the command “ random/list" The generated file will be saved in the root directory of your user account. Next, you will need to open this file using any text editor.

Inside this file you need to change the domain name inside the section that is limited by tags And and the NetBIOS name inside the tags And). Be sure to note that you should not change the GUID inside the corresponding tags.

In the following illustration you will see the process of executing the above command, the location of the Domainlist.xml file and the changes to the first section of this file. In my case the domain name in this config will be changed 4 times:

Rice. 3. Generating and modifying the Domainlist.xml file

To ensure that you have made the required changes to the appropriate file, you can run the command " rendom/showforest" As you can see in the following illustration, all my entries have changed to “Bopharm”:

Rice. 4. View Potential Changes

When executing the following command ( rendom/upload) the Rendom utility translates the new forest structure specified in the edited file into a sequence of directory update instructions that will run locally and remotely on each domain controller in the forest. In general terms, at this point, changes will be made to the directory section of the Domain Naming Wizard configuration to rename the Active Directory domain. In addition, a Dclist.xml file will be created, which is used to track the progress and status of each domain controller in the forest for the domain rename operation. By the way, at this point the Rendom utility freezes your Active Directory forest from making any changes to its configuration. The process of executing this command is visible below:

Rice. 5. Executing the rendom /upload command

The following command is run to check the readiness of the domain controllers before the domain rename operation. During this step, you must run the preparatory check command on every domain controller in the forest. This is to ensure that the Active Directory database on every domain controller in the forest is in the correct state and is ready to make changes that will allow you to rename your domain. Therefore, run the command " rendom/prepare", as shown in the following illustration:

Rice. 6. Preparing the domain for renaming

The most crucial moment. Executing the command " rendom /execute" When this command runs on a domain, instructions are executed to rename the domain. Essentially, at this very moment, each domain controller in the forest is contacted individually, causing each domain controller to execute the domain rename instructions. Upon completion of this operation, each domain controller will be rebooted. See the following illustration for the process of renaming a domain:

Rice. 7. Domain renaming process

But that is not all. Even though your domain has essentially already been renamed, you still have the task of fixing the GPOs and their links after the domain rename operation is complete. Use a command line utility to restore Group Policy Objects as well as GPO links in each renamed domain Gpfixup.exe. This procedure should not be neglected due to the fact that without its use, after the domain renaming operation is completed in the new forest, group policies simply will not function correctly. Please note that this command must be run once on each renamed domain. Hence, run the command once gpfixup with parameters /olddns:Biopharmaceutic.local(the old name of the domain you renamed) and /newdns:Biopharm.local(new name of the renamed domain), and then the command gpfixup with parameters /oldnb:Biopharmaceutical And /newnb:Biopharm(respectively, the old and new NETBIOS name of your domain). This procedure is visible below:

Rice. 8. Fixing Group Policy Objects

There are only two commands left to execute: the command “ rendom/clean", which allows you to remove all references to old domain names within your Active Directory, as well as the command " rendom/end", essentially unfreezing the Active Directory forest from making changes to its configuration. You can see the process of executing these commands in the following illustration:

Rice. 9. Complete the Active Directory domain rename

For the changes to apply to member servers and end clients, you will have to reboot their computers twice. However, you will have to rename the domain controllers manually. As you can see in the following illustration, my domain controller name remains the same.

This procedure is much more complicated than renaming a member server that is a regular member of a domain. For this task we need the utility " NETDOM", which starting from Windows 2008 included in OS, and for Windows 2003 will need to install " Support Tools ".

To rename a domain controller, proceed as follows:
1. First, make sure that the functional level of the domain is not lower Windows 2003 and check for permissions" Domain Admins " ("Domain Administrators ").
2. Open an elevated command prompt and add an additional name for the controller to which we are going to rename (in our example SRV-DC1-OLD.TEST.LOCAL rename to SRV-DC1.TEST.LOCAL ):

NETDOM computername SRV-DC1-OLD.TEST.LOCAL /add:SRV-DC1.TEST.LOCAL


3. Using the editor " ADSIEDIT.msc" make sure that the name is added correctly. In the editor, find the domain controller object and check the value of the property " msDS-AdditionalDnsHostName"which should be equal to " SRV-DC1.TEST.LOCAL ".


4. Now you need to make sure that the updated SPN the attributes managed to be fully replicated to other domain controllers in the forest. The utility will help us with this " REPADMIN" or " REPLMON" For Windows 2003.


To speed up the process, replication can be forced in the snap-in " DSSITE.msc". Simply right-click on the connection and select " Replicate now".


5. Now make the new domain controller name primary:

NETDOM computername SRV-DC1-OLD.TEST.LOCAL /makeprimary:SRV-DC1.TEST.LOCAL


6. Reboot the server.
7. Check again that the updated SPN attributes and entries in DNS managed to fully replicate to other domain controllers and servers DNS in the forest, and the property value " msDS-AdditionalDnsHostName" is now equal to the old server name.


If there is an acute shortage of time, you can again force replication and overload the zones DNS on other controllers if they display the previous name of our server.
8. Now we remove the old controller name, which is now additional:

NETDOM computername SRV-DC1.TEST.LOCAL /remove:SRV-DC1-OLD.TEST.LOCAL


9. Force or wait for full replication, and finally reload and check forward and reverse domain zones DNS for records with the old name. If we find any, we delete them or, if necessary, correct them to a new name. It's also worth checking the value of the " attribute again. msDS-AdditionalDnsHostName", which must be empty.

At the end of the procedure, when the above steps have been completed, carefully check the logs Active Directory on all domain controllers for errors and using the " DCDIAG“We make sure that the forest is working correctly.

It’s 2015, the Internet has become widespread, every self-respecting company has long had its own website. You don’t have to go far - even every city hospital has its own web resources. But nevertheless, system administrators still have not learned to create normal names for their domains.

The cost of a second-level domain (for example, bissquit.com) is a little more than 500 rubles per year. This is very little even for ordinary citizens like you and me, and it’s mere pennies for companies even more so. I purchased my domain long before the idea to start this blog appeared. It's just convenient. Let's even take a remote connection via rdp - I enter my domain name instead of a dull IP address.

On the Internet, when asked “active directory domain best practices”, almost every site contains comprehensive recommendations for naming AD domains and provides explanations of why you need to do it this way. Let's take a closer look at what recommendations we are talking about:

  • To name your AD domain, use a subdomain of your organization's officially registered domain.

You understood everything correctly, just one piece of advice. This is all! You can talk a lot about the details and small nuances, but 80-90% of the discussions come down to one single piece of advice, voiced above. All problems stem from the fact that a person knows that this should be done, but does not understand why it is impossible or highly recommended to do it differently. More details from now on.

1. Why can’t you use internal, externally unresolvable names like .local, .corp, .lan?

Can. As much as possible. Most people use them exactly. I have examples among friends whose organizations have 2000+ people and use the .local domain. All the difficulties will begin if you suddenly need a real AD domain. This can happen when using hybrid cloud deployments (Exchange + Office365 is a prime example). “Why not just rename the domain, because with a certain version of AD this is quite possible?” - you ask. Yes, in principle it is possible, but you will have to face the difficulties of migrating domain-dependent services. Among them is the same Exchange and others, but here Exchange alone is more than enough.

2. “Okay, let’s buy a real external name - my-company.com, and let’s also call the domain AD” is also not an option. There will be problems resolving other resources located at my-company.com, such as the company website. And besides, your DNS servers will not be authoritative for this domain, although they will consider themselves as such. This will also cause problems.

There are other considerations regarding domain naming, including creating a domain similar to the real one but in a different TLD. But it seems to me that there is not much point in doing this, because some of the problems still remain, and there are simply no obvious advantages in comparison with using the corp.my-company.com domain (the name is taken as an example).

For those who like to do everything their own way, problems with certificates have recently been added, so there is no point in using internal names now at all.

The issue of choosing a domain name technically depends on the line in which you enter the name when creating the AD domain and nothing more. However, the consequences that will follow from choosing the wrong name will cause you a lot of problems in the future, and therefore at the planning stage it is very important to do everything efficiently. Once again it’s a good idea to read articles from experienced admins

In short, AD allows you to have a single point of administration for all your published resources. AD is based on the X.500 naming standard, uses the Domain Name System (DNS) to determine location, and uses Lightweight Directory Access Protocol (LDAP) as its primary protocol.

AD combines the logical and physical structure of a network. The AD logical structure consists of the following elements:

  • organizational unit – a subgroup of computers, usually reflecting the structure of the company;
  • domain – a group of computers sharing a common directory database;
  • domain tree – one or more domains sharing a contiguous namespace;
  • domain forest – one or more trees that share directory information.

The physical structure includes the following elements:

  • subnet – a network group with a specified IP address area and network mask;
  • site – one or more subnets. The site is used to configure access to the directory and for replication.

The directory stores three types of information: domain data, schema data, and configuration data. AD only uses domain controllers. Domain data is replicated to all domain controllers. All domain controllers have equal rights, i.e. all changes made from any domain controller will be replicated to all other domain controllers. The schema and configuration data are replicated across all domains of the tree or forest. In addition, all individual domain objects and some forest object properties are replicated to the global catalog (GC). This means that a domain controller stores and replicates schema for a tree or forest, configuration information for all domains in the tree or forest, and all directory objects and properties for its own domain.

The domain controller on which the GC is stored contains and replicates schema information for the forest, configuration information for all domains in the forest, and a limited set of properties for all directory objects in the forest (which is replicated only between GC servers), and all directory objects and properties for your domain.

Domain controllers can have different operations master roles. The operations master handles tasks that are inconvenient to perform in a multi-master replication model.

There are five operations master roles that can be assigned to one or more domain controllers. Some roles must be unique at the forest level, others at the domain level.

The following roles exist in each AD forest:

  • Schema master – Manages directory schema updates and changes. To update a directory schema, you must have access to the schema master. To determine which server is currently the owner of the schema in the domain, you need to type the command in the command line window dsquery server -hasfsmo schema
  • Domain naming master – manages the addition and removal of domains in the forest. To add or remove a domain, you need access to the domain naming master. To determine which server is currently the domain naming master, enter dsquery server -hasismo name in the Command Prompt window

These roles are common to the entire forest as a whole and are unique to it.

Each AD domain must have the following roles:

  • Relative ID master – allocates relative identifiers to domain controllers. Each time a user, group, or computer object is created, controllers assign the object a unique security identifier, consisting of a domain security identifier and a unique identifier that has been allocated by the relative identifier master. To determine which server is currently the master of relative domain IDs, at the command prompt, enter dsquery server -hasfsmo rid
  • PDC emulator – In mixed or intermediate domain mode, acts as a Windows NT master domain controller. It authenticates Windows logins, handles password changes, and replicates updates to the BDC if any. To determine which server is currently the domain's PDC emulator, enter dsquery server -hasfsmo pdc at the command prompt
  • Infrastructure master – updates object links by comparing its catalog data with GC data. If the data is out of date, it requests updates from the GC and replicates them to the remaining domain controllers. To determine which server is currently master of the domain infrastructure, at the command prompt, enter dsquery server -hasfsmo infr

These roles are common to the entire domain and must be unique within it.

Operations master roles are automatically assigned to the first controller in the domain, but can be reassigned by you later. If there is only one controller in a domain, then it performs all operations master roles at once.

It is not recommended to separate the roles of schema master and domain naming master. If possible, assign them to the same domain controller. For maximum efficiency, it is desirable that the relative ID master and the PDC emulator also be on the same controller, although these roles can be separated if necessary. In a large network where heavy loads reduce performance, the relative ID master and the PDC emulator should be placed on different controllers. Additionally, it is not recommended to host the infrastructure master on the domain controller that stores the global catalog.

Installing a Windows Server 2003-based domain controller (DC) using the Active Directory Setup Wizard

The domain controller is installed using the Active Directory Installation Wizard. To promote a server to a domain controller, you must ensure that all the necessary requirements are met:

  1. The server must have at least one NTFS partition to accommodate the SYSVOL system volume.
  2. The server must have access to the DNS server. It is advisable to install the DNS service on the same server. If a separate server is used, you must ensure that it supports Service Location resource records (RFC 2052) and the Dynamic Updates protocol (RFC 2136).
  3. You must have an account with local administrator rights on the server.

Let's take a closer look at promoting the role of a server to an Active Directory domain controller step by step:

Active Directory Domain Management Basics

A number of tools in the Microsoft Management Console (MMC) snap-in make working with Active Directory easier.

The Active Directory Users and Computers snap-in is an MMC that you can use to administer and publish directory information. It is the main administrative tool for Active Directory and is used to perform all tasks related to users, groups, and computers, as well as to manage organizational units.

To launch the snap-in (Active Directory Users and Computers), select the command of the same name in the Administrative Tools menu.

By default, the Active Directory Users and Computers console works with the domain to which your computer belongs. You can access computer and user objects in this domain through the console tree or connect to another domain. Tools in the same console allow you to view additional object parameters and search for them.

Having gained access to the domain, you will see a standard set of folders:

  • Saved Queries (Saved queries) – saved search criteria that allow you to quickly repeat a previously performed search in Active Directory;
  • builtin – list of built-in user accounts;
  • Computers – default container for computer accounts;
  • Domain Controllers – default container for domain controllers;
  • ForeignSecurityPrincipals – contains information about objects from a trusted external domain. Typically, these objects are created when an object from an external domain is added to the current domain group;
  • Users – default container for users.

Some console folders are not displayed by default. To display them, select Advanced Features from the View menu. These are the additional folders:

  • LostAndFound – lost owner, catalog objects;
  • NTDS Quotas – data on directory service quotas;
  • Program Data – Data stored in the directory service for Microsoft applications;
  • System – built-in system parameters.

You can independently add folders for organizational units to the AD tree.

Let's look at an example of creating a domain user account. To create a user account, right-click the container in which you want to place the user account, select New from the context menu, and then select User. The New Object – User wizard window will open:

  1. Enter the user's first name, initial, and last name in the appropriate fields. You will need this information to create your user's display name.
  2. Edit your full name. It must be unique within the domain and be no more than 64 characters long.
  3. Enter your login name. Use the drop-down list to select the domain the account will be associated with.
  4. If necessary, change your login username on systems running Windows NT 4.0 or earlier. By default, the first 20 characters of the user's full name are used as the login name for systems running previous versions of Windows. This name must also be unique within the domain.
  5. Click Next. Provide a password for the user. Its settings should match your password policy;
    Confirm Password – field used to confirm that the entered password is correct;
    User must change password at next logon(Require password change at next login) – if this checkbox is selected, the user will have to change the password at the next login;
    User cannot change password – if this checkbox is checked, the user cannot change the password;
    Password never expires – If this checkbox is selected, the password for this account will never expire (this setting overrides domain account policy);
    Account is disabled - If this checkbox is checked, the account is disabled (this option is useful for temporarily disabling someone from using the account).

Accounts allow you to store user contact information, as well as information about participation in various domain groups, profile path, login script, home folder path, list of computers from which the user is allowed to log into the domain, etc.

Logon scripts define commands that are executed each time you log on to a system. They allow you to configure system time, network printers, paths to network drives, etc. Scripts are used to run commands one-time, and the environment settings set by the scripts are not saved for later use. Login scripts can be Windows script server files with the extensions .VBS, .JS and others, batch files with the extension .BAT, batch files with the extension .CMD, programs with the extension .EXE.

You can assign each account its own home folder for storing and restoring user files. Most applications open the home folder by default for file opening and saving operations, making it easier for users to find their data. On the command line, the home folder is the starting current directory. The home folder can be located either on the user's local hard drive or on a shared network drive.

Group policies can be applied to domain computer and user accounts. Group Policy simplifies administration by giving administrators centralized control over the privileges, permissions, and capabilities of users and computers. Group Policy allows you to:

  • create centrally managed special folders, such as My Documents;
  • control access to Windows components, system and network resources, control panel tools, the desktop, and the Start menu;
  • configure user and computer scripts to complete a task at a specified time;
  • Configure policies for passwords and account lockouts, auditing, user rights assignments, and security.

In addition to the tasks of managing user accounts and groups, there are many other domain management tasks. Other tools and applications serve this purpose.

Equipment Active Directory Domains and Trusts(Active Directory - domains and trust) is used to work with domains, domain trees and domain forests.

Equipment Active Directory Sites and Services(Active Directory - sites and services) allows you to manage sites and subnets, as well as inter-site replication.

To manage AD objects, there are command line tools that allow you to perform a wide range of administrative tasks:

  • Dsadd – adds computers, contacts, groups, organizational units and users to Active Directory. For help information, type dsadd /? , for example dsadd computer/?
  • Dsmod – changes the properties of computers, contacts, groups, organizational units, users and servers registered in Active Directory. For help information, type dsmod /? , for example dsmod server /?
  • Dsmove – Moves a single object to a new location within a domain, or renames the object without moving it.
  • Dsget – Displays the properties of computers, contacts, groups, organizational units, users, sites, subnets, and servers registered in Active Directory. For help information, type dsget /? , for example dsget subnet /?
  • Dquery – searches for computers, contacts, groups, organizational units, users, sites, subnets and servers in Active Directory according to specified criteria.
  • Dsrm – deletes an object from Active Directory.
  • Ntdsutil – allows you to view information about a site, domain or server, manage operations masters and maintain the Active Directory database.

There are also Active Directory support tools:

  • LDP – Performs operations using the LDAP protocol in Active Directory Administration.
  • Replymon – Manages replication and displays its results in a graphical interface.
  • Dsacls – Manages ACLs (access control lists) for Active Directory objects.
  • Dfsutil – Manages the Distributed File System (DFS) and displays information about its operation.
  • Dnscmd – Manages the properties of servers, zones, and DNS resource records.
  • Movetree – Moves objects from one domain to another.
  • Repadmin – Manages replication and displays its results in the command line window.
  • Sdcbeck – Analyzes distribution, replication and inheritance of access control lists.
  • Sidwalker – Sets ACLs for objects historically owned by moved, deleted, or orphaned accounts.
  • Netdom – Allows you to manage domains and trust relationships from the command line.

As you can see from this article, combining groups of computers into domains based on Active Directory can significantly reduce the costs of administrative tasks by centralizing the management of domain computer and user accounts, and also allows you to flexibly manage user rights, security and a host of other parameters. More detailed materials on the organization of domains can be found in the relevant literature.

Yesterday, we received a letter to our studio from our regular reader Andrey, with the question:

I read your blog with pleasure, I learned a lot of useful things for myself, I wanted to know your opinion about the name of the Active Directory domain, many write that it should be called *organization*.local, and someone writes that it should be called the same as the domain.

Let's take a quick look at what is the best name to use when naming a domain within an organization.

As practice shows, choosing a domain name can baffle even an experienced system administrator. When you launch the utility for the first time dcpromo The domain name will be generated automatically and randomly; if at this stage the domain name is not brought into compliance with the necessary rules, then in the future it will be more difficult to change the domain name. Let's look at the possible options in order of popularity.

1. Domain named example.local

The leader of our hit parade is the domain name ending with local. There are other variations on this theme, for example test, firma, factory, nn, loc, and so on. Nowadays you can’t even remember where such love came from; in all its books, Microsoft always uses its own names like contoso.com where we clearly see domain naming format. However, for almost 10 years the domain .local occupied a leading position. The situation began to improve with the arrival of services that use SSL certificates. Where the use of “don’t care” domains becomes impossible. Look, let's say your company uses internally Exchange server, which requires an SSL certificate to encrypt client connections. According to your scenario, you need a certificate to implement this task external certification authority, in which you must specify all the names of the servers used for external connections. It would seem that what’s wrong, we write down all the server names and apply for the issuance of certificates, but there is one thing. With the name of such a domain you will not be able to pass validation, since the “don’t care” domain does not exist and if you try to explain to an external certification authority that you need to put the FQDN name of a non-existent domain in the SAN, you will receive a soft refusal:

It’s not possible, we issue only certificates for real domain names.

But there is one more problem. Domain Name Usage not yours in a domain name can lead to disastrous consequences. Imagine the situation if the zone local will have public status. Like a zone com or ru. I don’t think it’s worth continuing any further :)

2. The domain name is the same as the external domain name

Second place in our hit parade. Despite the fact that such a scenario is less popular, it still has the right to life. Apart from the fact that in the near future you will still experience some inconvenience when maintaining the network, nothing else threatens you. The main problem in this scenario is that you will have to maintain two DNS servers: internal and external. Under this condition, computers located inside the network will use the internal DNS server to resolve names, and computers outside the company perimeter will use an external one. Let's assume your domain has a proud name example.com. IN DMZ zone you are in website company named example.com. In the scenario described above, the computers located inside organizations they won't be able to access it due to the fact that for them example.com is domain name and when you enter this address in the browser they will go to domain controller. As I noted above, apart from inconvenience, this will lead to nothing. You can always use crutches that will redirect you to an external site, but you will agree that this is unnecessary double work, or inside the network use the site name starting with www, or outside.

3. One-word domain name

Perhaps the most incorrect option of the above. Single-level domains: Single-label domain is a domain that only contains one component. Apparently they began to be used in the days of NT, when Microsoft adopted the successful experience of Novell. It so happened that initially I was the administrator of FreeBSD and a large fleet of NetWare servers starting with version 4.11, and so in those ancient times NetWare used Bindery in its work, which is precisely the names single-level domain diagram, which was later adopted by Microsoft.

Best practices

It's time to sum it up. What domain name should I use? Only a third-level domain in the domain you own. You should not use other people's more beautiful domain names :-). You can see an example of such a domain below.







2024 gtavrl.ru.