Add a txt entry to the dns configuration for. DNS

Continuing the topic of website building, let's talk about such an important aspect as the operation of the domain name system - DNS. Many issues related to the initial placement, as well as the transfer of sites between different servers and hostings, are associated with the setup and location of the DNS zone. Understanding how the domain name system works makes it easy to manage your own domains and associated sites and other services.

What's happened Domain name? For many, this is synonymous with a website address, for example, www.site. By typing this address, you are firmly confident that you will end up on this site and not somewhere else. At the same time, a domain name can designate not only a website, but also a server Email, exchange short messages or other other Internet and network service. Domain names are included in domain zones, which are located within each other in a hierarchical order.

IN general understanding A domain is a symbolic name that allows you to uniquely address an autonomous domain of names on the Internet. And not only address, but also allow any client to quickly find the required node, without even having the slightest idea about its location. It is no exaggeration to say that the DNS system is the basis of the modern Internet in the form in which we all know and are accustomed to it.

The DNS system is global and has a strict hierarchy. Consider the following diagram:

The top level of the hierarchy is the root domain, denoted by a dot, which contains information about first-level domains, e.g. ru, com, org and so on. The work of the root zone is ensured by 13 root servers located around the world and constantly replicating their data among themselves. In fact, there are more root servers, but protocol features allow you to specify only 13 nodes top level, therefore, the scalability and fault tolerance of the system is ensured by the mirrors of each root server.

First-level domains are familiar to us domain zones and can be managed by both national and international organizations and have their own terms of use. Each first-level domain zone allows you to place an unlimited number of second-level domains, which are familiar to every Internet user as website addresses.

In turn, second-level domains are also domain zones and allow you to place third-level domains, into which, like in a nesting doll, you can place fourth, fifth, etc. domains. levels. In order to be able to unambiguously identify nodes located in different zones, the concept fully qualified domain name (FQDN, Fully Qualified Domain Name), which includes all parent domain names in the DNS hierarchy. For example, for our site the FQDN will be: website. Exactly like that, ending with a dot indicating the root zone.

This is a very important point. IN everyday use It is customary to discard the trailing dot, but in DNS records the absence of the trailing dot means that this domain name belongs to the current domain zone, i.e. The DNS server will add to this name its own domain zone and all higher-level zones up to the root.

For example, on our server in the zone website we add a CNAME type record that will point to a third-party server, say, Yandex mail. The correct entry should look like this:

MailIN CNAMEdomain.mail.yandex.net.

IN in this case mail is not an FQDN and will be padded to mail.site., if we forget to put a period at the end of the Yandex domain name, then this name will also not be perceived as an FQDN and must be completed with the full domain name. The following is an incorrect entry:

Mail IN CNAME domain.mail.yandex.net

It’s difficult to notice the difference with the untrained eye, but instead of the Yandex mail web interface, this design will send us to a non-existent address: domain.mail.yandex.net.site.

One more thing. All records for a domain zone are entered by zone administrators on their own DNS servers, how do these records become known to the DNS system? After all, we do not notify higher-level DNS servers that we have changed any record.

Any DNS zone contains records only about its member nodes and child zones. Information about nodes in a downstream zone is stored on its own servers. This is called delegation and allows you to reduce the load on root servers and provide the necessary autonomy to the owners of child domain zones.

So you bought a domain, let's say example.org, after which you must delegate it, i.e. specify name servers (DNS servers) that will contain records for this file zone. These can be either your own servers or public services, for example, Yandex DNS.

In this case, in the domain zone org an entry will be added:

Example IN NS dns1.yandex.net.

Which will indicate that all records of this zone are located on the server dns1.yandex.net. According to the rules, each domain zone must have at least two NS servers located in different subnets. In practice, they often make do with one server, purchasing two IP addresses for it from different ranges.

Now let's look at how the search for the DNS record we need occurs and why the record made on your server allows visitors from anywhere in the world to get to your site.

Let's say a user wants to visit the popular Yandex Market resource, he types in address bar browser corresponding to the site name and clicks Enter button. In order to display the contents of a page to the user, the browser must send a request to the web server serving the site, and for this you need to know its IP address. Therefore, the browser contacts the DNS client to find out which address matches the domain name entered by the user.

In turn, the DNS client checks the entries in the hosts file, then in the local cache and, not finding the necessary entries there, passes the request to the one specified in network settings DNS server. This will most likely be a local caching DNS proxy such as dnsmasq or local DNS server enterprises. These solutions are usually not full-fledged servers of the global DNS system and are not part of it, serving only the local zone and caching DNS requests, so such a request, if the data is not in the cache, is transferred to a higher-level DNS server, usually the provider’s server.

Having received a request, the provider's server will check its own records, then its own cache, and if the result is found, it will report it to the client, otherwise the server will be forced to resort to recursion- search in the global DNS system. To better understand the mechanism of this process, we have prepared the following diagram:

So, the client sends a DNS request to the provider’s server in order to find out the domain address market.yandex.ru, the provider's server does not have such information, so it contacts one of the root servers, passing the request to it. The root server also does not have the necessary records, but responds that it knows the server responsible for the zone ru - a.dns.ripn.net. Along with this name, the root server can immediately report its IP address (and in most cases it will), but it may not do this if it does not have such information, in which case, before contacting this server, you will need to do more one recursive query, only to determine its name.

Having found out the address of the server responsible for the ru zone, the provider’s server will transfer the request to it, but this server also does not have the necessary records, but will tell you what zone it is yandex server responds ns1.yandex.ru And Necessarily will give his address. Otherwise, the recursion will not be able to be completed, since the zone yandex the server located in the zone responds yandex. To do this, in the higher zone, in addition to the NS record about the name servers serving the zone, a "linked" A-record, which allows you to find out the address of such a server.

Finally, by sending a request to the server serving the zone yandex, the provider's server will receive the address of the required domain and report it to the client. It will also place the resulting result in cache for the time specified by the TTL value in the SOA record of this domain. In practice, since recursive queries are very expensive, record caching time for providers can ignore domain TTL values ​​and reach values ​​from two to four hours to several days or even a week.

Now let's look at one more point. Queries can be recursive or non-recursive. A recursive request provides for obtaining a ready-made answer, i.e. IP addresses or messages that the domain does not exist, is not delegated, etc. A non-recursive request provides a response only about the zone for which the given server is responsible or returns an error.

Since recursive queries are quite resource-intensive, most servers DNS networks process recursive queries non-recursively. Or they can do this selectively, for example, the provider's DNS servers perform recursive queries only for their clients, and the rest non-recursively.

In our case, the client sent a recursive request to the provider's server, which, in turn, sequentially sent non-recursive requests until it found the required server, which gave the required answer. At the same time, not only the results of the user request, but also the results of intermediate queries are placed in the cache of the provider’s server, which allows you to execute the following such queries non-recursively or with minimum quantity requests.

For example, if a user, after visiting Yandex Market, decides to use the mail service, the server will immediately send a request to ns1.yandex.ru, since it already knows which server contains records for the zone yandex.

From theory to practice

When you purchase a domain from a registrar, you will be asked to delegate it, i.e. specify the DNS servers on which the domain zone will be located. These can be registrar servers (usually free), hoster servers, public DNS services or your own name servers; if it is located in the same domain zone, then you will also need to specify IP addresses. For example, this is what the domain delegation window looks like at one well-known registrar:

What exactly should I put there? It depends on where and how you will host your site. If you use shared hosting, then all the necessary records are created by the hoster automatically, when you add your site to the hosting control panel, all you need is to delegate the domain to the hoster’s NS server, i.e. indicate them in this window. This method is well suited for beginners due to its simplicity, but there are also back side, the user’s ability to manage the DNS zone is absent or minimal. In addition, on virtual hosting The site's IP address can be changed by administrators without notifying the user, so if you do not want to use the hoster's NS server, then this issue should definitely be discussed with technical support.

If you are transferring a site to another hoster, then you will need to transfer the site and change the name servers of the old hoster to the servers of the new one at the registrar. But keep in mind that the information in the cache of DNS servers is not updated instantly, but at least after the TTL domain value has expired, so for some time your site may still be accessible at the old address. If you need to work with it urgently, you can, without waiting for your provider’s DNS cache to update, add it to the file hosts entry with the following content:

1.2.3.4 example.com

Where 1.2.3.4 And example.com accordingly, the new IP address and your domain name.

If you have your own VPS or want to completely control the domain zone, then you should use the registrar’s servers or public services. Creation own server names, in our opinion, is not a worthwhile idea, unless you do your own hosting.

In this case, you need to create at least two A records that will point to the web server serving the site in this domain:

@ IN A 1.2.3.4
www IN A 1.2.3.4

The dog character in DNS records denotes the domain itself, and you should also create a record for the www subdomain so that users who type the site address with www can also access it.

We will not consider adding entries for email, you can read about this in our article:

When moving a site, you will only need to change the IP addresses in the A records and wait for the DNS information to be updated. Usually, this is the most unpleasant moment - everything seems to be done, but you can’t change anything, you can only wait. But if you follow some recommendations, then this process can be carried out as painlessly and unnoticed by visitors as possible.

First of all, change the TTL value in the SOA record. By default, it is equal to several hours and that is how long you will have to wait for your entry in the DNS server cache to be updated. To find out the current TTL value, you can run the command by specifying the desired domain name:

Nslookup -typr=soa site

In our case it is 4 hours:

Therefore, at least 4 hours (old TTL value) before the planned transfer, change the TTL value to a lower value, for example, 900 (15 minutes). Then set your site to read-only mode and migrate it to new server. The site should not be turned off or transferred for maintenance; it can and should remain accessible. But you must prevent users from changing and adding information, i.e. prohibit registration, commenting, placing orders, etc. Also, be sure to post a notice in a visible place about technical work and approximate completion date.

To work with the new server without changing DNS records, add the desired line to the hosts file. By placing the site on new site and making sure of his normal operation change the DNS records, now within 15 minutes the first users will start visiting your site on the new server. The functionality of the old server needs to be maintained for some more time, ideally up to a week, since not all providers use the TTL value from the SOA record to update the cache; your own settings can be used to reduce the load on the equipment.

After a successful migration, the TTL value should be increased to its previous values ​​so as not to create unnecessary load on the name servers.

We have considered the most simple diagram, but in practice, in addition to the site, there is usually also office network, many of whose resources must also be available externally. Consider the following diagram:

We have public servers for the website and email and office network, for which we have allocated a subdomain office. If there are no special issues with the mail and web server, then there are options with the office area. Typically the local area is served own DNS and is in no way connected with the maternal zone. For global DNS system zone office.example.com does not exist, but the host of the same name exists. This is justified if the enterprise network is behind NAT and its nodes only have gray addresses, and access from the outside is carried out only to the gateway, to which the corresponding ports from internal nodes are forwarded.

In this case, the zone's DNS records example.com may look like this:

@ IN A 1.2.3.4
www IN A 1.2.3.4
mail IN A 1.2.3.5
office IN A 5.6.7.8

But some complexity arises; within the network, clients access network services using internal names: corp.office.example.com or rdp.office.example.com, which point to internal "gray" addresses." However, outside local network It is not possible to resolve the IP address for such names because there is no global DNS zone containing them. A mechanism called Split-DNS allows you to get out of this situation, which allows you to give different results depending on the client’s position.

In the local network, DNS requests of clients are served by local server, which has corresponding records, requests outside of it will be sent to the server serving the zone example.com. At the same time, all corporate resources, which are represented by various servers on the local network, are accessible from the outside at a single address: office.example.com. Therefore, it's time to remember the nickname or CNAME record. This entry allows additional mnemonic names or aliases to be associated with the real hostname. Please note that using aliases in other entries is unacceptable. In our case, we should add the following entries:

Corp.office IN CNAME office.example.com.
rdp.office IN CNAME office.example.com.

Now a client, regardless of its location, can use the same name to access resources, but the results will be different. On the local network it will receive the real server address and connect directly, and outside it it will be directed to the network gateway.

Also, CNAME type records can be used to redirect outside the supported domain zone. The main condition is that the CNAME record must point to a real name in FQDN format.

Another use of aliases is to shorten an address. Let's say, as a mail server for the entire domain example.com we want to use a server that is located in the Moscow office and has the address mail.office.msk.example.com, you must admit, it doesn’t look very attractive. It would be much more convenient to have an address like mail.example.com, there is nothing simpler, add the following entry:

Mail IN CNAME mail.office.msk.example.com.

But remember that in other resource records you should only use real names, so this entry will be incorrect:

Example.com. IN MX 10 mail

The correct way would be:

Example.com. IN MX 10 mail.office.msk

