How to set up smartphones and PCs. Informational portal
  • home
  • Programs
  • What information does a dns record like mx. DNS management, working with NS and A records by examples

What information does a dns record like mx. DNS management, working with NS and A records by examples

Webmin does not support all record types that BIND knows. Work is supported only with those that are more common. The types of records that Webmin can work with will be described below. In addition, it will be given a brief description of each of these types.

Record types available in direct zone:

Address (A) - address type records. This type associates an IP address with a hostname. Any system that you want to connect to via HTTP, telnet, or some other protocol that has a hostname assigned to it must have an address record so that the hostname can be used to look up the IP address of the host. Remember, one hostname( hostname) may have several address records (records A type). This is often used to distribute the load on a website across multiple systems. It is also possible to create multiple address entries with different hostname but the same IP address, as if creating name-based(name-based) virtual servers Apache.

When creating or editing an address entry, the field Address(IP address) is for writing an IP address to be associated with hostname. Field Update reverse??) , responsible for automatic creation and changing the record Reverse Address, typePTR) V Reverse zone) . See Adding and Editing Records for details.

Name Server (NS)- record type defining the name of the server responsible for servicing the zone. Each zone must have at least one NS record and, in addition, may have additional NS records for subdomains of that zone. If you are setting up an additional (secondary, secondary) DNS server for a certain zone, then do not forget to check if an NS record has been added for this zone on the main (primary, master) DNS server. In this case (if you are setting up an additional DNS server), the record name must be canonical for the zone, for example example.com (i.e. completely with the parent zone(s)) .

When creating or editing a record of this type, the Name Server field is used to enter the IP address or hostname of the DNS server responsible for maintaining the zone. If you enter hostname, you also need an Address record (A-record) with an IP address for that hostname, located in some zone, on your DNS server.

Name Alias ​​(CNAME)- this record type allows you to create aliases (aliases, links, bindings) to existing address (Address; type A) and reverse address (Reverse Address, PTR type) records. When a DNS client requests an IP address of this type (Name Alias), it receives the IP address specified in the entry to which it is bound. This can be useful if you want a host to be available under multiple names. Of course, this can be achieved by creating several address records, but the alias option is more convenient in that if a host has a changed IP address, then there is no need to change anything in the aliases. While, if you use a lot of address records, you will have to make changes to each record associated with this certain server.

The Name Alias ​​record creation and editing form contains the Real Name field for entering the canonical real name the entry to which the alias will point (for example, webserver.example.com).

Mail Server (MX)- record type that reports email programs, like Sendmail or Qmail, where the mail server is located (the server you need to contact to deliver mail in this domain). Without this entry, mail for this domain will be delivered to that system (that server, host) whose IP address is specified in the address record (Address, type A) for this zone.

Each MX record has a priority, which allows you to offload the load between multiple mail servers. Accordingly, the priority tells the mailers (deliverers) which server will be contacted first. And then in descending order, for example, if the server with a high priority does not respond.

Note: High priority in this context means not the most big number, and the smallest, i.e. 10 is higher than 50.

Servers with low MX priority are designed to forward mail to some host that would store the mail. Then, when the highest priority mail server becomes free, it will take the mails from the store and send them to the address.

When adding or editing an MX record, two fields are available to you. In the first one, you need to enter the canonical hostname (host name) or a link to it (to the host name) of the mail server. The second field is for entering the priority of the MX record. Usually, the priority is set to 5 for the main server. If you have only one mail server, then the priority does not matter. In addition, you can set for two mail servers the same priority. In this case, the server that will deliver the letter to the addressee will be determined randomly.

Host Information (HINFO)- record type used to store information about the architecture and operating system of some host. For example, you may need to create an entry for the test.example.ru server that it (the server) is an x86 PC running FreeBSD. However, this is very rarely used, since such information can be used by attackers in preparing attacks.

When adding or editing this type of entry, the Hardware(Architecture) and Operating System(Operating System) fields are intended to enter the architecture and operating system host, respectively. Enter data in these fields without spaces, replacing spaces with the sign "earth", that is, "_" without quotes.

Text (TXT) - record type that associates arbitrary textual information with the selected zone (domain). That is, you cannot add TXT record just somewhere. It can only be added when editing a certain zone. So this textual information will be attached to the editable zone. This type can be used to attach comments to some zone (domain). Be careful, because this information can be read by anyone who requested information about the zone (domain), so do not post confidential information in the comments.

When adding or editing this type of entry, the Message field is for entering a comment about the host. This text may contain spaces.

Well Known Service (WKS) - an entry type that associates the hostname, port, and protocol of some service (such as mail) with the selected zone. This can, for example, be used to indicate to clients which host is the mail server. However, most programs do not request WKS records, so in practice this type of record is often useless.

When adding or editing this type of record, the fields Address(IP address), Protocol(Protocol) and Services(Services), are intended to enter the IP address of the host of some service that appears for this zone (domain); network protocol, which is used by the service - TCP or UDP; port number on which it is provided this service, respectively.

Responsible Person (RP)- record type that associates a person or group of people responsible for this zone (domain). Fields E-mail address (E-mail address) and Text Record Name (Name), are intended for entering E-mail addresses responsible person and his name (name and surname), respectively. This post type is rarely used.

Location (LOC)- record type, which is used to indicate physical location host. In latitude and longitude coordinates. Possibly useful for large organizations, servers, which are in different countries.

When adding or editing this record type, the Latitude and Longtitude fields are for entering latitude and longitude. For example, the host cambridge-net.kei.com is 42 21 54 N 71 06 18 W -24m 30m .

Service Address (SRV)- record type that associates Domain name, service name and protocol with some host. In other words, this entry is used to indicate the location of some service on some host. For example, this record type can be used if you want to specify that the POP3 server for example.ru is mail.example.ru and the web server is www.example.ru.

When adding or editing this record type, the fields Protocol (Protocol) and Service Name (Service Name) are intended to enter the protocol that the service uses (TCP, UDP, TLS) and the name (name) of the service (this name can be taken from the file / etc/services) respectively. Service names can be pop3, telnet, and others. When a client is looking for some SRV record, the record request type is: _telnet._tcp.example.ru (For example, it could be like this). Webmin will automatically convert the entry you create to this (correct) form. This means that there is no need to create or edit this type of post manually.

The Priority field is for entering the priority for this server, meaning (priority) is the same as the priority for MX records. The Weight field is for entering a number representing the "weight" of this host. User requests will be mainly to the server with more "weight".

The Port field is intended for entering the port number on which this service is provided.

Public Key (KEY)- an entry type that associates a "key" with some host. This key is used for IPsec VPN.

Record types available in the return zone:

Reverse Address (PTR)- an entry type that associates hostname with an IP address in the reverse zone. For DNS clients, you need to look up hostnames (hostnames) at a given IP address. You should create one entry of this type for each host. However, in most cases this can be automated. Webmin can add an address entry to the reverse zone as soon as the corresponding address entry is added to the forward zone. That is, Webmin can synchronize the forward and reverse zones.

When adding or editing this record type, the Address(IP address) and Hostname(Hostname) fields are for entering an IP address (For example, 192.168.1.5; This address will be automatically converted by Webmin to the in-addr.arpa format used by DNS server for the reverse zone) and hostname (hostname) in canonical form (For example, test.example.ru . ), respectively.

WARNING: When entering Hostname, be sure to include a dot at the end. This is not a typo.

Name Server (NS)- NS record type in the reverse zone, intended for the same as in the forward one - it tells other DNS servers the IP address or hostname (hostname) of the server serving some zone (domain) or some subdomain.

The Zone Name field is for entering the name of the zone served by this server. Typically, that zone name is the same as the zone name to which this entry is added. In this field, you should enter a value in the format in-addr.arpa (Since there is no synchronization, as in address records - type A and PTR). Therefore, the Zone Name for 192.168.1 will look like 1.168.192.in-addr.arpa . (The period is required at the end, this is not a typo) In the Name Server field, you must enter the IP address or hostname in canonical form (for example, ns1.example.ru).

