Solaris DNS Tutorial, part 3/3

Prev Index Next

DNS for Your Domain

To further modify our Solaris configuration to handle DNS for a domain or domains requires simply that we add a zone section to /etc/named.conf file and add two new files under /var/named for each new domain. Once these things are accomplished, you'll need to restart your named process for the changes to take effect.

Let's make up a fictitious domain called "net.myfirm.com" and set it up as if we're the primary domain name server for this domain. Hey, it could happen. Start off by modifying /etc/named.conf by adding a section that looks like this:

zone "net.myfirm.com" {
        type master;
        file "db.net.myfirm.com";
};

This adds a zone for our domain, specifies that it is the "master" domain server for it and the file to look for information regarding this domain can be found in /var/named/db.net.myfirm.com which we'll create in a moment. There's no security in this example, but we'll get into that later. For now just tell BIND that we're responsible for the new domain. Don't restart it yet, as we'll need to create the zone file for it first.

The zone file is much like the one we entered for "0.0.127.in-addr.arpa" and contains many of the same fields. However, this applies to an actual domain entry now and follows a slightly different format. This file will vary for every domain and must be customized for same to reflect IP addresses, aliases, Email addresses and a few other things such as the "TTL" or "Time To Live" value, expiration and refresh intervals, etc. This controls precisely how your domain is propogated throught the DNS hierarchy and luckily, you can follow a typical default setup for most cases. Here is what our /var/named/db.net.myfirm.com zone file should contain:

; /var/named/db.net.myfirm.com - Created on 03/02/2001 by My Name
;

; REFRESH INTERVALS, ETC.
;
@     IN   SOA   net.myfirm.com.  hostmaster.net.myfirm.com. (
      2001030201 ; DB Serial Number
      10800      ; Secondary Refresh Interval
      3600       ; Secondary AXFR Retry Interval
      604800     ; Unref Secondary Expiry Interval
      86400 )    ; Minimum Time To Live

; NAME SERVICE
;
      IN  NS      my.host.name.here.
      IN  NS      a.secondary.server.here.
      IN  NS      b.secondary.server.here.

; MAIL
;
      IN  MX  10  net.myfirm.com.
      IN  MX  20  backup.net.myfirm.com.

; HOSTS WITH THIS DOMAIN NAME
;
net.myfirm.com.   IN  A       w.x.y.z

www   IN  CNAME   net.myfirm.com.
ftp   IN  CNAME   net.myfirm.com.
mail  IN  CNAME   net.myfirm.com.

In this exmaple, there are brief explanations as to what does, but let's get into the details a little more. In the first block, you'll see the "SOA record" which defines how domain will fit into the DNS hiearchy via timeouts, refresh intervals and who gets Email about it.

The first line establishes that this is an "SOA record" ("Start of Authority"), and you put in your domain name followed by something like "hostmaster.net.myfirm.com" which specifies that the address "[email protected]" will receive Email regarding this domain as the primary name server. This is not related to who registered the domain, or who the administrative or technical contacts are. By and large the user is "hostmaster" but you can make this "root" if you wish. Leave it as something vague, and define an alias or forward in /etc/aliases if you wish to send it to multiple people or a regular user. In the case of Solaris, "hostmaster" isn't defined as an alias, so you may choose to use "root" but I usually prefer to define "hostmaster" as an alias that forwards mail to "root" or maybe also my own username. This way, if you choose to modify who gets these Emails, you simply change the alias and it's done. Otherwise, you'd have to edit the zone file and restart named and wait for your DNS changes to proogate to the world. A slow process at times and not very elegant.

On the next line, you specify a serial number which usually takes the format of "yyymmddnn" where "yyyy" is the year, "mm" is the month, "dd" is the day and "nn" is a number from 01 to 99. This lets you have up to 100 revisions of this particular file/domain on any given day. If you have more than that, you should really examine your DNS maintenance policies... Any time this file is modified, you must update this number! This tells other DNS servers if they have the current version or not when getting notified of changes.

On the following lines in the first block, you define a a period of time which is specified as a number of seconds. As the comments in our example indicate, these parameters control how often the secondary name servers are refreshed, what the retry interval is for zone transfers, when entries expire on secondaries and how long your DNS entry should remain alive via the "TTL" entry before other DNS servers start looking back to your server for validation. All of the values presented in the example above are good, generic values and should suffice in most cases.

In the next block as shown by the comment "; NAME SERVICE" you can list all the name servers that are involved with this domain. The first should be the primary, even if it's the current host. Follow that with any secondary name servers. It is important to note the period at the end of each line, or usually any time a hostname is given versus an IP address. If this period is missing, your BIND might startup, but you're going to have odd quirks happening. Likewise, each line must start with "IN NS."

The next block as shown by the comment "; MAIL" contains one or more entries for your "MX records" or "Mail eXchanger" hosts. These are machines that have (usually) sendmail running and ready to accept Email for the domain you're setting up. Often this will be the same machine, but not necessarily. You could do a little load balancing here by having one server for DNS, and another for sendmail. The value that follows the "IN MX" statement specifies the preference of that particular mail server. They are arbitrary numbers, but it's the order that's important - 20 is more than 10, just as 2 is more than 1. Often they're spread out a little (by ten or so) so that you can easily insert later on. The example shows two entries, meaning two separate mail servers - in the event the first is down, Email is sent to the second host listed. Once the first server is back online, normal order is restored.

The last section is where all your actual hosts are defined that reside within the domain. You must at least have the first line that specifies the IP address for your domain. In the example, this is the line that reads:

net.myfirm.com.   IN  A       w.x.y.z

You must specify your domain (in this case "net.myfirm.com.") and what IP address it should resolve to which in this case "w.x.y.z" but should be replaced with your real IP address.

Following that line are several more which use the "IN CNAME" statement to define hosts within this domain. By using the "IN CNAME" statement, you're basically pointing these hosts back to whatever IP is listed for "net.myfirm.com" If you wanted to have a separate machine for ftp and Web services, you could have different IP addresses instead and must use the "IN A" statement. It would look like this:

www.net.myfirm.com.   IN  A   a.b.c.d
ftp.net.myfirm.com.   IN  A   e.f.g.h

By repeating the lines above, you can define any number of other hosts, such as workstations - that belong to your domain. For example, if your workstation is named "scooby" then you would add an entry as above with "scooby.net.myfirm.com." followed by the IP address of your workstation. This would make "scooby.net.myfirm.com" resolve to your IP address to the Internet at large. This is only the "forward lookup" part, and while it will do the job, you'll want to add another file here to do "reverse lookups" as well.

To finish up our task, we need add the aforementioned "reverse lookup" zone file. It's proper DNS etiquette to take this extra step, but it's not necessary to have your hosts resolve to the outside world. What it does is ensure that people can not only resolve your hostname to an IP address, but also to resolve your IP address back to your hostname. There are instances where this may be required for access or a number of other reasons - so it's best to do it the right way. To create this file, you must know the network that falls under your domain - and reverse it. In our case, that file would be called /var/named/db.w.x.y and the "z" octet of the IP address gets mapped to the individual hosts that fall under that network. This is done via the "PTR" or "pointer record." It would look similar to the following:

y.x.w.in-addr.arpa. IN SOA net.myfirm.com. hostmaster.net.myfirm.com. (
        2001030201  ; DB Serial Number
        10800       ; Secondary Refresh Interval
        3600        ; Secondary AXFR Retry Interval
        604800      ; Unref Secondary Expiry Interval
        86400 )     ; Minimum Time To Live

; Name Service
;
y.x.w.in-addr.arpa. IN  NS        net.myfirm.com.

; Hosts with this domain name
;

2       PTR         www.net.myfirm.com.

This would define "w.x.y.2" as the reverse entry for "www.net.myfirm.com" - again, note the trailing periods. Your values will of course vary from these examples, and you should certainly apply your own IP addresses and hostnames.

To make sure named reads this file in as well, don't forget to edit /etc/named.conf by adding lines similar to the following:

zone "y.x.w.in-addr.arpa" {
        type master;
        file "db.w.x.y";
};

Finally! That's it. Your domain is all set now, and all you have to do is restart named for these changes to take effect! Keep in mind that if you use your own DNS server to resolve hostnames for your domain, the changes will be instantaneous as can be verified by the use of the nslookup command. However, to the outside world - this DNS propagation will take some time, ideally as specified by your "TTL" value in the zone file. In our example, this is set to 24 hours, or 86400 seconds. So it could take up to 24 hours (or slightly more) for DNS servers elsewhere in the world to know that you've made a change. Keep this in mind when making any changes to your domain's zone files. The updates are done automatically, so nothing further is required on your part.

Upgrading Your BIND

You can upgrade bind 8 to 9. Version 9 adds more security features and takes advantage of symmetrical multi-processing (SMP) servers (with two or more CPUs) for faster name resolution on loaded servers.

When it starts and is working properly, you should see something like this:

Mar 2 14:59:33 hostname /usr/local/sbin/named[7983]: starting
BIND 9.1.0 -c /etc/named.conf -n 2

Unless you're the very trusting type, you'd better secure your server some and control who has access to it. We can do this by controlling who can get information from it in the way of hostname lookups or "zone transfers" if you're running a primary and secondary domain name server setup. If for example you're running an internal name server for your office, you don't want just anyone on the Internet to be able to use you for DNS lookups. That would invite abuse and load your server unecessarily and in general, just bad policy.

You should definately consider upgrading your version of BIND first, as discussing security with the stock Solaris version of BIND would be moot. Many of the procedures below apply to this stock version, but some require features found only in the newer version of BIND. You can still control zone transfers and such, but what's the point if there's a hole in BIND that would let some cracker into your system as root? Upgrade. Do it now, then come back here.

Okay, all set? Here we go.

To control access, we use what is called an "ACL" or "Access Control List" that is defined within your /etc/named.conf file. A simple entry at the top of the file defines your groups:

acl "allowDNS" { w.x.y.z/24; localhost; };
acl "bogusnets" { 0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24;
                  224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12;
		  192.168.0.0/16; };

This sets up a group called "allowDNS" that contains the 192.168.0.4/24 network and the localhost. We'll use this to control who has access to the server to perform DNS queries. The second line adds The group "bogusnets" which contains network definitions of normally non-legitimate IP address ranges. These are often used when spoofing IP addresses or for various internal "test networks" as defined in RFCs. We'll use this group to "blackhole" or drop requests from these types of hosts. In the options section of /etc/named.conf, we must add these lines:

allow-query { "allowDNS"; };              # Block access via ACL
blackhole { "bogusnets"; };               # Block spoofing

Then, just restart named as usual for the changes to take effect. Now you should have a name server that at least only answers queries from trusted hosts and not the Internet at large.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019