Archive for March 16th, 2010

3 Major incorrect beliefs about Global DNS (root DNS) servers

Tuesday, March 16th, 2010

Until today, since I started getting into the depth of DNS some years from now, I always thought that there are 13 major super-computers used as a Global DNS servers which were responsible for caching in all the domain names on the IPv4 and IPv6 internet and that’s all I knew about this matter.
Today I had to review my knowledge on the subject of DNS protocol, BIND server etc. in order to be able to fix an issue with a newly configured BIND dns server. In relation to that I red a bunch of interesting articles online discussing a matters concerning root DNS servers.
Here are two major articles worthy to read:

1. DNS Root Name Servers Explained for Non-Experts – by Daniel Karrenberg
2. DNS Root servers in the World
This blow off the myth about 13 major super-servers running on top of backbones to serve DNS requests online. By the way it’s interesting fact that I’ve learned that myth from some O’reilly’s books that were explaining the Redhat Linux distrubution long time ago.
It could be that long time ago this was true but not anymore!

As of today’s date: Tue Mar 16 17:19:02 EET 2010, there are 425 DNS root servers which are an Internet’s bone today.

Interestingly enough full list of the root servers is available via isoc.org’s website along with many more information on the subject of how root DNSes works, how the DNS is served on the Internet as well as the RFC which explain the proper way to implement a DNS server.

A copy of the zonefile containing in it all the root DNSes can be obtained via isoc’s website

Another wrong idea about Global DNS servers that I kept with me over the years is that most of the root servers are geographically located in USA.

A good proof to this delusion is root-servers.org website which contains a wonderful Google map with pinpointed geographical locations of all root servers .Along with this there is a plenty of extensive information on root DNS servers.

Another misbelief when talking about DNS servers is that the A-root server is the main DNS server in the Global DNS cluster.

Another good reading location concerning DNS Root servers is The DNS Root Name Server FAQ .

What causes the “nRRPResponseCode 531” error, A fix to the nasty “nRRPResponseCode 531” error during domain name DNS change

Tuesday, March 16th, 2010

For two days now, I’m trying to set a custom DNS server for a (.net) domain purchased by gigaspark.com . Every time I try to change the nameservers for the (.net) domain an irritating error pops up, the error reads “nRRPResponseCode 531” and I cannot set my custom configured Bind DNS server for the (.net) domain. I believe the same problem happens also with (.com) domains.

In this relation, I tried googling online searching and searching what might be the stupid cause of the “nRRPResponseCode 531” error that prevents me from setting my custom configured Bind domain name servers to mydomain.net . I also contacted the support team from gigaspark multiply until I found out what is the trouble cause.
In short the “nRRPresponseCode 531” is an error that indicates your .net or .com domain is not figuring in VeriSign’s GRS domain database .
The Verisign GRS domain database contains a list of DNS servers that are correctly configured and trustworthy enough. I’ve seen many people online suffering from the same terrible error,
who pointed out that the error is caused by misconfigurations in the Bind DNS server or the zone file for the problematic domain name, though I’ve looked through multiple times to possibly track the problem in both my major named.conf and the rest of bind’s configuration files as well as in the domain name I had registered mydomain.net ,there was nothing misconfigured or unusual.
I have to admit, this problem is really odd, because I was able to successfully set the same custom configured Bind DNS server for mydomain.info and mydomain.biz but, yet whenever trying to set the same Bind DNS for mydomain.net I came across the shitty nrRRPResponseCode 531 .
Thanks to the kind help of Gigaspark’s tech support together with some google posts on the matter I figured out Gigaspark are using ENOM – a major domain name registrar offering easy ways for an end domain providers to become their resellers.
It seems ENOM’s policy is enforces you as a domain name customer to register your full DNS domain name let’s say (ns1.mydns.com) in Verisign’s GRS domain database otherwise they refuse you the right to set yourself your ns1.mydns.com for your domain, because if the DNS domain name is not figuring in that database it’s not trust worthy!
I believe many people would agree with me this is a real shit! You pay for your domain and you should have the full rights over it.
I mean you should be allowed to set whatever DNS domain name even, if it’s not an existing one and they shouldn’t bother you with stupid DNS domain name registrations in stupid Verisign GRS databases and so on!
Now you probably wonder what is the required steps to take to be able to register the domain in that Verisign GRS database in order to be able to set your ns1.mydomain.com as a default DNS server for your mydomainname.com .
Well you have to contact your domain registrar, let’s say gigaspark.com .
You log to your account on tucowsdomains for your domain mydomain.com … then you find something similar to: “register a nameserver” among the overall menus options.
Then you have to register your nameserver ns1.mydomain.com. Then you wait between 24 up to 48h and then you have to test if your NS has already properly entered the Verisign GRS database you have to visit on Verisign GRS Whois .
Hopefully the guys from Verisign GRS would approve your DNS host to enter there database and then at last you might be able to set in your DNS host as a preferred DNS for your (.net) / (.com?) domain name.
So go back to gigaspark’s slovenian interface and try changing the DNSes once again! If you’re lucky with God’s help (for sure), you would be at last be successful in setting your BIND name server as a primary DNS.