The current version of this Guide achieves only some of the above objectives.
This is not a book nor is it intended to be, the following summarises who should read what and when:
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.
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.
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.
Section 4: HOWTO for Common Configurations and Requirements. If you need to configure Load Balancing or Sub-Domain Delegation among others use this section.
Section 5: DNS Security. If you want to know about TSIG (Server-Server) and DNSSEC (Client-Server) use this section.
Section 6: DNS Messages. If you want to know about DNS message formats (queries and responses) use this section.
Appendix A: If you want explanations, tips or some background notes on BIND and DNS use this Appendix.
Appendix B: If you want to know how to register gTLD or ccTLD domains use this Appendix.
Appendix C: If you want to find alternative (to BIND) Open Source DNS software, tools or links use this Appendix.
Appendix D: If you want or need the real stuff - specifically all the relevant RFC's - use this Appendix.
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. example.com, example.de, example.ny.us, example.co.uk and example.montreal.qc.ca 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. www.example.com 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, www.example.com. is a fully qualified domain name whereas www.example.com 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, fred.example.com 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, example.com. is a qualified domain name whereas example.com 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.com, 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, example.co.uk. |
| 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. us.example.com is a valid sub-domain name of example.com. 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, example.com, us.example.com (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. |
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.
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.
