OK, we had an extended breather from our last look at BIND's zone file pri.example.org. It's time to finish up and get a sense of what these records mean.
To go off-topic a little, recently, I had the task of setting up two OpenLDAP servers and putting together a test environment for a project with several developers and several applications including some LAMP applications. Without a working knowledge of DNS, the project would have gone amuck.
So, I take DNS seriously and consider it an essential skill set for Linux system administrators. If you're on the path or have the goal of functioning on the server side of the house, get to know this area.
Now, back to the program.
The records designate how one receives email in a domain from other mail transfer agents (MTAs). To receive email on example.org, we list the mail exchanger(s) for the domain. This is done with a MX record:
MX 10 server1.example.org.
This record says that emails for example.org should be delivered to server1.example.org (which is the mailserver for the domain) with a priority of 10. You can list more than one mail exchanger:
MX 10 server1.example.org. MX 20 mail.someotherdomain.com.
Now if mail goes to example.org, the originating MTA attempts to connect to server1.example.org since the DNS directory denotes its priority of 10.
If server1.example.org cannot be reached (for whatever reason), then the originating MTA will use the next server mail.someotherdomain.com. Notice that it has a priority of 20. This may not seem intuitive but the higher the number to the right of the MX record, the lower priority that server receives. In this case, 10 is higher than 20.
Until now we have defined MX records for email addressed to firstname.lastname@example.org. Let's say we want to route email to different departments in a company or sections within a governmental agency. We can do that by adding a subdomain to the mail records.
email@example.com would simply require another mx record:
subdomain.example.org. MX 10 server1.example.org.
Note the '.' at the end of subdomain.example.org. If you do not add the period, then the origin of the zone is appended to the name. For example, if you wrote
subdomain.example.org MX 10 server1.example.org.
without a '.', this would transform to
Up to now we have used the domain names example.org, server1.example.org, and server2.example.org, but we did not specify the IP addresses to which these names should map. We use A records to accomplish the mapping. Many observers consider them the most important DNS records; since you can use them to create host addresses such as www.example.org where www is the host.
Let's create our first A record:
example.org. A 184.108.40.206
This means that example.org has the IP address 220.127.116.11.
Remember to use the period.
Now in a browser you are used to typing www.example.org instead of example.org, aren't you? www.example.org is technically totally different from example.org, but obviously you expect to see the same web site for both. Therefore we create this record:
www A 18.104.22.168
which is the same as
www.example.org. A 22.214.171.124
Finally we specify server1.example.org and ns0.example.org:
server1 A 126.96.36.199 server2 A 188.8.131.52
server2.example.org points to a different IP address which makes sense because it is our secondary nameserver which should be on a different system in case our primary nameserver goes down.
The Bootstrapping Problem -Glue Records
You might wonder how server1.example.org and server2.example.org can be used to look up records for example.org if they are in the zone that is to be looked up. When the TLD servers for org tell us the name servers for example.org, they normally give us a name instead of an IP address (server1.example.org instead of 184.108.40.206).
For situations where the authoritative DNS servers exist in the zone looked up, a glue record exists on the TLD server that maps a name to an IP address (in our case server1.example.org to 220.127.116.11), and the TLD servers deliver the IP address instead of the name of the name server. So I don't have to find you before I can ask where you are.
CNAME is short for "canonical name", you can think of it as an alias to an A record. For example,
ftp CNAME www
means, ftp.example.org is an alias for www.example.org, so ftp.example.org points to the same machine as www.example.org. You may encounter situations, especially downloading Linux packages, where the repository looks like http://ftp.mirrors.kernel.org. This allows someone to reach an ftp site with a browser and download files. CNAMEs permit you to accomplish this.
A CNAME must always point to an A record; not to another CNAME. In addition to that, you must not use CNAME records for MX and SOA records. For example, MX 10 ftp is not allowed.
The use of CNAMEs has pros and cons. Many DNS specialists consider CNAMEs deprecated. Still you might find that CNAME records have some usefulness. For example, if your DNS directory contains many names written as A records, which point to the same IP address.
If you move to another hosting service using different IP address, you would have to update every A record. If you had just one A record and all your other records used CNAMEs, you'd just have to update one A record. So, we still consider that they have a place in the DNS hierarchy.
TXT records give you the ability to assign text to a zone. People primarily use TXT with SPF (Sender Policy Framework) records. Administrators use SPFs to control email from initiating MTAs.
Technically, you can send email from any machine, but the larger email providers such as Yahoo or Hotmail now rely heavily on SPF records to make sure the sending domain has an SPF record. If email arrives from a machine that is not listed in the SPF record, then an MTA could classify you mail as spam.
A wizard exists for creating SPF records at http://www.openspf.org/wizard.html?mydomain=&x=26&y=8. We used this wizard to create an SPF record for example.org, and added it to our zone file:
example.org. TXT "v=spf1 a mx ~all" server1.example.org. TXT "v=spf1 a -all"
Putting It All Together
Now let's look at our zone file pri.example.org. It has changed from the first iteration you read earlier. Notice that we added a CNAME and SPF files.
@ IN SOA server1.example.org. root.localhost. ( 2006012103; serial 28800; refresh, seconds 7200; retry, seconds 604800; expire, seconds 86400 ); minimum, seconds ; NS server1.example.org.; NS server2.example.org. ; ; MX 10 server1.example.org. ; example.org. A 18.104.22.168 www A 22.214.171.124 server1 A 126.96.36.199 server2 A 188.8.131.52 ftp CNAME www example.org. TXT "v=spf1 a mx ~all" server1.example.org. TXT "v=spf1 a -all
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Mediated Reality: University of Toronto RWM Project
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- Dart: a New Web Programming Experience
- OpenOffice.org Off-the-Wall: ToCs, Indexes and Bibliographies in OOo Writer
1 hour 2 min ago
- Kernel Problem
11 hours 5 min ago
- BASH script to log IPs on public web server
15 hours 32 min ago
19 hours 7 min ago
- Reply to comment | Linux Journal
19 hours 40 min ago
- All the articles you talked
22 hours 3 min ago
- All the articles you talked
22 hours 7 min ago
- All the articles you talked
22 hours 8 min ago
1 day 2 hours ago
- Keeping track of IP address
1 day 4 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?