Name Alias ​​(CNAME)- record type in the reverse zone, intended for the same as in the forward zone - alias, link, binding to some record. In the fields Name (Name) and Real Name (Real name) you should enter a value in the format in-addr.arpa, because Webmin does not automatically do this.

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, however, how soon this will be noticeable to users directly depends on the settings of the ISP server through which the connection to the network is made ). When you click on the zone name (let it be in our example domain.tld) the DNS Editor page opens. Let's take a look at each of the fields on this page one by one.

    Name field offers several filling options:

    • @ — the “@” symbol means that the action of the entry will apply to the zone on the editing page of which you are located. 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 a zone of more than low level than the one you are on the edit page. In our example, the recording action will apply to the zone abc.domain.tld.
    • * — the symbol "*" means that the action of the entry will apply to all zone options below the one on the editing page of which you are located. In our case, this is 123.domain.tld, abc.domain.tld, qwe.rty.domain.tld etc.
  • In the "type" field you are presented with several options. Let's consider each of them separately:

    • A- used to match a hostname to an IP address.
    • MX- used to specify the mail server for the domain.
    • CNAME- used to redirect a hostname to another name.
    • SRV- is used to specify a server that provides services for a particular service. In a rough approximation, this is analogous to an MX record, which indicates where e-mail that is addressed to a specific domain should be delivered. Regularly supported by such protocols as XMPP (Jabber), SIP, LDAP. By using this type of entry, you can place a Jabber server on separate machine, and not the same one pointed to by the DNS A-record.
    • txt- used to indicate additional text information that 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 numerical value determines the priority of using the mail server. Since several mail servers can be specified for one domain, the sequence in which attempts to deliver a letter will be made 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.)" filled in depending on the selected entry:

    • For A-records specifies the IP address.
    • For MX records specifies the name of the mail server. In case you write the name in full, you must put a dot at the end!
    • For CNAME records specifies the hostname to which we are redirecting. There must be a dot at the end of the name!
    • For SRV records a string of the form "priority weight port value" is indicated, where priority, weight and port must consist only of numbers, and the value - full name host with a dot at the end.
    • For TXT records arbitrary text string. Restriction - the entry can only consist of letters Latin alphabet, numbers, spaces, and the following characters: . , ; :-= " / ~ ?

Characteristic DNS records

Consider some of the most popular situations:

A-record: the site needs to be opened 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.): IP address of the server

MX record: Requires domain mail to be served by a different server

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

    • 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 on 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 of the form:

    • 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, let's say 10.
    • value (IP/host.): mail-server

SRV record

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

  • Service
  • Protocol (proto)
  • Priority
  • Weight
  • port
  • Server (target)

* TTL does not change, so it does not need to be specified;

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

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

List of NS servers of a subdomain

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

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

PTR record: You have given me an IP address and I want to map this IP address to a specific hostname

To do this, 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 record

A fairly common technique used by the organizers of SPAM mailing lists is the forgery of the return address of the letter. In this case, your mailboxes may sometimes receive service error messages (bounce messages) if one or more of these SPAM letters with the return address of your mailbox were blocked by the recipients' servers.

There are several technologies that can help protect your mail domain from malicious use: 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 to DNS zone this domain, the next TXT record with our SPF rule, 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 cause the recipient's 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 inoperability of your resources for quite a long time. long term!

DKIM

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

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

This is just an example exact information according to the content of the "Value" field, you should check with your certification authority.

Changing the NS servers of a domain

To change the list of DNS servers:

  • Go to ;
  • Specify login cXXXXX and password;
  • Open section " General Services" and click "change" opposite 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 disable pre-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 access details.

Important:

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

How does the DNS system work?

When you type the domain name MYDOMAIN.COM into your browser, your computer first of all contacts the DNS server specified in your Internet connection settings. A DNS server is needed in order to resolve the requested domain name into an IP address.

The DNS server accesses one of the root NS servers of the Internet, whose ip addresses are hard-coded and known, and in response, the Root server gives the DNS server a list of ip-addresses of servers where the .COM zone is located. This list looks something like this:

