Domain Name System

The Domain Name System (DNS) is the crucial glue that keeps computer networks in harmony by converting human-friendly hostnames to the numerical IP addresses computers require to communicate with each other. DNS is one of the largest and most important distributed databases the world depends on by serving billions of DNS requests daily for public IP addresses. Most public DNS servers today are run by larger ISPs and commercial companies but private DNS servers can also be useful for private home networks. This article will explore some advantages of setting up various types of DNS servers in the home network.

Why set up a private DNS server?
This question is valid and the answer may vary depending on your home network environment. Maintaining a host file on each client with IP/hostname mappings in a home network that contains a router and a few machines may be sufficient for most users. If your network contains more than a few machines, then adding a private DNS server may be more attractive and worth the setup effort. Some advantages may include:
Maintenance: keeping track of the host file for every client in your network can be tedious. In fact, it may not even be feasible for roaming DHCP laptops or your occasional LAN party guests. Maintaining host information in one central area and allowing DNS to manage host names is more efficient.
Cache performance: DNS servers can cache DNS information, allowing your clients to acquire DNS information internally without the need to access public nameservers. This performance improvement can add up for tasks such as web browsing.
Prototyping: A private internal DNS server is an excellent first step to eventually setting up a public accessible DNS server to access a web server or other services hosted on your internal network. Learning from mistakes on an internal network can help prevent duplicate errors on a public DNS server that could result in loss of service for external users. Note: Some ISPs require customers to have a static IP or business subscription when hosting services in a home network environment.

Cool factor: Ok, I may be stretching it, but the “cool” factor did have some influence when I set up my first home network DNS server. Creating an internal domain that reflects an individual’s personality without paying a domain registrar and issuing hostnames to your clients is cool. The cool factor doubles when your customized hostname glows from your friend’s laptop screen.
Let’s start out simply by setting up a caching-only nameserver to handle client DNS requests. A caching-only nameserver won’t allow references to internal clients by hostname, but it does allow clients to take advantage of frequently requested domains that are cached.

Run the following command:

yum install bind bind-utils bind-libs bind-chroot caching-nameserver

A caching nameserver forwards queries to an upstream nameserver and caches the results. Open the file /var/named/chroot/etc/named.conf and add the following lines to the global options section:

forwarders { 69.162.126.5; 208.115.196.62; }; #IP of upstream ISP nameserver(s)
forward only; #rely completely on our upstream nameservers

The forwarders above are mine, you may adapt them to, say, the Google DNS’s at 8.8.8.8 and 8.8.4.4. The block above will cause the caching name server to forward DNS requests it can’t resolve to your ISP nameserver. Save the named.conf file and then assign 644 permissions:

chmod 644 named.conf

Check the syntax using the named-checkconf utility provided by the bind RPM:

named-checkconf named.conf

Correct any syntax errors (watch those semicolons) named-checkconf reports. Monitoring the /var/log/messages file may also be helpful in debugging any errors.
We now need to set the local resolver to point to itself for DNS resolution. Modify the /etc/resolv.conf file to the following:

nameserver 127.0.0.1

If you are running a DHCP server on your router make sure your /etc/resolv.conf file does not get overwritten whenever your DHCP lease is renewed. To prevent this from happening, modify /etc/sysconfig/network-scripts/ifcfg-eth0 (replace eth0 with your network interface if different) and make sure the following settings are set:

BOOTPROTO=dhcp
PEERDNS=no
TYPE=Ethernet

Go ahead and start the nameserver as root and configure to start in runlevels 2-5:

service named start
chkconfig named on

Testing
The bind-utils RPM contains tools we can use to test our caching nameserver. Test your nameserver using host or dig and querying redhat.com:

dig speedtest.net
.
.
;; Query time: 42 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

From the above dig query you can see it took 42 msec to receive the DNS request. Now test out the caching ability of your nameserver by running dig again on the speedtest.net domain:

dig speedtest.net
.
.
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

We dropped from 42 msec to 1 msec after the previous DNS query was cached. Caching is working! Let’s now put the cache to work by configuring the clients to use the new caching nameserver.
Client Configuration
For Linux and Windows clients you may have a couple of options for your resolver configuration depending on your network environment:
If you have a router and your client’s IP address is assigned via DHCP from the router, then you can use the router to assign the primary nameserver during the DHCP lease requested from the client. Log in to your router and make sure your primary nameserver points to your caching nameserver IP address in the router DHCP settings.
For Linux clients, you can set up the resolver in the same procedure as the nameserver by modifying the /etc/resolv.conf file. For Windows clients you will need to set the nameserver IP address in the Control Panel -> Network Connections -> TCP/IP -> Properties -> Use the DNS Server Address option. NOTE: The Windows DNS server option may vary depending on your version.
Test your new client configuration(s) using dig. You can use the nslookup command for Windows clients. Your DNS requests should have similar response times as we saw earlier when testing the nameserver directly.
NOTE: If you are running a firewall on the nameserver system, make sure clients have access to port 53. An example

