DNS-Master Russian   English
PROJECT
OF COMPANY
RU-CENTER
 
     
 
 
 

Help

DNS-master user's manual

Contents:

1. Definitions
2. Introduction
Zone file editor allows you to
3. Editing a zone file
3.1. Changing Default TTL
3.2. Changing the SOA record
3.3. Changing, adding, deleting resource records
4. Exiting the editor
5. Additional features
5.1. Upload the zone file from your computer
5.2. Downloading zone file to your computer
5.3. Load the zone file from the version archive
5.4. View the zone file access log
5.5. Compare archived versions
6. Additional options
6.1. Zone file preview
6.2. Adding comments on zone file versions
7. Diagnosis of attempts to edit a zone file by several users concurrently
8. Record types and parameters
8.1. Format of temporal parameters
8.2. Default TTL, TTL, and Minimum TTL parameters.
8.3. Start Of Authority (SOA) record
8.4. A record
8.5. NS record
8.6. MX record
8.7. CNAME record
8.8. AAAA record
8.9. PTR record
8.10. SRV record
8.11. TXT record
8.12. Wildcard ("*") in zone file records

1. Definitions

Domain is an autonomously administered area of the DNS.

DNS is Domain Name System. Its main purpose is to map domain names into IP addresses and vice versa — IP addresses into domain names. The basis of the DNS is a distributed hierarchical database.

Domain name is the identifier of a record in the DNS database, which is usually in the form of several labels separated by dots.

DNS server is a program that stores one or several DNS zones and serves queries to the DNS database.

Zone is a portion of the DNS database which holds information on a domain.

Primary DNS server for a zone is the DNS server that stores full resource information on the zone.

Zone file is a file that contains complete resource information on a zone and is stored on the Primary DNS server for the zone.

Zone file version is a number which is incremented whenever an editing session is closed and the relevant zone file is saved.

Host is a computer or other device connected to the Internet.

2. Introduction

DNS servers are essential for the operation of a domain (zone), processing requests for the domain (zone) on the Internet. At least two of these servers are required for the proper operation of a domain.

The DNS server that holds complete resource information on a particular zone is known as the Primary DNS server. Any other DNS server is termed Secondary if it receives full information on the zone from the Primary or another Secondary DNS server.

Zone file editor allows you to:

  • Make changes in a zone file with subsequent verification of every single record as well as their aggregate.
  • Return to any of the previously saved zone file versions.
  • Upload a zone from a file located on your computer.
  • Avoid the errors that often occur when several users attempt to edit a zone file concurrently.
  • View a zone file access log maintained by the editor.
  • Compare any of the previously saved zone file versions.

IMPORTANT NOTE:

  • The editor is intended for use with browsers that support JavaScript.
  • The data is transferred through HTTPS (Hypertext Transfer Protocol Secure). If upon starting the editor you receive a message saying the page cannot be displayed, this may be due to the following factors: either the SSL connection option of your browser is set off, or your network forbids the connection via the 443 port.

3. Editing a zone file

Editing a zone file consists of a series of actions; each of them can alter records, values, or parameters of the zone. Each action ends with interim saving of the changes.

When temporally saving the entered record's correctness is checked (parameter, value) and the totality of records in the zone with consideration of the entered record is also checked (parameter, value). When editing a zone file, auto checking of the whole totality of records in the zone is not performed, if the zone file includes more than 250 records. In that case the "Check" button can be used to check the totality of records in the zone during editing.

To finish editing and save all changes you have made in a zone file on the DNS server, you have to close the editing session according to the recommendations given in the paragraph 4 of this manual.

When editing is ended, correctness of the whole totality of records in the zone is checked. If the totality of records in the zone is not correct according to DNS standards, the zone file editor reports an error. Changes, made in the zone file during editing, will be saved only if checking the totality of records in the zone is successful.

3.1. Changing Default TTL

  • in the "Default TTL:" line, click on the "Change" link;
  • change the parameter and press the "Save" button.

3.2. Changing the SOA record for a zone

  • in the "SOA record for this zone:" line, click on the "Change" link;
  • make changes and press the "Save" button.

There are following parameters in an SOA record:

Note: While editing, do not alter the "Serial number". Its value will automatically be incremented after you have saved your changes.

3.3. Changing, adding, deleting resource records

A, NS, MX, CNAME, PTR, SRV or TXT type records belong to zone file resource records that can be changed, deleted, and added.

Further information about these types and their functions is available here: RFC-1035.

You can do the following:

3.3.1. Changing (editing) an existing record

  • Click on the "Change" icon located to the right of the record you wish to edit.
  • Change the record parameters in this new window.
  • Press the "Save" button to save the changes or press the "Cancel" button to cancel them.

3.3.2. Deleting a record

  • Click on the "Delete" icon located to the right of the record you wish to delete.
  • In the new window, press the "OK" button to confirm the deletion of the record or press the "Cancel" button to cancel it.

3.3.3. Adding a new record

  • Click on the "Add" icon located where you wish to add a new record.
  • In the window that opens, choose a record type: A, NS, MX, CNAME, PTR SRV or TXT and press the "Continue" button to proceed with adding the record or press the "Cancel" button to cancel this process.
  • in the window that appears, enter the values for the parameters of the record and press one of the following buttons:
    • "Back" — to return to the window where you choose the record type.
    • "Save" — to save the record.
    • "Cancel" — to cancel the addition of the record and return to the zone file editing page.

4. Exiting the editor

4.1. If no changes have been made in the process, the zone file editing interface is exited by pushing the "Finish zone file editing" button.
4.2. If during an editing session you have made changes, the zone file editing page will include new links:



as well as a warning message: "Unsaved changes" with the date and time of the last change and IP address of the host from which the changes were made.

  • To finish zone file editing without saving click on the link "Finish editing: >and don't save changes" and in the window that opens, press the "OK" button to confirm "exiting without saving" or press the "Cancel" button to refuse "exiting without saving".

    If you choose "Finish editing: >and don't save changes", all the changes you have made during this editing session will be lost.

  • To finish zone file editing with saving click on the link "Finish editing: > and save changes".

    When you finish an editing session, the aggregate of records in the zone file is verified, and the "Serial number" parameter in the SOA record is incremented.

    Saved changes take effect (are entered onto the DNS server) within 4 hours.

4.3. After you finished editing a zone file, you can go to the "Manage your account" section on www.nic.ru, and in that case authorization for entering the zone file editor remains valid.

4.4. To finish working with the zone file editor and to end the authorization session, click on the "Exit" link.

5. Additional features

The additional features menu is accessible through the "Additional features" link, which is found on the zone file editing page. This menu provides you with the following options:

  • Upload the zone file from your computer
    You can create a file containing the information about your zone (in compliance with the documents RFC-882, 1035, and 1183) on your computer, and then upload it to the zone file editor.
  • Downloading zone file to your computer
    You may get the file copy, being edited at the moment, with your zone details in the format given in documents RFC-882, RFC-1035, RFC-1183.
  • Load the zone file from the version archive
    You can edit the current zone file by returning to and editing any of its previously saved versions.
  • View the zone file access log
    You can view the history of all operations of access to the current zone file, which is stored in the access log for this file.
  • Compare archived versions
    You can view a visual representation of the differences between any of the previously saved versions of the current zone file. (The version numbers here are those in the archive.)

5.1. Upload the zone file from your computer

  • On the "Additional features" page, click on the link "Upload the zone file from your computer".
  • In the window that opens, select a zone file located on your computer by typing its full path in the "Zone file" field or pressing the "Browse..." button and browsing through the folder tree.
  • After selecting a file, press the "Upload File" button to load the file into the editor.

If the zone file contains an error, the loading will be aborted with a message describing the error and indicating the number of the line where the error occurs. It is necessary to fix the error and retry loading the zone file.

Note: After loading a zone file the "Serial number" parameter in the SOA-record will be automatically raised by one point compared to the last zone file version, so that its value is higher than the previously set.

5.2. Downloading zone file to your computer

  • On the "Additional features" page click on the link "Downloading zone file to your computer".
  • In the window that opens press the "Download zone file" button and save the zone file to your computer.

5.3. Load the zone file from the version archive

On the "Additional features" page, click on the link "Load the zone file from the version archive". In the window that opens, you will see a list of all versions of the zone file that have ever been saved onto the DNS server.

The list of versions contains the following fields:

Version is the zone file version number.
Date is the date and time when the version was saved.
Agreement is the contract (form) number and the authorization type (admin or tech) which were used by the person that saved the version.
Comment is the comment on the version, which was made by the person that saved the version;
"Load" link is the link to click on to load the relevant version.

Locate the desired zone file version and click on the "Load" link.

5.4. View the zone file access log

  • On the "Additional features" page, click on the link "View the zone file access log".
  • In the window that opens, specify any of the conditions for retrieval of records from the log (time limits, IP address, agreement number, operation) and press the "Display" button, or, if you wish to view all records in the log, press the "Show all records" button;
  • You will be shown the specified selection from the zone file access log.

5.5. Compare archived versions

  • On the "Additional features" page, click on the link "Compare archived versions".
  • In the window that opens, enter the numbers of the versions you wish to compare in the input fields of the "Compare versions" line (the version numbers here are the serial numbers in the archive). A version number must be a positive integer within the range of 1 to the number of the last saved version. The latter is prompted next to the input fields.
  • Choose a mode of outputting the information on the differences between the versions:
    • Visual — the result of the comparison will be represented as a pair of columns: one for each of the specified versions. Those lines that are different will appear opposite each other and have a distinct colour. Next to each line you will see its number (for each of the compared zone file versions respectively).
      To help you orient yourself in the compared zone files, there is an option of displaying the matching lines that are before and after the differing file sections. To enable this option, tick the box "Display matching lines" and, in the relevant input field, indicate the number of lines before and after a differing section to be displayed.
    • In diff format — the result of the comparison will be represented in a text form, in the standard format of the diff utility.
  • After specifying the versions to compare and the display parameters, press the "Compare" button to view the results of the comparison.

6. Additional options

6.1. Zone file preview

View the chosen zone file in a text form. This can be copied and saved.

6.2. Adding comments on zone file versions

If changes are made in the zone file, comments can be added to the changed zone file version.

To add the comment, you need to:

  • In the "Comment:" line, click on the "Change comment" link.
  • in the window that appears, type your text (not more than 255 characters) in the "Comment" field and press one of the following buttons:
    • "Save" to save the comment.
    • "Cancel" to cancel the addition of the comment and return to the zone file editing page.

The comments are displayed in the zone file version list and help locate the desired version.

7. Diagnosis of attempts to edit a zone file by several users concurrently

The following are the possible scenarios of attempts to edit a zone file by several users concurrently:

  • You enter the zone file editor and attempt to edit a zone file when someone else is already editing it and there are interim changes in this file (paragraph 7.1).
  • You enter the zone file editor and attempt to edit a zone file when someone else is already editing it but there are no interim changes in this file (paragraph 7.2).
  • When you are working on a zone file in the editor, some of your colleagues who have the right to edit this file enters the editor, takes over the editing (paragraph 7.3.)
    • And exits the editor (quits the editing session) before your next attempt to save an interim result or to exit the editor and save the changes (paragraph 7.3.1.).
    • And has not yet finished the editing session at the time of your next attempt to save an interim result or to exit the editor and save the changes (paragraph 7.3.2.).

7.1. If you enter the zone file editor and attempt to edit a zone file when someone else is already editing it and there are interim changes in this file, you will see the following message:

The changes of the last editing session are not saved.
Someone may be editing this zone file.

You will also see the dates and times of the unsaved changes and the IP addresses from which they were made.

This means that:

  • Either someone else is currently editing the zone file and there are unsaved changes; or
  • The last session of editing this file has not been closed properly; or
  • You yourself are editing the file and trying to start another session, for example, in a new window of your browser.

You can:

  • Decide not to edit the file at this moment.
  • Continue to edit the file accepting the changes of the current session. In this case, the person who has been editing the file will receive a message saying that the session has been taken over by "somebody" with your IP address.
  • Start editing the file from its last saved version, i.e. start a new editing session for this file (which will cancel the changes made in the currently open session).
Note: all operations of taking over an editing session or starting another session for the same file are recorded in the zone file access log, which is accessible through the "Additional features" menu.

7.2. If you enter the zone file editor and attempt to edit a zone file when someone else is already editing it but there are no interim changes in this file, you will see the following message:

Someone else is editing this zone file.

The absence of unsaved changes in the current editing session will be indicated, and you will also see the IP address of the person who is editing the file.

In this case, you can:

  • Decide not to edit the file at this moment and exit the editor.
  • Take over the editing session.

7.3. When you are working on a zone file in the editor, some of your colleagues that have the right to edit this file enters the editor and takes over the editing.

7.3.1. If at the time of your next attempt to save an interim result or to exit the editor and save the changes the person who took over the session has already exited the editor (finished the editing session), you will receive the message:

The changes of your last editing session are deleted or saved by a person with the proper authority.

If this is the case, you can:

  • Exit the editor
  • Start a new editing session

7.3.2. If the person who took over the editing session has not yet finished it at the time of your next attempt to save an interim result or to exit the editor and save the changes, you will see the message:

The editing session has been taken over by a person with the proper authority

The presence of unsaved changes in the current session will be indicated, and you will also see the dates and times of these changes and the IP address of the person who has taken over the session.

You can:

  • Decide not to edit the file at this moment.
  • Continue to edit the file accepting the changes of the current session.
  • Start editing the file from its last saved version, i.e. start a new editing session for this file.

8. Record types and parameters

A zone file consists of resource records of different types.
The only supported class of records is IN.
A set of resource records of the same type, class and name (on the left of the record) is called a RRset.
SOA and NS records for a name matching the zone name are essential. All other records are optional.
The records are composed of several fields (parameters).

8.1. Format of temporal parameters

In the interface of the zone file editor, you can specify a temporal parameter in weeks, days, hours, minutes, and seconds using the appropriate letters: w — for weeks, d — days, h — hours, m — minutes, s — seconds.

XXw — XX weeks, XXd — XX days, XXh — XX hours, XXm — XX minutes, XXs — XX seconds (where XX is a number).

When writing the parameter into the zone file, the editor will convert it to seconds.

Examples:

1890 — 1890 seconds;

2d5h — 2 days and 5 hours;

3h30s — 3 hours and 30 seconds.

8.2. Default TTL, TTL, and Minimum TTL parameters

Default TTL, TTL, and Minimum TTL are the temporal parameters that determine the Time To Live of a record, during which a DNS server that receives information on the record from any other DNS server (and is not a Secondary one) will store it in its cache and transmit it at the request of another DNS server.

TTL: determines the life time of a particular record.
Optional parameter. If not specified, the time to live is determined by the Default TTL parameter.
Recommended value:
86400 (1d)
Range of values:
600 to 2147483647 seconds inclusive (the 31st power of 2 minus 1)
Records belonging to one RRset (with the same type, class and name on the left of the record) should have the same TTL value.
Default TTL: determines the time to live of those records whose TTL parameter is not specified.
Recommended value:
86400 (1d)
Range of values:
600 to 2147483647 seconds inclusive (the 31st power of 2 minus 1)
Minimum TTL: determines the life time of the negative responses to queries for resources that do not exist in the DNS.
Range of values:
minimum 5 minutes

The format of the temporal parameters is explained in the paragraph 8.1.

8.3. Start Of Authority (SOA) record

The SOA record for a zone contains the name of the Primary DNS server (Primary Name Server), the address for technical contacts (Hostmaster), the serial number (Serial number), various timer values (Refresh, Retry, Expire, Minimum TTL).

In any zone there should be only one SOA-record for a name, coinciding with the name of a zone.

An SOA record has the following format:

Name [TTL] SOA Data

Name: zone name
TTL: see description of the TTL parameter in the paragraph 8.2
SOÓ: record type
Data: Primary Name Server, Hostmaster, Serial number, Refresh, Retry, Expire, Minimum TTL

Example:

8.3.1. Primary Name Server

The Primary DNS server for a zone is the DNS server that stores full resource information on the zone.

Example:

ns3.test.ru. (unchangeable value)

8.3.2. Hostmaster

The e-mail address of the person who is responsible for the content of the zone file.

The format of the Hostmaster parameter:

In the interface of the zone file editor, you specify this parameter as a single e-mail address in its usual format.

When writing the parameter into the zone file, the editor will convert it to the standard format of the Hostmaster field, i.e. with the "." symbol instead of the "@" and a dot at the end.

Example:

test@my-domain-name.ru.

8.3.3. Serial number

The serial number of the current zone file version. This number must be a positive integer and will be incremented every time the zone file is changed (see RFC1982). Incrementing a serial number shows the Secondary servers that the zone file has been changed and they have to update their information on the zone accordingly.

You may forget about incrementing this number manually since it is automatically incremented when you save the zone file in the zone file editor.

If you change a serial number so that after saving the zone file the number turns out to be the same or less than before the editing session, the Secondary servers will not reread the data from the Primary Server, as they will consider the data unchanged.

Range of values (for the zone file editor): 0 to 2147483646 seconds inclusive (the 31st power of 2 minus 2)

8.3.4. Refresh

The Refresh temporal parameter indicates how often the Secondary servers have to query the Primary server in order to find out if the serial number has increased and, therefore, they need to update their data on the zone.

Recommended value: from 1h to 6h

Range of values: from 30m to 4w

The format of the temporal parameters is explained in the paragraph 8.1.

8.3.5. Retry

The Retry parameter indicates how long a Secondary server has to wait before retrying to query the Primary server (in order to check the serial number) if the last attempt failed.

Recommended value: from 20m to 60m

Range of values: from 5m to 2w, but not greater than the value of the Refresh parameter

The format of the temporal parameters is explained in the paragraph 8.1.

8.3.6. Expire

The Expire parameter indicates the period of time during which the Secondary servers can use the current data on the zone if they are unable to check whether the data needs to be updated (for example, because of a lengthy disconnection from the Primary server).

Recommended value: from 1w to 1m

Range of values: no less than the value of the Refresh parameter but no more than 1 year

The format of the temporal parameters is explained in the paragraph 8.1

8.4. A record

An A record allows mapping between the domain name of a host and its IP address.

An A record has the following format:

host_name [TTL] A IP_address

host_name: the domain name of the Internet host for which this record defines the mapping.
TTL: see description of the TTL parameter in the paragraph 8.2
Ó: record type
IP_address: the IP address of the host

Please note that the TTL parameter of all A records related to one domain should have the same value.

Examples of an A record for the host info.test.ru in the test.ru zone file:

or

8.5. NS record

A Name Server (NS) record describes one of the DNS servers for a given domain. The number of NS records in a zone file should equal the number of DNS servers that serve the domain and should include all DNS servers that are specified in the domain. For the second level domains, these are the DNS servers specified in the "nserver" fields in the information on the domain which can be obtained using the Whois service (https://www.nic.ru/whois/).

An NS record has the following format:

domain_name [TTL] NS host_name

TTL: see description of the TTL parameter in the paragraph 8.2
NS: record type
host_name: the host name of a DNS server

Examples of NS records in the domain test.ru. These are DNS servers that serve test.ru and mf.test.ru, which is a third level domain in test.ru:

For the domain test.ru:

For a subdomain, e.g. mf.test.ru:

Please note that the TTL parameter of all NS records related to one domain name should have the same value.

If there are NS-records for any delegated domain name, there can't be any other type records for this domain in this zone, except for glue-records, if necessary (see RFC1034).

For example, in the test.ru zone the vasja.test.ru domain is delegated:

vasja.test.ru. NS ns1.vasja.test.ru.
vasja.test.ru. NS ns2. vasja.test.ru.

In that case glue-records are necessary (A-records with indications of IP-addresses of DNS-servers) of the following type:

ns1.vasja.test.ru. A 194.123.1.1
ns2.vasja.test.ru. A 194.123.2.1

And the following type records are invalid:

vasja.test.ru. MX 10 mail.test.ru.
www.vasja.test.ru. A 194.123.1.3

These records must be in the zone of the domain vasja.test.ru.

8.6. MX record

A Mail Exchange (MX) record defines a mail server, which is a machine that handles post for your domain.

An MX record has the following format:

your_domain [TTL] MX priority mail_server

TTL: see description of the TTL parameter in the paragraph 8.2
MX: record type
priority: determines the priority of this mail server. The less the number the higher the priority (0 means the highest priority, 65535 — the lowest). Thus, mail servers with lower priorities are regarded as secondary and will be used only if all mail servers with higher priorities are inaccessible or out of order for some reasons.
mail_server: the name of a mail server

Examples of MX records for the domain test.ru:

Thus, relay2.test.ru is the primary and relay3.test.ru is a secondary mail server, which will go into action only if relay2.test.ru is inaccessible or out of order for some reasons.

Please note that the TTL parameter of all MX records related to one domain should have the same value, i.e. records from the example cannot exist concurrently.

8.7. CNAME record

A Canonical Name (CNAME) record allows a host to have a mnemonic name. Mnemonic names, or nicknames, are widely used to associate a host with a function, or to abbreviate a name.

The real name is sometimes called canonical.

If there is a CNAME record for a host, other records for this host must refer to its real (canonical) name, not mnemonic. When DNS programs meet a CNAME record, they stop their queries for the mnemonic name and switch to the real name.

For example, the following records are invalid:

ns1.test.ru. CNAME ns.test.ru.
office.test.ru. NS ns1.test.ru.

Furthermore, if a particular name is used as a nickname, it cannot show up as the name in a record of another type in the same file.

I.e. the following construction is invalid:

domain CNAME host_name
domain MX 10 mail_server

Mnemonics are useful, for example, when a host name has changed and you wish to let the users who know the old name gain access to the host.

A CNAME record has the following format:

Mnemonic [TTL] CNAME host_name

Mnemonic: mnemonic name of the host
TTL: see description of the TTL parameter in the paragraph 8.2
CNAME: record type
host_name: canonic host name

Examples of CNAME records for the host arhive.test.ru in the domain test.ru:

8.8. AAAA record

AAAA-type record enables to establish correspondence between the host name in the domain and its IPv6 address.

AAAA-type record has the following format:

host_name [TTL] AAAA IPv6-address

host_name: domain name of the device connected to the Internet, for which this record determines correspondence with its IPv6-address.
TTL: see TTL parameter description in para 8.2
AAAA: record type
IPv6-address: IPv6-address of the host

Please note that all AAAA-type records related to one host name shall have equivalent TTL value.

AAAA record examples for host info.test.ru in zone file test.ru:

or

8.9. PTR record

Pointer (PTR) records enable the reverse mapping of IP addresses into host names. Creating a PTR record is recommended for every host network interface.

It is generally sensible to enter PTR records into reverse zones only.

Note: If your provider has allocated you several IP addresses from its own network, you should request the provider to enter records into reverse zones.

A PTR record has the following format:

address [TTL] PTR host_name

address: the converted IP address of a host
TTL: see description of the TTL parameter in the paragraph 8.2
PTR: record type

Examples of PTR records

If the provider has allocated you IP address 194.85.61.42 in the network 194.85.61.0/24, the record of your host (for example, mx.test.ru) will be made in the reverse zone 61.85.194.in-addr.arpa. The record will have the following form:

or

8.10. SRV record

The SRV record specifies the location of the server(s) providing any service for a specific domain.

Full description of this record type is available in RFC 2782.

The format of the SRV record

_Service._Proto.Name [TTL] SRV Priority Weight Port Target

Service: The symbolic name of the desired service (for example, ldap, kerberos, gc etc.)
Proto: The symbolic name of the protocol may be used by users (for example, tcp, udp)
Name: The domain this record refers to
TTL: See description of the TTL parameter in the paragraph 8.2
SRV: Record type
Priority: The priority of the target host. The lowest number corresponds to the highest priority. (0 means the highest priority, 65535 means the lowest priority)
Weight: A server selection mechanism. The weight field specifies a relative weight for entries with the same priority.
Port: The port on the target host for this service
Target: The domain name of the target host

Examples of SRV records

or

8.11. TXT record

TXT type record is usually used for a text description of a domain name.

A TXT type records has the following format:

name [TTL] TXT text

name: the name of a domain or a host
TTL: see description of the TTL parameter in the paragraph 8.2
TXT: record type
text: one or several text lines, each of which includes no more than 255 characters

Examples of a TXT record:

When adding or editing a TXT-record in the zone file editor's interface:

  • If it is necessary to enter several text lines they should be separated by a line feed.
  • If there are more than 255 characters in a line, line feed is done after the 255th character.
  • It's not necessary to put quotes (") in the beginning and the end of a text line. The line will be automatically recorded in the standard for the field TXT format, that is, with quotes.
  • If quotes are used in a text line, they will be automatically screened.

8.12. Wildcard ( "*" symbol) in zone file records

DNS reserves a special symbol, an asterisk (*), to be used in zone files as a wildcard. A wildcard corresponds with any number of marks in a name, except when a record for a name already exists in the DNS-server's data-base.

The wildcard symbol (*) is valid in a domain name or a host name, if the host name is displayed on the left of the record. The wildcard symbol (*) is invalid in a domain name on the left of the NS-record.

For example, in the test.ru zone file a record for "*.anydomain" name can be made, where anydomain is any domain name in the test.ru zone (for example, domain1.test.ru, domain2.test.ru and so on).

Examples of using wildcards:

Records mean that mail sent to somebody@test.ru addresses will be sent to the relay1.test.ru mail server, and mail sent to any other addresses in the test.ru domain, for example, somebody@mail.test.ru or somebody@anyhost.test.ru, will be forwarded to the relay2.test.ru mail server.

Or

The record means that any possible host name in the test.ru domain (for example, "www.test.ru", "mail.test.ru", "anyname1.anyname2.test.ru" and so on) will correspond to the IP address 194.123.1.1.

Wildcards limitations:

Wildcards do not correspond with domain names for which data is already defined.

For example:

*.test.ru. MX 10 relay2.test.ru.
mail.test.ru. MX 10 relay3.test.ru.
info.test.ru. A 194.123.1.1
office.test.ru. NS ns1.office.test.ru.

For example, mail for somebody@mail.test.ru will be forwarded to the relay3.test.ru mail server, but mail for somebody@anydomain.test.ru will be forwarded to the relay2.test.ru mail server. A search for a MX record for info.test.ru will lead to a reply, that there is no MX record for this domain name, because there is an A record for this name. The wildcard also will not be used for domain names in range of the office.test.ru zone, because the domain office.test.ru is delegated.

 

Maintained by RU-CENTER