a.gtld-servers.net. 160060 IN A 192.5.6.30 a.gtld-servers.net. 160060 IN AAAA 2001:503:a83e::2:30 b.gtld-servers.net. 160060 IN A 192.33.14.30 b.gtld-servers.net. 160060 IN AAAA 2001:503:231d::2:30 c.gtld-servers.net. 160060 IN A 192.26.92.30 d.gtld-servers.net. 160060 IN A 192.31.80.30 e.gtld-servers.net. 160060 IN A 192.12.94.30 f.gtld-servers.net. 160060 IN A 192.35.51.30 g.gtld-servers.net. 160060 IN A 192.42.93.30 h.gtld-servers.net. 160060 IN A 192.54.112.30 i.gtld-servers.net. 160060 IN A 192.43.172.30 j.gtld-servers.net. 160060 IN A 192.48.79.30 k.gtld-servers.net. 160060 IN A 192.52.178.30 l.gtld-servers.net. 160060 IN A 192.41.162.30 m.gtld-servers.net. 160060 IN A 192.55.83.30

The DNS server contacts one of the NS servers in the .COM zone (Let's say a.gtld-servers.net is 192.5.6.30) and requests a list of NS servers for the MYDOMAIN.COM domain. These NS servers are called NS servers to which the domain is delegated.

ns1.mydomain.com. 172800 IN A 66.96.142.148 ns2.mydomain.com. 172800 IN A 65.254.254.172 ns3.mydomain.com. 172800 IN A 66.96.142.146 ns4.mydomain.com. 172800 IN A 65.254.254.170

Then it accesses one of the received list of NS servers and requests information about the MYDOMAIN.COM domain. Answer example:

mydomain.com. 3248 IN MX 0 mail.mydomain.com. mydomain.com. 86048 IN TXT "v=spf1 ip4:38.113.1.0/24 ip4:38.113.20.0/24 ip4:12.45.243.128/26 ip4:65.254.224.0/19 ?all" mydomain.com. 2208 IN SOA ns1.mydomain.com. hostmaster.mydomain.com. 1335787408 16384 2048 1048576 2560 mydomain.com. 248 IN A 65.254.242.180 mydomain.com. 1448 IN NS ns3.mydomain.com. mydomain.com. 1448 IN NS ns2.mydomain.com. mydomain.com. 1448 IN NS ns4.mydomain.com. mydomain.com. 1448 IN NS ns1.mydomain.com. ;; AUTHORITY SECTION: mydomain.com. 1448 IN NS ns3.mydomain.com. mydomain.com. 1448 IN NS ns4.mydomain.com. mydomain.com. 1448 IN NS ns2.mydomain.com. mydomain.com. 1448 IN NS ns1.mydomain.com. ;; ADDITIONAL SECTION: ns1.mydomain.com. 167564 IN A 66.96.142.148 ns2.mydomain.com. 167564 IN A 65.254.254.172 ns3.mydomain.com. 126551 IN A 66.96.142.146 ns4.mydomain.com. 126551 IN A 65.254.254.170

The DNS server gives your computer the received information and it accesses the desired IP address. But, as we can see, there is a lot of various information here. Let's consider everything in more detail.

What is domain delegation

Delegation of a domain is the transfer by the root server of a zone of the right to host a domain on a specific NS server. For example, the root servers DELEGATE the .COM zone to the servers that will be responsible for it, and the servers of the .COM zone DELEGATE the MYDOMAIN.COM domain to the hosting provider's NS servers or to some others. The delegation itself means that the root server for the domain has IN NS records that point to the NS server that hosts the information for the domain. Note that delegation assumes ONLY IN NS records and no others. Therefore, a second-level domain cannot be assigned, for example, a CNAME record.

What are child NS servers

Sometimes NS servers for a domain are located on its subdomains. In the example above, the MYDOMAIN.COM domain is delegated to the NS servers ns1.mydomain.com, ns2.mydomain.com, and so on. How is this possible? After all, in order to contact these NS-servers, you need to find out their ip-address. It's simple - the root server of the .COM zone with this option requires specifying not only the domain names of the NS servers, but also their ip-addresses. Therefore, the DNS server knows where to look for details. Consider an example of two domains - with and without a child NS-server: NS-record for the domain diphost.ru

;; ANSWER SECTION: diphost.ru. 292 IN NS ns1.bz8.ru.

NS-record for bz8.ru domain

;; ANSWER SECTION: bz8.ru. 300 IN NS ns1.bz8.ru. ;; ADDITIONAL SECTION: ns1.bz8.ru. 95617 IN A 185.35.220.5 ns1.bz8.ru. 95617 IN AAAA 2a00:e460:2a00:c01d::9:aaaa

As you can see, everything is simple. Such a setting is foreign registrars called Child NameServers

What are NS records for a domain

NS record- indicates on which NS servers the domain is located. This entry must match the values ​​for the domain found on the zone's root servers. Only in this case the domain will be DELEGATED.

mydomain.com. 1448 IN NS ns3.mydomain.com.

A-record- specifies the IPv4 address of the server to be accessed by domain name. A domain can have several A-records. In this case, a random one is chosen.

mydomain.com. 248 IN A 65.254.242.180

AAAA record- indicates the IPv6 address of the server. Also, this entry is sometimes referred to as Quadra-A (four A)

MX record- points to the ip-address or domain name of the server responsible for receiving mail to this domain (MX-server). In our example, all mail to any address in the MYDOMAIN.COM domain will go to the mail.mydomain.com server.

mydomain.com. 3248 IN MX 0 mail.mydomain.com.

There can also be multiple MX records. The MX record, in addition to the server name, also has a "Priority" field. It specifies in what order to contact the MX servers of the domain. The lower the priority value, the higher the priority of the server.

TXT record- Here they record various service information, for which there are no selected fields. You can write down the administrator's contact information, or whatever. TXT records are also used to store SPF and DKIM records used for spam protection.

mydomain.com. 86048 IN TXT "v=spf1 ip4:38.113.1.0/24 ip4:38.113.20.0/24 ip4:12.45.243.128/26 ip4:65.254.224.0/19 ?all"

CNAME record- serves to indicate that the domain is a synonym (alias) of another domain. For the same reason, a domain with a CNAME record cannot have any other records.

SOA record- generated automatically by the NS-server and contains service information: address Email responsible for NS-server, date and time latest update domain, zone cache time limit (TTL), etc.

SRV record- serves to store the addresses of various servers serving the domain. They usually do not match the address of the web server specified in the A-record and, like the MX server, are located at different addresses. You can add JABBER addresses to this entry, TeamSpeak servers etc.

General rules for registration of records on the NS-server

If the entry contains a domain name, it must end with a period, otherwise the main domain name will be glued to it. Those. if you specify an entry

mydomain.com. IN MX 10 mx.mail.ru

then the MX server of the domain will be defined as mx.mail.ru.mydomain.com. So the correct notation is:

mydomain.com. IN MX 10 mx.mail.ru.

  • Translation

An attentive reader will find in this picture IPv6


People are often puzzled by domains. Why is my site not working? Why is this crap broken, nothing helps, I just want it to work! Usually, the questioner either does not know about DNS, or does not understand the fundamental ideas. For many, DNS is a terrible and incomprehensible thing. This article is an attempt to dispel such fear. DNS is Just if you understand a few basic concepts.

What is DNS

DNS stands for Domain Name System. It is a global distributed key and value store. Servers around the world can provide you with a key, and if they don't know the key, they will ask another server for help.


That's all. Is it true. You or your browser requests a value for the www.example.com key, and receives 1.2.3.4 in response.

Basic pieces

A big plus of DNS is that it is a public service, and you can poke at the servers if you want to figure it out. Let's try. I have a petekeen.net domain hosted on web01.bugsplat.info . The commands used below can be run from command line OS X ( oh, that is macOS, - approx. per.).


Let's take a look at the mapping between name and address:


$ dig web01.bugsplat.info

The dig command is like a swiss army knife for DNS queries. Cool, multifunctional tool. Here is the first part of the answer:


; <<>> DiG 9.7.6-P1<<>> web01.bugsplat.info ;; global options: +cmd ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51539 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

There is only one interesting detail here: information about the request itself. It is said that we requested a record and received exactly one response. Here:


;; QUESTION SECTION: ;web01.bugsplat.info. IN A

dig asks for A records by default. A is address(address), and this is one of the fundamental types of records in the DNS. A contains one IPv4 address. There is an equivalent for IPv6 addresses - AAAA. Let's take a look at the answer:


;; ANSWER SECTION: web01.bugsplat.info. 300 IN A 192.241.250.244

The rest of the answer describes the answer itself:


;; Query time: 20msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:01:16 2013 ;; MSG SIZE rcvd: 56

Specifically, it says how long the server took to respond, what the server's IP address is (192.168.1.1), what port dig knocked on (53 , the default DNS port), when the request was completed, and how many bytes were in the response.


As you can see, a normal DNS query has a lot going on. when you open a web page, the browser makes dozens of these requests, including downloading all external resources like images and scripts. Each resource is responsible for at least one new DNS request, and if the DNS was not designed for strong caching, then a lot of traffic would be generated.


But what you don't see in this example is that DNS server 192.168.1.1 contacted a bunch of other servers to answer a simple question: "where does web01.bugsplat.info point to?". Let's run a trace to find out about the entire possible chain that dig "y would have to go through if the information was not cached:


$ dig +trace web01.bugsplat.info ;<<>> DiG 9.7.6-P1<<>> +trace web01.bugsplat.info ;; global options: +cmd . 137375 IN NS l.root-servers.net. . 137375 IN NS m.root-servers.net. . 137375 IN NS a.root-servers.net. . 137375 IN NS b.root-servers.net. . 137375 IN NS c.root-servers.net. . 137375 IN NS d.root-servers.net. . 137375 IN NS e.root-servers.net. . 137375 IN NS f.root-servers.net. . 137375 IN NS g.root-servers.net. . 137375 IN NS h.root-servers.net. . 137375 IN NS i.root-servers.net. . 137375 IN NS j.root-servers.net. . 137375 IN NS k.root-servers.net. ;; Received 512 bytes from 192.168.1.1#53(192.168.1.1) in 189 ms info. 172800 IN NS c0.info.afilias-nst.info. info. 172800 IN NS a2.info.afilias-nst.info. info. 172800 IN NS d0.info.afilias-nst.org. info. 172800 IN NS b2.info.afilias-nst.org. info. 172800 IN NS b0.info.afilias-nst.org. info. 172800 IN NS a0.info.afilias-nst.info. ;; Received 443 bytes from 192.5.5.241#53(192.5.5.241) in 1224 ms bugsplat.info. 86400 IN NS ns-1356.awsdns-41.org. bugsplat.info. 86400 IN NS ns-212.awsdns-26.com. bugsplat.info. 86400 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 86400 IN NS ns-911.awsdns-49.net. ;; Received 180 bytes from 199.254.48.1#53(199.254.48.1) in 239 ms web01.bugsplat.info. 300 IN A 192.241.250.244 bugsplat.info. 172800 IN NS ns-1356.awsdns-41.org. bugsplat.info. 172800 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 172800 IN NS ns-212.awsdns-26.com. bugsplat.info. 172800 IN NS ns-911.awsdns-49.net. ;; Received 196 bytes from 205.251.195.143#53(205.251.195.143) in 15 ms

The information is displayed in a hierarchical sequence. Remember how dig inserted a dot. after host, web01.bugsplat.info ? So, point. this is an important detail, and it signifies the root of the hierarchy.


Root DNS servers are maintained by various companies and governments around the world. Initially, there were few of them, but the Internet grew, and now there are 13 of them. But each of the servers has dozens or hundreds of physical machines that hide behind one IP.


So, at the very top of the trace are the root servers, each defined with an NS record. An NS record associates a domain name (in this case, the root domain) with a DNS server. When you register a domain name with a registrar like Namecheap or Godaddy, they create NS records for you.


In the next block, you can see how dig picked a random root server and asked it for the A record for web01.bugsplat.info . Only the IP address of the root server (192.5.5.241) is visible. So what exactly was the root server? Let's find out!


$ dig -x 192.5.5.241 ;<<>> DiG 9.8.3-P1<<>> -x 192.5.5.241;; global options: +cmd ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2862 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;241.5.5.192.in-addr.arpa. IN PTR ;; ANSWER SECTION: 241.5.5.192.in-addr.arpa. 3261 IN PTR f.root-servers.net.

The -x flag tells dig to do a reverse lookup on the IP address. The DNS responds with a PTR record that connects the IP and the host, in this case f.root-servers.net .


Returning to our initial query, the root server F returned a different set of NS servers. It is responsible for the info top-level domain. dig asks one of these servers for the A record for web01.bugsplat.info , and gets back another set of NS servers, and then asks one of these servers record A for web01.bugsplat.info. . And finally gets an answer!


Phew! A lot of traffic would be generated, but almost all of these records were cached for a long time by each server in the chain. Your computer also caches this data, as does your browser. More often than not, DNS queries never reach the root servers because their IP addresses almost never change ( “Probably all the same, we are talking about a large TTL for records in their database. If the IP address of the DNS server has never changed at all, this does not mean that its database is cached forever.- approx. from ). Top-level domains com , net , org , etc. are also usually heavily cached.

Other types

There are a few more types worth knowing about. The first one is MX . It connects a domain name to one or more mail servers. Email is so important that it has its own type of DNS record. Here are the MX values ​​for petekeen.net:


$ dig petekeen.net mx ;<<>> DiG 9.7.6-P1<<>> petekeen.net mx ;; global options: +cmd ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18765 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;petekeen.net. IN MX ;; ANSWER SECTION: petekeen.net. 86400 IN MX 60 web01.bugsplat.info. ;; Query time: 272 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:33:43 2013 ;; MSG SIZE rcvd: 93

Note that the MX record points to a name, not an IP address.


Another type that you are probably familiar with is CNAME . Decodes as Canonical Name(canonical name). He associates one name with another. Let's look at the answer:


$ dig www.petekeen.net ;<<>> DiG 9.7.6-P1<<>> www.petekeen.net ;; global options: +cmd ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16785 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.petekeen.net. IN A ;; ANSWER SECTION: www.petekeen.net. 86400 IN CNAME web01.bugsplat.info. web01.bugsplat.info. 300 IN A 192.241.250.244 ;; Query time: 63 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:36:58 2013 ;; MSG SIZE rcvd: 86

It is immediately clear that we received two responses. The first one says that www.petekeen.net points to web01.bugsplat.info . The second returns the A record for that server. You can think of a CNAME as an alias (or alias) for another server.

What's wrong with CNAME

CNAME records are very useful, but there is an important point: if there is a CNAME with some name, then you cannot create another record with the same name. No MX , no A , no NS , nothing.


The reason is that the DNS does the replacement so that all records of the location where the CNAME points to are also valid for the CNAME . In our example, the entries for www.petekeen.net and web01.bugsplat.info will match.


Therefore, you can't do a CNAME on a root domain like petekeen.net , because you usually need other records there, like MX .

Requests to other servers

Let's pretend that the DNS configuration is messed up. You think you've fixed the problem, but don't want to wait for the cache to refresh to make sure. With dig, you can query the public DNS server instead of your default, like this:


$ dig [email protected]

The @ symbol followed by an IP address or host causes dig to query the specified server on the default port. You can use Google's public DNS server or the Level 3 near-public DNS server at 4.2.2.2 .

Typical situations

Let's look at typical situations that are familiar to many web developers.

Domain redirect to www

It is often necessary to redirect the iskettlemanstillopen.com domain to www.iskettlemanstillopen.com . Registrars like Namecheap or DNSimple call it URL Redirect. Here is an example from the Namecheap admin:



The @ character means the root domain iskettlemanstillopen.com . Let's look at the A record for this domain:


$ dig iskettlemanstillopen.com ;; QUESTION SECTION: ;iskettlemanstillopen.com. IN A ;; ANSWER SECTION: iskettlemanstillopen.com. 500 IN A 192.64.119.118

This IP belongs to Namecheap, and there is a small web server running there that just does an HTTP level redirect to http://www.iskettlemanstillopen.com:


$ curl -I iskettlemanstillopen.com curl -I iskettlemanstillopen.com HTTP/1.1 302 Moved Temporarily Server: nginx Date: Fri, 19 Jul 2013 23:53:21 GMT Content-Type: text/html Connection: keep-alive Content-Length : 154 Location: http://www.iskettlemanstillopen.com/

CNAME for Heroku or Github

Take a look at the screenshot above. On the second line there is CNAME . In this case, www.iskettlemanstillopen.com points to an application running on Heroku.


$ heroku domains === warm-journey-3906 Domain Names warm-journey-3906.herokuapp.com www.iskettlemanstillopen.com

With Github, the story is similar, but there you need to create a special file in the root of the repository, and name it CNAME . See .dns documentation

  • domain
  • net
  • Internet
  • administration
  • Add tags

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

    Name/Host/Alias; Record Type; Value/Response/Destination/Address.

    In all options, "Record Type" remains unchanged.

    Record name

    The name of the entry, also known as the host/alias, is the domain name to which the created entry belongs or is linked.

    When creating a record in the "Name" field, the domain name is specified in full. The subdomain or alias name does not need to be fully qualified. It is enough to specify the name of the third level: mail, www, ftp. If you enter the full name, be sure to put a dot at the end. That is, the name mail and mail.example.ru. it's the same name in the Name/Host/Alias ​​field.

    DNS Record Types

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

    Record Type A

    Record Type: A (address record) or (Internet 4 address). This record type binds a specific domain name to a specific, precise IP address.

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

    In theory, you can specify more than one domain for one IP address. But you don't need to do this, because the Domain Name System (DNS) has an entry specifically for creating aliases. This record is called a CNAME.

    Record type AAAA

    Record type: AAAA (address record for IPv6) or (Internet 6 address). Same. Same as record type A, but IP address looks like IPv6. 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 record of type A is created, for one IP address. The domain name in an 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).

    The 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

    ftp IN CNAME hosting-b , transfer to the 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 bind 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 associate the domains example.com, www.example.com, test.example.com with the canonical domain example.ru. The dots at the end are required.

    Another example of a redirect (redirect) using a CNAME record

    www.example.ru IN CNAME example.ru.

    Usually, by default, servers create CNAME records only for subdomains of the main domain and do not make 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 (own) mail server.

    For example: Name/host/alias - example.ru; Record type -MX (mail server); Value/Response/Destination/Address - mail. With this entry, you create the mail subdomain mail.example.ru. If the server's internal mail service is used, then the "A" record type must be created for the mail.example.ru subdomain. Name: mail - A (record type) - Address: Server IP.

    As a mail service, you can use third-party mail servers. 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 do not create, they will give the address of the mail server. After that, you need to create CNAME and MX records on your server.

    Forward the mail domain mail.example.ru with the CNAME record. to the email address. And a record of the MX type for the example.ru domain 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:

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

    • The CNAME type is:

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

    On the Yandex mail server, without delegating a domain, 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 Google, Mail.ru and other mail servers:

    NS record type

    The record type is NS (name server). This is perhaps the most important type of entry. It defines the domains (addresses) of the DNS servers serving this domain.

    TXT record type

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

    SOA (Start Of Authority) record

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

    • An arbitrary serial number of the data version (Serial). When a secondary server requests a data update, it first checks the serial number;
    • Frequency of a request to update data from the secondary (Secondary) server (Refresh), in seconds;
    • The period of re-request of 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 serving requests if it fails to restore communication with the primary server, in seconds;
    • Lastly, the time to live for DNS zone data in the cache of the server (TTL) that requested it, in seconds.

    Here is an example 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, entries are edited on the tab: DNS Management.

    Top Related Articles