.RU, .РФ, .SU, домены 3-го уровня
[order-item]
service:domain
action:update
domain:test.ru
descr:Domain for test purpose
e-mail:sidor@test.my-provider.ru
phone:+7 495 1234567
fax-no:+7 495 1234568
nserver:ns2.nic.ru
nserver:ns1.nic.ru
Пример запроса для геодомена:
lang: ru
request:order
operation:create
login:123/NIC-REG/ADM
password:qwerty
subject-contract:3457/NIC-D
request-id:20011220103455.12345@nic.ru
[order-item]
service:domain
action:update
domain:test.msk.ru
descr:Domain for test purpose
e-mail:sidor@test.my-provider.ru
phone:+7 495 1234567
fax-no:+7 495 1234568
nserver:ns2.nic.ru
nserver:ns1.nic.ru
В заголовке запроса необходимо указать значения request:order и operation:create (см. описание формата заголовка запроса).
После заголовка запроса следуют блоки order-item. Количество этих блоков неограничено, т.е. в одном запросе можно заказать произвольное количество услуг (в том числе не связанных между собой). Каждый блок начинается заголовком, указанным в квадратных скобках в отдельной строке.
Блок [order-item] состоит из следующих полей:
Значение поля
Тип заказываемой услуги. В данном случае необходимо указать фиксированное значение — domain (см. значения полей service и template ). Обязательное поле. Однострочное поле.
Шаблон заказываемой услуги. Необходимо указать значение
client_ru — для .RU, .SU и доменов третьего уровня;
domain_rf — для .РФ
(см. значения полей service и template ). Необязательное поле. Однострочное поле.
Тип заказа. Для заказа на изменение данных по услуги в этом поле необходимо указать значение update. Обязательное поле. Однострочное поле.
Имя регистрируемого домена вместе с зоной. Доменное имя на национальном языке должно быть указано в виде XN—***. Обязательное поле. Однострочное поле.
Описание домена в произвольном текстовом формате на английском языке. Выводится через Whois-сервис . Поле может содержать латинские буквы, цифры, знаки препинания и пробелы. Максимальный размер поля — 300 символов. Необязательное поле. Многострочное поле.
e-mail
phone
fax-no
Контактная информация для отображения через Whois-сервис. Поля могут быть пустыми. Указанные данные будут отображаться в ответах Whois-сервиса только в том случае, если заполнены поля e-mail и phone. В противном случае будут отображаться данные из анкеты.
DNS-серверы домена в формате имя_сервера — пробел — IP-адреса через запятую. Указание IP-адреса (IP-адресов) требуется в том случае, если имя DNS-сервера содержит регистрируемый домен. Во всех остальных случаях достаточно указания имени DNS-сервера. Необязательное поле (но в том случае, если заполняется, должно быть указано как минимум два DNS-сервера, находящиеся в различных сетях класса C). Многострочное поле.
Флаг, управляющий запуском тестирования DNS-серверов при регистрации домена .RU, .РФ и .SU или при направлении заказа типа UPDATE на изменение списка DNS-серверов для зарегистрированного домена.
ON — инициировать стандартную процедуру тестирования DNS-серверов, OFF — не проводить стандартную процедуру тестирования DNS-серверов. Однострочное поле, необязательное для заполнения (по умолчанию его значение ON).
Порядок следования полей в запросе произвольный в пределах каждого блока. Многострочные поля записываются в несколько строк, при этом в начале каждой строки присутствует название поля и разделитель (двоеточие). Для однострочных полей повторение не допускается. Необязательные поля могут либо отсутствовать в блоке, либо их значение может быть пустым (состоящим из пробельных символов).
Пример ответа:
State: 200 OK
request-id:20011220103455.12345@nic.ru
Ответ содержит заголовок (см. формат заголовка ответа) и тело ответа, которое отделяется от заголовка пустой строкой.
В случае успешного выполнения запроса (код 200) в теле ответа содержится одно поле — order_id, в котором указывается идентификатор принятого заказа.
Примечание: Для данного типа запросов код 200 означает только то, что запрос не содержит синтаксических ошибок и принят к обработке. Указанный код не означает, что заказ выполнен с успешным результатом. Сообщаемый в ответе order_id можно использовать для запросов на получение информации о ходе исполнения заказа. В ответ на такие запросы предоставляется точная информация о статусе заказа: выполнен (успешно или неуспешно), в обработке и т.п.
Если в форме запроса обнаружены ошибки, выдается ответ с кодом 402, и в теле ответа содержится блок errors с описанием ошибок на языке, указанном в запросе в поле lang.
The NS record
Like a number of other DNS record types, the original DNS specifications (RFC 1034 and 1035) introduced this record type in 1987. Along with the Start of Authority (SOA) record type, NS records are integral to the proper functioning of the DNS.
A trail of NS records leads to your domain. By NsLookup.io. Licensed under CC By 4.0.
The NS record has only one data field besides the usual DNS TTL field: the fully qualified DNS name of a name server that is authoritative for the domain.
Each NS record specifies the name of one authoritative name server for a particular DNS zone. To specify a list of name servers that are authoritative for a particular DNS zone, a set of NS records is published, where each NS record in the set specifies one authoritative name server.
What is an authoritative name server?
A name server is a server running DNS software listening for DNS requests on port 53. When this server receives a DNS request, it consults its local database of DNS data. If it finds an answer in its local database, it responds with the requested data. If it does not find the data in its local database, then depending on the role and configuration of the name server, it will either return an error or consult other name servers to determine the answer.
An authoritative name server is a name server that has been delegated a DNS zone, and hosts a complete copy of that particular DNS zone. So, an authoritative name server for the zone example.org is a server listening for DNS requests on port 53 whose local DNS database contains a complete copy of the zone example.org .
The master authoritative name server for a zone will often host a copy of the zone served from a standard DNS data file. The zone must have at least one other authoritative name server and will generally have three more. There can be only one primary (also sometimes called master) server for a DNS zone, so the other authoritative DNS servers may use DNS zone transfer (see RFC 5936 and RFC 1995) to copy the zone data.
Name servers that use zone transfer to retrieve a copy of a zone are called secondary servers. However, and somewhat confusingly, secondary servers are authoritative. They hold a copy of the DNS zone, but that copy is just as good from the perspective of authority as the master copy of the zone served by the primary server.
So, if a zone has four authoritative names servers, it may have one primary name servers and three secondary name servers. This pattern is common, but it is not always optimal. The master server might be hidden to protect it from attack, and the four authoritative name servers advertised in the NS records for the zone might all be secondary servers.
Alternatively, a proprietary replication protocol may be used instead of zone transfer. This is commonly seen in the large cloud scale DNS providers.
At the end of the day, it does not matter how DNS data is replicated among the authoritative name servers for the zone. All that matters is that each of the authoritative name servers has a complete copy of the DNS zone and is ready and willing to respond to DNS requests for all the DNS names contained within the zone. See also RFC 8499 for a more technical definition of «authoritative server» and a number of related DNS terms.
NS records at the zone root
Every zone in the DNS must have exactly one SOA record and two or more NS records at the root of the zone. These SOA and NS records are mandatory and together signify the existence of a zone in the DNS. The zone root for an example zone might include records such as:
In this example, we have the SOA record and four NS records at the root of the DNS zone. It is typical to have four NS records for a zone. Most DNS cloud providers today automatically provide four name server records but as few as two NS records is legal.
The requirement to have a minimum of two NS records ensures a basic level of redundancy and is specified by RFC 1034 section 4.1 and also by RFC 1912 section 2.8. A zone may have more than four NS records but this is typically unnecessary.
The time-to-live (TTL) value for NS records should be relatively long. One to two days is typical. Shorter TTL values for NS records are not recommended. As discussed in our article on TTL selection in the DNS, a small outage in the DNS lasting longer than the TTL of the NS records could cause a total outage for all records in the zone.
NS records in delegations
As explained in our article on zone delegation in the DNS, NS records exist at the root of every DNS zone and also at the same name in the parent DNS zone. To resolve a DNS name, a DNS resolver must follow a chain, or trail, of NS records. This begins at the DNS root zone and extends downwards through child zones. That would be the root zone «.» followed by org. and then example.org. in this case.
By using NS records to follow the trail starting at the root zone, a DNS resolver will eventually reach a name server that is authoritative for the zone. The authoritative server will provide an answer to the original DNS query.
An example of zone delegation.
The IP addresses of name servers
You may have noticed that each NS record contains the DNS host name of a single authoritative name server, for example ns4.example.org . This is not sufficient for a DNS resolver to contact the name server. For a DNS resolver to contact a name server, it must know the IP address or addresses of the name server.
DNS gets a bit recursive here. The DNS itself is used to look up the IP addresses of name servers, which are then used by the DNS to contact other name servers in the DNS.
So, for example, if a recursive DNS resolver needs to answer a query for a name in example.org , it will have to perform additional DNS queries to determine the IP addresses of ns1.example.org , ns2.example.org , etc. The DNS is designed to minimize these queries by allowing them to be included as additional data in a delegation response. Caching is also used to minimize these queries.
However, it is vital that the DNS can resolve the host names of each of the authoritative name servers for every zone. If this is not the case, then that zone will likely be unresolvable. This will lead to an outage for any client attempting to use a web server or other resource for the zone.
NS record ordering and preference
The operator of a DNS zone cannot specify that one name server is the master and should be consulted first, for example. This means that the zone operator must ensure that all name servers for the zone have identical zone data and that replication of changes between the name servers occurs quickly and reliably.
DNS resolvers will attempt resolution against more than one available name server for a zone if necessary. So for example, if ns3.example.org is temporarily offline for maintenance, DNS resolvers who attempt to query it during the period of outage will retry the query against another of the name servers for the zone.
Anycast for name server IP addresses
It is common for the provider of any service on the Internet to want to ensure the fastest possible response to their clients. Nobody wants a slow, laggy web page! DNS is required for HTTP and virtually every protocol on the Internet, so fast DNS resolution is critical.
One way in which DNS resolution can be sped up is to have the authoritative DNS servers very close to customers. To this end, some cloud DNS providers have hundreds of datacenters around the world, so that virtually every person on Earth can get a fast DNS response.
It would be very difficult indeed to have hundreds of IP addresses for each of the name servers for a zone, so instead Anycast is used to very elegantly simplify this issue. With Anycast, each name server has only one or two IP addresses (perhaps one IPv4 address and one IPv6 address).
When a query is sent from anywhere in the world to one of these IP addresses, Anycast ensures that it is automatically routed to the nearest data center, and hence the client experiences the fastest possible DNS resolution.
Anycast is itself a very complex subject. It is largely built on the Border Gateway Protocol (BGP). Due to its complexity, and also due to malicious attacks, many high-profile outages in the past have involved BGP issues. Anycast is still a very powerful tool to improve DNS performance and is used by most major DNS providers today.
Dnsperf.com is a good resource to compare the relative speeds of the major authoritative DNS providers.
Common issues
Since DNS resolution depends on the chain of NS records from the DNS root zone down to every zone in the DNS, NS record configuration is critical.
Lame delegations, where one or more NS records have become incorrect, are a common reason for DNS resolution failure. Maintaining the NS records in both the parent and child zones can at times be a difficult task. DNS zone operators should exercise extreme care when making any changes to their NS records, since the change must be made at both the root of the zone and in the delegation in the parent zone. An error in NS record configuration in either zone can result in an outage.
Another common problem is when DNS changes do not replicate between name servers. Either due to human error or system failure, a change made on one name server might not replicate to the other name servers. In this scenario, some clients will see the change and some will not, depending on which name server is consulted. This will lead to sporadic outages for some clients.
RFC 1912 section 2.8 has a good discussion of potential NS record issues.
Finding the NS records for a zone
The NS records of a zone can be queried with the dig or nslookup command line tools. To find the NS record for example.org , use this command:
On operating systems that support nslookup, you can use the following:
You can also check the NS records of any domain name in our name server lookup tool, or by entering it here:
Jeff Westhead Technical writer
When are NS records at the apex of a DNS domain queried?
As seen above, ns1.example.com and ns2.example.com are two authoritative name-servers for that zone. When are they queried by other name-servers? As much as I tested, the only time when those two records were queried was when I asked for NS records from 192.168.0.159 with a DNS lookup utility, i.e dig @192.168.0.159 -t NS example.com .
1 Answer 1
For the casual user, it really shouldn’t matter. If what you’re after is consistent delivery and uptime for your domain, the rules are pretty simple:
- The NS records on your nameservers should only point at A and AAAA records. (not CNAME records, etc.)
- Make sure to include IPv4 addresses ( A records), or it will not be possible for DNS servers running single-stack IPv4 to obtain information about your domain.
- The names and IP addresses of those nameservers should match how your domain is configured within the registrar’s control panel.
That’s it. The how and why of the implementation doesn’t matter so much. If you diverge from this recommendation, the result will be a great deal of inconsistent and unpredictable behavior. Scary phrases such as «undefined behavior» and «implementation specific behavior» both apply here.
With that said, the question being asked by the OP is a completely fair one. Excluding explicit requests by clients and excluding indirect referencing within the authority section of other answers, when are these NS records explicitly requested by recursive nameservers?
You’ve inadvertently walked into one of the more ambiguous areas of how recursive DNS servers operate. To the best of my knowledge, we still don’t have an amendment to the governing Internet Standard clarifying how this is «supposed» to work.
A high level overview of how a recursive DNS server learns about your domain goes like this:
- Recursive server gets a request for www.example.com. IN A .
- If this DNS record is in cache, it is answered from cache.
- If the DNS record is not in cache, it needs to find a nameserver which can provide the answer. It starts by checking its memory to see if it has already identified nameservers related to the domain. It will consult the nameservers for the most specific zone (aka domain) it is aware of. If referrals for more specific zones are encountered, those referrals will be followed until a server identifies itself as authoritative for www.example.com. IN A . (or until an error prevents it from following the path further)
In a «cold cache» scenario (imagine a freshly restarted DNS server), it would have to start from scratch with least specific and work its way up to most specific. For our example of www.example.com. IN A , it would to follow the following set of referrals:
- . : AKA «root» nameservers.
- com. : The Top Level Domain nameservers for com. , learned from . nameservers.
- example.com. : The nameservers listed for example.com. in the com. registry, learned from the com. nameservers.
- www.example.com : This happens only if the example.com nameservers provided a referral to a different set of nameservers for www . For this example let’s assume that’s not the case. Our answer for the A record will have come directly from the nameservers for example.com .
Each step along this path, the recursive server asked if these servers were responsible for www.example.com and received a referral to a more specific set of DNS servers. At no point in this walk did we need to ask for the NS records. We learned about the more specific servers through referrals until one set of servers finally replied with an authoritative answer for www.example.com. (in this case, the example.com. nameservers had our answer)
This is where things get weird.
The NS records we have in memory at this point were learned through referrals. For the purposes of the nameserver this is «good enough», but we now have two problems:
What happens when the TTL associated with the NS records in the referral expire?
What happens when someone asks us for the value of these NS records?
We’ll explore each of these.
The TTL of NS records learned through referrals has expired. Now what?
This is where nameserver behavior diverges greatly. While it has some age on it (March 2011), I strongly recommend reading Ólafur Guðmundsson’s presentation that covers the topic. Slides 11 — 13 introduce us to several patterns of nameserver behavior. I’m going to borrow the same terms from Ólafur’s presentation:
In this instance, «parent» is referring to the NS records that we learned of through the referral. «child» is referring to the NS records that we learned through the authoritative answer we receive when we query the first set of NS records for the value of example.com. IN NS . (i.e. when we are asking those nameservers to return their own NS record. in theory)
The commonality with all of these patterns is that the NS data in memory is first learned from the parent. This is a given, as it’s fundamental to how the process works. Where implementations differ is what they do afterwards:
Child centric non-sticky will initially prefer parent, then swap to the child. Once the child expires, the NS records are «forgotten» and re-learned from scratch in order to provide an opportunity for changes on the parent nameservers to be incorporated. Without this, changes in nameservers related to expired domains would not be caught — both the expiration and renewal thereof. The disadvantage is that occasionally these NS record definitions do not agree, resulting in the recursive server returning different responses for a specific DNS record (i.e. www.example.com. IN A ) depending on which servers it is currently hitting.
Child centric sticky is a very problematic implementation where the nameservers get «stuck» on the child side of the definition and the parent side is not re-evaluated until the cache is purged or the server is restarted. It is generally considered to be the worst of these implementations due to the very obvious problems that are associated with it. (an example would be this Q&A where someone is observing the behavior)
Parent centric is an interesting implementation that eschews the value of the child/authoritative NS records entirely. The general idea behind it is that alternating between the values of the parent and the child cause much more trouble and confusion than it’s worth. By ignoring the «authoritative» version of the NS records completely and always preferring the referral (without which it’s not possible to learn about the authoritative records anyway), you avoid the «flip-flop» problem of child centric non-sticky entirely. The main disadvantage are some edge cases where the NS records from the child side can help expedite a migration off of old nameservers prior to the change being made at the registry. This can can be beneficial when you’re dealing with certain boneheaded registrars who also provide DNS services, but immediately kill all of your DNS data when you change the servers for your domain to point somewhere else.
As you can see, this is a complicated topic and one that is extremely difficult to document without extensive testing. It works this way because the standards remain loose in this area to this day, at least to the best of my knowledge.
What happens when a client asks a recursor for the value of NS records?
Once again, it depends.
RFC 2181 strongly discourages nameservers from returning cached nameserver data learned from referrals in the answer section, but does not outright forbid it: («should not»)
Despite this warning, we can return the NS records observed from the referral in our answer as it’s not explicitly forbidden. I suspect it’s more likely to happen with parent centric implementations, but I don’t have any good data in front of me at the moment. I’ll do some testing on my own when I find the time and update this answer.
What happens if the server has the nameservers from the referral cached, and does honor RFC 2181? In the case of ISC BIND (at least in the 9.10 and 9.11 implementations that I have most experience with), the explicit request for the NS records from the client triggers an immediate refresh against the child nameservers. It’s easiest to observe when the client nameservers are pointing at something that BIND considers broken, such as NS records that point at CNAME records. BIND will initially be able to answer for the domain using the information it received from the initial referral (glue included), but the domain will immediately stop working the moment the NS record request is received and the nameserver attempts to re-learn the nameserver information it needs to communicate with.
Closing Disclaimer: This is an extremely vague and confusing area of recursive server operation. Some things may have changed since I last explored the topic in-depth. I’m happy to amend any information provided here, but please provide specific data citations where possible.
How to Repair the DNS DCV Error in cPanel
How Using Cloudflare Affects AutoSSL in cPanel
We have provided information about Cloudflare, AutoSSL, and the advantages of utilizing those services in previous articles. In this article, we will focus on solving one of the specific issues seen when using Cloudflare and AutoSSL together on a cPanel/WHM server. These services function admirably in almost every setting and can be relied upon to deliver the service they advertise. However, in certain situations, services can clash through no fault of their own.
What is Cloudflare?
Cloudflare is an internet service company that provides a CDN (content delivery network), DDoS mitigation, Internet security, distributed DNS (domain name server), and other services. The Cloudflare service sits between the user and the website hosting provider while acting as a reverse proxy for websites connecting the two.
What is AutoSSL?
AutoSSL is a free alternative SSL certificate that precludes the purchasing of a yearly SSL certificate. It is usually an account-wide setting that is enabled or disabled within the user’s management panel. When AutoSSL is enabled, a daily cron replaces self-signed SSL certificates expired (or soon to be expired) with new Sectigo or Let’s Encrypt certificates. With AutoSSL, local websites are automatically secured with a free, Domain Validated SSL certificate. cPanel’s AutoSSL uses both the Sectigo provider module and a Let's Encrypt™ plugin, which can be downloaded.
What Does the Error Look Like?
When using AutoSSL within WHM and AutoSSL tries to renew an SSL automatically, if the domain is configured to use Cloudflare, an error like the one below is seen can occur. (This is a portion of a log file in which the error is seen.)
Why Does This Error Occur?
The primary method for DNS validation uses HTTP. Still, cPanel takes the extra step and uses an additional local DNS Domain Control Validation (or DCV) process to verify and prove a domain is valid to the certificate authorities.
As part of the DCV process, a DNS record is automatically added to the zone file of a domain on a cPanel & WHM server. This record is added/removed/modified automatically as needed by cPanel/WHM. This issue arises when cPanel cannot retrieve the needed validation due to the domain nameservers being used at Cloudflare, which prevents the validation process during the “AutoSSL” renewal process.
How Do I Know if I am Using Cloudflare?
There are 2 methods we can easily use to verify if our domain is indeed using Cloudflare to handle its DNS, using the command line.