Posts Tagged ‘nameserver’

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.

Tags: , , , , , , , , ,
Posted in System Administration | 6 Comments »

How to configure manually static IP address on Debian GNU/Linux / How to fix eth0 interface not brought up with error (networking restart is deprecated)

Friday, July 29th, 2011

I’ve recently had to manually assign a static IP address on one of the servers I manage, here is how I did it:             

debian:~# vim /etc/network/interfaces

Inside the file I placed:

# The primary network interface
allow-hotplug eth0 auto eth0
iface eth0 inet static address 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.0 gateway 192.168.0.1 dns-nameservers 8.8.8.8 8.8.4.4 208.67.222.222 208.67.220.220

The broadcast and gateway configuration lines are not obligitory.
dns-nameservers would re-create /etc/resolv.conf file with the nameserver values specified which in these case are Google Public DNS servers and OpenDNS servers.

Very important variable is allow-hotplug eth0
If these variable with eth0 lan interface is omitted or missing (due to some some weird reason), the result would be the output you see from the command below:

debian:~# /etc/init.d/networking restart
Running /etc/init.d/networking restart is deprecated because it may not enable again some interfaces ... (warning).
Reconfiguring network interfaces...

Besides the /etc/init.d/networking restart is deprecated because it may not enable again some interfaces … (warning). , if the allow-hotplug eth0 variable is omitted the eth0 interface would not be brough up on next server boot or via the networking start/stop/restart init script.

My first reaction when I saw the message was that probably I’ll have to use invoke-rc.d, e.g.:
debian:~# invoke-rc.d networking restart
Running invoke-rc.d networking restart is deprecated because it may not enable again some interfaces ... (warning).

However as you see from above’s command output, running invoke-rc.d helped neither.

I was quite surprised with the inability to bring my network up for a while with the networking init script.
Interestingly using the command:

debian:~# ifup eth0

was able to succesfully bring up the network interface, whether still invoke-rc.d networking start failed.

After some wondering I finally figured out that the eth0 was not brought up by networking init script, because auto eth0 or allow-hotplug eth0 (which by the way are completely interchangable variables) were missing.

I added allow-hotplug eth0 and afterwards the networking script worked like a charm 😉

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Posted in Linux, System Administration, Various | No Comments »

Speed up your DNS resolve if your Internet Service Provider DNS servers fail or resolve slowly / Privacy concerns of public DNS services use

Wednesday, March 30th, 2011

In my experience with many network Internet Service Providers by so far I’ve encountered a lot of DNS oddities and therefore surfing (web) and mail slowness.

It’s sometimes very irritating especially in cases, when I use my internet over Wireless public or university wireless networks.
In principle many of the Wireless routers which distribute the internet especially in organizations are badly configured and the slowness with DNS resolvings is an absolute classic.
If you haven’t encountered that slowness in opening web pages when connected from your University’s canteen, whether it’s fill with people for the lunch break, then I should say you’re really lucky!

My personal experience with this bad configured devices DNS services has been quite negative and every now and then I use to set and use public DNS servers like OpenDNS and Google DNS

Very often when I connect to a wireless network with my notebook running Debian Linux and the internet is too slow in opening pages I automatically set the Google or OpenDNS servers as a default DNS IP resolving servers.

1. DNS IP addresses of Google Public DNS are:

8.8.8.7
and
8.8.8.8

2. OpenDNS Public DNS servers has the IP addresses of:

208.67.222.222
208.67.222.220

I do set up and use the upper public DNS services addresses via the commands:

3. Set and use Google Public DNS services on my Linux debian:~# cp -rpf /etc/resolv.conf /etc/resolv.conf.orig
debian:~# echo "nameserver 8.8.8.7n nameserver 8.8.8.8 n" > /etc/resolv.conf;

I first create backu pof my resolv.conf under the name resolv.conf.orig just to make sure I can revert back to my old DNSes if I need them at some point.

If you prefer to use the OpenDNS services for some let’s say privacy reasons, you do it in the same manner as in the above commands, you only change the IP addresses. 4. Configure and use the OpenDNS public DNS services

debian:~# cp -rpf /etc/resolv.conf /etc/resolv.conf.orig
debian:~# echo "nameserver 208.67.222.222n nameserver 208.67.222.220 n" > /etc/resolv.conf;

Of course using Public DNS services has it’s disadvantages over the domain resolving speed up advantage.
One major issue is that Public DNS services are running on a top of a cloud and if you have red my previous article Cloud Computing a possible threat to users privacy and system administrator employment you might be agaist the idea of using a services which are powered by cloud.

The other primary concern is related to your SECURITY and a PRIVACY by using Public DNS networks, you risk that your Public DNS provider might use some DNS spoof techniques to mislead you and resolve you common domain names which usually resolve to let’s say 1.1.1.1 to let’s say 1.5.5.10

Even though this kind of practices on a side of a public DNS provider is not a likely scenario the possible implications of Public DNS providers using DNS forgery to fool you about domain names locations is a very serious issue.

As public DNS providers does contain again the good old philosophy of cloud computing embedded in themselves and they strive to become some kind of a standard which people might vote to adopt and use, the future implications of a wide adoption of Public DNS servers might be a terrible thing on internet users privacy!!!

Just think about a future scenario where we users of the Internet are forced to use a number of public DNS servers in order to use the Internet!
Usually a very huge companies are possessing the Public DNS services and do pay for the tech equipment required for building up the cluster clouds which provide the DNS services and therefore, if in the short future public DNS becomes a fashion and (God forbid!) a standard which shifts up the regular ISP DNS servers to resolve domains to IPs then it will be terrible.

The corporations which does own the Public DNS service/s might have a direct control over filtering and censoling information posted on any website on the internet.
Even worser if the world decides to adopt public DNS services somewhere in the future this means that large corporations owning the open dns cluster or clusters will be able to check each and every resolving made by any user on the net.
If you think closely such an information possessed by a company is not the best thing we want.

So let me close up this article, I’m not a fan and an evangelist who preaches the use of Public DNS services. Right on Contrary I do honestly hate the idea behind public DNS.
Nevertheless apart from my personal opinion I’m a practical person and using the public DNS servers every now and then when this will accelerate my access to the internet is still an option I do enjoy.

Maybe it’s time for a free software project (a tor like), which will provide users with an OpenDNS alternative which will run on hobbyist computers around the globe (just like with tor).

What’s rather funny is that the loud name OpenDNS is a big lie in reality OpenDNS is not opened it’s a company owned closed source service 😉

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
Posted in Linux, Linux and FreeBSD Desktop, System Administration | 1 Comment »