DNS: The Bind Leading the Bind

Hiding beneath the surface of your web browser, email and instant messaging lies a phone book for computers on the Internet. We call it Domain Name System or DNS. It looks up the names of other computers and calls them to chat, shake hands or whatever PCs do with their own kind.

Aside from hiding beneath hundreds of millions of people's awareness, some people know that DNS seems to like Linux. In fact, they're sort of made for each other. You can get Linux for free and the software for DNS comes packaged with Linux distributions and it's also free.

Almost universally DNS servers run Berkeley Internet Name Domain or BIND. Any one wanting their own web site and/or domain needs two domain servers. That's just one of the rules of the game. Obviously, the requirement for two servers made Linux the choice of ISPs and system administrators because it saves people money.

So What

If you want to work as a Linux sysadmin and travel that career path, then you'll need to learn DNS. That's where the other shoe drops. Keep reading.

The big directory runs in a distributed mode and it wants the owner of a domain to provide it's own directory listings. Basically, you have to write your part of the DNS system because the rest of the Internet depends on you doing that.

A slight catch exists. The Internet Engineering Task Force (IETF) established our current DNS protocols long before the enormous growth of the Internet. No one really knew if it would scale.

Funny as it may seem, DNS worked even under the tremendous stress placed on it as the Internet grew exponentially. The Domain Name System simply grew as the Internet grew. And while the current system remains a bit archaic, it works and it works well.

It just requires a set of skills popular well over two decades ago. The standards of DNS did not have a chance to adjust their technical underpinnings while the great Internet adoption took place. The protocols came into existence in 1985. Oh, did I mention that those protocols lack something we call intuitive.

Do I Have To?

Simple answer: yes. Linux system administrators have to learn DNS. Even if you off-load your DNS to a service provider, you'll likely wind up getting all or part of it back. The Internet continues to change and the demands requiring the resolution of friendly names like domain.org to an IP address has become mission critical.

Let's look at the reality in the market. Businesses, especially big ones, hate to change their systems. Forget the noise people make about migrating or upgrading this or that. Big orgs hate it.

But, Big orgs also have to keep current or they'll get bloodied by nimbler businesses using new standards and protocols. Just so those angry Big orgs can keep their legacy applications in use by let's say 100,000 employees on terminals or PCs, a new industry emerged. We call it the web-enablement segment.

Along comes application servers like JBoss and WebSphere and suddenly disparate silos of servers start speaking to each other. Then we have front-end applications speaking to their supply chain while customers and vendors come into the enterprise.

The rest of the world doesn't even know that another layer of applications surrounds those legacy apps and data repositories. It reminds me of the convergence of public libraries. One on side of the Ethernet lies the library's old database. On the other side lies a LAMP application talking to other servers as if they all had the same MySQL database engines full of book titles, authors and subjects.

How does all this work? Oh, it works because a twenty year old directory with a billion entries almost instantly looks up a name, translates it to a number and let's those babies chat, shake hands and do whatever PCs and their kind do.

It's Archaic and Unintuitive?

You can take that to the data center or is it the server bank? Yes, it's old and cranky and doesn't like GUI front-ends. It wants you to write everything by hand on the command line.

Every time you make a change, it wants you to restart it. It says it doesn't want any more of a certain kind of record and then the people at Apache make their server do something cool and you have to put those deprecated record types back into the configuration files.

Guess what else. It's installed base is so big, it won't start migrating and upgrading anytime soon. Like those Big orgs that hate to change - you can add the Internet DNS system to that angry bunch.

Should I Buy a Book?

You can buy a book or take Ambien CR. Either way, you get plenty of sleep. Reading the book might cause irritable neck syndrome.

So, poke around the Internet and look for readable tutorials and howtos. Or wait and catch the rest of this series as we head into the underground caverns of resolver libraries, zone files, hints and local zones to mention a few.

Until then, enjoy.

-------------------------------

Resource Links

Thanks to Keith Daniels for these.

The Open Source version of DNS
OpenNIC: Democratic Name System DNS
Tutorials, Tips and Tricks, HowTo and other Articles
DNS Concepts
DNS HOWTO
DNS tricks and tips
DNS for Rocket Scientists
Internet Domain Name Structure
Domain Name System
Men & Mice - DNS Resources
Setting Up Your New Domain Mini-HOWTO
How to Use Domain-Based Blacklist Zones
Bind and Dnsmasq
freshmeat.net: Project details for Dnsmasq
Configuring BIND with Webmin - RimuHosting
BIND 9 Administrator Reference Manual
Berkeley Internet Name Domain (BIND)
Free DNS hosting- When you are learning, sometimes it is real handy to have a free backup for a while.:-)
The Public DNS Service
List of free DNS hosting sites
Another list of free DNS hosting sites
Setting up Dynamic DNS at Home is a good way to learn without breaking anything important. :-)
How To Set Static and Dynamic DNS for Your ISP
Free Dynamic and Static DNS
Dynamic Network Services
Online Tools for the Beginner to play with
DNS, Network and other tools.
Expired Domain Name Search
E-Mail relay, DNS, Network and other tools

Comments

Comment viewing options

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

As long as you're learning, you might learn about DNSSEC

Wes Hardaker's picture

The one problem about DNS is that the data isn't secure and there are easy-to-find kits out there to spoof dns responses to people and talk them into directing their traffic to the wrong place. The IETF's latest version of extensions for DNS (DNSSEC) fixes this by signing the data. If you're about to dive into DNS, you might as well make sure you find a book that includes DNSSEC in it's list of things to teach you about.

There are a number of sites out there that are implementing docs and tools to help you out with learning DNSSEC as well... www.dnssec-deployment.org www.dnssec.org www.dnssec-tools.org etc.

