- •Table of Contents
- •Dedication
- •Foreword
- •Introduction
- •What Is FreeBSD?
- •How Did FreeBSD Get Here?
- •The BSD License: BSD Goes Public
- •The Birth of Modern FreeBSD
- •FreeBSD Development
- •Committers
- •Contributors
- •Users
- •Other BSDs
- •NetBSD
- •OpenBSD
- •Other UNIXes
- •Solaris
- •Linux
- •IRIX, HPUX, etc.
- •FreeBSD's Strengths
- •Portability
- •Power
- •Simplified Software Management
- •Optimized Upgrade Process
- •Filesystem
- •Who Should Use FreeBSD
- •FreeBSD as Your Desktop
- •Who Should Run Another BSD
- •Who Should Run a Proprietary Operating System
- •How to Read This Book
- •What Must You Know?
- •How to Think About UNIX
- •Channels of Communication
- •Working with Channels
- •The Command Line
- •Chapter 1: Installation
- •FreeBSD Hardware
- •Processor
- •Memory (RAM)
- •Hard Drives
- •Downloading FreeBSD
- •Installing by FTP
- •Other FTP Install Information
- •Hardware Setup
- •Actually Installing FreeBSD
- •Configuring the Kernel for ISA Cards
- •Sysinstall: The Ugly FreeBSD Installer
- •Disk Usage
- •Partitioning
- •Root
- •Swap Space
- •Swap Splitting
- •/var, /usr, and /home
- •A Second Hard Drive
- •Soft Updates
- •Block Size
- •What to Install
- •Installation Media
- •Committing
- •Root Password
- •Adding Users
- •Time Zone
- •Mouse
- •Configuring Network Cards
- •Xfree86
- •Software
- •Restart
- •A Note on Editors
- •Chapter 2: Getting More Help
- •Why Not Mail First?
- •The FreeBSD Attitude
- •Man Pages
- •The FreeBSD Manual
- •Man Page Headings
- •The FreeBSD Documentation
- •The Mailing List Archives
- •Other Web Sites
- •Checking the Handbook/FAQ
- •Checking the Man Pages
- •Checking the Mailing List Archives
- •Using Your Answer
- •Mailing for Help
- •Chapter 3: Read This Before You Break Something Else! (Backup and Recovery)
- •Overview
- •System Backups
- •Tape Devices
- •How to Read Dmesg.boot
- •Controlling Your Tape Drive
- •Device Nodes
- •Using the TAPE Variable
- •The mt Command
- •Backup Programs
- •Dump/Restore
- •Restoring from an Archive
- •Checking the Contents of an Archive
- •Extracting Data from an Archive
- •Restoring Interactively
- •Recording What Happened
- •Revision Control
- •Getting Older Versions
- •Breaking Locks
- •Viewing Log Messages
- •Reviewing a File's Revision History
- •Ident and ident Strings
- •Going Further
- •The Fixit Disk
- •Chapter 4: Kernel Games
- •Overview
- •What Is the Kernel?
- •Configuring Your Kernel
- •Sysctl
- •Changing Sysctls
- •Setting Sysctls at Boot
- •Kernel Configuration with Loader.conf
- •Manually Configuring the Loader
- •Viewing Loaded Modules
- •Loading and Unloading Modules
- •Customizing the Kernel
- •Preparation
- •Your Backup Kernel
- •Editing Kernel Files
- •Basic Options
- •Multiple Processors
- •Device Entries
- •Building Your Kernel
- •Troubleshooting Kernel Builds
- •Booting an Alternate Kernel
- •Adding to the Kernel
- •LINT
- •Fixing Errors with Options
- •Tweaking Kernel Performance
- •Sharing Kernels
- •Chapter 5: Networking
- •Overview
- •Network Layers
- •The Physical Layer
- •The Physical Protocol Layer
- •The Logical Protocol Layer
- •The Application Layer
- •The Network in Practice
- •Mbufs
- •What Is a Bit?
- •Ethernet
- •Broadcasting
- •Address Resolution
- •Hubs and Switches
- •Netmasks
- •Netmask Tricks
- •Hexadecimal Netmasks
- •Unusable IP Addresses
- •Routing
- •Network Ports
- •Connecting to an Ethernet Network
- •Multiple IP Addresses on One Interface
- •Using Netstat
- •Chapter 6: Upgrading FreeBSD
- •Overview
- •FreeBSD Versions
- •Release
- •Snapshots
- •Security Updates
- •Which Release Should You Use?
- •Upgrade Methods
- •Upgrading via Sysinstall
- •Upgrading via CVSup
- •Simplifying the CVSup Upgrade Process
- •Building a Local CVSup Server
- •Controlling Access
- •Authentication
- •Combining Authentication and Access
- •Chapter 7: Securing Your System
- •Overview
- •Who Is the Enemy?
- •Script Kiddies
- •Disaffected Users
- •Skilled Attackers
- •FreeBSD Security Announcements
- •Subscribing
- •What You'll Get
- •Installation Security Profiles
- •Moderate
- •Extreme
- •Root, Groups, and Permissions
- •The root Password
- •Groups of Users
- •Primary Group
- •Some Interesting Default Groups
- •Group Permissions
- •Changing Permissions
- •Changing File Ownership
- •Assigning Permissions
- •File Flags
- •Viewing a File's Flags
- •Setting Flags
- •Securelevels
- •Setting Securelevels
- •Which Securelevel Do You Need?
- •What Won't Securelevel and File Flags Do?
- •Living with Securelevels
- •Programs That Can Be Hacked
- •Putting It All Together
- •Chapter 8: Advanced Security Features
- •Traffic Control
- •Default Accept vs. Default Deny
- •TCP Wrappers
- •Configuring Wrappers
- •Daemon Name
- •The Client List
- •Putting It All Together
- •Packet Filtering
- •IPFilter
- •IPFW
- •Default Accept and Default Deny in Packet Filtering
- •Basic Concepts of Packet Filtering
- •Implementing IPFilter
- •Configuring Your Server to Use Jail
- •Configuring Your Kernel to Use Jail
- •Client Setup
- •Final Jail Setup
- •Starting the Jail
- •Managing Jails
- •Shutting Down a Jail
- •Monitoring System Security
- •If You're Hacked
- •Chapter 9: Too Much Information About /etc
- •Overview
- •Varieties of /etc Files
- •Default Files
- •/etc/defaults/rc.conf
- •/etc/adduser.conf
- •/etc/crontab
- •/etc/dhclient.conf
- •/etc/fstab
- •/etc/hosts.allow
- •/etc/hosts.equiv
- •/etc/hosts.lpd
- •/etc/inetd.conf
- •/etc/locate.rc
- •/etc/login.access
- •/etc/login.conf
- •Specifying Default Environment Settings
- •/etc/mail/mailer.conf
- •/etc/make.conf and /etc/defaults/make.conf
- •/etc/master.passwd
- •/etc/motd
- •/etc/mtree/*
- •/etc/namedb/*
- •/etc/newsyslog.conf
- •/etc/passwd
- •/etc/periodic.conf and /etc/defaults/periodic.conf
- •/etc/printcap
- •Working with Printcap Entries
- •/etc/profile
- •/etc/protocols
- •/etc/rc.conf and /etc/defaults/rc.conf
- •/etc/resolv.conf
- •/etc/security
- •/etc/services
- •/etc/shells
- •/etc/spwd.db
- •/etc/sysctl.conf
- •/etc/syslog.conf
- •Chapter 10: Making Your System Useful
- •Overview
- •Making Software
- •The Pain and Pleasure of Source Code
- •Debugging
- •The Ports and Packages System
- •Ports
- •Finding Software
- •Legal Restrictions
- •Using Packages
- •Installing via FTP
- •What Does a Package Install?
- •Uninstalling Packages
- •Package Information
- •Controlling Pkg_add
- •Package Problems
- •Forcing an Install
- •Using Ports
- •Installing a Port
- •Using Make Install
- •Uninstalling and Reinstalling
- •Cleaning Up with Make Clean
- •Building Packages
- •Changing the Install Path
- •Setting Make Options Permanently
- •Upgrading Ports and Packages
- •Upgrading the Ports Collection
- •Ports Collection Upgrade Issues
- •Checking Software Versions
- •Hints for Upgrading
- •Chapter 11: Advanced Software Management
- •Overview
- •Startup and Shutdown Scripts
- •Typical Startup Script
- •Using Scripts to Manage Running Programs
- •Managing Shared Libraries
- •Ldconfig
- •Running Software from the Wrong OS
- •Recompilation
- •Emulation
- •ABI Implementation
- •Foreign Software Libraries
- •Installing and Enabling Linux Mode
- •Identifying Programs
- •What Is Linux_base?
- •Adding to Linux_base
- •Configuring Linux Shared Libraries
- •Installing Extra Linux Packages as RPMs
- •What Is SMP?
- •Kernel Assumptions
- •FreeBSD 3.0 SMP
- •FreeBSD 5 SMP
- •Using SMP
- •SMP and Upgrades
- •Chapter 12: Finding Hosts With DNS
- •How DNS Works
- •Basic DNS Tools
- •The Host Command
- •Getting Detailed Information with Dig
- •Looking Up Hostnames with Dig
- •More Dig Options
- •Configuring a DNS Client: The Resolver
- •Domain or Search Keywords
- •The Nameserver List
- •DNS Information Sources
- •The Hosts File
- •The Named Daemon
- •Zone Files
- •A Real Sample Zone
- •named.conf
- •/var/named/master/absolutebsd.com
- •Making Changes Work
- •Starting Named at Boottime
- •Checking DNS
- •Named Configuration Errors
- •Named Security
- •Controlling Information Order
- •More About BIND
- •Chapter 13: Managing Small Network Services
- •Bandwidth Control
- •Configuring IPFW
- •Reviewing IPFW Rules
- •Dummynet Queues
- •Directional Traffic Shaping
- •Certificates
- •Create a Request
- •Being Your Own CA
- •Testing SSH
- •Enabling SSH
- •Basics of SSH
- •Creating Keys
- •Confirming SSH Identity
- •SSH Clients
- •Connecting via SSH
- •Configuring SSH
- •System Time
- •Setting the Time Zone
- •Network Time Protocol
- •Ntpdate
- •Ntpd
- •Inetd
- •/etc/inetd.conf
- •Configuring Programs in Inetd
- •Inetd Security
- •Starting Inetd
- •Changing Inetd's Behavior
- •Chapter 14: Email Services
- •Email Overview
- •Where FreeBSD Fits In
- •The Email Protocol
- •Email Programs
- •Who Needs Sendmail?
- •Replacing Sendmail
- •Installing Postfix
- •Pieces of Postfix
- •Configuring Postfix
- •Email Aliases
- •Email Logging
- •Virtual Domains
- •Postfix Commands
- •Finding the Correct Mail Host
- •Undeliverable Mail
- •Installing POP3
- •Testing POP3
- •POP3 Logging
- •POP3 Modes
- •Qpopper Preconfiguration Questions
- •Default Qpopper Configuration
- •APOP Setup
- •Configuring Pop3ssl
- •Qpopper Security
- •Chapter 15: Web and FTP Services
- •Overview
- •How a Web Server Works
- •The Apache Web Server
- •Apache Configuration Files
- •Configuring Apache
- •Controlling Apache
- •Virtual Hosting
- •Tweaking Virtual Hosts
- •.NET on FreeBSD
- •Installing the SSCLI
- •FTP Security
- •The FTP Client
- •The FTP Server
- •Chapter 16: Filsystems and Disks
- •Device Nodes
- •Hard Disks and Partitions
- •The /etc/fstab File
- •Disk Basics
- •The Fast File System
- •Vnodes
- •FFS Mount Types
- •FFS Mount Options
- •What's Mounted Now?
- •Dirty Disks
- •Fsck
- •Mounting and Unmounting Disks
- •Mounting Standard Filesystems
- •Mounting with Options
- •Mounting All Standard Filesystems
- •Mounting at Nonstandard Locations
- •Unmounting
- •Soft Updates
- •Enabling Soft Updates
- •IDE Write Caching and Soft Updates
- •Virtual Memory Directory Caching
- •Mounting Foreign Filesystems
- •Using Foreign Mounts
- •Foreign Filesystem Types
- •Mount Options and Foreign Filesystems
- •Filesystem Permissions
- •Removable Media and /etc/fstab
- •Creating a Floppy
- •Creating an FFS Filesystem
- •The Basics of SCSI
- •SCSI Types
- •SCSI Adapters
- •SCSI Buses
- •Termination and Cabling
- •SCSI IDs and LUNs
- •FreeBSD and SCSI
- •Wiring Down Devices
- •Adding New Hard Disks
- •Creating Slices
- •Creating Partitions
- •Configuring /etc/fstab
- •Installing Existing Files onto New Disks
- •Temporary Mounts
- •Moving Files
- •Stackable Mounts
- •Chapter 17: RAID
- •Hardware vs. Software RAID
- •RAID Levels
- •Software RAID
- •Vinum Disk Components
- •Vinum Plex Types
- •Preparing Vinum Drives
- •Dedicating Partitions to Vinum
- •Configuring Vinum
- •Concatenated Plex
- •Removing Vinum Configuration
- •Striped Volumes
- •Mirrored Volumes
- •Starting Vinum at Boot
- •Other Vinum Commands
- •Replacing a Failed Mirrored Plex
- •Chapter 18: System Performance
- •Overview
- •Computer Resources
- •Disk Input/Output
- •Network Bandwidth
- •CPU and Memory
- •Using Top
- •Memory Usage
- •Swap Space Usage
- •CPU Usage
- •When Swap Goes Bad
- •Paging
- •Swapping
- •Are You Swapping or Paging?
- •Fairness in Benchmarking
- •The Initial Test
- •Using Both CPUs
- •Directory Caching
- •Moving /usr/obj
- •Lessons Learned
- •Chapter 19: Now What's It Doing?
- •Status Mails
- •Forwarding Reports
- •Logging with Syslogd
- •Facilities
- •Levels
- •Syslog.conf
- •Wildcards
- •Rotating Logs with Newsyslog.conf
- •Reporting with SNMP
- •Basics of SNMP
- •MIBs
- •Snmpwalk
- •Specific Snmpwalk Queries
- •Translating Between Numbers and Names
- •Setting Up Snmpd
- •Index Numbers
- •Configuring MRTG
- •Sample mrtg.cfg Entry
- •Testing MRTG
- •Tracking Other System Values
- •Monitoring a Single MIB
- •Customizing MRTG
- •MRTG Index Page
- •Sample MRTG Configurations
- •Chapter 20: System Crashes and Panics
- •What Causes Panics?
- •What Does a Panic Look Like?
- •Responding to a Panic
- •Prerequisites
- •Crash Dump Process
- •The Debugging Kernel
- •kernel.debug
- •Dumpon
- •Savecore
- •Upon a Crash
- •Dumps and Bad Kernels
- •Using the Dump
- •Advanced Kernel Debugging
- •Examining Lines
- •Examining Variables
- •Apparent Gdb Weirdness
- •Results
- •Vmcore and Security
- •Symbols vs. No Symbols
- •Serial Consoles
- •Hardware Serial Console
- •Software Serial Console
- •Changing the Configuration
- •Using a Serial Console
- •Serial Login
- •Emergency Logon Setup
- •Disconnecting the Serial Console
- •Submitting a Problem Report
- •Problem Report System
- •What's in a PR?
- •Filling Out the Form
- •PR Results
- •Chapter 21: Desktop FreeBSD
- •Overview
- •Accessing File Shares
- •Prerequisites
- •Character Sets
- •Kernel Support for CIFS
- •SMB Tools
- •Configuring CIFS
- •Minimum Configuration: Name Resolution
- •Other smbutil Functions
- •Mounting a Share
- •Other mount_smbfs Options
- •Sample nsmb.conf Entries
- •CIFS File Ownership
- •Serving Windows File Shares
- •Accessing Print Servers
- •Running a Local Lpd
- •Printer Testing
- •Local Printers
- •X: A Graphic Interface
- •X Prerequisites
- •X Versions
- •Configuring X
- •Making X Look Decent
- •Desktop Applications
- •Web Browsers
- •Email Readers
- •Office Suites
- •Music
- •Graphics
- •Desk Utilities
- •Games
- •Afterword
- •Overview
- •The Community
- •What Can You Do?
- •Getting Things Done
- •Second Opinions
- •Appendix: Some Useful SYSCTL MIBs
- •List of Figures
- •Chapter 1: Installation
- •Chapter 5: Networking
- •Chapter 6: Upgrading FreeBSD
- •Chapter 19: Now What's It Doing?
- •List of Tables
- •Chapter 4: Kernel Games
- •Chapter 5: Networking
- •Chapter 8: Advanced Security Features
- •Chapter 9: Too Much Information About /etc
- •List of Sidebars
- •Chapter 15: Web and FTP Services
must be preserved. Files in the slave zone aren't exactly garbage, but their loss is no big deal.
If you expect to serve thousands of domains, you might want to divide your master zone files still further. I use a set of 36 directories under the master directory, one for each letter and number. Of course, you can create any arrangement of directories that fits your needs. Just remember that you're going to either live with this arrangement or go through some annoyance changing it.
Taking this to the logical extreme, your zone entry could look like the following:
...............................................................................................
zone "AbsoluteBSD.com" { type master;
file "master/clients/a/absolutebsd.com";
};
...............................................................................................
Most people do not need this number of subdirectories, but you could do it if you needed to.
Zone Files
At this point we have a configuration file that tells named what domains it's responsible for, and where the files that contain the information on those domains live. But we still need to make those files!
Zone files have a rather obscure syntax because, much like sendmail, BIND was assembled by programmers who were more interested in efficiency than ease of use. Unlike sendmail, zone file configuration is not blatantly user−hostile, though some parts of zone files appear inconsistent.
To learn how to work with zone files, follow the given examples and you should be all right. And any time you find yourself scratching your head and wondering why they did something a certain way, just remember that you're digging through the primordial ooze of the Internet. (If DNS were invented today, zone files would probably look very different.)
Here's a simple example of configuring a zone file. FreeBSD includes a shell script to create the localhost file, make−localhost. To create the localhost file, all you have to do is go to /etc/namedb and type this:
...............................................................................................
# sh make−localhost
...............................................................................................
And poof! The file localhost.rev appears. We'll dissect this file as our first example.
...............................................................................................
;From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90
;$FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10 15:31:40 peter Exp $
;This file is automatically edited by the `make−localhost' script in
;the /etc/namedb directory.
;
v |
$TTL |
3600 |
w |
@ |
x IN y SOA z satariel.blackhelicopters.org. { |
root.satariel.blackhelicopters.org. (
282
|
|
|
| 20010601 ; Serial |
|
|
|
} 3600 ; Refresh |
|
|
|
~ 900 ; Retry |
|
|
|
• 3600000 ; Expire |
|
|
|
j 3600 ) ; Minimum |
|
IN |
NS |
satariel.blackhelicopters.org. |
1 |
IN |
PTR |
localhost.blackhelicopters.org. |
...............................................................................................
First of all, remember that anything that begins with a semicolon is a comment. (Comment your zone files liberally; it'll help you figure out later what the heck you were doing.)
$TTL: Time to Live
We'll skip on through this file to the first line of real interest, the $TTL statement (v). This statement is the zone's default time to live, in seconds (3,600 seconds, in this case), and it dictates how long other servers will cache information from this zone. You can give data in the zone any time to live you choose. This is actually a fairly short time; a good average is 10,800, or 3 hours. Choosing a TTL is something of a black art; stick with the default, and you'll be fine for most purposes.
Start of Authority
Next is the Start of Authority (SOA) record. This is a brief description of the zone, and of how its characters and servers should treat it. Every zone has exactly one SOA record. The SOA does not include information about what is in the domain, merely information about how long this information lasts.
The @ sign The at symbol (@), which begins the SOA record (w), is a special character that's shorthand for "whatever named.conf says this file is for," and in this case, named.conf says that this file holds data for the zone 0.0.127.in−addr.arpa. When named reads named.conf and loads this file into memory, it makes this substitution. Using the actual domain name would be less confusing for new users, but you'll see this in most nameservers and will need to be familiar with it. You could use the full domain name in this file instead of the @ symbol if you wished, but almost nobody does that.
The Data Type and Label The IN represents the type of data (x), Internet data in this case, and SOA means that this is a Start of Authority record ($). Both elements will appear in every DNS record you create.
Machine Name The next part is the name of the machine where the master file lives (z). (This file was created on satariel.blackhelicopters.org.)
Responsible Party Then we have the email address of the person responsible for this zone ({). Since the make−localhost script defaults to root@hostname, the email address lacks the @ sign, because the @ sign had already been assigned to mean the zone name from named.conf.[1] (Were w e t o p u t t h e @ i n , t h e e m a i l a d d r e s s w o u l d b e c o m e http://root0.0.127.in−addr.arpa.satariel.blackhelicopters.org/. That would be worse than http://root.satariel.blackhelicopters.org/, wouldn't it?) This is important when you create your own zone files for your domains. Replace the @ in the email address with a period.
In many cases, the nameserver doesn't have a mail server on it. To follow best current practices on the Internet, replace the email address with hostmaster. and your domain name. Every domain is expected to have a "hostmaster" email address to respond to DNS issues.
283
Parentheses While technically the SOA record should be on a single line, if it were, it would be difficult to read. Instead, standard zone files have this broken up into several lines, with the first opening parenthesis (or round bracket) indicating the line break. Each of the next five lines is part of the SOA record, with the record ending with the closing parenthesis.
Serial Number The first piece is the serial number, which indicates the zone file's version (|). While the serial number can be whatever you choose, it's most convenient to use the date. You'll usually see the date in YYYYMMDD format with two extra digits at the end. This serial number, 20010601, represents June 1, 2001. The extra two numbers in the serial number represent the number of times the file has changed in a day. For example, there have been times that I've had to update one domain a dozen times in one day, with each change requiring a serial number bump. Here's how this works: Say I create the zone file on May 9, 2002, with the first serial number 2002050901. If I change the zone file on June 8, the serial number changes to 2002060801. If I then change the zone file a second time on that same day, the serial number changes to 2002060802. This system allows up to 100 changes in a day, or roughly one change every 15 minutes. If this isn't enough for you, you need to rethink your work processes.
The serial number is important, because every so often a slave server will contact the master server to see if the zone has updated. It determines whether there's been an update by comparing the serial number of its cached copy to the master zone file's serial number. If the master zone file's serial number is greater than the one on the slave, the slave server determines that the zone file has been updated and downloads the latest domain information.
Note If your secondary nameservers haven't updated their zone files from the master nameserver, it's probably a serial number problem. Even if you swear up and down that you incremented the serial number, increment the serial number again and try once more. It'll probably work.
Refresh The next number is the refresh value, in seconds (}). This number determines how frequently slave servers will contact the master server to check for an updated master file. In the localhost.rev file, a secondary nameserver would update every 3,600 seconds, or 60 minutes.
If the slave cannot check its data against the master in a refresh attempt, it keeps giving answers with its current record—that's what a backup nameserver is for, after all! We'll see exactly how this works in the "Refresh, Retry, and Expire in Practice" section.
Retry The next number is the retry value, also in seconds (~). If the slave cannot reach the master nameserver, it will retry at this interval. Our sample file has a 900 second (15 minute) retry. If the secondary nameserver cannot update at the 1 hour mark, it will keep trying every 15 minutes until the master nameserver answers. Again, we'll see exactly how this works in the "Refresh, Retry, and Expire in Practice" section.
Expire Next we have the expire value, in seconds (•). If a slave nameserver cannot update its records for this many seconds, it stops giving out its cached information. It's at this point that the administrator thinks bad information is worse than no information. In our example we have 3,600,000 seconds (1,000 hours, or a little over 41 days).
Minimum TTL The last number is the minimum time to live (j). In older implementations of BIND, this was used for the time to live for absolutely everything. Today, it's only used for the TTL for negative answers. (Nameservers can cache negative answers.) For example, if you look up givememymoneyback. http://www.absolutebsd.com/, your nameserver will learn that there's no such host. In localhost.rev, negative answers will be cached for 3,600 seconds (1 hour).
284
Note Be sure you have a closing parenthesis after the minimum time to live! Otherwise, named will assume that the remainder of the file is also part of the SOA record and get confused.
Recycling SOAs Now that you understand all the painful details of the SOA record, here's the good news. Once you set up an SOA the way you like, you can recycle that same SOA, with only minimal changes, across multiple domains. I've set up thousands of domains from a template SOA.
Domain Information
Now that you have a complete SOA record, you can list actual information for the domain. Domain information immediately follows the SOA record.
In the following example, the two lines contain the zone's actual host information:
...............................................................................................
|
IN |
NS |
satariel.blackhelicopters.org. |
1 |
IN |
PTR |
localhost.blackhelicopters.org. |
...............................................................................................
Each of these lines has four parts: a hostname or number, the data type, the server type, and the actual data. The first field contains either a hostname (such as www) or a number (such as 12). The name of the zone is automatically attached to this entry, either at the beginning or at the end, depending on whether the file is for reverse or forward DNS. Since our example is for reverse DNS, the 1 is appended onto 127.0.0 giving us the IP address 127.0.0.1. (If there is nothing in the first field, named will append the zone name anyway, giving us a reasonable default.) The data type is always IN (Internet).
The third field, the type of server we have, is actually interesting. An NS entry (shown in the first line above) represents a nameserver, and in this example, the only nameserver for this domain is satariel.blackhelicopters.org. If you're distributing localhost.rev among several nameservers, you should add additional NS lines for them.
Note Because there is no first field in our NS example here, BIND assumes that this is for the 0.0.127.in−addr.arpa zone, or the network beginning with 127.0.0, the domain specified for this file in named.conf.
A PTR entry (as shown in the second line of the preceding example) represents IP−address−to−hostname mapping. This zone is for the 127.0.0 network. on the second line of our example, we have a .1. This represents the .1 in the network, or 127.0.0.1, the standard loopback IP address. This record points to the local host, in this case localhost.blackhelicopters.org.
Refresh, Retry, and Expire in Practice
While I've mentioned what the refresh, retry, and expire times mean, that's still a ways from understanding how they work. Here's an example of these times in operation.
Suppose we have a domain with a refresh time of 4 hours, a retry time of 1 hour, and an expire time of 48 hours. This means that the slave nameserver will contact the master every hour to check for updates. Every so often, you edit records on the master nameserver, and they propagate to the slave within an hour.
285