Domain Name Handbook
DNS NewsDomain DisputesU.S. PolicyICANNMailing ListsArchivesTable of ContentsReviews & CitesViewpointAcknowledgmentGlossarySpecial FeaturesBooklist

We sincerely appreciate the careful attention given to our book by those readers who noted the following errors.

BOOK ERRATA

Error .01


Page 38, the first sentence on the page should read: 

The top level domain (TLD) is the least significant octet (eight bits) in a four-octet Internet protocol (IP, a 4 x 8 = 32-bit address) that comprises...

We thank Paul Colquhoun for bringing this error to our attention.

 

Error.02


Page 52, the third paragraph should read as follows:

Each octet in a 32-bit address is allowed to have an alphanumeric equivalent, which is called a "label". A domain name is a sequence of [alphanumeric] labels separated by dots. In the section entitled "2.3.1 Preferred Name Syntax" in RFC 1035:

  • The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes. However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs.

    For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names.  

    The label consists of "any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case or any one of the ten digits 0 through 9."
    Note that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical. The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less.

    The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less.

    For example, the following strings identify hosts in the Internet:

  • A.ISI.EDU
    XX.LCS.MIT.EDU
    SRI-NIC.ARPA
  • The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET).
  • <domain> ::= <subdomain> | " "
    <subdomain> ::= <label> | <subdomain> "." <label>
    <label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
    <ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
    <let-dig-hyp> ::= <let-dig> | "-"
    <let-dig> ::= <letter> | <digit>
    <letter> ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case
    <digit> ::= any one of the ten digits 0 through 9

    The dash ( - ) is the only symbol, besides the dot separator, that the DNS allows in a label.

    Once again, we thank Paul Colquhoun for his careful reading of our book and specially for a well documented email message that brought several book errors to our attention. For Errata 02, we have rewritten the middle section of page 52, based upon quotes from RFCs 1034 and 1035. Paul also pointed out that:

    " . . . the above range ( 'A' to 'Z', 'a' to 'z', '0' to '9' and '-' ) is the range that the latest versions of the Unix name server software ( BIND ) is enforcing as the only allowable characters. In particular BIND is treating the underscore ("_" ) as an error, and can be set to ignore any domain names which contain this character." 

    Error.03


    Page 96, section 4.7 should read as follows:

    Socket - A 48-bit quantity that is the combination of the Port address (16 bits) and the Internet Address (32 bits)."

    We thank Paul Colquhoun for bringing these two errors to our attention.

     

    Error.04


    Pages 103-104

    Paul Colquhoun suggested that we add the following comments at the end of Section 4.9.3:

    RFC 1475 "TP/IX: The Next Internet" was one of the competing proposals for the next version of the IP protocol suite. The proposal that was eventual chosen was a modified version of a proposal called SIP put forward by S. Deering and P. Francis. Called IPv6 (or IPng) it uses 128-bit addresses and is detailed in the following RFCs (and others).

    RFC 1752: The Recommendation for the IP Next Generation Protocol
    RFC 1883: Internet Protocol, Version 6 (IPv6) Specification
    RFC 1884: IP Version 6 Addressing Architecture
    RFC 1885: Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
    RFC 1887: An Architecture for IPv6 Unicast Address Allocation
    RFC 1888: OSI NSAPs and IPv6
    RFC 1933: Transition Mechanisms for IPv6 Hosts and Routers
    RFC 1970: Neighbor Discovery for IP Version 6 (IPv6)
    RFC 2133: Basic Socket Interface Extensions for IPv6
    RFC 2185: Routing Aspects of IPv6 Transition 

    Error.05


    Page 123. The last paragraph in Section 4.18.3 should read as follows:

     

     

    As we examine Dr. Postel's chronology, we catch a glimmer of the organizational competition that may have occurred in the assigned numbers/Internet numbers activity he originated in 1971. Postel"s fifteen-year streak of uninterrupted responsibility for all networking numbers ended abruptly -- but only temporarily -- in 1987 (Section 4.14) when the authority for 32-bit Internet Protocol (IP) Addresses was transferred from ISI to SRI-NIC. ISI, Postel, and Reynolds did retain a piece of the networking numbers pie, namely, authority for all Internet protocol parameters ˆ "Assigned Numbers" ˆ other than the Class A, Class B, and Class C 32-bit addresses of computer networks. Postel and ISI are responsible for the significant .US top level domain. After a brief period at SRI-NIC -- and up to and including 1997 -- IANA has retained ultimate responsibility for the overall DNS as well as officially sanctioned regional registries for Internet Protocol (IP) addresses as well as autonomous system numbers. Such regional registries include over the DNS once involvement of the U.S. Government ceases on September 30, 1998. By August 31, 1998, IANA had produced a draft, which had gone through three iterations, for the "IANA-2" or "NewCorp"-- the successor to IANA (also known as the old IANA).

    We thank Rob Hassett for bringing our unspecific, and misleading, wording to our attention on August 20, 1998.

    Error.06


    Page 123. The first paragraph in Section 4.19 should read as follows:

     

     

    An examination of RFC file sizes for the "numbers" standards provides evidence of the magnitude of the change involving SRI-NIC versus ISI (Figure 4-9). As the ARPA-Internet grew, the size of the "Assigned Numbers" RFC file steadily increased. In Figure 4-9 (Series 1), we plot the file sizes of RFCs 204, 349, 739, 750, 755, 758, 762, 770, 776, 790, 820, 870, 900, 923, 943, 960, 990, 1010, 1060, 1340, and 1700 versus their respective ISI distribution dates. We also plot (Series 2) the "Internet Numbers" file sizes for RFCs 997, 1020, 1062, and 1166 versus their respective SRI -NIC distribution dates. It can be observed from Figure 4-9 that a significant drop, from 167 KB to 74KB, occurred for ISI between RFC 990 (November 1986) and RFC 1010 (May 1987); we infer that this drop corresponded to the temporary transfer of responsibility for the IP addresses and Autonomous System Numbers (ASNs) from ISI to SRI-NIC.

    We thank Rob Hassett for bringing our unspecific, and misleading, wording to our attention on August 20, 1998.

    Error.07


    Page 90 and Page 130, Footnote 2, were incorrectly attributed and should read:

     

    The second document is Anthony M. Rutkowski's "known detailed history" of the Internet Assiged Numbers Authority (IANA).2

    2. Anthony M. Rutkowski, "US DOD [Internet] Assigned Numbers [Authority]*, Network Information Centers (NICs), Contractors, and Activities.: 1996 at. http://www.wia.org/pub/iana.html.

    We thank Craig McTaggart, a graduate student of the Faculty of Law, University of Toronto, for questioning the attribution on August 22, 1999, which sent us back to the source.

    Top
     

    WHAT'S INSIDE?

    CONTENTS

    TABLES

    FIGURES

    CD-ROM

     

    CHECK OUR BOOKLIST FOR OTHER INTERNET BOOKS ON THE DOMAIN NAME SYSTEM AND ISSUES IN CYBERSPACE.

     

    Domain Handbook Cover 

     

     

     

     

     

     

     

     

     

     

    Website design and host

    Contact | Order | Site | News | Disputes | Policy | ICANN | Lists | Archives
    Contents | Reviews | Viewpoint | Acknowledgment | Glossary | Special Features | Booklist

     The Domain Name Handbook: High Stakes and Strategies in Cyberspace
    Copyright© 1998 Ellen Rony and Peter Rony. All Rights Reserved.

    http://www.domainhandbook.com/errata.html