Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better

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 "" 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 "" {
        type master;
        file "";

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/ 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 "" 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/ zone file should contain:

; /var/named/ - Created on 03/02/2001 by My Name

@     IN   SOA (
      2001030201 ; DB Serial Number
      10800      ; Secondary Refresh Interval
      3600       ; Secondary AXFR Retry Interval
      604800     ; Unref Secondary Expiry Interval
      86400 )    ; Minimum Time To Live

      IN  NS
      IN  NS
      IN  NS

      IN  MX  10
      IN  MX  20

;   IN  A       w.x.y.z

www   IN  CNAME
ftp   IN  CNAME
mail  IN  CNAME

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 "" which specifies that the address "" 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:   IN  A       w.x.y.z

You must specify your domain (in this case "") 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 "" 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:   IN  A   a.b.c.d   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 "" followed by the IP address of your workstation. This would make "" 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: IN SOA (
        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

; Hosts with this domain name

2       PTR

This would define "w.x.y.2" as the reverse entry for "" - 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 "" {
        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

Securing Your Server

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" {;;;;
        ;;;; };

This sets up a group called "allowDNS" that contains the 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.


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

Copyright 1996-2018 by Dr. Nikolai Bezroukov. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


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 author present and former employers, SDNP or any other organization the author may be associated with. 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