Hack and / - Your Own Personal Server: DNS

 in
Why let registrars have all the fun? Learn how to set up your own DNS server completely under your own control.
Slave DNS Configuration

Many registrars on the Internet require that any domain you register have at least two DNS servers configured with it. It's a good practice to have, because if you have a single DNS server and it goes down, it effectively will make all your servers under that domain inaccessible. This means you need to set up a second DNS server on a different IP, ideally on a different network, or have a friend with a DNS server act as a slave to your master DNS server. In either case, it's a relatively simple process. Let's say that my second DNS server is going to be at the IP address 98.76.54.32. First, I would log in to my Master DNS server and add the new NS and A records to my zone file:

;
; BIND data file for example.org
;
$TTL 4h
@  IN  SOA ns1.example.org. root.example.org. (
	    2		; Serial
	    604800 	; Refresh
	    86400 	; Retry
	    2419200 	; Expire
	    604800 ) 	; Negative Cache TTL
;
@	IN NS	ns1.example.org.
@	IN NS	ns2.example.org.
@ 	IN A	123.12.34.57
www	IN A	123.12.34.57
ns1 	IN A 	123.12.34.56
ns2 	IN A 	98.76.54.32

Next, I edit named.conf and add a line to the configuration of example.org so that it will allow zone transfers from my DNS slave:

zone "example.org" {
	type master;
	file "/etc/bind/db.example.org";
	allow-transfer { 98.76.54.32; };
};

Finally, I would install BIND on the second server, or if it already exists, all I would have to do is add a new entry at the end of the named.conf file to define the example.org zone and tell this server the IP address of the master:

zone "example.org" {
	type slave;
	file "/var/cache/bind/db.example.org";
	masters { 123.12.34.56; };
};

Note that in this case the slave zone is being stored under /var/cache/bind. That's the default location for slave zone files under Debian-based systems. Under Red Hat, you would store them under /var/named/. Once I reload BIND on the slave server, it will pull the new zone information from the master, and I should be able to perform DNS queries against it.

Once you have set up a slave, keep in mind that anytime you make a change to the master, you will need to increment the Serial field in the Master's zone file (in my example, it is set to 2, but a lot of administrators like to set it to the current date plus two extra number fields, such as 2010120500). When the slave needs to know whether its zone information is up to date, it compares its serial number with the serial number on the master. If the master's serial number for a zone is higher, it copies down the new zone information; otherwise, it sticks with what it has cached.

Domain Registration

Once you have a functioning DNS server, all that's left is to tell the world to use it. If you haven't already registered your domain with a registrar, find a domain registration service on the Internet (there are too many for me to list here, but a search for domain name registration should turn up plenty). When you register the domain, most registrars will let you use their own DNS servers for your domain, but you don't need them! When you get to the point in the registration process where it asks you about your DNS servers, just give them the public IP address for your own DNS server (in my case, it would be ns1.example.org or 123.12.34.56). Note that many registrars require you to have two DNS servers defined for a domain, so in that case, set up a slave DNS server and add its IP address as well. Once you complete the registration process and allow the new domain information time to propagate around the Internet, you will have the ability make IP changes for your Web, mail and other servers all from your own machines.

Kyle Rankin is a Systems Architect in the San Francisco Bay Area and the author of a number of books, including The Official Ubuntu Server Book, Knoppix Hacks and Ubuntu Hacks. He is currently the president of the North Bay Linux Users' Group.

______________________

Kyle Rankin is a systems architect; and the author of DevOps Troubleshooting, The Official Ubuntu Server Book, Knoppix Hacks, Knoppix Pocket Reference, Linux Multimedia Hacks, and Ubuntu Hacks.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

huh?

jonny rocket's picture

yawn...

A good high level explanation.

pradeep.aradhya's picture

A good high level explanation.

White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions