- - - - -
 Home :: Name Server Configuration

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 .my DOMAIN REGISTRY 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 .my DOMAIN REGISTRY. 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.

my DOMAIN REGISTRY reserves the right to revoke the domain name at any time without prior written notice to the Registrant should .my DOMAIN REGISTRY 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 .my DOMAIN REGISTRY:

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 RFC1033 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 .my DOMAIN REGISTRY. 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.4

abc.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

Secondary Name Server Query Result

Server:  ns2.abc.com.my				  <== PTR Record
Address:  5.6.7.8

abc.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

When is a Name Server Non-Authoritative?

  • If the name server gives a non-authoritative answer, this could mean that the name server is not properly configured for the domain name.
  • The name server may consider itself non-authoritative even though it is a primary name server if there is a syntax error in the zone.

If the name servers have not been configured correctly, both servers will give non-authoritative answers 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 
Address: 1.2.3.4 

Non-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  

Query Performed on the Secondary Name Server

nslookup -q=any abc.com.my 5.6.7.8

Secondary Name Server Query Result

Server:  ns2.abc.com.my
Address:  5.6.7.8

Non-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 .my DOMAIN REGISTRY. 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 .my DOMAIN REGISTRY. Then, .my DOMAIN REGISTRY had listed two name servers in the com.my name servers as follows:
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 .my DOMAIN REGISTRY 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 .my DOMAIN REGISTRY 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.

my DOMAIN REGISTRY 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

  • DNS & BIND 3rd Edition by Paul Albitz & Cricket Liu, O'Reilly & Associates Inc.