Knowledge Base

Name Server Configuration

Introduction
Registrant is responsible for the completeness and accuracy of all information stated in the domain name application form including the name server configuration and operation.
 
Please take note that MYNIC is not in any way involved in or responsible for the configuration and operation of the Registrant's name servers.
 
Registrant is requested to first contact and resolve matters with its Technical Contact if there is any interruption related to the domain name registered with MYNIC. Common interruptions include e-mail and website problems of the registered domain name.
 
It is also the Technical Contact's responsibility to ensure all the technical requirements are fulfilled at the time of application.
 
You may wish to refer to our guidelines on "How to Configure Your Name Server" and "How to Check Name Server Configuration" for more detailed information regarding name server configuration activities.
 
MYNIC reserves the right to revoke the domain name at any time without prior written notice to the Registrant should MYNIC find any of the information supplied in the form to be incomplete, incorrect or inaccurate.
 
How to Configure Your Name Server?
Let's say you are applying for a domain name abc.com.my with the following name server information in your application form submitted to MYNIC:
Primary Name Server : ns1.abc.com.my
IP Address : 1.2.3.4
Secondary Name Server : ns2.abc.com.my
IP Address : 5.6.7.8
 
The configuration of your name server will involve the creation of a zone file with the following content:
abc.com.my. IN SOA   ns1.abc.com.my.
abc.com.my. IN NS     ns1.abc.com.my.
abc.com.my. IN NS     ns2.abc.com.my.
ns1.abc.com.my. IN A   1.2.3.4
ns2.abc.com.my. IN A   5.6.7.8
 
In this situation, hostnames "ns1.abc.com.my" and "ns2.abc.com.my" are sub-domains of the domain "abc.com.my" and have the IP addresses of 1.2.3.4 and 5.6.7.8. The respective A records must be added in the one file. If the hostname is NOT a sub-domain of the new domain in the zone, then the A record need NOT be added. The hostname must have a trailing dot, i.e. the dot at the end of the hostname.
 
For successful delegation, please ensure that the list of name servers in your configuration matches the list of name servers in the form. This relates to the SOA, NS and A records in the zone file. Also please ensure that your PTR record is configured correctly in your IN-ADDR.ARPA domain.
 
DNS resource records (SOA, NS, A, PTR) are described below.
SOA Record : The first entry in each of the DNS database files (zone files) is the SOA (start of authority) resource record. The SOA record indicates that this name server is the best source of information for the data within this domain. This means that if your primary name server is authoritative for the domain, it is because of the SOA record.
NS Records : The next entries added to a zone file are called NS (name server) resource records. Two NS records indicate that there are two name servers for the domain.
A Records : The A (address) resource records map names to addresses within this domain.
PTR Record : PTR records map IP addresses to domain names (reverse of A records). PTR record is the IP address written in backward order with "in-addr.arpa." appended to the end. As an example, looking up the domain name for IP address "1.2.3.4" is done through a query for the PTR record for "4.3.2.1.in-addr.arpa."
 
For further information please refer to DNS & BIND 3rd Edition by Paul Albitz & Cricket Liu, O'Reilly & Associates Inc. and Domain Administrators Operations Guide.
 
How to Check Name Server Configuration?
Registrant and Technical Contact are required to check on the configuration to ensure that the domain name is properly delegated. There must be a primary and a secondary name server that have IP connectivity to the Internet and can be easily checked for operational status and database accuracy by MYNIC. The Technical Contact is responsible to ensure that both primary and secondary name servers give authoritative answers for the domain name at all times, thus eliminating lame delegation problem.
 
There are many DNS tools such as nslookup, dig and host which can be used to query name servers. Here we will stress more on the usage of the nslookup command:
 
nslookup -q=any <domain name> <Primary/Secondary's IP>
 
The query type " -q=any " is a nslookup query option to get any type of records configured for that domain. The example below will illustrate on how to check the name server configuration using nslookup. The name servers listed in the application for domain name abc.com.my:
Primary Name Server : ns1.abc.com.my
IP Address : 1.2.3.4
Secondary Name Server : ns2.abc.com.my
IP Address : 5.6.7.8
When is a Name Server Authoritative?
  • The name server contains current data in files for the zone in question. Data must be current for secondaries, as defined in the SOA
  • The name server is told that it is authoritative for the zone
  • The name server does an error-free load of the zone
 
If the name servers have been configured correctly, both servers should give authoritative answers as follows when queries are performed using nslookup command.
 
Query Performed on the Primary Name Server
nslookup -q=any abc.com.my 1.2.3.4
 
Primary Name Server Query Result
Server: ns1.abc.com.my <== PTR Record Address: 1.2.3.4abc.com.my origin = ns1.abc.com.my <== SOA Record mail addr = hostmaster.abc.com.my serial = 2001062103 refresh = 28800 (8H) retry = 7200 (2H) expire = 604800 (1W) minimum ttl = 3600 (1H) abc.com.my internet address = 7.8.9.1 abc.com.my preference = 10, mail exchanger = mail.abc.com.my abc.com.my nameserver = ns1.abc.com.my <== NS Record abc.com.my nameserver = ns2.abc.com.my <== NS Record ns1.abc.com.my internet address = 1.2.3.4 <== A Record ns2.abc.com.my internet address = 5.6.7.8 <== A Record
 
Query Performed on the Secondary Name Server
nslookup -q=any abc.com.my 5.6.7.8
 