iptables rule for the 192.168.15.0/24 subnet would be:
iptables -A INPUT -s 192.168.15.0/24 -p udp --dport 53 -j ACCEPT
service iptables save

Summary
Your new caching nameserver offers a performance improvement with a minimal amount of set up effort. Clients can now ask the caching nameserver for DNS information, and it only needs to ask the upstream ISP nameserver for cache misses. In the next issue we will setup a master nameserver that is responsible for the authoritative information for our internal client hostnames. An authoritative nameserver also caches by default but additionally allows managing both static and DHCP clients using personalized hostnames set up in zone files. In the meantime, enjoy your new caching nameserver and be thinking about a creative domain and hostname theme for your future authoritative nameserver.

e-Club Malaysia have organised a new tournament for the game by Valve Software currently in beta, DOTA 2. The event, named as “DOTA 2 CHALLENGE: THE EVOLUTION @ HEADSHOT GAMING CLUB 2012 “, is held at Headshot Gaming Club along Upper Serangoon Road. The map can be viewed here.

The competition is a 5v5 team event in double elimination format. e-Club Malaysia promises great prizes for the winning teams, as mentioned below. The top 3 teams will also qualify for the “DOTA 2 THE EVOLUTION GRAND FINALS” event.

Prizes

1st Prize < SGD$ 300 + SteelSeries QcK+ DotA 2 mousepad x5 + Dota 2 Invite Keys x6 >
2nd Prize < SGD$ 200 + SteelSeries QcK mini DotA 2 retail mousepad x5 + Dota 2 Invite Keys x6>
3rd Prize < SGD$ 100 + SteelSeries QcK mini DotA 2 bulk mousepad x5 + Dota 2 Invite Keys x6 >

Interested parties may view more information and sign up at the event page, located here.

As of the time of writing, there have been 6 teams registered.

MIRRORED:

17 Feb 2012: Starhub takes aim at allegations made by founders of MyRepublic, two of which are Starhub’s ex-seniors.

“We are very concerned about references made by MyRepublic, suggesting that StarHub discourages its customers to move to the Next-Gen NBN. StarHub fully supports the rollout of the Next-Gen NBN and is disappointed with the rather irresponsible statements made by the new entrant,” said Starhub Vice President of Home Solutions Iris Wee in an email sent to Singapore Business Review in response to a story ran yesterday, Feb.16.

The story titled “Singapore telco giants get competition with MyRepublic” quoted CEO & co-founder of MyRepublic Malcolm Rodrigues saying the following:

“There is a documented case where StarHub actually encouraged a customer to stick to their current cable broadband instead of switching to fibre. There are many such references in online forums, as the Internet-using public shares their experiences in trying to get NBN service.”

In an email to Singapore Business Review, the founders of MyRepublic who are ex senior telco directors claimed that while Singtel, Starhub and M1 offer NBN, they do not promote it and do not offer it at its full potential.

According to Mr Rodrigues, the principle goal of the 3 Telcos does not lie in offering customers the best of NBN. This mainly stems, he said from their legacies of other types of broadband services they have to promote and sell.

Mr. Rodrigues noted that the 3 telcos apply traditional engineering models to the NBN which cause them to have very high contention ratios – number of customers that share one pipe, cap international capacity, and throttle customer traffic at peak hours from 9pm to 2am.

MyRepublic, meanwhile he said has no legacies they need to protect and is only interested in working with customers to give them the best NBN experience.

Mr Rodrigues was a former Vice President of StarHub International & Wholesale. He founded MyRepublic with KC Lai who was also a former StarHub’s Senior VP of Consumer Sales for 10 years and Greg Mittman who was tasked to lead Alcatel-Lucent’s NBN team. Get to know the people behind My Republic

Responding to the allegations, Ms. Wee said “Our fibre broadband plans and promotions are prominently advertised on our website, shop front and retail advertisements. They are equal to, if not more attractively priced than the equivalent on our cable platform. The public is well aware of the ongoing issues that the RSPs and Nucleus Connect have with OpenNet with regard to delays in service activation that would pose more of a serious problem to adoption of fibre broadband.”

As for the statement about not tying customers down to contracts, Ms Wee has this to say: “Customers have the flexibility to subscribe to any of our services without contract. They have the freedom to choose and we give them the power to choose plans that suit their various needs.”