Finally, let's talk about the delegation of domain zones. In the example above, we looked at a situation where within a domain different divisions are allocated their own subdomains, since each division has its own infrastructure, it makes sense to delegate to them the management of their own domain zones. For this purpose in the zone example.com an NS and associated A record should be placed for each zone. For example:

Msk IN NS ns1.msk.example.com.
msk IN NS ns2.msk.example.com.

ns1.msk IN A 1.2.3.4
ns2.msk IN A 5.6.7.8

Now when accessing an address, let's say mail.office.msk.example.com zone name servers example.com will display the name and address of the server serving the zone msk.example.com. This allows zone administrators to make the necessary changes themselves without affecting the functioning of the parent zone or contacting its administrators for any issue that requires changing records.

• Tags:

Please enable JavaScript to view the

On the page DNS zones a list of zones that you can edit is presented (the changes you make will be updated on our server within 30-40 minutes, but how quickly this will be noticeable to users directly depends on the settings of the Internet provider server through which you connect to the network ). When you click on the zone name (let it be in our example domain.tld) the DNS editor page opens. Let's look at each of the fields presented on this page separately.

Field "name" suggests several filling options:

• @ — the “@” symbol means that the entry will apply to the zone on which you are on the editing page. In our case, this is domain.tld.
• abc - a set of letters and numbers ("abc" was chosen as an example - you can enter your name) means that the entry will cover an area more low level than the one whose editing page you are on. In our example, the recording action will apply to the zone abc.domain.tld.
• * — the “*” symbol means that the recording will apply to all zone options below the one you are on the editing page. In our case, this is 123.domain.tld, abc.domain.tld, qwe.rty.domain.tld etc.

• In the "type" field you are offered several options. Let's look at each of them separately:

  • A— used to indicate the mapping of a hostname to an IP address.
  • MX - used to specify the mail server for a domain.
  • CNAME - used to redirect a hostname to another name.
  • SRV - used to indicate the server providing the service specific service. Roughly speaking, this is analogous to an MX record, which specifies where email that is addressed to a specific domain should be delivered. Standardly supported by such protocols as XMPP (Jabber), SIP, LDAP. By using this type of record, you can host the Jabber server on a separate machine, and not on the same machine that the DNS A record points to.
  • TXT - used to indicate additional text information, which the domain owner wants to communicate.
• "MX preference" field available for filling only in case of creating/editing MX type records. Specified in this field numeric value determines the priority of using the mail server. Since several mail servers can be specified for one domain, the sequence in which attempts will be made to deliver a letter to these servers is determined precisely by the priority of the corresponding MX record. The lower the number in the “MX preference” field, the higher the priority of the server itself.

• Field "value (IP/host.)" is filled in depending on the selected entry:

  • For A-records IP address is indicated.
  • For MX records the name of the mail server is indicated. If you write the name in full, be sure to put a period at the end!
  • For CNAME records indicates the host name to which we set the redirection. There must be a period at the end of the name!
  • For SRV records a line of the form “priority weight port value” is indicated, where priority, weight and port must consist only of numbers, and the value is full name host with a dot at the end.
  • For TXT records arbitrary is indicated text string. Restriction - the entry can only consist of letters of the Latin alphabet, numbers, spaces and the following symbols: . , ; : - = " / ~ ?

Representative DNS records

Let's look at a few of the most popular situations:

A-record: it is necessary that the site opens from another server

• If it needs to be done

  • @ IN A<серверы.masterhost>
  • Name: @
  • type: A
• If it needs to be done for a subdomain of the domain specified in the “DNS zones” section
  • abc.domain.tld in the domain zone domain.tld.
  • type: A
  • value (IP/host.): server IP address

MX record: Domain mail needs to be served by another server

if you the server name is unknown, but you know its IP address - you must first create in the domain zone new entry with the following parameters:

• name: mail-server
• type: A
• value (IP/host.): IP address of the mail server

• If you want to change the mail server for the domain specified in the “DNS zones” section, click on it with the mouse and, if new page there is an entry:

  • @ IN MX 10<серверы.masterhost>

    turn it off. After the entry is disabled, click on the “add new entry” link and create an entry like:

  • Name: @
  • type: MX
• If you want to change the mail server for subdomain of the domain specified in the “DNS zones” section, click on the domain name with the mouse and add a new entry with the following parameters:
  • name: abc ("abc" is given as an example. Works if you want to create an entry for a domain abc.domain.tld in the domain zone domain.tld. In your case there will be some other name)
  • type: MX
  • MX preference: numeric value, say 10.
  • value (IP/host.): mail-server

SRV record

To make an SRV record, you must obtain the following data from the service owner:

• Service
• Protocol
• Priority
• Weight
• Port
• Server (target)

* TTL does not change, so it is not necessary to specify it;

The entry name is formed from the service name and protocol: _service._protocol

The entry value has the following format: priority weight port server.(there must be a dot at the end of the name!)

List of subdomain NS servers

If the main domain is delegated to the masterhost servers, then changing the NS servers of the third-level subdomain is done through the editor.

If the main domain is supported on third-party servers, then changing the list of NS servers for its subdomains is done in the control panel of these servers.

PTR Record: You have allocated me an IP address and I want to match that IP address to a specific hostname

To do this you need to go to the section DNS zones, select your IP address and click on the button «>>» . In the editable field, enter the host name with a dot at the end and click “save.”

SPF entry

A fairly common technique used by organizers of SPAM mailings is faking the return address of the letter. In this case, service error messages (bounce messages) may sometimes arrive in your mailboxes if one or more such SPAM letters with the return address of your mailbox were blocked by recipient servers.

There are several technologies that will help protect your email domain from being used by attackers: SPF, DKIM, DMARC

IN this moment Our mail servers support SPF and DKIM technologies. If sending mail on behalf of your domain addresses is carried out only from our mail servers, we recommend adding the following TXT record with our SPF rule to the DNS zone of this domain, which will not allow your domain to be used on third-party mail servers.

• Name: @
• type: TXT
• value: v=spf1 include:_spf.site -all

This rule will force recipient servers to block all SPAM emails that use your domain name as the sender address. .

Dear users, we kindly ask you to be especially careful when editing DNS zones; incorrect configuration of the DNS zone can lead to the inoperability of your resources for a sufficiently long time. long term!

DKIM

To protect against fraudulent activities on behalf of your domain, we recommend adding a DKIM record to the DNS zone. If you use our email, you can add DKIM in your Personal Account.

Using this entry, you can specify the certification authorities that have the right to issue SSL/TLS certificates for this domain. A CAA record helps prevent unauthorized issuance of certificates by mistake or fraud.

This is just an example; exact information on the contents of the “Value” field should be clarified with your certification center.

Changing domain NS servers

To change the list of DNS servers:

• Go to ;
• Specify login cXXXXX and password;
• Open the “General Services” section and click “edit” next to the desired domain;
• Click on the link “Change delegation settings”;
• To indicate third party servers, select “Delegate to third-party servers”;
• Enter addresses DNS servers one per line;
• To cancel preliminary testing of DNS servers, check the “No testing” property;
• Click the "Save" button.

If login cXXXXX and access password Personal account lost, you can use the link to restore your access details.

Important:

1. Changing the list of DNS servers is possible only after completing mobile authorization.
2. From the moment of domain delegation (changing its list of NS servers) it will take from 6 to 72 hours before it is available on the Internet.

Any Internet user who has domains on the servers of hosting providers can create and edit their DNS records. DNS records have a Name, Record Type and Address. These names may change in different panels. For example, it could be like this:

Name/Host/Alias; Record type; Meaning/Answer/Destination/Address.

In all options, the “Record Type” remains the same.

Entry name

The record name, also known as host/alias, is the domain name to which the record being created belongs or is associated.

When creating an entry, the domain name is indicated in full in the “Name” field. The subdomain or alias name does not need to be specified in full. It is enough to indicate the third level name: mail, www, ftp. If you enter your full name, be sure to put a period at the end. That is, the name mail and mail.example.ru. is the same name in the Name/Host/Alias ​​field.

DNS record types

Let's look at the main DNS types records that you will encounter when servicing your domains.

Record Type A

Record type: A (address record) or (Internet 4 address). This type of record associates a specific domain name with a specific, precise IP address.

You can add more than one IP address for one domain (hostname). This is necessary if a firewall is used. To do this, you need to add a second record of type A, similar to the first. By specifying only a different IP.

In theory, you can specify more than one domain for one IP address. But this is not necessary, since the Domain Name System (DNS) has a record specifically designed for creating aliases. This record type is called CNAME.

Record type AAAA

Record type: AAAA (address record for IPv6) or (Internet 6 address). Same. Same as record type A, but the IP address has appearance via IPv6 protocol. For example: IPv6-2a03:4900:0:3::99:155

CNAME record type

CNAME (canonical name record). A CNAME record allows you to have and use more than one domain name (host) on a server.

First, one type A record is created for one IP address. The domain name in the Type A record is called the canonical name. Other domains are called mnemonic. Mnemonic names can be aliases (arbitrary names) or subdomains. Here's an example CNAME record:

popov.example.ru. CNAME example.ru.(don't forget the dots at the end).

A server can have any number of aliases. For each alias, you need to create a CNAME record.

Another example of a CNAME record:

hosting-1 IN A 8.8.8.8

www IN CNAME hosting-1

ftp IN CNAME hosting-1

We buy a second IP and transfer the ftp subdomain to the second IP:

hosting-1 IN A 8.8.8.8

hosting-2 IN A 8.8.8.9

www IN CNAME hosting-a

ftp IN CNAME hosting-b , transfer to a second hosting FTP server.

Another example of a CNAME record:

hosting-1 IN A 8.8.8.8

peter IN CNAME hosting-1

oleg IN CNAME hosting-1

We associate aliases with the following CNAME records:

example.com. IN CNAME example.ru.

www.example.com. IN CNAME example.ru.

test.example.com. IN CNAME example.ru.

Thus, we link the domains example.com, www.example.com, test.example.com with the canonical domain example.ru. The periods at the end are required.

Another example of redirection using a CNAME record

www.example.ru. IN CNAME example.ru.

Typically, servers by default create CNAME records only for subdomains of the main domain and do not create them for other domains (as in the photo).

MX record type

MX (mail server). This entry creates a subdomain that is served by an internal (its own) mail server.

For example: Name/host/alias - example.ru; Record type -MX (mail server); Meaning/answer/destination/Address – mail. With this entry you create a mail subdomain mail.example.ru. If you are using the internal mail service of the server, then you need to create a record type “A” for the mail.example.ru subdomain. Name: mail - A (record type) - Address: server IP.

You can use third-party mail servers as a mail service. To do this, you need to link your domain to a third-party mail server. It will automatically create an MX record for you. If they don’t create it, they will give you the address of the mail server. After that, you need to create CNAME and MX records on your server.

Use the CNAME record to redirect the mail domain mail.example.ru. to the email domain address. And an MX record for the domain example.ru itself. set the address of your third-party mailbox. As an example, you can use the Yandex mail server.

• For Yandex, the MX record type will be like this:

Name/host/alias - example.ru; Record type -MX (mail server); Meaning/answer/purpose/Address – mx.yandex.ru. Priority 10.

• The CNAME type is:

Name/host/alias – mail; Record type –CNAME; Meaning/response/destination/Address –domain.mail.yandex.ru. Priority 10.

On the Yandex mail server, without domain delegation, you can connect it only to the Yandex mail server by creating a mailbox there.

In addition to Yandex, using MX records you can link a domain to email Google servers, Mail.ru and others:

Record type NS

Record type NS (name server). This is perhaps the most important type records. It determines the domains (addresses) of DNS servers serving this domain.

Record type TXT

TXT (text entry). This is an informational entry. It does not carry a functional load.

Record type SOA (Start Of Authority)

SOA record type shows where the basic information about this domain is stored on which server. The SOA record type specifies the fully qualified domain name of the zone. The qualified domain name must end with a period. An SOA record may have an @ symbol instead of a qualified name. In this case, the domain name will be taken from the configuration file.

• Arbitrary serial number data versions (Serial). When a secondary server requests a data update, it first checks the serial number;
• The frequency of the request for updating data from the secondary (Secondary) server (Refresh), in seconds;
• The period for re-requesting the secondary server in case of primary failure (Retry);
• Data expiration date (Expire), otherwise the expiration of time after which the secondary server will stop servicing requests if it fails to restore communication with the primary server, in seconds;
• And lastly, data lifetime DNS zones in the cache of the server (TTL) that requested them, in seconds.

Here's an example of a SOA record for Microsoft DNS

How to edit DNS records in the ISPManager panel

In the ISPManager DNS panel, records are edited on the tab: Domain names→ “Click” on a domain.

How to edit DNS records in the DirectAdmin panel

In the DirectAdmin DNS panel, records are edited on the tab: DNS Management.

Advice. Expand all the steps in this guide and print it out so you have it in front of you when you verify ownership.

Why do you need confirmation?

Once you've verified your domain ownership, you'll be able to use your Google service, such as G Suite, Drive Enterprise, or Cloud Identity. A G Suite account gives you access to Gmail, Google Drive and other services.

Note. If you purchased a domain when you signed up for a G Suite account, you don't need to verify ownership.

Google Domain Ownership Verification

Ownership of a domain name can be verified through the domain registrar (usually the company you purchased the domain from). The registrar stores special settings – DNS records, which direct Internet traffic to your domain name.

Google will give you TXT verification record, which needs to be added to the domain registrar's DNS records. The presence of this record confirms that the domain really belongs to you. This action will not affect email or website functionality.

How to add a TXT verification record (instructions for popular domain registrars)

1. Identify your domain registrar (for example, using this article).
2. Take advantage step by step instructions(they are available for some domain registrars).

If there are no instructions for your recorder, add a TXT verification record using the general instructions below.

How to add a TXT verification record (general instructions for different domain registrars)

1. Obtain a verification record.

After registering in Google service run the setup wizard. He will walk you through all the steps of setting up your account, including verifying domain ownership.

If you haven't exited the wizard yet, go to step 3. Otherwise, start from step 1.

2. Open your domain's DNS records.

1. In a new window or tab, open the domain registrar's website. Learn more about how to identify your registrar...
2. Open your domain's DNS records. The corresponding page may be called DNS Management, Name Server Management(Domain Name Server Management), Control Panel(Control Panel) or Advanced Settings.
3. Select a command to add a new entry.

3. Add a verification entry.

1. For the post type, select TXT.
2. In field Name/Host/Alias enter @ or leave it blank. Some registrars require you to add a domain in this field, for example your-domain.com (correct option can be found in other DNS records).
3. In field Time to Live (TTL) enter 86400 or leave the default value.
4. In field Value/Answer/Destination Paste the copied confirmation entry from the Setup Wizard.
5. Save your changes.

Note. If a change warning appears DNS settings, ignore him. Adding a TXT record will not affect your site or DNS settings.

You can control DNS records. In the subsection Helpful information you can see a list of our DNS servers. Meaning A-records by default you can look at the technical domain.

Editing DNS servers

If your domain is in our service, then in this section you can change the DNS servers. To do this you need to select desired domain from the drop-down list and opposite it click the button " Editing DNS servers".

Make the necessary changes, then save them by clicking on the " Save"Please note that changes to NS servers take effect within 24-72 hours from the moment they are changed, depending on the speed of updating the DNS cache of your Internet provider.

Add subzone xxx.yourdomain.ru

You can add a subzone for your domain directly from the section DNS without creating a subdomain. The created subzone will appear in the general list.

When creating a subzone, you can select settings MX records for mail operation through services such as Yandex, Google or Mail.ru, and also indicate verification code(in the form of a TXT record) confirming domain ownership for search engines.

Full zone text

To view the full configuration file main zone, you can click on the button Full zone text

Editing a zone

In the subsection Quick Add You can literally add in a couple of clicks the desired entry to the desired subzone. To do this, select the desired subzone, record type ( A, AAAA, MX, SRV, TXT) and enter the entry itself, then click " Add"

In the same subsection there is brief information according to the selected entry. You can view help by hovering your mouse over the icon.

To edit the desired zone (subzone), you must press the button. Here you can view, change and delete current DNS records, as well as add new ones.
To delete an entry, click the button next to it.

By clicking the button, you can restore all DNS records to default:

• As A-records will be installed IP address server on which your account is located
• MX records will change to mx1.site And mx2.site

Opposite each subzone there is a button that allows you to delete a subzone. However, the subdomain itself will not be deleted.

Redirection to alternatives is also available for subdomains NS servers. NS records are responsible for which DNS servers to look for information about your domain (subdomain). The option is available only for subdomains if our DNS servers are registered for the main domain. In order to install NS records N.S., then enter the required NS records and apply the changes.

It is also possible to create a record alias for a subdomain. CNAME (canonical name record) or canonical name notation is used to redirect to another name. In order to install CNAME record for a subdomain, you need to go to edit the desired subzone and select CNAME, then enter necessary entry and apply the changes.