(proper disclosure: I am affiliated with the last of those sites, but it's open-source and BSD licensed so I don't think it's a bad thing necessarily)

djbdns?

Bill Kerr's picture

Every once in a while I need to set up a (usually) temporary nameserver, and for expediency have used DJBDNS (http://cr.yp.to/djbdns.html).

It has some interesting properties that the associated documentation (highly opinionated, or maybe sharply objective) contrasts with BIND. For example, djbdns runs (1) as a non-Root unprivileged user with no login account, (2) in a chroot "jail". In addition to being an order of magnitude smaller and able to scale somewhat larger than BIND, it seems as though those properties have security aspects that are attractive.

I'm very much not a DNS expert, but I've found djbdns easy to quickly set up and administer. (I run the "dnscache" server on my firewall at home to speed up name resolution. This works out well, as I just point all /etc/resolv.conf files to the firewall machine as the nameserver, and the firewall itself sets its resolv.conf as instructed by my ISP. The 'dnscache' program handles resolution and caches results until they expire.)

If someone with expertise would care to comment, I'd be interested in hearing if djbdns has any future, and also how it compares with other non-BIND DNS implementations.

Thanks!
bilker

I love djbdns. It runs

Anonymous's picture

I love djbdns. It runs circles around BIND in terms of ease of administration, reliability, and efficiency. djbdns will easily handle 3x the load of BIND. Unlike BIND, it is very secure.

The downside is the license. DJB only allows patches to be distributed, not modified tarballs or binaries. So it's very dependent on Prof. Bernstein. I'm testing other DNS servers just to have some alternatives handy.

Domain Name System

JEFSEY's picture

I just want to underline that the DNS is the domain name SYSTEM.

Understanding it as a service is not a bad idea, but it can be confusing as it is many different things (a service to the browser, a protocol, a set of concepts, a database, different possible organisations, the core of the Internet Governance "Misunderstanding", an application with possible different usages, a possible single point of failure through the uncessary root server system, a controversy through the root file evolution, a list of different softwares, etc).

I feel that clarifying this first may help new commers progressing step by step and not being afraid by the supposed complexity. DNS is extremely simple: "I do not know something: I ask it to the one who know the one who knows". We do that all the time in real life, and we know the way it works: sometimes easily, sometimes not. This helps focusing first on what works easily, and not to be afraid by the rest.

FreeBSD handbook makes

Anonymous's picture

FreeBSD handbook makes setting up BIND slightly easier. Also, on FreeBSD it runs chrooted (not sure about Linux), and this is a really good thing, considering that BIND was notorious for security exploits.

Still learning

Kary's picture

I think you need to buy several books and also take classes if nothing else online edjucate yourselve. Linux is not for the peole who fear a challenge though. I have done just about everyting one can do to learn linux and keep up with it, and still everday I learn someting new which is why I choose this profession it is never boring would you not agree?

Still learning

Tom Adelstein's picture

Kary,

Thanks. You're right. I should have bought several books on Linux before I wrote the ones I did. I don't know why people ask me to write these articles.

Thanks for writing it - article a great start

Jessica's picture

I appreciate your article putting what was at one time a complext issue filled with command line crap, into an easy to understand the concept - english for me. Your article has helped me articluate what friends have tried teaching me, into something easier to understand, and now maybe I would consider a book to go further, or some of the resources you listed instead of just giving up on the whole tech side of it.

don't confuse BIND with the DNS protocol

Anonymous's picture

You are correct that admins need to understand DNS. The Internet is much too plagued by mis-configured DNS servers.

The bad news is the big mistake that everyone makes, and the big weakness of DNS, is confusing BIND with DNS. That's like making SMTP the same as Sendmail, or HTTP = Apache. Those are implementations of the protocols, not the protocols themselves. Unfortunately the DNS protocol and BIND have become intertwined, with DNS being weighed down with BIND-specific baggage. It should not be this way.

DNS is just matching names to numbers- why on Earth does BIND need megabytes of code to do this? Why does BIND need multiple large error-prone configuration files to do what tinydns or maradns or any other DNS server can do in a few lines? Why does BIND needs its own weirdo replication tools, when rsync and ssh do the job securely and reliably? Why, after all these years, can BIND still not make a clean distinction between caching and authoritative services? BIND makes a small job into a large job.

Yes, Young Linux Admin, go forth and learn DNS. Do yourself a favor and learn something besides BIND. See some examples here: http://www.zytrax.com/books/dns/apc/

Your make a good argument for

Phil Howard's picture

You make a good argument for why one should not choose to run BIND for their DNS server software. But that's not the same issue as the argument that one should learn BIND to become a versatile system/network administrator. The only exception is if your only purpose to be a system/network administrator is to know how to run your own computers that happen to not run BIND (or Sendmail for that matter).

If you want to give people good advice, then I suggest urging people to run separate DNS servers for the different DNS functions a single machine or network would need: cached recursive lookups and authoritative hosting of your own domain names.

Interesting, but not the point?

Joe Bauser's picture

You make an interesting point, however you seem to be mis-interpreting te authors intentions. (Excuse me in advance if I too am missing the point)

I don't think anybody in the world would argue with you that a DNS server using BIND is hard to configure, manage, or learn compared to other DNS server options out there. However, the diligent Linux Systems Administrator would be remiss to chose not to learn BIND only because it is not his or her favorite DNS server.

BIND is in wide spread use right now, and it is rarely easy to convince management that a migration to a new server package is worth while when the existing BIND server does exactly what they want.

I would argue that it is the duty of a Linux Systems Administrator to learn the tools of his or her trade, regardless of their personal feelings about the product.

The point isn't if BIND is the best solution at all times. The point is that BIND is here, BIND is popular, and BIND does not seem to be going away any time soon.

Yes Linux Systems Administrator, learn BIND, you will need to use it sooner rather than later.

Tom: Thank you, I look forward to the series. :)

Interesting, but not the point?

Tom Adelstein's picture

Joe, thanks for your post. Exactly! You clarified the intent perfectly. People can complain about BIND but with a tens of million BIND servers out there, we have to learn it. It's not that rare to run into a BIND 4 operation, either. Your point is well made.

I disagree that learning

Anonymous's picture

I disagree that learning BIND is a necessity, though it's not a bad thing to know. That's like saying a mail admin needs to learn Sendmail. A mail admin can do just fine learning something else and never touching Sendmail. BIND != DNS.

I disagree that learning

Tom Adelstein's picture

****I disagree that learning BIND is a necessity

OK, get a Linux cert without knowing it.

As to sendmail, many replacements for it exist. Still, the install base is huge. If you don't want to learn it, then you do yourself a disservice. I hate sendmail and I don't want to mess with all those config files. But, not knowing something about it could mean you miss a hiring opportunity.

BIND is different and comparing it to sendmail doesn't equate.

Missed Opportunities

ucntcme's picture

If you don't want to learn it, then you do yourself a disservice. I hate sendmail and I don't want to mess with all those config files. But, not knowing something about it could mean you miss a hiring opportunity.

This is to me a much more personal question than is generally supposed. I've forgotten my sendmail and I don't look back. What good is a job opportunity in something I don't want to do? It's only useful if you are entirely unemployed and in need of an immediate income. I have no desire to do sendmail, so I won't bother applying for a job that requires it. No loss here. For each person it is up to them to determine what they will do and thus seek out that knowledge, and yes nearly always at the expense of other routes of knowledge.

That said, I don't think I have ever seen a "BIND Administrator" job. It's always been a part of the administrator position (network or sysadmin), not a specific job in and of itself (which arguably it could be). Thus, it is inappropriate, as you say, to compare Sendmail to BIND. Being a Sendmail Admin is often a full time position or at least the primary responsibility. Being a BIND Admin is rarely, if ever.

What a sysadmin needs to know

Phil Howard's picture

What a sysadmin needs to know really depends on what sysadmin role you are trying to fill. Many of those roles will need to run traditional internet suite applications like BIND and Sendmail. There are others where the possibility, and sometimes necessity, exists to run alternatives such as Exim, MaraDNS, NSD, Postfix, etc. If you're just setting up your own systems (for home or business) for the first time, I'll even recommend choosing from the latter. But if you want to learn systems (and network) administration at a level where you can jump into just about any job opening you might find, or where you need to be able to offer consultation services to a number of clients, then knowing the former applications are what will serve you best if all you're going to do is learn one application of each class of service (one DNS server, one MTA server, etc). Ultimately, I recommend learning at least 2 (or more) applications of each class of service just so you don't end up in a one track mindset about how things work.

don't confuse BIND with the DNS protocol

Tom Adelstein's picture

Your comment is so off topic and incorrect, I don't know how to reply to it. You seem like the confused one. I really hate it when that happens.

How is it offtopic? Your

Anonymous's picture

How is it offtopic? Your article discusses administering DNS in BIND terms. My point is yes, you're right that learning to administer DNS correctly is important, and no, DNS is not BIND. You imply that DNS and BIND are the same thing. Zone files, hints, and forced restarts are all BIND-specific, and do not apply to other DNS servers.

If you think that despite its insecurity and inefficiency DNS admins need to know BIND, that point is debatable, but valid.

How is it offtopic? Your

Tom Adelstein's picture

***You imply that DNS and BIND are the same thing.

First off, I'm not interested in a flame war and I do respect your knowledge. We don't have a problem there.

To answer your question of where it's off topic, I didn't write that BIND and DNS are the same thing. If you think I implied it, then perhaps I should refine my writing skills.

I did write:

"Almost universally DNS servers run Berkeley Internet Name Domain or BIND."

Note the word "almost". And IMO to say that BIND doesn't sit on >95% of the name servers on the planet would qualify as misinformation.

If our readers needed to do research on the issue then can start with
The American Registry of Internet Numbers - https://www.arin.net/ .

So, I agree that other solutions exist. But, I'm not planning to write much about them or try and get anyone to adopt them because it's off topic.

The operative phrase here is "off topic". Sysadmins will encounter BIND if they get a job in the field, as I stated. If they want to look for other solutions for their own projects or hosting, they can do that too.

Best wishes,

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix