mail us  |  mail this page

contact us
training  | 
tech stuff  | 

BIND 9 Support

Chapter 1 BoilerPlate & Terminology

  1. 1.1 Objectives
  2. 1.2 How to read this Guide
  3. 1.3 Terminology and Conventions
  4. 1.4 Acknowledgements
  5. 1.5 License and Copyright
  6. 1.6 Disclaimer

1.1 Objectives

This Open Guide is intended to:

  1. Provide all the material necessary to deploy an appropriate DNS software solution in a organisation.
  2. Provide a single dynamic source of material
  3. Provide background material on the Internet's Domain Name system architecture and its relationship to domain Registration.
  4. To act as a reference source for DNS information with links to definitive documentation.
  5. Provide HOWTO Guides for commonly required configurations.
  6. Provide a Quickstart guide for BIND 9 in various configurations.
  7. Other DNS Solution guides as appropriate.
  8. Define DNS attacks and threats.
  9. Securing DNS - BIND ACL, Zone Transfer authentication, Chroot Jails and DNSSEC
  10. BIND (and other) Error messages and trouble shooting
  11. DNS Tools and Utilities
  12. BIND 9 (and other) API's.
  13. DNS ZONE files in Databases and LDAP.
  14. Provide Links and overviews for Alternate Open Source DNS solutions
  15. Provide DNS Links and resources
  16. On-line (HTML) and Printable formats (OpenOffice and PDF)

The current version of this Guide achieves only some of the above objectives.

1.2 How to Read this Guide

This is not a book nor is it intended to be, the following summarises who should read what and when:

  1. Section 1: Overview: General background and concept level material. Read if you want an overview of Name Servers and DNS concepts, DNS types, reverse mapping, Delegation and Security.

  2. Section 2: BIND Quick start - various common configurations are shown. If you need to get BIND (DNS) up quickly without necessarily knowing too much about DNS use this section.

  3. Section 3: BIND and Resource Records Reference section. Defines the BIND named.conf parameters with examples. Shows most Resource Record with examples. Links are provided to definitive references or specifications.

  4. Section 4: HOWTO for Common Configurations and Requirements. If you need to configure Load Balancing or Sub-Domain Delegation among others use this section.

  5. Section 5: DNS Security. If you want to know about TSIG (Server-Server) and DNSSEC (Client-Server) use this section.

  6. Section 6: DNS Messages. If you want to know about DNS message formats (queries and responses) use this section.

  7. Appendix A: If you want explanations, tips or some background notes on BIND and DNS use this Appendix.

  8. Appendix B: If you want to know how to register gTLD or ccTLD domains use this Appendix.

  9. Appendix C: If you want to find alternative (to BIND) Open Source DNS software, tools or links use this Appendix.

  10. Appendix D: If you want or need the real stuff - specifically all the relevant RFC's - use this Appendix.

1.3 Terminology and Conventions

One of the reasons we found the whole DNS world so confusing at the outset was that terminology was not consistent nor consistently applied. The 'high-priests' of the DNS/BIND world may be comfortable in this environment, we were not. Further, we contend that the reason there are so many repeat question on the news group or so many lame-servers out there is not because users are inherently stupid but just plain confused.

We define the following terms below. They are not always the same ones as commonly used. There are some new ones we invented to try and clarify points. They may not be right. If they are not by all means point out - politely - the error of our ways BUT provide an alternative. We always respond in the same spirit that you write to us.


Term Definition and Usage
domain Common usage. Technically, a domain is the area covered by an arc from any node in the DNS hierarchical structure (a directed graph). Each domain will have an associated Domain Name and may in turn have 'subdomains' each node of which is also a domain and will have a Domain Name. Frequently used as a shortform for Domain Name as in 'my domain' which more correctly would be 'my Domain Name'.
Domain Name Common usage. Always shown in bold as two proper nouns (Capitalised). Defines that part of a domain name that is delegated by ICANN, one of its accredited registrars, a delegated country code authority or one of its appointed registrars or agents as defined by the country code authority policy. A Domain Name has a registered owner and the owner is both Authoritative and Responsible for DNS information.,,, and are all examples of Domain Names.
domain name Always shown as two simple nouns. Defines any part of a domain which fully includes the Domain Name e.g. is a domain name.
Fully Qualified Domain Name (FQDN) Common Usage. Unambiguously defines a domain name to the root. A FQDN MUST therefore include the root which in turn means it must have a final DOT on the extreme right of the domain name, for instance, is a fully qualified domain name whereas is not (it does not terminate with a DOT). Because of the arbitrary starting point of any domain name this term does not specify or mandate any starting point only that it must end with the root. There is no commonly used term that describes a host-to-root domain name.
host name Fully defines a host within a domain, for example, is a host name. Note: fred in this context is only a host name because we know it to be a host or have discovered it to be a host via interrogation of a DNS, that is, it has an A or AAAA RR. At its face value it could equally well be a subdomain name.
qualified domain name Fairly meaningless term. Defines a part of a domain name to the root. A qualified domain name should ALWAYS include the root which in turn means it must have a final DOT on the extreme right of the domain name, for instance, is a qualified domain name whereas is not (it does not terminate with a DOT).
Second Level Domain (SLD) Common usage in conjunction with gTLDs to describe that part of the Domain Name uniquely registered by the Domain owner. Defines that part of the Domain Name below the TLD in the domain hierarchy, for instance, in, example is the Second Level Domain. Term much less useful with ccTLDs since the registered domain name may in fact be the Third Level domain Name, for instance,
sub-domain name An arbitrary name that is allocated by the owner of the Domain Name. A sub-domain name will fully include the Domain Name. is a valid sub-domain name of Technically, the name of a subdomain is also a Domain Name.
Top Level Domain (TLD) Common usage. Defines the TLD part of a Domain Name (q.v.) Top Level Domains are split into Generic Top Levels Domains (gTLDs), for example, .com, .int etc. and Country Code Top Level Domains (ccTLDs), for example, .us, .ca, .de etc. and Sponsored Top Level Domains (sTLDs), for example, .aero, .travel etc..
unqualified domain name Imprecise term. Common usage to describe something that is not a Fully Qualified Domain Name (FQDN), that is, it does not end with a dot. Frequently used to mean what this book calls a 'domain name'.
Zone Name Any part of a domain that is configured in a DNS server and which fully contains the Domain Name for which the owner is authoritative, for instance,, (a delegated sub-domain) are Zone Names. A zone is an operational convenience for DNS software and not part of the domain naming hierarchy. RFC 1034 describes sub-domains zones as subzones rather than re-use the term zone and to the process of creating sub-domains as 'cuts' in the name space. The term subzone appears to have been lost in history.
clause In an attempt to be consistent we use the term clause to describe the top level organization in the named.conf file, for example, the zone clause. A clause groups together related statements. What we call a clause is variously called a section, a clause, a statement or an option in other documents. Webster defines a clause to be "a separate section of a discourse or writing; specifically : a distinct article in a formal document" which is good enough for us.
statement We use the term statement to describe an item in a clause of a named.conf file, for example, the allow-transfer statement may be used in a view, options or zone clause. What we call a statement is variously called a clause, a statement, an option, a substatement and a phrase in other documents. Webster defines a statement to be "a single declaration or remark" which is good enough for us.


Convention Explanation and Usage
... The dots appear in fragments of zone and other files and indicate that additional lines may or may not be present but have been omitted for brevity. The dots should not be present in the real file.
# Used to indicate a comment in, say, a sequence of command lines. Lines beginning with this symbol should not be typed or present. In the case of comments in a file we will always use the appropriate comment convention if one exists.
a.k.a. Also Known As. Used to indicate that a particular term has alternate forms which may be widely used or have been used in the literature.

1.4 Acknowledgements

This Guide acknowledges and is dedicated to the programmers, documenters, testers and administrators who laboured long and hard in the trenches to turn visionary concepts into reality.

1.5 License and Copyright

Creative Commons License   This work is licensed under a Creative Commons License.

1.6 Disclaimer

The author and publisher have made every effort in the preparation of this guide to ensure the accuracy of the information. However, the information contained in this guide is offered without warranty, either express or implied. Neither the author nor the publisher will be held liable for any damages caused or alleged to be caused either directly or indirectly by this guide.

The logos, trademarks and symbols used in this document are the properties of their respective owners.

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.

Pro DNS and BIND by Ron Aitchison


tech info
guides home
dns articles
1 objectives
big picture
2 concepts
3 reverse map
4 dns types
5 install bind
6 samples
7 named.conf
8 zone records
9 howtos
10 tools
11 trouble
12 bind api's
13 dns security
bits & bytes
15 messages
notes & tips
registration FAQ
dns resources
dns rfcs
change log

Creative Commons License
This work is licensed under a Creative Commons License.

If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox




Icons made by Icomoon from is licensed by CC 3.0 BY
share page via facebook tweet this page


email us Send to a friend feature print this page Display full width page Decrease font size Increase font size



Debian Linux


GNU-Free SW Foundation


Open Source Initiative
Creative Commons


Ibiblio - Library
Open Book Project
Open Directory


CSS Technology SPF Record Conformant Domain
Copyright © 1994 - 2024 ZyTrax, Inc.
All rights reserved. Legal and Privacy
site by zytrax
hosted by
web-master at zytrax
Page modified: January 20 2022.