Primary Name Server Query Result
Server: ns2.abc.com.my Address: 5.6.7.8Non-authoritative answer: <== ERROR abc.com.my nameserver = ns1.abc.com.my abc.com.my nameserver = ns2.abc.com.my Authoritative answers can be found from: abc.com.my nameserver = ns1.abc.com.my abc.com.my nameserver = ns2.abc.com.my ns1.abc.com.my internet address = 1.2.3.4 ns2.abc.com.my internet address = 5.6.7.8
Nslookup Errors Reports
If the lookup request was not successful, an error message is printed. Below are possible common errors from the name server that might cause to the interruption in accessing the domain name (i.e website, e-mail, etc). Thus, Registrant is required to seek assistance from Technical Contact to resolve the problem.
 
Nslookup Error Message
ERROR DESCRIPTION
Timed out The server did not respond to a request after a certain amount of time (changed with set timeout=value) and a certain number of retries (changed with set retry=value).
No response from server
  • No name server is running on the server machine
  • The name server didn't get back the response
No records The server does not have resource records of the current query type for the host, although the host name is valid. The query type is specified with the set query type command.
Non-existent host/domain
  • The host or domain name does not exist
  • PTR data for that name server's address does not exist
Connection refused Network is unreachable The connection to the name or finger server could not be made at the current time.
Server failure The name server found an internal inconsistency in its database and could not return a valid answer.
Query Refused The name server refused to service the request. This one has two possible causes:-
  • Name server does not support inverse queries (older nslookups ONLY) OR
  • Zone security is stopping the lookup
Why Do We Need to Check on All The Records?
It is very important to see the respond that we might get from the name servers to be registered with MYNIC. Please refer to the table below for more details on the effect of name servers not giving proper answers to the nslookup query.
 
Common Configuration Error Effect
One or more name servers, registered as being authoritative for the zones, did not contain authoritative data (lame delegations) Lame delegations are very common on the Internet and cause unnecessary traffic for DNS queries, slow down the lookup of zone data, and may cause lookup failures for zone data. This can cause potentially serious for web visitors and for delivery of mail; If only one of the servers to which the zone is delegated actually has authoritative data for the zone, then if that server should unavailable, the zone is effectively not locatable from the net. It doesn't matter if there are other servers that have authoritative data for the zone, because they are not listed in the delegation.
Delegation data and zone data do not match This can be source of lame delegations, and otherwise can cause similar problems as lame delegations.
None of the authoritative name server answered It was not possible to get information about the zone from any of the servers that were listed as being authoritative for the zone, causing web site lookup failures when name servers try to look up data for the zone. As with the lame delegations, it doesn't matter if other name servers are configured with authoritative data for the zone and are up and running, because they are not listed in the delegation. This domain is effectively cut off from the net.
PTR record is missing for an A (IP address) record If a PTR record is missing for a host, a client running on that host may have problems getting access to some services on the internet (FTP for example). In general though, there should be exactly one PTR record per IP address in use, not necessarily one for every A record.
Two authoritative name servers have the same IP address Both primary and secondary name servers are run on the same physical machine, which can provide false security since data from both servers will become inaccessible if the machine crashes.
There is only one NS record in the zone data This can disrupt service if the server listed in the zone data becomes inaccessible.
What is Lame Delegation?
Lame delegation is a situation when name server X is delegated as authoritative for domain Y, yet when you ask X about Y, it returns non-authoritative data.
 
A lame delegation situation happens when:
  • Name server X is delegated as authoritative for a domain.
  • Name server X is not performing nameservice for that domain.
 
Let's say the domain abc.com.my gets registered at MYNIC. Then, MYNIC had listed two name servers in the com.my name servers as follows:
abc.com.my. IN SOA   ns1.abc.com.my.
abc.com.my. IN NS     ns1.abc.com.my.
abc.com.my. IN NS     ns2.abc.com.my.
ns1.abc.com.my. IN A   1.2.3.4
ns2.abc.com.my. IN A   5.6.7.8
 
The Technical Contact had correctly configured the name server ns1.abc.com.my. However, the name server ns2.abc.com.my was either improperly configured or the owner of name server (e.g. an internet service provider) was not informed to configure it for the domain abc.com.my. This means that the name server ns2.abc.com.my will not answer authoritatively when queried for the domain abc.com.my. In short, the name server ns2.abc.com.my is not performing nameservice for domain abc.com.my even though MYNIC has delegated the domain to ns2.abc.com.my.
 
As a result, any caching name server connected to internet might have the name server information cached (which it got from the parent server, i.e. the com.my name server), but when it tries to query name server ns2.abc.com.my, it will not get an authoritative answer.
 
Lame delegations can cause potentially serious problems for web visitors and for delivery of e-mail. If only one name server, i.e. ns1.abc.com.my, has authoritative data for the domain, then if something goes wrong and it becomes offline, the domain name is effectively not located on the net.
Disclaimer
Although every effort has been taken to ensure that our information is accurate, we recommend you consult professional technical advisers for information appropriate for your specific needs.
 
These Guidelines are provided as is, and MYNIC disclaims any and all representations or warranties of any kind, whether express or implied, with respect to it, including any implied warranties of merchantability or fitness for a particular purpose.
 
MYNIC is not liable for any loss, damage, cost or expense incurred or arising by reason of you using or relying on the information and whether caused by reason of any error, negligent act, omission or misrepresentation in the information or otherwise.
References

Was this article helpful?

Helpful Not Helpful