summaryrefslogtreecommitdiff
path: root/docs/rfc
diff options
context:
space:
mode:
authorPeter Powell <petpow@saberuk.com>2013-11-24 16:20:31 +0000
committerPeter Powell <petpow@saberuk.com>2013-12-15 06:46:44 +0000
commit7fea7c24c509731040b76191d279972fced7b64c (patch)
tree65fc075fad393f4398592016cefa8fd42a6541a9 /docs/rfc
parent07d0d8f52f361c64b3c16d7e432f475cd2131a28 (diff)
Purge docs/rfc from the repository.
These are of no use to 99% of users and anyone who actually wants to read them should be capable of using Google to find them.
Diffstat (limited to 'docs/rfc')
-rw-r--r--docs/rfc/rfc1035.txt3077
-rw-r--r--docs/rfc/rfc1413.txt451
-rw-r--r--docs/rfc/rfc1459.txt3643
3 files changed, 0 insertions, 7171 deletions
diff --git a/docs/rfc/rfc1035.txt b/docs/rfc/rfc1035.txt
deleted file mode 100644
index b1a9bf5a9..000000000
--- a/docs/rfc/rfc1035.txt
+++ /dev/null
@@ -1,3077 +0,0 @@
-Network Working Group P. Mockapetris
-Request for Comments: 1035 ISI
- November 1987
-Obsoletes: RFCs 882, 883, 973
-
- DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
-
-
-1. STATUS OF THIS MEMO
-
-This RFC describes the details of the domain system and protocol, and
-assumes that the reader is familiar with the concepts discussed in a
-companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
-
-The domain system is a mixture of functions and data types which are an
-official protocol and functions and data types which are still
-experimental. Since the domain system is intentionally extensible, new
-data types and experimental behavior should always be expected in parts
-of the system beyond the official protocol. The official protocol parts
-include standard queries, responses and the Internet class RR data
-formats (e.g., host addresses). Since the previous RFC set, several
-definitions have changed, so some previous definitions are obsolete.
-
-Experimental or obsolete features are clearly marked in these RFCs, and
-such information should be used with caution.
-
-The reader is especially cautioned not to depend on the values which
-appear in examples to be current or complete, since their purpose is
-primarily pedagogical. Distribution of this memo is unlimited.
-
- Table of Contents
-
- 1. STATUS OF THIS MEMO 1
- 2. INTRODUCTION 3
- 2.1. Overview 3
- 2.2. Common configurations 4
- 2.3. Conventions 7
- 2.3.1. Preferred name syntax 7
- 2.3.2. Data Transmission Order 8
- 2.3.3. Character Case 9
- 2.3.4. Size limits 10
- 3. DOMAIN NAME SPACE AND RR DEFINITIONS 10
- 3.1. Name space definitions 10
- 3.2. RR definitions 11
- 3.2.1. Format 11
- 3.2.2. TYPE values 12
- 3.2.3. QTYPE values 12
- 3.2.4. CLASS values 13
-
-
-
-Mockapetris [Page 1]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 3.2.5. QCLASS values 13
- 3.3. Standard RRs 13
- 3.3.1. CNAME RDATA format 14
- 3.3.2. HINFO RDATA format 14
- 3.3.3. MB RDATA format (EXPERIMENTAL) 14
- 3.3.4. MD RDATA format (Obsolete) 15
- 3.3.5. MF RDATA format (Obsolete) 15
- 3.3.6. MG RDATA format (EXPERIMENTAL) 16
- 3.3.7. MINFO RDATA format (EXPERIMENTAL) 16
- 3.3.8. MR RDATA format (EXPERIMENTAL) 17
- 3.3.9. MX RDATA format 17
- 3.3.10. NULL RDATA format (EXPERIMENTAL) 17
- 3.3.11. NS RDATA format 18
- 3.3.12. PTR RDATA format 18
- 3.3.13. SOA RDATA format 19
- 3.3.14. TXT RDATA format 20
- 3.4. ARPA Internet specific RRs 20
- 3.4.1. A RDATA format 20
- 3.4.2. WKS RDATA format 21
- 3.5. IN-ADDR.ARPA domain 22
- 3.6. Defining new types, classes, and special namespaces 24
- 4. MESSAGES 25
- 4.1. Format 25
- 4.1.1. Header section format 26
- 4.1.2. Question section format 28
- 4.1.3. Resource record format 29
- 4.1.4. Message compression 30
- 4.2. Transport 32
- 4.2.1. UDP usage 32
- 4.2.2. TCP usage 32
- 5. MASTER FILES 33
- 5.1. Format 33
- 5.2. Use of master files to define zones 35
- 5.3. Master file example 36
- 6. NAME SERVER IMPLEMENTATION 37
- 6.1. Architecture 37
- 6.1.1. Control 37
- 6.1.2. Database 37
- 6.1.3. Time 39
- 6.2. Standard query processing 39
- 6.3. Zone refresh and reload processing 39
- 6.4. Inverse queries (Optional) 40
- 6.4.1. The contents of inverse queries and responses 40
- 6.4.2. Inverse query and response example 41
- 6.4.3. Inverse query processing 42
-
-
-
-
-
-
-Mockapetris [Page 2]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 6.5. Completion queries and responses 42
- 7. RESOLVER IMPLEMENTATION 43
- 7.1. Transforming a user request into a query 43
- 7.2. Sending the queries 44
- 7.3. Processing responses 46
- 7.4. Using the cache 47
- 8. MAIL SUPPORT 47
- 8.1. Mail exchange binding 48
- 8.2. Mailbox binding (Experimental) 48
- 9. REFERENCES and BIBLIOGRAPHY 50
- Index 54
-
-2. INTRODUCTION
-
-2.1. Overview
-
-The goal of domain names is to provide a mechanism for naming resources
-in such a way that the names are usable in different hosts, networks,
-protocol families, internets, and administrative organizations.
-
-From the user's point of view, domain names are useful as arguments to a
-local agent, called a resolver, which retrieves information associated
-with the domain name. Thus a user might ask for the host address or
-mail information associated with a particular domain name. To enable
-the user to request a particular type of information, an appropriate
-query type is passed to the resolver with the domain name. To the user,
-the domain tree is a single information space; the resolver is
-responsible for hiding the distribution of data among name servers from
-the user.
-
-From the resolver's point of view, the database that makes up the domain
-space is distributed among various name servers. Different parts of the
-domain space are stored in different name servers, although a particular
-data item will be stored redundantly in two or more name servers. The
-resolver starts with knowledge of at least one name server. When the
-resolver processes a user query it asks a known name server for the
-information; in return, the resolver either receives the desired
-information or a referral to another name server. Using these
-referrals, resolvers learn the identities and contents of other name
-servers. Resolvers are responsible for dealing with the distribution of
-the domain space and dealing with the effects of name server failure by
-consulting redundant databases in other servers.
-
-Name servers manage two kinds of data. The first kind of data held in
-sets called zones; each zone is the complete database for a particular
-"pruned" subtree of the domain space. This data is called
-authoritative. A name server periodically checks to make sure that its
-zones are up to date, and if not, obtains a new copy of updated zones
-
-
-
-Mockapetris [Page 3]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-from master files stored locally or in another name server. The second
-kind of data is cached data which was acquired by a local resolver.
-This data may be incomplete, but improves the performance of the
-retrieval process when non-local data is repeatedly accessed. Cached
-data is eventually discarded by a timeout mechanism.
-
-This functional structure isolates the problems of user interface,
-failure recovery, and distribution in the resolvers and isolates the
-database update and refresh problems in the name servers.
-
-2.2. Common configurations
-
-A host can participate in the domain name system in a number of ways,
-depending on whether the host runs programs that retrieve information
-from the domain system, name servers that answer queries from other
-hosts, or various combinations of both functions. The simplest, and
-perhaps most typical, configuration is shown below:
-
- Local Host | Foreign
- |
- +---------+ +----------+ | +--------+
- | | user queries | |queries | | |
- | User |-------------->| |---------|->|Foreign |
- | Program | | Resolver | | | Name |
- | |<--------------| |<--------|--| Server |
- | | user responses| |responses| | |
- +---------+ +----------+ | +--------+
- | A |
- cache additions | | references |
- V | |
- +----------+ |
- | cache | |
- +----------+ |
-
-User programs interact with the domain name space through resolvers; the
-format of user queries and user responses is specific to the host and
-its operating system. User queries will typically be operating system
-calls, and the resolver and its cache will be part of the host operating
-system. Less capable hosts may choose to implement the resolver as a
-subroutine to be linked in with every program that needs its services.
-Resolvers answer user queries with information they acquire via queries
-to foreign name servers and the local cache.
-
-Note that the resolver may have to make several queries to several
-different foreign name servers to answer a particular user query, and
-hence the resolution of a user query may involve several network
-accesses and an arbitrary amount of time. The queries to foreign name
-servers and the corresponding responses have a standard format described
-
-
-
-Mockapetris [Page 4]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-in this memo, and may be datagrams.
-
-Depending on its capabilities, a name server could be a stand alone
-program on a dedicated machine or a process or processes on a large
-timeshared host. A simple configuration might be:
-
- Local Host | Foreign
- |
- +---------+ |
- / /| |
- +---------+ | +----------+ | +--------+
- | | | | |responses| | |
- | | | | Name |---------|->|Foreign |
- | Master |-------------->| Server | | |Resolver|
- | files | | | |<--------|--| |
- | |/ | | queries | +--------+
- +---------+ +----------+ |
-
-Here a primary name server acquires information about one or more zones
-by reading master files from its local file system, and answers queries
-about those zones that arrive from foreign resolvers.
-
-The DNS requires that all zones be redundantly supported by more than
-one name server. Designated secondary servers can acquire zones and
-check for updates from the primary server using the zone transfer
-protocol of the DNS. This configuration is shown below:
-
- Local Host | Foreign
- |
- +---------+ |
- / /| |
- +---------+ | +----------+ | +--------+
- | | | | |responses| | |
- | | | | Name |---------|->|Foreign |
- | Master |-------------->| Server | | |Resolver|
- | files | | | |<--------|--| |
- | |/ | | queries | +--------+
- +---------+ +----------+ |
- A |maintenance | +--------+
- | +------------|->| |
- | queries | |Foreign |
- | | | Name |
- +------------------|--| Server |
- maintenance responses | +--------+
-
-In this configuration, the name server periodically establishes a
-virtual circuit to a foreign name server to acquire a copy of a zone or
-to check that an existing copy has not changed. The messages sent for
-
-
-
-Mockapetris [Page 5]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-these maintenance activities follow the same form as queries and
-responses, but the message sequences are somewhat different.
-
-The information flow in a host that supports all aspects of the domain
-name system is shown below:
-
- Local Host | Foreign
- |
- +---------+ +----------+ | +--------+
- | | user queries | |queries | | |
- | User |-------------->| |---------|->|Foreign |
- | Program | | Resolver | | | Name |
- | |<--------------| |<--------|--| Server |
- | | user responses| |responses| | |
- +---------+ +----------+ | +--------+
- | A |
- cache additions | | references |
- V | |
- +----------+ |
- | Shared | |
- | database | |
- +----------+ |
- A | |
- +---------+ refreshes | | references |
- / /| | V |
- +---------+ | +----------+ | +--------+
- | | | | |responses| | |
- | | | | Name |---------|->|Foreign |
- | Master |-------------->| Server | | |Resolver|
- | files | | | |<--------|--| |
- | |/ | | queries | +--------+
- +---------+ +----------+ |
- A |maintenance | +--------+
- | +------------|->| |
- | queries | |Foreign |
- | | | Name |
- +------------------|--| Server |
- maintenance responses | +--------+
-
-The shared database holds domain space data for the local name server
-and resolver. The contents of the shared database will typically be a
-mixture of authoritative data maintained by the periodic refresh
-operations of the name server and cached data from previous resolver
-requests. The structure of the domain data and the necessity for
-synchronization between name servers and resolvers imply the general
-characteristics of this database, but the actual format is up to the
-local implementor.
-
-
-
-
-Mockapetris [Page 6]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-Information flow can also be tailored so that a group of hosts act
-together to optimize activities. Sometimes this is done to offload less
-capable hosts so that they do not have to implement a full resolver.
-This can be appropriate for PCs or hosts which want to minimize the
-amount of new network code which is required. This scheme can also
-allow a group of hosts can share a small number of caches rather than
-maintaining a large number of separate caches, on the premise that the
-centralized caches will have a higher hit ratio. In either case,
-resolvers are replaced with stub resolvers which act as front ends to
-resolvers located in a recursive server in one or more name servers
-known to perform that service:
-
- Local Hosts | Foreign
- |
- +---------+ |
- | | responses |
- | Stub |<--------------------+ |
- | Resolver| | |
- | |----------------+ | |
- +---------+ recursive | | |
- queries | | |
- V | |
- +---------+ recursive +----------+ | +--------+
- | | queries | |queries | | |
- | Stub |-------------->| Recursive|---------|->|Foreign |
- | Resolver| | Server | | | Name |
- | |<--------------| |<--------|--| Server |
- +---------+ responses | |responses| | |
- +----------+ | +--------+
- | Central | |
- | cache | |
- +----------+ |
-
-In any case, note that domain components are always replicated for
-reliability whenever possible.
-
-2.3. Conventions
-
-The domain system has several conventions dealing with low-level, but
-fundamental, issues. While the implementor is free to violate these
-conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
-ALL behavior observed from other hosts.
-
-2.3.1. Preferred name syntax
-
-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.
-
-
-
-Mockapetris [Page 7]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-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 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
-
-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.
-
-For example, the following strings identify hosts in the Internet:
-
-A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
-
-2.3.2. Data Transmission Order
-
-The order of transmission of the header and data described in this
-document is resolved to the octet level. Whenever a diagram shows a
-
-
-
-Mockapetris [Page 8]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-group of octets, the order of transmission of those octets is the normal
-order in which they are read in English. For example, in the following
-diagram, the octets are transmitted in the order they are numbered.
-
- 0 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 1 | 2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 3 | 4 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 5 | 6 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-Whenever an octet represents a numeric quantity, the left most bit in
-the diagram is the high order or most significant bit. That is, the bit
-labeled 0 is the most significant bit. For example, the following
-diagram represents the value 170 (decimal).
-
- 0 1 2 3 4 5 6 7
- +-+-+-+-+-+-+-+-+
- |1 0 1 0 1 0 1 0|
- +-+-+-+-+-+-+-+-+
-
-Similarly, whenever a multi-octet field represents a numeric quantity
-the left most bit of the whole field is the most significant bit. When
-a multi-octet quantity is transmitted the most significant octet is
-transmitted first.
-
-2.3.3. Character Case
-
-For all parts of the DNS that are part of the official protocol, all
-comparisons between character strings (e.g., labels, domain names, etc.)
-are done in a case-insensitive manner. At present, this rule is in
-force throughout the domain system without exception. However, future
-additions beyond current usage may need to use the full binary octet
-capabilities in names, so attempts to store domain names in 7-bit ASCII
-or use of special bytes to terminate labels, etc., should be avoided.
-
-When data enters the domain system, its original case should be
-preserved whenever possible. In certain circumstances this cannot be
-done. For example, if two RRs are stored in a database, one at x.y and
-one at X.Y, they are actually stored at the same place in the database,
-and hence only one casing would be preserved. The basic rule is that
-case can be discarded only when data is used to define structure in a
-database, and two names are identical when compared in a case
-insensitive manner.
-
-
-
-
-Mockapetris [Page 9]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-Loss of case sensitive data must be minimized. Thus while data for x.y
-and X.Y may both be stored under a single location x.y or X.Y, data for
-a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In
-general, this preserves the case of the first label of a domain name,
-but forces standardization of interior node labels.
-
-Systems administrators who enter data into the domain database should
-take care to represent the data they supply to the domain system in a
-case-consistent manner if their system is case-sensitive. The data
-distribution system in the domain system will ensure that consistent
-representations are preserved.
-
-2.3.4. Size limits
-
-Various objects and parameters in the DNS have size limits. They are
-listed below. Some could be easily changed, others are more
-fundamental.
-
-labels 63 octets or less
-
-names 255 octets or less
-
-TTL positive values of a signed 32 bit number.
-
-UDP messages 512 octets or less
-
-3. DOMAIN NAME SPACE AND RR DEFINITIONS
-
-3.1. Name space definitions
-
-Domain names in messages are expressed in terms of a sequence of labels.
-Each label is represented as a one octet length field followed by that
-number of octets. Since every domain name ends with the null label of
-the root, a domain name is terminated by a length byte of zero. The
-high order two bits of every length octet must be zero, and the
-remaining six bits of the length field limit the label to 63 octets or
-less.
-
-To simplify implementations, the total length of a domain name (i.e.,
-label octets and label length octets) is restricted to 255 octets or
-less.
-
-Although labels can contain any 8 bit values in octets that make up a
-label, it is strongly recommended that labels follow the preferred
-syntax described elsewhere in this memo, which is compatible with
-existing host naming conventions. Name servers and resolvers must
-compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
-with zero parity. Non-alphabetic codes must match exactly.
-
-
-
-Mockapetris [Page 10]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.2. RR definitions
-
-3.2.1. Format
-
-All RRs have the same top level format shown below:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- / /
- / NAME /
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TYPE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | CLASS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TTL |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RDLENGTH |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
- / RDATA /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-where:
-
-NAME an owner name, i.e., the name of the node to which this
- resource record pertains.
-
-TYPE two octets containing one of the RR TYPE codes.
-
-CLASS two octets containing one of the RR CLASS codes.
-
-TTL a 32 bit signed integer that specifies the time interval
- that the resource record may be cached before the source
- of the information should again be consulted. Zero
- values are interpreted to mean that the RR can only be
- used for the transaction in progress, and should not be
- cached. For example, SOA records are always distributed
- with a zero TTL to prohibit caching. Zero values can
- also be used for extremely volatile data.
-
-RDLENGTH an unsigned 16 bit integer that specifies the length in
- octets of the RDATA field.
-
-
-
-Mockapetris [Page 11]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-RDATA a variable length string of octets that describes the
- resource. The format of this information varies
- according to the TYPE and CLASS of the resource record.
-
-3.2.2. TYPE values
-
-TYPE fields are used in resource records. Note that these types are a
-subset of QTYPEs.
-
-TYPE value and meaning
-
-A 1 a host address
-
-NS 2 an authoritative name server
-
-MD 3 a mail destination (Obsolete - use MX)
-
-MF 4 a mail forwarder (Obsolete - use MX)
-
-CNAME 5 the canonical name for an alias
-
-SOA 6 marks the start of a zone of authority
-
-MB 7 a mailbox domain name (EXPERIMENTAL)
-
-MG 8 a mail group member (EXPERIMENTAL)
-
-MR 9 a mail rename domain name (EXPERIMENTAL)
-
-NULL 10 a null RR (EXPERIMENTAL)
-
-WKS 11 a well known service description
-
-PTR 12 a domain name pointer
-
-HINFO 13 host information
-
-MINFO 14 mailbox or mail list information
-
-MX 15 mail exchange
-
-TXT 16 text strings
-
-3.2.3. QTYPE values
-
-QTYPE fields appear in the question part of a query. QTYPES are a
-superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the
-following QTYPEs are defined:
-
-
-
-Mockapetris [Page 12]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-AXFR 252 A request for a transfer of an entire zone
-
-MAILB 253 A request for mailbox-related records (MB, MG or MR)
-
-MAILA 254 A request for mail agent RRs (Obsolete - see MX)
-
-* 255 A request for all records
-
-3.2.4. CLASS values
-
-CLASS fields appear in resource records. The following CLASS mnemonics
-and values are defined:
-
-IN 1 the Internet
-
-CS 2 the CSNET class (Obsolete - used only for examples in
- some obsolete RFCs)
-
-CH 3 the CHAOS class
-
-HS 4 Hesiod [Dyer 87]
-
-3.2.5. QCLASS values
-
-QCLASS fields appear in the question section of a query. QCLASS values
-are a superset of CLASS values; every CLASS is a valid QCLASS. In
-addition to CLASS values, the following QCLASSes are defined:
-
-* 255 any class
-
-3.3. Standard RRs
-
-The following RR definitions are expected to occur, at least
-potentially, in all classes. In particular, NS, SOA, CNAME, and PTR
-will be used in all classes, and have the same format in all classes.
-Because their RDATA format is known, all domain names in the RDATA
-section of these RRs may be compressed.
-
-<domain-name> is a domain name represented as a series of labels, and
-terminated by a label with zero length. <character-string> is a single
-length octet followed by that number of characters. <character-string>
-is treated as binary information, and can be up to 256 characters in
-length (including the length octet).
-
-
-
-
-
-
-
-
-Mockapetris [Page 13]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.1. CNAME RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / CNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CNAME A <domain-name> which specifies the canonical or primary
- name for the owner. The owner name is an alias.
-
-CNAME RRs cause no additional section processing, but name servers may
-choose to restart the query at the canonical name in certain cases. See
-the description of name server logic in [RFC-1034] for details.
-
-3.3.2. HINFO RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / CPU /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / OS /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CPU A <character-string> which specifies the CPU type.
-
-OS A <character-string> which specifies the operating
- system type.
-
-Standard values for CPU and OS can be found in [RFC-1010].
-
-HINFO records are used to acquire general information about a host. The
-main use is for protocols such as FTP that can use special procedures
-when talking between machines or operating systems of the same type.
-
-3.3.3. MB RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MADNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME A <domain-name> which specifies a host which has the
- specified mailbox.
-
-
-
-Mockapetris [Page 14]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-MB records cause additional section processing which looks up an A type
-RRs corresponding to MADNAME.
-
-3.3.4. MD RDATA format (Obsolete)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MADNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME A <domain-name> which specifies a host which has a mail
- agent for the domain which should be able to deliver
- mail for the domain.
-
-MD records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MD is obsolete. See the definition of MX and [RFC-974] for details of
-the new scheme. The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 0.
-
-3.3.5. MF RDATA format (Obsolete)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MADNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME A <domain-name> which specifies a host which has a mail
- agent for the domain which will accept mail for
- forwarding to the domain.
-
-MF records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MF is obsolete. See the definition of MX and [RFC-974] for details ofw
-the new scheme. The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 10.
-
-
-
-
-
-
-
-Mockapetris [Page 15]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.6. MG RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MGMNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MGMNAME A <domain-name> which specifies a mailbox which is a
- member of the mail group specified by the domain name.
-
-MG records cause no additional section processing.
-
-3.3.7. MINFO RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / RMAILBX /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / EMAILBX /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-RMAILBX A <domain-name> which specifies a mailbox which is
- responsible for the mailing list or mailbox. If this
- domain name names the root, the owner of the MINFO RR is
- responsible for itself. Note that many existing mailing
- lists use a mailbox X-request for the RMAILBX field of
- mailing list X, e.g., Msgroup-request for Msgroup. This
- field provides a more general mechanism.
-
-
-EMAILBX A <domain-name> which specifies a mailbox which is to
- receive error messages related to the mailing list or
- mailbox specified by the owner of the MINFO RR (similar
- to the ERRORS-TO: field which has been proposed). If
- this domain name names the root, errors should be
- returned to the sender of the message.
-
-MINFO records cause no additional section processing. Although these
-records can be associated with a simple mailbox, they are usually used
-with a mailing list.
-
-
-
-
-
-
-
-
-Mockapetris [Page 16]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.8. MR RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / NEWNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NEWNAME A <domain-name> which specifies a mailbox which is the
- proper rename of the specified mailbox.
-
-MR records cause no additional section processing. The main use for MR
-is as a forwarding entry for a user who has moved to a different
-mailbox.
-
-3.3.9. MX RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | PREFERENCE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / EXCHANGE /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PREFERENCE A 16 bit integer which specifies the preference given to
- this RR among others at the same owner. Lower values
- are preferred.
-
-EXCHANGE A <domain-name> which specifies a host willing to act as
- a mail exchange for the owner name.
-
-MX records cause type A additional section processing for the host
-specified by EXCHANGE. The use of MX RRs is explained in detail in
-[RFC-974].
-
-3.3.10. NULL RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / <anything> /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Anything at all may be in the RDATA field so long as it is 65535 octets
-or less.
-
-
-
-
-Mockapetris [Page 17]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-NULL records cause no additional section processing. NULL RRs are not
-allowed in master files. NULLs are used as placeholders in some
-experimental extensions of the DNS.
-
-3.3.11. NS RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / NSDNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NSDNAME A <domain-name> which specifies a host which should be
- authoritative for the specified class and domain.
-
-NS records cause both the usual additional section processing to locate
-a type A record, and, when used in a referral, a special search of the
-zone in which they reside for glue information.
-
-The NS RR states that the named host should be expected to have a zone
-starting at owner name of the specified class. Note that the class may
-not indicate the protocol family which should be used to communicate
-with the host, although it is typically a strong hint. For example,
-hosts which are name servers for either Internet (IN) or Hesiod (HS)
-class information are normally queried using IN class protocols.
-
-3.3.12. PTR RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / PTRDNAME /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PTRDNAME A <domain-name> which points to some location in the
- domain name space.
-
-PTR records cause no additional section processing. These RRs are used
-in special domains to point to some other location in the domain space.
-These records are simple data, and don't imply any special processing
-similar to that performed by CNAME, which identifies aliases. See the
-description of the IN-ADDR.ARPA domain for an example.
-
-
-
-
-
-
-
-
-Mockapetris [Page 18]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.13. SOA RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / RNAME /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | SERIAL |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | REFRESH |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RETRY |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | EXPIRE |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | MINIMUM |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MNAME The <domain-name> of the name server that was the
- original or primary source of data for this zone.
-
-RNAME A <domain-name> which specifies the mailbox of the
- person responsible for this zone.
-
-SERIAL The unsigned 32 bit version number of the original copy
- of the zone. Zone transfers preserve this value. This
- value wraps and should be compared using sequence space
- arithmetic.
-
-REFRESH A 32 bit time interval before the zone should be
- refreshed.
-
-RETRY A 32 bit time interval that should elapse before a
- failed refresh should be retried.
-
-EXPIRE A 32 bit time value that specifies the upper limit on
- the time interval that can elapse before the zone is no
- longer authoritative.
-
-
-
-
-
-Mockapetris [Page 19]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-MINIMUM The unsigned 32 bit minimum TTL field that should be
- exported with any RR from this zone.
-
-SOA records cause no additional section processing.
-
-All times are in units of seconds.
-
-Most of these fields are pertinent only for name server maintenance
-operations. However, MINIMUM is used in all query operations that
-retrieve RRs from a zone. Whenever a RR is sent in a response to a
-query, the TTL field is set to the maximum of the TTL field from the RR
-and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower
-bound on the TTL field for all RRs in a zone. Note that this use of
-MINIMUM should occur when the RRs are copied into the response and not
-when the zone is loaded from a master file or via a zone transfer. The
-reason for this provison is to allow future dynamic update facilities to
-change the SOA RR with known semantics.
-
-
-3.3.14. TXT RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / TXT-DATA /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-TXT-DATA One or more <character-string>s.
-
-TXT RRs are used to hold descriptive text. The semantics of the text
-depends on the domain where it is found.
-
-3.4. Internet specific RRs
-
-3.4.1. A RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ADDRESS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS A 32 bit Internet address.
-
-Hosts that have multiple Internet addresses will have multiple A
-records.
-
-
-
-
-
-Mockapetris [Page 20]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-A records cause no additional section processing. The RDATA section of
-an A line in a master file is an Internet address expressed as four
-decimal numbers separated by dots without any imbedded spaces (e.g.,
-"10.2.0.52" or "192.0.5.6").
-
-3.4.2. WKS RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ADDRESS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | PROTOCOL | |
- +--+--+--+--+--+--+--+--+ |
- | |
- / <BIT MAP> /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS An 32 bit Internet address
-
-PROTOCOL An 8 bit IP protocol number
-
-<BIT MAP> A variable length bit map. The bit map must be a
- multiple of 8 bits long.
-
-The WKS record is used to describe the well known services supported by
-a particular protocol on a particular internet address. The PROTOCOL
-field specifies an IP protocol number, and the bit map has one bit per
-port of the specified protocol. The first bit corresponds to port 0,
-the second to port 1, etc. If the bit map does not include a bit for a
-protocol of interest, that bit is assumed zero. The appropriate values
-and mnemonics for ports and protocols are specified in [RFC-1010].
-
-For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
-25 (SMTP). If this bit is set, a SMTP server should be listening on TCP
-port 25; if zero, SMTP service is not supported on the specified
-address.
-
-The purpose of WKS RRs is to provide availability information for
-servers for TCP and UDP. If a server supports both TCP and UDP, or has
-multiple Internet addresses, then multiple WKS RRs are used.
-
-WKS RRs cause no additional section processing.
-
-In master files, both ports and protocols are expressed using mnemonics
-or decimal numbers.
-
-
-
-
-Mockapetris [Page 21]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.5. IN-ADDR.ARPA domain
-
-The Internet uses a special domain to support gateway location and
-Internet address to host mapping. Other classes may employ a similar
-strategy in other domains. The intent of this domain is to provide a
-guaranteed method to perform host address to host name mapping, and to
-facilitate queries to locate all gateways on a particular network in the
-Internet.
-
-Note that both of these services are similar to functions that could be
-performed by inverse queries; the difference is that this part of the
-domain name space is structured according to address, and hence can
-guarantee that the appropriate data can be located without an exhaustive
-search of the domain space.
-
-The domain begins at IN-ADDR.ARPA and has a substructure which follows
-the Internet addressing structure.
-
-Domain names in the IN-ADDR.ARPA domain are defined to have up to four
-labels in addition to the IN-ADDR.ARPA suffix. Each label represents
-one octet of an Internet address, and is expressed as a character string
-for a decimal value in the range 0-255 (with leading zeros omitted
-except in the case of a zero octet which is represented by a single
-zero).
-
-Host addresses are represented by domain names that have all four labels
-specified. Thus data for Internet address 10.2.0.52 is located at
-domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to
-read, allows zones to be delegated which are exactly one network of
-address space. For example, 10.IN-ADDR.ARPA can be a zone containing
-data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
-MILNET. Address nodes are used to hold pointers to primary host names
-in the normal domain space.
-
-Network numbers correspond to some non-terminal nodes at various depths
-in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
-2, or 3 octets. Network nodes are used to hold pointers to the primary
-host names of gateways attached to that network. Since a gateway is, by
-definition, on more than one network, it will typically have two or more
-network nodes which point at it. Gateways will also have host level
-pointers at their fully qualified addresses.
-
-Both the gateway pointers at network nodes and the normal host pointers
-at full address nodes use the PTR RR to point back to the primary domain
-names of the corresponding hosts.
-
-For example, the IN-ADDR.ARPA domain will contain information about the
-ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
-
-
-
-Mockapetris [Page 22]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI
-gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
-GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
-and a name GW.LCS.MIT.EDU, the domain database would contain:
-
- 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
- 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
-
-Thus a program which wanted to locate gateways on net 10 would originate
-a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA. It
-would receive two RRs in response:
-
- 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
-
-The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
-GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
-these gateways.
-
-A resolver which wanted to find the host name corresponding to Internet
-host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
-QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
-
- 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
-
-Several cautions apply to the use of these services:
- - Since the IN-ADDR.ARPA special domain and the normal domain
- for a particular host or gateway will be in different zones,
- the possibility exists that that the data may be inconsistent.
-
- - Gateways will often have two names in separate domains, only
- one of which can be primary.
-
- - Systems that use the domain database to initialize their
- routing tables must start with enough gateway information to
- guarantee that they can access the appropriate name server.
-
- - The gateway data only reflects the existence of a gateway in a
- manner equivalent to the current HOSTS.TXT file. It doesn't
- replace the dynamic availability information from GGP or EGP.
-
-
-
-Mockapetris [Page 23]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.6. Defining new types, classes, and special namespaces
-
-The previously defined types and classes are the ones in use as of the
-date of this memo. New definitions should be expected. This section
-makes some recommendations to designers considering additions to the
-existing facilities. The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
-forum where general discussion of design issues takes place.
-
-In general, a new type is appropriate when new information is to be
-added to the database about an existing object, or we need new data
-formats for some totally new object. Designers should attempt to define
-types and their RDATA formats that are generally applicable to all
-classes, and which avoid duplication of information. New classes are
-appropriate when the DNS is to be used for a new protocol, etc which
-requires new class-specific data formats, or when a copy of the existing
-name space is desired, but a separate management domain is necessary.
-
-New types and classes need mnemonics for master files; the format of the
-master files requires that the mnemonics for type and class be disjoint.
-
-TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
-respectively.
-
-The present system uses multiple RRs to represent multiple values of a
-type rather than storing multiple values in the RDATA section of a
-single RR. This is less efficient for most applications, but does keep
-RRs shorter. The multiple RRs assumption is incorporated in some
-experimental work on dynamic update methods.
-
-The present system attempts to minimize the duplication of data in the
-database in order to insure consistency. Thus, in order to find the
-address of the host for a mail exchange, you map the mail domain name to
-a host name, then the host name to addresses, rather than a direct
-mapping to host address. This approach is preferred because it avoids
-the opportunity for inconsistency.
-
-In defining a new type of data, multiple RR types should not be used to
-create an ordering between entries or express different formats for
-equivalent bindings, instead this information should be carried in the
-body of the RR and a single type used. This policy avoids problems with
-caching multiple types and defining QTYPEs to match multiple types.
-
-For example, the original form of mail exchange binding used two RR
-types one to represent a "closer" exchange (MD) and one to represent a
-"less close" exchange (MF). The difficulty is that the presence of one
-RR type in a cache doesn't convey any information about the other
-because the query which acquired the cached information might have used
-a QTYPE of MF, MD, or MAILA (which matched both). The redesigned
-
-
-
-Mockapetris [Page 24]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-service used a single type (MX) with a "preference" value in the RDATA
-section which can order different RRs. However, if any MX RRs are found
-in the cache, then all should be there.
-
-4. MESSAGES
-
-4.1. Format
-
-All communications inside of the domain protocol are carried in a single
-format called a message. The top level format of message is divided
-into 5 sections (some of which are empty in certain cases) shown below:
-
- +---------------------+
- | Header |
- +---------------------+
- | Question | the question for the name server
- +---------------------+
- | Answer | RRs answering the question
- +---------------------+
- | Authority | RRs pointing toward an authority
- +---------------------+
- | Additional | RRs holding additional information
- +---------------------+
-
-The header section is always present. The header includes fields that
-specify which of the remaining sections are present, and also specify
-whether the message is a query or a response, a standard query or some
-other opcode, etc.
-
-The names of the sections after the header are derived from their use in
-standard queries. The question section contains fields that describe a
-question to a name server. These fields are a query type (QTYPE), a
-query class (QCLASS), and a query domain name (QNAME). The last three
-sections have the same format: a possibly empty list of concatenated
-resource records (RRs). The answer section contains RRs that answer the
-question; the authority section contains RRs that point toward an
-authoritative name server; the additional records section contains RRs
-which relate to the query, but are not strictly answers for the
-question.
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 25]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-4.1.1. Header section format
-
-The header contains the following fields:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode |AA|TC|RD|RA| Z | RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ID A 16 bit identifier assigned by the program that
- generates any kind of query. This identifier is copied
- the corresponding reply and can be used by the requester
- to match up replies to outstanding queries.
-
-QR A one bit field that specifies whether this message is a
- query (0), or a response (1).
-
-OPCODE A four bit field that specifies kind of query in this
- message. This value is set by the originator of a query
- and copied into the response. The values are:
-
- 0 a standard query (QUERY)
-
- 1 an inverse query (IQUERY)
-
- 2 a server status request (STATUS)
-
- 3-15 reserved for future use
-
-AA Authoritative Answer - this bit is valid in responses,
- and specifies that the responding name server is an
- authority for the domain name in question section.
-
- Note that the contents of the answer section may have
- multiple owner names because of aliases. The AA bit
-
-
-
-Mockapetris [Page 26]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- corresponds to the name which matches the query name, or
- the first owner name in the answer section.
-
-TC TrunCation - specifies that this message was truncated
- due to length greater than that permitted on the
- transmission channel.
-
-RD Recursion Desired - this bit may be set in a query and
- is copied into the response. If RD is set, it directs
- the name server to pursue the query recursively.
- Recursive query support is optional.
-
-RA Recursion Available - this be is set or cleared in a
- response, and denotes whether recursive query support is
- available in the name server.
-
-Z Reserved for future use. Must be zero in all queries
- and responses.
-
-RCODE Response code - this 4 bit field is set as part of
- responses. The values have the following
- interpretation:
-
- 0 No error condition
-
- 1 Format error - The name server was
- unable to interpret the query.
-
- 2 Server failure - The name server was
- unable to process this query due to a
- problem with the name server.
-
- 3 Name Error - Meaningful only for
- responses from an authoritative name
- server, this code signifies that the
- domain name referenced in the query does
- not exist.
-
- 4 Not Implemented - The name server does
- not support the requested kind of query.
-
- 5 Refused - The name server refuses to
- perform the specified operation for
- policy reasons. For example, a name
- server may not wish to provide the
- information to the particular requester,
- or a name server may not wish to perform
- a particular operation (e.g., zone
-
-
-
-Mockapetris [Page 27]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- transfer) for particular data.
-
- 6-15 Reserved for future use.
-
-QDCOUNT an unsigned 16 bit integer specifying the number of
- entries in the question section.
-
-ANCOUNT an unsigned 16 bit integer specifying the number of
- resource records in the answer section.
-
-NSCOUNT an unsigned 16 bit integer specifying the number of name
- server resource records in the authority records
- section.
-
-ARCOUNT an unsigned 16 bit integer specifying the number of
- resource records in the additional records section.
-
-4.1.2. Question section format
-
-The question section is used to carry the "question" in most queries,
-i.e., the parameters that define what is being asked. The section
-contains QDCOUNT (usually 1) entries, each of the following format:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- / QNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QTYPE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QCLASS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-QNAME a domain name represented as a sequence of labels, where
- each label consists of a length octet followed by that
- number of octets. The domain name terminates with the
- zero length octet for the null label of the root. Note
- that this field may be an odd number of octets; no
- padding is used.
-
-QTYPE a two octet code which specifies the type of the query.
- The values for this field include all codes valid for a
- TYPE field, together with some more general codes which
- can match more than one type of RR.
-
-
-
-Mockapetris [Page 28]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-QCLASS a two octet code that specifies the class of the query.
- For example, the QCLASS field is IN for the Internet.
-
-4.1.3. Resource record format
-
-The answer, authority, and additional sections all share the same
-format: a variable number of resource records, where the number of
-records is specified in the corresponding count field in the header.
-Each resource record has the following format:
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- / /
- / NAME /
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TYPE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | CLASS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TTL |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RDLENGTH |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
- / RDATA /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NAME a domain name to which this resource record pertains.
-
-TYPE two octets containing one of the RR type codes. This
- field specifies the meaning of the data in the RDATA
- field.
-
-CLASS two octets which specify the class of the data in the
- RDATA field.
-
-TTL a 32 bit unsigned integer that specifies the time
- interval (in seconds) that the resource record may be
- cached before it should be discarded. Zero values are
- interpreted to mean that the RR can only be used for the
- transaction in progress, and should not be cached.
-
-
-
-
-
-Mockapetris [Page 29]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-RDLENGTH an unsigned 16 bit integer that specifies the length in
- octets of the RDATA field.
-
-RDATA a variable length string of octets that describes the
- resource. The format of this information varies
- according to the TYPE and CLASS of the resource record.
- For example, the if the TYPE is A and the CLASS is IN,
- the RDATA field is a 4 octet ARPA Internet address.
-
-4.1.4. Message compression
-
-In order to reduce the size of messages, the domain system utilizes a
-compression scheme which eliminates the repetition of domain names in a
-message. In this scheme, an entire domain name or a list of labels at
-the end of a domain name is replaced with a pointer to a prior occurance
-of the same name.
-
-The pointer takes the form of a two octet sequence:
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | 1 1| OFFSET |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The first two bits are ones. This allows a pointer to be distinguished
-from a label, since the label must begin with two zero bits because
-labels are restricted to 63 octets or less. (The 10 and 01 combinations
-are reserved for future use.) The OFFSET field specifies an offset from
-the start of the message (i.e., the first octet of the ID field in the
-domain header). A zero offset specifies the first byte of the ID field,
-etc.
-
-The compression scheme allows a domain name in a message to be
-represented as either:
-
- - a sequence of labels ending in a zero octet
-
- - a pointer
-
- - a sequence of labels ending with a pointer
-
-Pointers can only be used for occurances of a domain name where the
-format is not class specific. If this were not the case, a name server
-or resolver would be required to know the format of all RRs it handled.
-As yet, there are no such cases, but they may occur in future RDATA
-formats.
-
-If a domain name is contained in a part of the message subject to a
-length field (such as the RDATA section of an RR), and compression is
-
-
-
-Mockapetris [Page 30]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-used, the length of the compressed name is used in the length
-calculation, rather than the length of the expanded name.
-
-Programs are free to avoid using pointers in messages they generate,
-although this will reduce datagram capacity, and may cause truncation.
-However all programs are required to understand arriving messages that
-contain pointers.
-
-For example, a datagram might need to use the domain names F.ISI.ARPA,
-FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the
-message, these domain names might be represented as:
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 20 | 1 | F |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 22 | 3 | I |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 24 | S | I |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 26 | 4 | A |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 28 | R | P |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 30 | A | 0 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 40 | 3 | F |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 42 | O | O |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 44 | 1 1| 20 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 64 | 1 1| 26 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 92 | 0 | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The domain name for F.ISI.ARPA is shown at offset 20. The domain name
-FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
-concatenate a label for FOO to the previously defined F.ISI.ARPA. The
-domain name ARPA is defined at offset 64 using a pointer to the ARPA
-component of the name F.ISI.ARPA at 20; note that this pointer relies on
-ARPA being the last label in the string at 20. The root domain name is
-
-
-
-Mockapetris [Page 31]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-defined by a single octet of zeros at 92; the root domain name has no
-labels.
-
-4.2. Transport
-
-The DNS assumes that messages will be transmitted as datagrams or in a
-byte stream carried by a virtual circuit. While virtual circuits can be
-used for any DNS activity, datagrams are preferred for queries due to
-their lower overhead and better performance. Zone refresh activities
-must use virtual circuits because of the need for reliable transfer.
-
-The Internet supports name server access using TCP [RFC-793] on server
-port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
-port 53 (decimal).
-
-4.2.1. UDP usage
-
-Messages sent using UDP user server port 53 (decimal).
-
-Messages carried by UDP are restricted to 512 bytes (not counting the IP
-or UDP headers). Longer messages are truncated and the TC bit is set in
-the header.
-
-UDP is not acceptable for zone transfers, but is the recommended method
-for standard queries in the Internet. Queries sent using UDP may be
-lost, and hence a retransmission strategy is required. Queries or their
-responses may be reordered by the network, or by processing in name
-servers, so resolvers should not depend on them being returned in order.
-
-The optimal UDP retransmission policy will vary with performance of the
-Internet and the needs of the client, but the following are recommended:
-
- - The client should try other servers and server addresses
- before repeating a query to a specific address of a server.
-
- - The retransmission interval should be based on prior
- statistics if possible. Too aggressive retransmission can
- easily slow responses for the community at large. Depending
- on how well connected the client is to its expected servers,
- the minimum retransmission interval should be 2-5 seconds.
-
-More suggestions on server selection and retransmission policy can be
-found in the resolver section of this memo.
-
-4.2.2. TCP usage
-
-Messages sent over TCP connections use server port 53 (decimal). The
-message is prefixed with a two byte length field which gives the message
-
-
-
-Mockapetris [Page 32]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-length, excluding the two byte length field. This length field allows
-the low-level processing to assemble a complete message before beginning
-to parse it.
-
-Several connection management policies are recommended:
-
- - The server should not block other activities waiting for TCP
- data.
-
- - The server should support multiple connections.
-
- - The server should assume that the client will initiate
- connection closing, and should delay closing its end of the
- connection until all outstanding client requests have been
- satisfied.
-
- - If the server needs to close a dormant connection to reclaim
- resources, it should wait until the connection has been idle
- for a period on the order of two minutes. In particular, the
- server should allow the SOA and AXFR request sequence (which
- begins a refresh operation) to be made on a single connection.
- Since the server would be unable to answer queries anyway, a
- unilateral close or reset may be used instead of a graceful
- close.
-
-5. MASTER FILES
-
-Master files are text files that contain RRs in text form. Since the
-contents of a zone can be expressed in the form of a list of RRs a
-master file is most often used to define a zone, though it can be used
-to list a cache's contents. Hence, this section first discusses the
-format of RRs in a master file, and then the special considerations when
-a master file is used to create a zone in some name server.
-
-5.1. Format
-
-The format of these files is a sequence of entries. Entries are
-predominantly line-oriented, though parentheses can be used to continue
-a list of items across a line boundary, and text literals can contain
-CRLF within the text. Any combination of tabs and spaces act as a
-delimiter between the separate items that make up an entry. The end of
-any line in the master file can end with a comment. The comment starts
-with a ";" (semicolon).
-
-The following entries are defined:
-
- <blank>[<comment>]
-
-
-
-
-Mockapetris [Page 33]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- $ORIGIN <domain-name> [<comment>]
-
- $INCLUDE <file-name> [<domain-name>] [<comment>]
-
- <domain-name><rr> [<comment>]
-
- <blank><rr> [<comment>]
-
-Blank lines, with or without comments, are allowed anywhere in the file.
-
-Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is
-followed by a domain name, and resets the current origin for relative
-domain names to the stated name. $INCLUDE inserts the named file into
-the current file, and may optionally specify a domain name that sets the
-relative domain name origin for the included file. $INCLUDE may also
-have a comment. Note that a $INCLUDE entry never changes the relative
-origin of the parent file, regardless of changes to the relative origin
-made within the included file.
-
-The last two forms represent RRs. If an entry for an RR begins with a
-blank, then the RR is assumed to be owned by the last stated owner. If
-an RR entry begins with a <domain-name>, then the owner name is reset.
-
-<rr> contents take one of the following forms:
-
- [<TTL>] [<class>] <type> <RDATA>
-
- [<class>] [<TTL>] <type> <RDATA>
-
-The RR begins with optional TTL and class fields, followed by a type and
-RDATA field appropriate to the type and class. Class and type use the
-standard mnemonics, TTL is a decimal integer. Omitted class and TTL
-values are default to the last explicitly stated values. Since type and
-class mnemonics are disjoint, the parse is unique. (Note that this
-order is different from the order used in examples and the order used in
-the actual RRs; the given order allows easier parsing and defaulting.)
-
-<domain-name>s make up a large share of the data in the master file.
-The labels in the domain name are expressed as character strings and
-separated by dots. Quoting conventions allow arbitrary characters to be
-stored in domain names. Domain names that end in a dot are called
-absolute, and are taken as complete. Domain names which do not end in a
-dot are called relative; the actual domain name is the concatenation of
-the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
-an argument to the master file loading routine. A relative name is an
-error when no origin is available.
-
-
-
-
-
-Mockapetris [Page 34]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-<character-string> is expressed in one or two ways: as a contiguous set
-of characters without interior spaces, or as a string beginning with a "
-and ending with a ". Inside a " delimited string any character can
-occur, except for a " itself, which must be quoted using \ (back slash).
-
-Because these files are text files several special encodings are
-necessary to allow arbitrary data to be loaded. In particular:
-
- of the root.
-
-@ A free standing @ is used to denote the current origin.
-
-\X where X is any character other than a digit (0-9), is
- used to quote that character so that its special meaning
- does not apply. For example, "\." can be used to place
- a dot character in a label.
-
-\DDD where each D is a digit is the octet corresponding to
- the decimal number described by DDD. The resulting
- octet is assumed to be text and is not checked for
- special meaning.
-
-( ) Parentheses are used to group data that crosses a line
- boundary. In effect, line terminations are not
- recognized within parentheses.
-
-; Semicolon is used to start a comment; the remainder of
- the line is ignored.
-
-5.2. Use of master files to define zones
-
-When a master file is used to load a zone, the operation should be
-suppressed if any errors are encountered in the master file. The
-rationale for this is that a single error can have widespread
-consequences. For example, suppose that the RRs defining a delegation
-have syntax errors; then the server will return authoritative name
-errors for all names in the subzone (except in the case where the
-subzone is also present on the server).
-
-Several other validity checks that should be performed in addition to
-insuring that the file is syntactically correct:
-
- 1. All RRs in the file should have the same class.
-
- 2. Exactly one SOA RR should be present at the top of the zone.
-
- 3. If delegations are present and glue information is required,
- it should be present.
-
-
-
-Mockapetris [Page 35]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 4. Information present outside of the authoritative nodes in the
- zone should be glue information, rather than the result of an
- origin or similar error.
-
-5.3. Master file example
-
-The following is an example file which might be used to define the
-ISI.EDU zone.and is loaded with an origin of ISI.EDU:
-
-@ IN SOA VENERA Action\.domains (
- 20 ; SERIAL
- 7200 ; REFRESH
- 600 ; RETRY
- 3600000; EXPIRE
- 60) ; MINIMUM
-
- NS A.ISI.EDU.
- NS VENERA
- NS VAXA
- MX 10 VENERA
- MX 20 VAXA
-
-A A 26.3.0.103
-
-VENERA A 10.1.0.52
- A 128.9.0.32
-
-VAXA A 10.2.0.27
- A 128.9.0.33
-
-
-$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
-
-Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
-
- MOE MB A.ISI.EDU.
- LARRY MB A.ISI.EDU.
- CURLEY MB A.ISI.EDU.
- STOOGES MG MOE
- MG LARRY
- MG CURLEY
-
-Note the use of the \ character in the SOA RR to specify the responsible
-person mailbox "Action.domains@E.ISI.EDU".
-
-
-
-
-
-
-
-Mockapetris [Page 36]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-6. NAME SERVER IMPLEMENTATION
-
-6.1. Architecture
-
-The optimal structure for the name server will depend on the host
-operating system and whether the name server is integrated with resolver
-operations, either by supporting recursive service, or by sharing its
-database with a resolver. This section discusses implementation
-considerations for a name server which shares a database with a
-resolver, but most of these concerns are present in any name server.
-
-6.1.1. Control
-
-A name server must employ multiple concurrent activities, whether they
-are implemented as separate tasks in the host's OS or multiplexing
-inside a single name server program. It is simply not acceptable for a
-name server to block the service of UDP requests while it waits for TCP
-data for refreshing or query activities. Similarly, a name server
-should not attempt to provide recursive service without processing such
-requests in parallel, though it may choose to serialize requests from a
-single client, or to regard identical requests from the same client as
-duplicates. A name server should not substantially delay requests while
-it reloads a zone from master files or while it incorporates a newly
-refreshed zone into its database.
-
-6.1.2. Database
-
-While name server implementations are free to use any internal data
-structures they choose, the suggested structure consists of three major
-parts:
-
- - A "catalog" data structure which lists the zones available to
- this server, and a "pointer" to the zone data structure. The
- main purpose of this structure is to find the nearest ancestor
- zone, if any, for arriving standard queries.
-
- - Separate data structures for each of the zones held by the
- name server.
-
- - A data structure for cached data. (or perhaps separate caches
- for different classes)
-
-All of these data structures can be implemented an identical tree
-structure format, with different data chained off the nodes in different
-parts: in the catalog the data is pointers to zones, while in the zone
-and cache data structures, the data will be RRs. In designing the tree
-framework the designer should recognize that query processing will need
-to traverse the tree using case-insensitive label comparisons; and that
-
-
-
-Mockapetris [Page 37]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-in real data, a few nodes have a very high branching factor (100-1000 or
-more), but the vast majority have a very low branching factor (0-1).
-
-One way to solve the case problem is to store the labels for each node
-in two pieces: a standardized-case representation of the label where all
-ASCII characters are in a single case, together with a bit mask that
-denotes which characters are actually of a different case. The
-branching factor diversity can be handled using a simple linked list for
-a node until the branching factor exceeds some threshold, and
-transitioning to a hash structure after the threshold is exceeded. In
-any case, hash structures used to store tree sections must insure that
-hash functions and procedures preserve the casing conventions of the
-DNS.
-
-The use of separate structures for the different parts of the database
-is motivated by several factors:
-
- - The catalog structure can be an almost static structure that
- need change only when the system administrator changes the
- zones supported by the server. This structure can also be
- used to store parameters used to control refreshing
- activities.
-
- - The individual data structures for zones allow a zone to be
- replaced simply by changing a pointer in the catalog. Zone
- refresh operations can build a new structure and, when
- complete, splice it into the database via a simple pointer
- replacement. It is very important that when a zone is
- refreshed, queries should not use old and new data
- simultaneously.
-
- - With the proper search procedures, authoritative data in zones
- will always "hide", and hence take precedence over, cached
- data.
-
- - Errors in zone definitions that cause overlapping zones, etc.,
- may cause erroneous responses to queries, but problem
- determination is simplified, and the contents of one "bad"
- zone can't corrupt another.
-
- - Since the cache is most frequently updated, it is most
- vulnerable to corruption during system restarts. It can also
- become full of expired RR data. In either case, it can easily
- be discarded without disturbing zone data.
-
-A major aspect of database design is selecting a structure which allows
-the name server to deal with crashes of the name server's host. State
-information which a name server should save across system crashes
-
-
-
-Mockapetris [Page 38]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-includes the catalog structure (including the state of refreshing for
-each zone) and the zone data itself.
-
-6.1.3. Time
-
-Both the TTL data for RRs and the timing data for refreshing activities
-depends on 32 bit timers in units of seconds. Inside the database,
-refresh timers and TTLs for cached data conceptually "count down", while
-data in the zone stays with constant TTLs.
-
-A recommended implementation strategy is to store time in two ways: as
-a relative increment and as an absolute time. One way to do this is to
-use positive 32 bit numbers for one type and negative numbers for the
-other. The RRs in zones use relative times; the refresh timers and
-cache data use absolute times. Absolute numbers are taken with respect
-to some known origin and converted to relative values when placed in the
-response to a query. When an absolute TTL is negative after conversion
-to relative, then the data is expired and should be ignored.
-
-6.2. Standard query processing
-
-The major algorithm for standard query processing is presented in
-[RFC-1034].
-
-When processing queries with QCLASS=*, or some other QCLASS which
-matches multiple classes, the response should never be authoritative
-unless the server can guarantee that the response covers all classes.
-
-When composing a response, RRs which are to be inserted in the
-additional section, but duplicate RRs in the answer or authority
-sections, may be omitted from the additional section.
-
-When a response is so long that truncation is required, the truncation
-should start at the end of the response and work forward in the
-datagram. Thus if there is any data for the authority section, the
-answer section is guaranteed to be unique.
-
-The MINIMUM value in the SOA should be used to set a floor on the TTL of
-data distributed from a zone. This floor function should be done when
-the data is copied into a response. This will allow future dynamic
-update protocols to change the SOA MINIMUM field without ambiguous
-semantics.
-
-6.3. Zone refresh and reload processing
-
-In spite of a server's best efforts, it may be unable to load zone data
-from a master file due to syntax errors, etc., or be unable to refresh a
-zone within the its expiration parameter. In this case, the name server
-
-
-
-Mockapetris [Page 39]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-should answer queries as if it were not supposed to possess the zone.
-
-If a master is sending a zone out via AXFR, and a new version is created
-during the transfer, the master should continue to send the old version
-if possible. In any case, it should never send part of one version and
-part of another. If completion is not possible, the master should reset
-the connection on which the zone transfer is taking place.
-
-6.4. Inverse queries (Optional)
-
-Inverse queries are an optional part of the DNS. Name servers are not
-required to support any form of inverse queries. If a name server
-receives an inverse query that it does not support, it returns an error
-response with the "Not Implemented" error set in the header. While
-inverse query support is optional, all name servers must be at least
-able to return the error response.
-
-6.4.1. The contents of inverse queries and responses Inverse
-queries reverse the mappings performed by standard query operations;
-while a standard query maps a domain name to a resource, an inverse
-query maps a resource to a domain name. For example, a standard query
-might bind a domain name to a host address; the corresponding inverse
-query binds the host address to a domain name.
-
-Inverse queries take the form of a single RR in the answer section of
-the message, with an empty question section. The owner name of the
-query RR and its TTL are not significant. The response carries
-questions in the question section which identify all names possessing
-the query RR WHICH THE NAME SERVER KNOWS. Since no name server knows
-about all of the domain name space, the response can never be assumed to
-be complete. Thus inverse queries are primarily useful for database
-management and debugging activities. Inverse queries are NOT an
-acceptable method of mapping host addresses to host names; use the IN-
-ADDR.ARPA domain instead.
-
-Where possible, name servers should provide case-insensitive comparisons
-for inverse queries. Thus an inverse query asking for an MX RR of
-"Venera.isi.edu" should get the same response as a query for
-"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
-produce the same result as an inverse query for "IBM-pc unix". However,
-this cannot be guaranteed because name servers may possess RRs that
-contain character strings but the name server does not know that the
-data is character.
-
-When a name server processes an inverse query, it either returns:
-
- 1. zero, one, or multiple domain names for the specified
- resource as QNAMEs in the question section
-
-
-
-Mockapetris [Page 40]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 2. an error code indicating that the name server doesn't support
- inverse mapping of the specified resource type.
-
-When the response to an inverse query contains one or more QNAMEs, the
-owner name and TTL of the RR in the answer section which defines the
-inverse query is modified to exactly match an RR found at the first
-QNAME.
-
-RRs returned in the inverse queries cannot be cached using the same
-mechanism as is used for the replies to standard queries. One reason
-for this is that a name might have multiple RRs of the same type, and
-only one would appear. For example, an inverse query for a single
-address of a multiply homed host might create the impression that only
-one address existed.
-
-6.4.2. Inverse query and response example The overall structure
-of an inverse query for retrieving the domain name that corresponds to
-Internet address 10.1.0.52 is shown below:
-
- +-----------------------------------------+
- Header | OPCODE=IQUERY, ID=997 |
- +-----------------------------------------+
- Question | <empty> |
- +-----------------------------------------+
- Answer | <anyname> A IN 10.1.0.52 |
- +-----------------------------------------+
- Authority | <empty> |
- +-----------------------------------------+
- Additional | <empty> |
- +-----------------------------------------+
-
-This query asks for a question whose answer is the Internet style
-address 10.1.0.52. Since the owner name is not known, any domain name
-can be used as a placeholder (and is ignored). A single octet of zero,
-signifying the root, is usually used because it minimizes the length of
-the message. The TTL of the RR is not significant. The response to
-this query might be:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 41]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- +-----------------------------------------+
- Header | OPCODE=RESPONSE, ID=997 |
- +-----------------------------------------+
- Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
- +-----------------------------------------+
- Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
- +-----------------------------------------+
- Authority | <empty> |
- +-----------------------------------------+
- Additional | <empty> |
- +-----------------------------------------+
-
-Note that the QTYPE in a response to an inverse query is the same as the
-TYPE field in the answer section of the inverse query. Responses to
-inverse queries may contain multiple questions when the inverse is not
-unique. If the question section in the response is not empty, then the
-RR in the answer section is modified to correspond to be an exact copy
-of an RR at the first QNAME.
-
-6.4.3. Inverse query processing
-
-Name servers that support inverse queries can support these operations
-through exhaustive searches of their databases, but this becomes
-impractical as the size of the database increases. An alternative
-approach is to invert the database according to the search key.
-
-For name servers that support multiple zones and a large amount of data,
-the recommended approach is separate inversions for each zone. When a
-particular zone is changed during a refresh, only its inversions need to
-be redone.
-
-Support for transfer of this type of inversion may be included in future
-versions of the domain system, but is not supported in this version.
-
-6.5. Completion queries and responses
-
-The optional completion services described in RFC-882 and RFC-883 have
-been deleted. Redesigned services may become available in the future.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 42]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-7. RESOLVER IMPLEMENTATION
-
-The top levels of the recommended resolver algorithm are discussed in
-[RFC-1034]. This section discusses implementation details assuming the
-database structure suggested in the name server implementation section
-of this memo.
-
-7.1. Transforming a user request into a query
-
-The first step a resolver takes is to transform the client's request,
-stated in a format suitable to the local OS, into a search specification
-for RRs at a specific name which match a specific QTYPE and QCLASS.
-Where possible, the QTYPE and QCLASS should correspond to a single type
-and a single class, because this makes the use of cached data much
-simpler. The reason for this is that the presence of data of one type
-in a cache doesn't confirm the existence or non-existence of data of
-other types, hence the only way to be sure is to consult an
-authoritative source. If QCLASS=* is used, then authoritative answers
-won't be available.
-
-Since a resolver must be able to multiplex multiple requests if it is to
-perform its function efficiently, each pending request is usually
-represented in some block of state information. This state block will
-typically contain:
-
- - A timestamp indicating the time the request began.
- The timestamp is used to decide whether RRs in the database
- can be used or are out of date. This timestamp uses the
- absolute time format previously discussed for RR storage in
- zones and caches. Note that when an RRs TTL indicates a
- relative time, the RR must be timely, since it is part of a
- zone. When the RR has an absolute time, it is part of a
- cache, and the TTL of the RR is compared against the timestamp
- for the start of the request.
-
- Note that using the timestamp is superior to using a current
- time, since it allows RRs with TTLs of zero to be entered in
- the cache in the usual manner, but still used by the current
- request, even after intervals of many seconds due to system
- load, query retransmission timeouts, etc.
-
- - Some sort of parameters to limit the amount of work which will
- be performed for this request.
-
- The amount of work which a resolver will do in response to a
- client request must be limited to guard against errors in the
- database, such as circular CNAME references, and operational
- problems, such as network partition which prevents the
-
-
-
-Mockapetris [Page 43]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- resolver from accessing the name servers it needs. While
- local limits on the number of times a resolver will retransmit
- a particular query to a particular name server address are
- essential, the resolver should have a global per-request
- counter to limit work on a single request. The counter should
- be set to some initial value and decremented whenever the
- resolver performs any action (retransmission timeout,
- retransmission, etc.) If the counter passes zero, the request
- is terminated with a temporary error.
-
- Note that if the resolver structure allows one request to
- start others in parallel, such as when the need to access a
- name server for one request causes a parallel resolve for the
- name server's addresses, the spawned request should be started
- with a lower counter. This prevents circular references in
- the database from starting a chain reaction of resolver
- activity.
-
- - The SLIST data structure discussed in [RFC-1034].
-
- This structure keeps track of the state of a request if it
- must wait for answers from foreign name servers.
-
-7.2. Sending the queries
-
-As described in [RFC-1034], the basic task of the resolver is to
-formulate a query which will answer the client's request and direct that
-query to name servers which can provide the information. The resolver
-will usually only have very strong hints about which servers to ask, in
-the form of NS RRs, and may have to revise the query, in response to
-CNAMEs, or revise the set of name servers the resolver is asking, in
-response to delegation responses which point the resolver to name
-servers closer to the desired information. In addition to the
-information requested by the client, the resolver may have to call upon
-its own services to determine the address of name servers it wishes to
-contact.
-
-In any case, the model used in this memo assumes that the resolver is
-multiplexing attention between multiple requests, some from the client,
-and some internally generated. Each request is represented by some
-state information, and the desired behavior is that the resolver
-transmit queries to name servers in a way that maximizes the probability
-that the request is answered, minimizes the time that the request takes,
-and avoids excessive transmissions. The key algorithm uses the state
-information of the request to select the next name server address to
-query, and also computes a timeout which will cause the next action
-should a response not arrive. The next action will usually be a
-transmission to some other server, but may be a temporary error to the
-
-
-
-Mockapetris [Page 44]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-client.
-
-The resolver always starts with a list of server names to query (SLIST).
-This list will be all NS RRs which correspond to the nearest ancestor
-zone that the resolver knows about. To avoid startup problems, the
-resolver should have a set of default servers which it will ask should
-it have no current NS RRs which are appropriate. The resolver then adds
-to SLIST all of the known addresses for the name servers, and may start
-parallel requests to acquire the addresses of the servers when the
-resolver has the name, but no addresses, for the name servers.
-
-To complete initialization of SLIST, the resolver attaches whatever
-history information it has to the each address in SLIST. This will
-usually consist of some sort of weighted averages for the response time
-of the address, and the batting average of the address (i.e., how often
-the address responded at all to the request). Note that this
-information should be kept on a per address basis, rather than on a per
-name server basis, because the response time and batting average of a
-particular server may vary considerably from address to address. Note
-also that this information is actually specific to a resolver address /
-server address pair, so a resolver with multiple addresses may wish to
-keep separate histories for each of its addresses. Part of this step
-must deal with addresses which have no such history; in this case an
-expected round trip time of 5-10 seconds should be the worst case, with
-lower estimates for the same local network, etc.
-
-Note that whenever a delegation is followed, the resolver algorithm
-reinitializes SLIST.
-
-The information establishes a partial ranking of the available name
-server addresses. Each time an address is chosen and the state should
-be altered to prevent its selection again until all other addresses have
-been tried. The timeout for each transmission should be 50-100% greater
-than the average predicted value to allow for variance in response.
-
-Some fine points:
-
- - The resolver may encounter a situation where no addresses are
- available for any of the name servers named in SLIST, and
- where the servers in the list are precisely those which would
- normally be used to look up their own addresses. This
- situation typically occurs when the glue address RRs have a
- smaller TTL than the NS RRs marking delegation, or when the
- resolver caches the result of a NS search. The resolver
- should detect this condition and restart the search at the
- next ancestor zone, or alternatively at the root.
-
-
-
-
-
-Mockapetris [Page 45]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- - If a resolver gets a server error or other bizarre response
- from a name server, it should remove it from SLIST, and may
- wish to schedule an immediate transmission to the next
- candidate server address.
-
-7.3. Processing responses
-
-The first step in processing arriving response datagrams is to parse the
-response. This procedure should include:
-
- - Check the header for reasonableness. Discard datagrams which
- are queries when responses are expected.
-
- - Parse the sections of the message, and insure that all RRs are
- correctly formatted.
-
- - As an optional step, check the TTLs of arriving data looking
- for RRs with excessively long TTLs. If a RR has an
- excessively long TTL, say greater than 1 week, either discard
- the whole response, or limit all TTLs in the response to 1
- week.
-
-The next step is to match the response to a current resolver request.
-The recommended strategy is to do a preliminary matching using the ID
-field in the domain header, and then to verify that the question section
-corresponds to the information currently desired. This requires that
-the transmission algorithm devote several bits of the domain ID field to
-a request identifier of some sort. This step has several fine points:
-
- - Some name servers send their responses from different
- addresses than the one used to receive the query. That is, a
- resolver cannot rely that a response will come from the same
- address which it sent the corresponding query to. This name
- server bug is typically encountered in UNIX systems.
-
- - If the resolver retransmits a particular request to a name
- server it should be able to use a response from any of the
- transmissions. However, if it is using the response to sample
- the round trip time to access the name server, it must be able
- to determine which transmission matches the response (and keep
- transmission times for each outgoing message), or only
- calculate round trip times based on initial transmissions.
-
- - A name server will occasionally not have a current copy of a
- zone which it should have according to some NS RRs. The
- resolver should simply remove the name server from the current
- SLIST, and continue.
-
-
-
-
-Mockapetris [Page 46]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-7.4. Using the cache
-
-In general, we expect a resolver to cache all data which it receives in
-responses since it may be useful in answering future client requests.
-However, there are several types of data which should not be cached:
-
- - When several RRs of the same type are available for a
- particular owner name, the resolver should either cache them
- all or none at all. When a response is truncated, and a
- resolver doesn't know whether it has a complete set, it should
- not cache a possibly partial set of RRs.
-
- - Cached data should never be used in preference to
- authoritative data, so if caching would cause this to happen
- the data should not be cached.
-
- - The results of an inverse query should not be cached.
-
- - The results of standard queries where the QNAME contains "*"
- labels if the data might be used to construct wildcards. The
- reason is that the cache does not necessarily contain existing
- RRs or zone boundary information which is necessary to
- restrict the application of the wildcard RRs.
-
- - RR data in responses of dubious reliability. When a resolver
- receives unsolicited responses or RR data other than that
- requested, it should discard it without caching it. The basic
- implication is that all sanity checks on a packet should be
- performed before any of it is cached.
-
-In a similar vein, when a resolver has a set of RRs for some name in a
-response, and wants to cache the RRs, it should check its cache for
-already existing RRs. Depending on the circumstances, either the data
-in the response or the cache is preferred, but the two should never be
-combined. If the data in the response is from authoritative data in the
-answer section, it is always preferred.
-
-8. MAIL SUPPORT
-
-The domain system defines a standard for mapping mailboxes into domain
-names, and two methods for using the mailbox information to derive mail
-routing information. The first method is called mail exchange binding
-and the other method is mailbox binding. The mailbox encoding standard
-and mail exchange binding are part of the DNS official protocol, and are
-the recommended method for mail routing in the Internet. Mailbox
-binding is an experimental feature which is still under development and
-subject to change.
-
-
-
-
-Mockapetris [Page 47]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-The mailbox encoding standard assumes a mailbox name of the form
-"<local-part>@<mail-domain>". While the syntax allowed in each of these
-sections varies substantially between the various mail internets, the
-preferred syntax for the ARPA Internet is given in [RFC-822].
-
-The DNS encodes the <local-part> as a single label, and encodes the
-<mail-domain> as a domain name. The single label from the <local-part>
-is prefaced to the domain name from <mail-domain> to form the domain
-name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI-
-NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the
-<local-part> contains dots or other special characters, its
-representation in a master file will require the use of backslash
-quoting to ensure that the domain name is properly encoded. For
-example, the mailbox Action.domains@ISI.EDU would be represented as
-Action\.domains.ISI.EDU.
-
-8.1. Mail exchange binding
-
-Mail exchange binding uses the <mail-domain> part of a mailbox
-specification to determine where mail should be sent. The <local-part>
-is not even consulted. [RFC-974] specifies this method in detail, and
-should be consulted before attempting to use mail exchange support.
-
-One of the advantages of this method is that it decouples mail
-destination naming from the hosts used to support mail service, at the
-cost of another layer of indirection in the lookup function. However,
-the addition layer should eliminate the need for complicated "%", "!",
-etc encodings in <local-part>.
-
-The essence of the method is that the <mail-domain> is used as a domain
-name to locate type MX RRs which list hosts willing to accept mail for
-<mail-domain>, together with preference values which rank the hosts
-according to an order specified by the administrators for <mail-domain>.
-
-In this memo, the <mail-domain> ISI.EDU is used in examples, together
-with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
-ISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would
-route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name
-VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
-addresses.
-
-8.2. Mailbox binding (Experimental)
-
-In mailbox binding, the mailer uses the entire mail destination
-specification to construct a domain name. The encoded domain name for
-the mailbox is used as the QNAME field in a QTYPE=MAILB query.
-
-Several outcomes are possible for this query:
-
-
-
-Mockapetris [Page 48]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 1. The query can return a name error indicating that the mailbox
- does not exist as a domain name.
-
- In the long term, this would indicate that the specified
- mailbox doesn't exist. However, until the use of mailbox
- binding is universal, this error condition should be
- interpreted to mean that the organization identified by the
- global part does not support mailbox binding. The
- appropriate procedure is to revert to exchange binding at
- this point.
-
- 2. The query can return a Mail Rename (MR) RR.
-
- The MR RR carries new mailbox specification in its RDATA
- field. The mailer should replace the old mailbox with the
- new one and retry the operation.
-
- 3. The query can return a MB RR.
-
- The MB RR carries a domain name for a host in its RDATA
- field. The mailer should deliver the message to that host
- via whatever protocol is applicable, e.g., b,SMTP.
-
- 4. The query can return one or more Mail Group (MG) RRs.
-
- This condition means that the mailbox was actually a mailing
- list or mail group, rather than a single mailbox. Each MG RR
- has a RDATA field that identifies a mailbox that is a member
- of the group. The mailer should deliver a copy of the
- message to each member.
-
- 5. The query can return a MB RR as well as one or more MG RRs.
-
- This condition means the the mailbox was actually a mailing
- list. The mailer can either deliver the message to the host
- specified by the MB RR, which will in turn do the delivery to
- all members, or the mailer can use the MG RRs to do the
- expansion itself.
-
-In any of these cases, the response may include a Mail Information
-(MINFO) RR. This RR is usually associated with a mail group, but is
-legal with a MB. The MINFO RR identifies two mailboxes. One of these
-identifies a responsible person for the original mailbox name. This
-mailbox should be used for requests to be added to a mail group, etc.
-The second mailbox name in the MINFO RR identifies a mailbox that should
-receive error messages for mail failures. This is particularly
-appropriate for mailing lists when errors in member names should be
-reported to a person other than the one who sends a message to the list.
-
-
-
-Mockapetris [Page 49]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-New fields may be added to this RR in the future.
-
-
-9. REFERENCES and BIBLIOGRAPHY
-
-[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena
- Technical Plan - Name Service, April 1987, version 1.9.
-
- Describes the fundamentals of the Hesiod name service.
-
-[IEN-116] J. Postel, "Internet Name Server", IEN-116,
- USC/Information Sciences Institute, August 1979.
-
- A name service obsoleted by the Domain Name System, but
- still in use.
-
-[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
- Communications of the ACM, October 1986, volume 29, number
- 10.
-
-[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
- Information Center, SRI International, December 1977.
-
-[RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
- USC/Information Sciences Institute, August 1980.
-
-[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
- USC/Information Sciences Institute, September 1981.
-
-[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
- September 1981.
-
- Suggests introduction of a hierarchy in place of a flat
- name space for the Internet.
-
-[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
- USC/Information Sciences Institute, February 1982.
-
-[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
- Internet Host Table Specification", RFC-810, Network
- Information Center, SRI International, March 1982.
-
- Obsolete. See RFC-952.
-
-[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
- Server", RFC-811, Network Information Center, SRI
- International, March 1982.
-
-
-
-
-Mockapetris [Page 50]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- Obsolete. See RFC-953.
-
-[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
- Network Information Center, SRI International, March
- 1982.
-
-[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
- Internet User Applications", RFC-819, Network
- Information Center, SRI International, August 1982.
-
- Early thoughts on the design of the domain system.
- Current implementation is completely different.
-
-[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
- USC/Information Sciences Institute, August 1980.
-
-[RFC-830] Z. Su, "A Distributed System for Internet Name Service",
- RFC-830, Network Information Center, SRI International,
- October 1982.
-
- Early thoughts on the design of the domain system.
- Current implementation is completely different.
-
-[RFC-882] P. Mockapetris, "Domain names - Concepts and
- Facilities," RFC-882, USC/Information Sciences
- Institute, November 1983.
-
- Superceeded by this memo.
-
-[RFC-883] P. Mockapetris, "Domain names - Implementation and
- Specification," RFC-883, USC/Information Sciences
- Institute, November 1983.
-
- Superceeded by this memo.
-
-[RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
- RFC-920, USC/Information Sciences Institute,
- October 1984.
-
- Explains the naming scheme for top level domains.
-
-[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
- Table Specification", RFC-952, SRI, October 1985.
-
- Specifies the format of HOSTS.TXT, the host/address
- table replaced by the DNS.
-
-
-
-
-
-Mockapetris [Page 51]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
- RFC-953, SRI, October 1985.
-
- This RFC contains the official specification of the
- hostname server protocol, which is obsoleted by the DNS.
- This TCP based protocol accesses information stored in
- the RFC-952 format, and is used to obtain copies of the
- host table.
-
-[RFC-973] P. Mockapetris, "Domain System Changes and
- Observations", RFC-973, USC/Information Sciences
- Institute, January 1986.
-
- Describes changes to RFC-882 and RFC-883 and reasons for
- them.
-
-[RFC-974] C. Partridge, "Mail routing and the domain system",
- RFC-974, CSNET CIC BBN Labs, January 1986.
-
- Describes the transition from HOSTS.TXT based mail
- addressing to the more powerful MX system used with the
- domain system.
-
-[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
- service on a TCP/UDP transport: Concepts and Methods",
- RFC-1001, March 1987.
-
- This RFC and RFC-1002 are a preliminary design for
- NETBIOS on top of TCP/IP which proposes to base NetBIOS
- name service on top of the DNS.
-
-[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
- service on a TCP/UDP transport: Detailed
- Specifications", RFC-1002, March 1987.
-
-[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
- USC/Information Sciences Institute, May 1987.
-
- Contains socket numbers and mnemonics for host names,
- operating systems, etc.
-
-[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
- November 1987.
-
- Describes a plan for converting the MILNET to the DNS.
-
-[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for
- Administrators", RFC-1032, November 1987.
-
-
-
-Mockapetris [Page 52]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- Describes the registration policies used by the NIC to
- administer the top level domains and delegate subzones.
-
-[RFC-1033] M. Lottor, "Domain Administrators Operations Guide",
- RFC-1033, November 1987.
-
- A cookbook for domain administrators.
-
-[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
- Name Server", Computer Networks, vol 6, nr 3, July 1982.
-
- Describes a name service for CSNET which is independent
- from the DNS and DNS use in the CSNET.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 53]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-Index
-
- * 13
-
- ; 33, 35
-
- <character-string> 35
- <domain-name> 34
-
- @ 35
-
- \ 35
-
- A 12
-
- Byte order 8
-
- CH 13
- Character case 9
- CLASS 11
- CNAME 12
- Completion 42
- CS 13
-
- Hesiod 13
- HINFO 12
- HS 13
-
- IN 13
- IN-ADDR.ARPA domain 22
- Inverse queries 40
-
- Mailbox names 47
- MB 12
- MD 12
- MF 12
- MG 12
- MINFO 12
- MINIMUM 20
- MR 12
- MX 12
-
- NS 12
- NULL 12
-
- Port numbers 32
- Primary server 5
- PTR 12, 18
-
-
-
-Mockapetris [Page 54]
-
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- QCLASS 13
- QTYPE 12
-
- RDATA 12
- RDLENGTH 11
-
- Secondary server 5
- SOA 12
- Stub resolvers 7
-
- TCP 32
- TXT 12
- TYPE 11
-
- UDP 32
-
- WKS 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 55]
-
diff --git a/docs/rfc/rfc1413.txt b/docs/rfc/rfc1413.txt
deleted file mode 100644
index 17ede58a2..000000000
--- a/docs/rfc/rfc1413.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. St. Johns
-Request for Comments: 1413 US Department of Defense
-Obsoletes: 931 February 1993
-
-
- Identification Protocol
-
-Status of this Memo
-
- This RFC specifies an IAB standards track protocol for the Internet
- community, and requests discussion and suggestions for improvements.
- Please refer to the current edition of the "IAB Official Protocol
- Standards" for the standardization state and status of this protocol.
- Distribution of this memo is unlimited.
-
-1. INTRODUCTION
-
- The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident
- Protocol") provides a means to determine the identity of a user of a
- particular TCP connection. Given a TCP port number pair, it returns
- a character string which identifies the owner of that connection on
- the server's system.
-
- The Identification Protocol was formerly called the Authentication
- Server Protocol. It has been renamed to better reflect its function.
- This document is a product of the TCP Client Identity Protocol
- Working Group of the Internet Engineering Task Force (IETF).
-
-2. OVERVIEW
-
- This is a connection based application on TCP. A server listens for
- TCP connections on TCP port 113 (decimal). Once a connection is
- established, the server reads a line of data which specifies the
- connection of interest. If it exists, the system dependent user
- identifier of the connection of interest is sent as the reply. The
- server may then either shut the connection down or it may continue to
- read/respond to multiple queries.
-
- The server should close the connection down after a configurable
- amount of time with no queries - a 60-180 second idle timeout is
- recommended. The client may close the connection down at any time;
- however to allow for network delays the client should wait at least
- 30 seconds (or longer) after a query before abandoning the query and
- closing the connection.
-
-
-
-
-
-
-
-St. Johns [Page 1]
-
-RFC 1413 Identification Protocol February 1993
-
-
-3. RESTRICTIONS
-
- Queries are permitted only for fully specified connections. The
- query contains the local/foreign port pair -- the local/foreign
- address pair used to fully specify the connection is taken from the
- local and foreign address of query connection. This means a user on
- address A may only query the server on address B about connections
- between A and B.
-
-4. QUERY/RESPONSE FORMAT
-
- The server accepts simple text query requests of the form:
-
- <port-on-server> , <port-on-client>
-
- where <port-on-server> is the TCP port (decimal) on the target (where
- the "ident" server is running) system, and <port-on-client> is the
- TCP port (decimal) on the source (client) system.
-
- N.B - If a client on host A wants to ask a server on host B about a
- connection specified locally (on the client's machine) as 23, 6191
- (an inbound TELNET connection), the client must actually ask about
- 6191, 23 - which is how the connection would be specified on host B.
-
- For example:
-
- 6191, 23
-
- The response is of the form
-
- <port-on-server> , <port-on-client> : <resp-type> : <add-info>
-
- where <port-on-server>,<port-on-client> are the same pair as the
- query, <resp-type> is a keyword identifying the type of response, and
- <add-info> is context dependent.
-
- The information returned is that associated with the fully specified
- TCP connection identified by <server-address>, <client-address>,
- <port-on-server>, <port-on-client>, where <server-address> and
- <client-address> are the local and foreign IP addresses of the
- querying connection -- i.e., the TCP connection to the Identification
- Protocol Server. (<port-on-server> and <port-on-client> are taken
- from the query.)
-
- For example:
-
- 6193, 23 : USERID : UNIX : stjohns
- 6195, 23 : ERROR : NO-USER
-
-
-
-St. Johns [Page 2]
-
-RFC 1413 Identification Protocol February 1993
-
-
-5. RESPONSE TYPES
-
-A response can be one of two types:
-
-USERID
-
- In this case, <add-info> is a string consisting of an
- operating system name (with an optional character set
- identifier), followed by ":", followed by an
- identification string.
-
- The character set (if present) is separated from the
- operating system name by ",". The character set
- identifier is used to indicate the character set of the
- identification string. The character set identifier,
- if omitted, defaults to "US-ASCII" (see below).
-
- Permitted operating system names and character set
- names are specified in RFC 1340, "Assigned Numbers" or
- its successors.
-
- In addition to those operating system and character set
- names specified in "Assigned Numbers" there is one
- special case operating system identifier - "OTHER".
-
- Unless "OTHER" is specified as the operating system
- type, the server is expected to return the "normal"
- user identification of the owner of this connection.
- "Normal" in this context may be taken to mean a string
- of characters which uniquely identifies the connection
- owner such as a user identifier assigned by the system
- administrator and used by such user as a mail
- identifier, or as the "user" part of a user/password
- pair used to gain access to system resources. When an
- operating system is specified (e.g., anything but
- "OTHER"), the user identifier is expected to be in a
- more or less immediately useful form - e.g., something
- that could be used as an argument to "finger" or as a
- mail address.
-
- "OTHER" indicates the identifier is an unformatted
- character string consisting of printable characters in
- the specified character set. "OTHER" should be
- specified if the user identifier does not meet the
- constraints of the previous paragraph. Sending an
- encrypted audit token, or returning other non-userid
- information about a user (such as the real name and
- phone number of a user from a UNIX passwd file) are
-
-
-
-St. Johns [Page 3]
-
-RFC 1413 Identification Protocol February 1993
-
-
- both examples of when "OTHER" should be used.
-
- Returned user identifiers are expected to be printable
- in the character set indicated.
-
- The identifier is an unformatted octet string - - all
- octets are permissible EXCEPT octal 000 (NUL), 012 (LF)
- and 015 (CR). N.B. - space characters (040) following the
- colon separator ARE part of the identifier string and
- may not be ignored. A response string is still
- terminated normally by a CR/LF. N.B. A string may be
- printable, but is not *necessarily* printable.
-
-ERROR
-
- For some reason the port owner could not be determined, <add-info>
- tells why. The following are the permitted values of <add-info> and
- their meanings:
-
- INVALID-PORT
-
- Either the local or foreign port was improperly
- specified. This should be returned if either or
- both of the port ids were out of range (TCP port
- numbers are from 1-65535), negative integers, reals or
- in any fashion not recognized as a non-negative
- integer.
-
- NO-USER
-
- The connection specified by the port pair is not
- currently in use or currently not owned by an
- identifiable entity.
-
- HIDDEN-USER
-
- The server was able to identify the user of this
- port, but the information was not returned at the
- request of the user.
-
- UNKNOWN-ERROR
-
- Can't determine connection owner; reason unknown.
- Any error not covered above should return this
- error code value. Optionally, this code MAY be
- returned in lieu of any other specific error code
- if, for example, the server desires to hide
- information implied by the return of that error
-
-
-
-St. Johns [Page 4]
-
-RFC 1413 Identification Protocol February 1993
-
-
- code, or for any other reason. If a server
- implements such a feature, it MUST be configurable
- and it MUST default to returning the proper error
- message.
-
- Other values may eventually be specified and defined in future
- revisions to this document. If an implementer has a need to specify
- a non-standard error code, that code must begin with "X".
-
- In addition, the server is allowed to drop the query connection
- without responding. Any premature close (i.e., one where the client
- does not receive the EOL, whether graceful or an abort should be
- considered to have the same meaning as "ERROR : UNKNOWN-ERROR".
-
-FORMAL SYNTAX
-
- <request> ::= <port-pair> <EOL>
-
- <port-pair> ::= <integer> "," <integer>
-
- <reply> ::= <reply-text> <EOL>
-
- <EOL> ::= "015 012" ; CR-LF End of Line Indicator
-
- <reply-text> ::= <error-reply> | <ident-reply>
-
- <error-reply> ::= <port-pair> ":" "ERROR" ":" <error-type>
-
- <ident-reply> ::= <port-pair> ":" "USERID" ":" <opsys-field>
- ":" <user-id>
-
- <error-type> ::= "INVALID-PORT" | "NO-USER" | "UNKNOWN-ERROR"
- | "HIDDEN-USER" | <error-token>
-
- <opsys-field> ::= <opsys> [ "," <charset>]
-
- <opsys> ::= "OTHER" | "UNIX" | <token> ...etc.
- ; (See "Assigned Numbers")
-
- <charset> ::= "US-ASCII" | ...etc.
- ; (See "Assigned Numbers")
-
- <user-id> ::= <octet-string>
-
- <token> ::= 1*64<token-characters> ; 1-64 characters
-
- <error-token> ::= "X"1*63<token-characters>
- ; 2-64 chars beginning w/X
-
-
-
-St. Johns [Page 5]
-
-RFC 1413 Identification Protocol February 1993
-
-
- <integer> ::= 1*5<digit> ; 1-5 digits.
-
- <digit> ::= "0" | "1" ... "8" | "9" ; 0-9
-
- <token-characters> ::=
- <Any of these ASCII characters: a-z, A-Z,
- - (dash), .!@#$%^&*()_=+.,<>/?"'~`{}[]; >
- ; upper and lowercase a-z plus
- ; printables minus the colon ":"
- ; character.
-
- <octet-string> ::= 1*512<octet-characters>
-
- <octet-characters> ::=
- <any octet from 00 to 377 (octal) except for
- ASCII NUL (000), CR (015) and LF (012)>
-
-Notes on Syntax:
-
- 1) To promote interoperability among variant
- implementations, with respect to white space the above
- syntax is understood to embody the "be conservative in
- what you send and be liberal in what you accept"
- philosophy. Clients and servers should not generate
- unnecessary white space (space and tab characters) but
- should accept white space anywhere except within a
- token. In parsing responses, white space may occur
- anywhere, except within a token. Specifically, any
- amount of white space is permitted at the beginning or
- end of a line both for queries and responses. This
- does not apply for responses that contain a user ID
- because everything after the colon after the operating
- system type until the terminating CR/LF is taken as
- part of the user ID. The terminating CR/LF is NOT
- considered part of the user ID.
-
- 2) The above notwithstanding, servers should restrict the
- amount of inter-token white space they send to the
- smallest amount reasonable or useful. Clients should
- feel free to abort a connection if they receive 1000
- characters without receiving an <EOL>.
-
- 3) The 512 character limit on user IDs and the 64
- character limit on tokens should be understood to mean
- as follows: a) No new token (i.e., OPSYS or ERROR-TYPE)
- token will be defined that has a length greater than 64
- and b) a server SHOULD NOT send more than 512 octets of
- user ID and a client MUST accept at least 512 octets of
-
-
-
-St. Johns [Page 6]
-
-RFC 1413 Identification Protocol February 1993
-
-
- user ID. Because of this limitation, a server MUST
- return the most significant portion of the user ID in
- the first 512 octets.
-
- 4) The character sets and character set identifiers should
- map directly to those defined in or referenced by RFC 1340,
- "Assigned Numbers" or its successors. Character set
- identifiers only apply to the user identification field
- - all other fields will be defined in and must be sent
- as US-ASCII.
-
- 5) Although <user-id> is defined as an <octet-string>
- above, it must follow the format and character set
- constraints implied by the <opsys-field>; see the
- discussion above.
-
- 6) The character set provides context for the client to
- print or store the returned user identification string.
- If the client does not recognize or implement the
- returned character set, it should handle the returned
- identification string as OCTET, but should in addition
- store or report the character set. An OCTET string
- should be printed, stored or handled in hex notation
- (0-9a-f) in addition to any other representation the
- client implements - this provides a standard
- representation among differing implementations.
-
-6. Security Considerations
-
- The information returned by this protocol is at most as trustworthy
- as the host providing it OR the organization operating the host. For
- example, a PC in an open lab has few if any controls on it to prevent
- a user from having this protocol return any identifier the user
- wants. Likewise, if the host has been compromised the information
- returned may be completely erroneous and misleading.
-
- The Identification Protocol is not intended as an authorization or
- access control protocol. At best, it provides some additional
- auditing information with respect to TCP connections. At worst, it
- can provide misleading, incorrect, or maliciously incorrect
- information.
-
- The use of the information returned by this protocol for other than
- auditing is strongly discouraged. Specifically, using Identification
- Protocol information to make access control decisions - either as the
- primary method (i.e., no other checks) or as an adjunct to other
- methods may result in a weakening of normal host security.
-
-
-
-
-St. Johns [Page 7]
-
-RFC 1413 Identification Protocol February 1993
-
-
- An Identification server may reveal information about users,
- entities, objects or processes which might normally be considered
- private. An Identification server provides service which is a rough
- analog of the CallerID services provided by some phone companies and
- many of the same privacy considerations and arguments that apply to
- the CallerID service apply to Identification. If you wouldn't run a
- "finger" server due to privacy considerations you may not want to run
- this protocol.
-
-7. ACKNOWLEDGEMENTS
-
- Acknowledgement is given to Dan Bernstein who is primarily
- responsible for renewing interest in this protocol and for pointing
- out some annoying errors in RFC 931.
-
-References
-
- [1] St. Johns, M., "Authentication Server", RFC 931, TPSC, January
- 1985.
-
- [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
- USC/Information Sciences Institute, July 1992.
-
-Author's Address
-
- Michael C. St. Johns
- DARPA/CSTO
- 3701 N. Fairfax Dr
- Arlington, VA 22203
-
- Phone: (703) 696-2271
- EMail: stjohns@DARPA.MIL
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-St. Johns [Page 8]
- \ No newline at end of file
diff --git a/docs/rfc/rfc1459.txt b/docs/rfc/rfc1459.txt
deleted file mode 100644
index 09fbf34f7..000000000
--- a/docs/rfc/rfc1459.txt
+++ /dev/null
@@ -1,3643 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Oikarinen
-Request for Comments: 1459 D. Reed
- May 1993
-
-
- Internet Relay Chat Protocol
-
-Status of This Memo
-
- This memo defines an Experimental Protocol for the Internet
- community. Discussion and suggestions for improvement are requested.
- Please refer to the current edition of the "IAB Official Protocol
- Standards" for the standardization state and status of this protocol.
- Distribution of this memo is unlimited.
-
-Abstract
-
- The IRC protocol was developed over the last 4 years since it was
- first implemented as a means for users on a BBS to chat amongst
- themselves. Now it supports a world-wide network of servers and
- clients, and is stringing to cope with growth. Over the past 2 years,
- the average number of users connected to the main IRC network has
- grown by a factor of 10.
-
- The IRC protocol is a text-based protocol, with the simplest client
- being any socket program capable of connecting to the server.
-
-Table of Contents
-
- 1. INTRODUCTION ............................................... 4
- 1.1 Servers ................................................ 4
- 1.2 Clients ................................................ 5
- 1.2.1 Operators .......................................... 5
- 1.3 Channels ................................................ 5
- 1.3.1 Channel Operators .................................... 6
- 2. THE IRC SPECIFICATION ....................................... 7
- 2.1 Overview ................................................ 7
- 2.2 Character codes ......................................... 7
- 2.3 Messages ................................................ 7
- 2.3.1 Message format in 'pseudo' BNF .................... 8
- 2.4 Numeric replies ......................................... 10
- 3. IRC Concepts ................................................ 10
- 3.1 One-to-one communication ................................ 10
- 3.2 One-to-many ............................................. 11
- 3.2.1 To a list .......................................... 11
- 3.2.2 To a group (channel) ............................... 11
- 3.2.3 To a host/server mask .............................. 12
- 3.3 One to all .............................................. 12
-
-
-
-Oikarinen & Reed [Page 1]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- 3.3.1 Client to Client ................................... 12
- 3.3.2 Clients to Server .................................. 12
- 3.3.3 Server to Server ................................... 12
- 4. MESSAGE DETAILS ............................................. 13
- 4.1 Connection Registration ................................. 13
- 4.1.1 Password message ................................... 14
- 4.1.2 Nickname message ................................... 14
- 4.1.3 User message ....................................... 15
- 4.1.4 Server message ..................................... 16
- 4.1.5 Operator message ................................... 17
- 4.1.6 Quit message ....................................... 17
- 4.1.7 Server Quit message ................................ 18
- 4.2 Channel operations ...................................... 19
- 4.2.1 Join message ....................................... 19
- 4.2.2 Part message ....................................... 20
- 4.2.3 Mode message ....................................... 21
- 4.2.3.1 Channel modes ................................. 21
- 4.2.3.2 User modes .................................... 22
- 4.2.4 Topic message ...................................... 23
- 4.2.5 Names message ...................................... 24
- 4.2.6 List message ....................................... 24
- 4.2.7 Invite message ..................................... 25
- 4.2.8 Kick message ....................................... 25
- 4.3 Server queries and commands ............................. 26
- 4.3.1 Version message .................................... 26
- 4.3.2 Stats message ...................................... 27
- 4.3.3 Links message ...................................... 28
- 4.3.4 Time message ....................................... 29
- 4.3.5 Connect message .................................... 29
- 4.3.6 Trace message ...................................... 30
- 4.3.7 Admin message ...................................... 31
- 4.3.8 Info message ....................................... 31
- 4.4 Sending messages ........................................ 32
- 4.4.1 Private messages ................................... 32
- 4.4.2 Notice messages .................................... 33
- 4.5 User-based queries ...................................... 33
- 4.5.1 Who query .......................................... 33
- 4.5.2 Whois query ........................................ 34
- 4.5.3 Whowas message ..................................... 35
- 4.6 Miscellaneous messages .................................. 35
- 4.6.1 Kill message ....................................... 36
- 4.6.2 Ping message ....................................... 37
- 4.6.3 Pong message ....................................... 37
- 4.6.4 Error message ...................................... 38
- 5. OPTIONAL MESSAGES ........................................... 38
- 5.1 Away message ............................................ 38
- 5.2 Rehash command .......................................... 39
- 5.3 Restart command ......................................... 39
-
-
-
-Oikarinen & Reed [Page 2]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- 5.4 Summon message .......................................... 40
- 5.5 Users message ........................................... 40
- 5.6 Operwall command ........................................ 41
- 5.7 Userhost message ........................................ 42
- 5.8 Ison message ............................................ 42
- 6. REPLIES ..................................................... 43
- 6.1 Error Replies ........................................... 43
- 6.2 Command responses ....................................... 48
- 6.3 Reserved numerics ....................................... 56
- 7. Client and server authentication ............................ 56
- 8. Current Implementations Details ............................. 56
- 8.1 Network protocol: TCP ................................... 57
- 8.1.1 Support of Unix sockets ............................ 57
- 8.2 Command Parsing ......................................... 57
- 8.3 Message delivery ........................................ 57
- 8.4 Connection 'Liveness' ................................... 58
- 8.5 Establishing a server-client connection ................. 58
- 8.6 Establishing a server-server connection ................. 58
- 8.6.1 State information exchange when connecting ......... 59
- 8.7 Terminating server-client connections ................... 59
- 8.8 Terminating server-server connections ................... 59
- 8.9 Tracking nickname changes ............................... 60
- 8.10 Flood control of clients ............................... 60
- 8.11 Non-blocking lookups ................................... 61
- 8.11.1 Hostname (DNS) lookups ............................ 61
- 8.11.2 Username (Ident) lookups .......................... 61
- 8.12 Configuration file ..................................... 61
- 8.12.1 Allowing clients to connect ....................... 62
- 8.12.2 Operators ......................................... 62
- 8.12.3 Allowing servers to connect ....................... 62
- 8.12.4 Administrivia ..................................... 63
- 8.13 Channel membership ..................................... 63
- 9. Current problems ............................................ 63
- 9.1 Scalability ............................................. 63
- 9.2 Labels .................................................. 63
- 9.2.1 Nicknames .......................................... 63
- 9.2.2 Channels ........................................... 64
- 9.2.3 Servers ............................................ 64
- 9.3 Algorithms .............................................. 64
- 10. Support and availability ................................... 64
- 11. Security Considerations .................................... 65
- 12. Authors' Addresses ......................................... 65
-
-
-
-
-
-
-
-
-
-Oikarinen & Reed [Page 3]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-1. INTRODUCTION
-
- The IRC (Internet Relay Chat) protocol has been designed over a
- number of years for use with text based conferencing. This document
- describes the current IRC protocol.
-
- The IRC protocol has been developed on systems using the TCP/IP
- network protocol, although there is no requirement that this remain
- the only sphere in which it operates.
-
- IRC itself is a teleconferencing system, which (through the use of
- the client-server model) is well-suited to running on many machines
- in a distributed fashion. A typical setup involves a single process
- (the server) forming a central point for clients (or other servers)
- to connect to, performing the required message delivery/multiplexing
- and other functions.
-
-1.1 Servers
-
- The server forms the backbone of IRC, providing a point to which
- clients may connect to to talk to each other, and a point for other
- servers to connect to, forming an IRC network. The only network
- configuration allowed for IRC servers is that of a spanning tree [see
- Fig. 1] where each server acts as a central node for the rest of the
- net it sees.
-
-
- [ Server 15 ] [ Server 13 ] [ Server 14]
- / \ /
- / \ /
- [ Server 11 ] ------ [ Server 1 ] [ Server 12]
- / \ /
- / \ /
- [ Server 2 ] [ Server 3 ]
- / \ \
- / \ \
- [ Server 4 ] [ Server 5 ] [ Server 6 ]
- / | \ /
- / | \ /
- / | \____ /
- / | \ /
- [ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ]
-
- :
- [ etc. ]
- :
-
- [ Fig. 1. Format of IRC server network ]
-
-
-
-Oikarinen & Reed [Page 4]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-1.2 Clients
-
- A client is anything connecting to a server that is not another
- server. Each client is distinguished from other clients by a unique
- nickname having a maximum length of nine (9) characters. See the
- protocol grammar rules for what may and may not be used in a
- nickname. In addition to the nickname, all servers must have the
- following information about all clients: the real name of the host
- that the client is running on, the username of the client on that
- host, and the server to which the client is connected.
-
-1.2.1 Operators
-
- To allow a reasonable amount of order to be kept within the IRC
- network, a special class of clients (operators) is allowed to perform
- general maintenance functions on the network. Although the powers
- granted to an operator can be considered as 'dangerous', they are
- nonetheless required. Operators should be able to perform basic
- network tasks such as disconnecting and reconnecting servers as
- needed to prevent long-term use of bad network routing. In
- recognition of this need, the protocol discussed herein provides for
- operators only to be able to perform such functions. See sections
- 4.1.7 (SQUIT) and 4.3.5 (CONNECT).
-
- A more controversial power of operators is the ability to remove a
- user from the connected network by 'force', i.e. operators are able
- to close the connection between any client and server. The
- justification for this is delicate since its abuse is both
- destructive and annoying. For further details on this type of
- action, see section 4.6.1 (KILL).
-
-1.3 Channels
-
- A channel is a named group of one or more clients which will all
- receive messages addressed to that channel. The channel is created
- implicitly when the first client joins it, and the channel ceases to
- exist when the last client leaves it. While channel exists, any
- client can reference the channel using the name of the channel.
-
- Channels names are strings (beginning with a '&' or '#' character) of
- length up to 200 characters. Apart from the the requirement that the
- first character being either '&' or '#'; the only restriction on a
- channel name is that it may not contain any spaces (' '), a control G
- (^G or ASCII 7), or a comma (',' which is used as a list item
- separator by the protocol).
-
- There are two types of channels allowed by this protocol. One is a
- distributed channel which is known to all the servers that are
-
-
-
-Oikarinen & Reed [Page 5]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- connected to the network. These channels are marked by the first
- character being a only clients on the server where it exists may join
- it. These are distinguished by a leading '&' character. On top of
- these two types, there are the various channel modes available to
- alter the characteristics of individual channels. See section 4.2.3
- (MODE command) for more details on this.
-
- To create a new channel or become part of an existing channel, a user
- is required to JOIN the channel. If the channel doesn't exist prior
- to joining, the channel is created and the creating user becomes a
- channel operator. If the channel already exists, whether or not your
- request to JOIN that channel is honoured depends on the current modes
- of the channel. For example, if the channel is invite-only, (+i),
- then you may only join if invited. As part of the protocol, a user
- may be a part of several channels at once, but a limit of ten (10)
- channels is recommended as being ample for both experienced and
- novice users. See section 8.13 for more information on this.
-
- If the IRC network becomes disjoint because of a split between two
- servers, the channel on each side is only composed of those clients
- which are connected to servers on the respective sides of the split,
- possibly ceasing to exist on one side of the split. When the split
- is healed, the connecting servers announce to each other who they
- think is in each channel and the mode of that channel. If the
- channel exists on both sides, the JOINs and MODEs are interpreted in
- an inclusive manner so that both sides of the new connection will
- agree about which clients are in the channel and what modes the
- channel has.
-
-1.3.1 Channel Operators
-
- The channel operator (also referred to as a "chop" or "chanop") on a
- given channel is considered to 'own' that channel. In recognition of
- this status, channel operators are endowed with certain powers which
- enable them to keep control and some sort of sanity in their channel.
- As an owner of a channel, a channel operator is not required to have
- reasons for their actions, although if their actions are generally
- antisocial or otherwise abusive, it might be reasonable to ask an IRC
- operator to intervene, or for the usersjust leave and go elsewhere
- and form their own channel.
-
- The commands which may only be used by channel operators are:
-
- KICK - Eject a client from the channel
- MODE - Change the channel's mode
- INVITE - Invite a client to an invite-only channel (mode +i)
- TOPIC - Change the channel topic in a mode +t channel
-
-
-
-
-Oikarinen & Reed [Page 6]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- A channel operator is identified by the '@' symbol next to their
- nickname whenever it is associated with a channel (ie replies to the
- NAMES, WHO and WHOIS commands).
-
-2. The IRC Specification
-
-2.1 Overview
-
- The protocol as described herein is for use both with server to
- server and client to server connections. There are, however, more
- restrictions on client connections (which are considered to be
- untrustworthy) than on server connections.
-
-2.2 Character codes
-
- No specific character set is specified. The protocol is based on a a
- set of codes which are composed of eight (8) bits, making up an
- octet. Each message may be composed of any number of these octets;
- however, some octet values are used for control codes which act as
- message delimiters.
-
- Regardless of being an 8-bit protocol, the delimiters and keywords
- are such that protocol is mostly usable from USASCII terminal and a
- telnet connection.
-
- Because of IRC's scandanavian origin, the characters {}| are
- considered to be the lower case equivalents of the characters []\,
- respectively. This is a critical issue when determining the
- equivalence of two nicknames.
-
-2.3 Messages
-
- Servers and clients send eachother messages which may or may not
- generate a reply. If the message contains a valid command, as
- described in later sections, the client should expect a reply as
- specified but it is not advised to wait forever for the reply; client
- to server and server to server communication is essentially
- asynchronous in nature.
-
- Each IRC message may consist of up to three main parts: the prefix
- (optional), the command, and the command parameters (of which there
- may be up to 15). The prefix, command, and all parameters are
- separated by one (or more) ASCII space character(s) (0x20).
-
- The presence of a prefix is indicated with a single leading ASCII
- colon character (':', 0x3b), which must be the first character of the
- message itself. There must be no gap (whitespace) between the colon
- and the prefix. The prefix is used by servers to indicate the true
-
-
-
-Oikarinen & Reed [Page 7]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- origin of the message. If the prefix is missing from the message, it
- is assumed to have originated from the connection from which it was
- received. Clients should not use prefix when sending a message from
- themselves; if they use a prefix, the only valid prefix is the
- registered nickname associated with the client. If the source
- identified by the prefix cannot be found from the server's internal
- database, or if the source is registered from a different link than
- from which the message arrived, the server must ignore the message
- silently.
-
- The command must either be a valid IRC command or a three (3) digit
- number represented in ASCII text.
-
- IRC messages are always lines of characters terminated with a CR-LF
- (Carriage Return - Line Feed) pair, and these messages shall not
- exceed 512 characters in length, counting all characters including
- the trailing CR-LF. Thus, there are 510 characters maximum allowed
- for the command and its parameters. There is no provision for
- continuation message lines. See section 7 for more details about
- current implementations.
-
-2.3.1 Message format in 'pseudo' BNF
-
- The protocol messages must be extracted from the contiguous stream of
- octets. The current solution is to designate two characters, CR and
- LF, as message separators. Empty messages are silently ignored,
- which permits use of the sequence CR-LF between messages
- without extra problems.
-
- The extracted message is parsed into the components <prefix>,
- <command> and list of parameters matched either by <middle> or
- <trailing> components.
-
- The BNF representation for this is:
-
-
-<message> ::= [':' <prefix> <SPACE> ] <command> <params> <crlf>
-<prefix> ::= <servername> | <nick> [ '!' <user> ] [ '@' <host> ]
-<command> ::= <letter> { <letter> } | <number> <number> <number>
-<SPACE> ::= ' ' { ' ' }
-<params> ::= <SPACE> [ ':' <trailing> | <middle> <params> ]
-
-<middle> ::= <Any *non-empty* sequence of octets not including SPACE
- or NUL or CR or LF, the first of which may not be ':'>
-<trailing> ::= <Any, possibly *empty*, sequence of octets not including
- NUL or CR or LF>
-
-<crlf> ::= CR LF
-
-
-
-Oikarinen & Reed [Page 8]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-NOTES:
-
- 1) <SPACE> is consists only of SPACE character(s) (0x20).
- Specially notice that TABULATION, and all other control
- characters are considered NON-WHITE-SPACE.
-
- 2) After extracting the parameter list, all parameters are equal,
- whether matched by <middle> or <trailing>. <Trailing> is just
- a syntactic trick to allow SPACE within parameter.
-
- 3) The fact that CR and LF cannot appear in parameter strings is
- just artifact of the message framing. This might change later.
-
- 4) The NUL character is not special in message framing, and
- basically could end up inside a parameter, but as it would
- cause extra complexities in normal C string handling. Therefore
- NUL is not allowed within messages.
-
- 5) The last parameter may be an empty string.
-
- 6) Use of the extended prefix (['!' <user> ] ['@' <host> ]) must
- not be used in server to server communications and is only
- intended for server to client messages in order to provide
- clients with more useful information about who a message is
- from without the need for additional queries.
-
- Most protocol messages specify additional semantics and syntax for
- the extracted parameter strings dictated by their position in the
- list. For example, many server commands will assume that the first
- parameter after the command is the list of targets, which can be
- described with:
-
- <target> ::= <to> [ "," <target> ]
- <to> ::= <channel> | <user> '@' <servername> | <nick> | <mask>
- <channel> ::= ('#' | '&') <chstring>
- <servername> ::= <host>
- <host> ::= see RFC 952 [DNS:4] for details on allowed hostnames
- <nick> ::= <letter> { <letter> | <number> | <special> }
- <mask> ::= ('#' | '$') <chstring>
- <chstring> ::= <any 8bit code except SPACE, BELL, NUL, CR, LF and
- comma (',')>
-
- Other parameter syntaxes are:
-
- <user> ::= <nonwhite> { <nonwhite> }
- <letter> ::= 'a' ... 'z' | 'A' ... 'Z'
- <number> ::= '0' ... '9'
- <special> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'
-
-
-
-Oikarinen & Reed [Page 9]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- <nonwhite> ::= <any 8bit code except SPACE (0x20), NUL (0x0), CR
- (0xd), and LF (0xa)>
-
-2.4 Numeric replies
-
- Most of the messages sent to the server generate a reply of some
- sort. The most common reply is the numeric reply, used for both
- errors and normal replies. The numeric reply must be sent as one
- message consisting of the sender prefix, the three digit numeric, and
- the target of the reply. A numeric reply is not allowed to originate
- from a client; any such messages received by a server are silently
- dropped. In all other respects, a numeric reply is just like a normal
- message, except that the keyword is made up of 3 numeric digits
- rather than a string of letters. A list of different replies is
- supplied in section 6.
-
-3. IRC Concepts.
-
- This section is devoted to describing the actual concepts behind the
- organization of the IRC protocol and how the current
- implementations deliver different classes of messages.
-
-
-
- 1--\
- A D---4
- 2--/ \ /
- B----C
- / \
- 3 E
-
- Servers: A, B, C, D, E Clients: 1, 2, 3, 4
-
- [ Fig. 2. Sample small IRC network ]
-
-3.1 One-to-one communication
-
- Communication on a one-to-one basis is usually only performed by
- clients, since most server-server traffic is not a result of servers
- talking only to each other. To provide a secure means for clients to
- talk to each other, it is required that all servers be able to send a
- message in exactly one direction along the spanning tree in order to
- reach any client. The path of a message being delivered is the
- shortest path between any two points on the spanning tree.
-
- The following examples all refer to Figure 2 above.
-
-
-
-
-
-Oikarinen & Reed [Page 10]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-Example 1:
- A message between clients 1 and 2 is only seen by server A, which
- sends it straight to client 2.
-
-Example 2:
- A message between clients 1 and 3 is seen by servers A & B, and
- client 3. No other clients or servers are allowed see the message.
-
-Example 3:
- A message between clients 2 and 4 is seen by servers A, B, C & D
- and client 4 only.
-
-3.2 One-to-many
-
- The main goal of IRC is to provide a forum which allows easy and
- efficient conferencing (one to many conversations). IRC offers
- several means to achieve this, each serving its own purpose.
-
-3.2.1 To a list
-
- The least efficient style of one-to-many conversation is through
- clients talking to a 'list' of users. How this is done is almost
- self explanatory: the client gives a list of destinations to which
- the message is to be delivered and the server breaks it up and
- dispatches a separate copy of the message to each given destination.
- This isn't as efficient as using a group since the destination list
- is broken up and the dispatch sent without checking to make sure
- duplicates aren't sent down each path.
-
-3.2.2 To a group (channel)
-
- In IRC the channel has a role equivalent to that of the multicast
- group; their existence is dynamic (coming and going as people join
- and leave channels) and the actual conversation carried out on a
- channel is only sent to servers which are supporting users on a given
- channel. If there are multiple users on a server in the same
- channel, the message text is sent only once to that server and then
- sent to each client on the channel. This action is then repeated for
- each client-server combination until the original message has fanned
- out and reached each member of the channel.
-
- The following examples all refer to Figure 2.
-
-Example 4:
- Any channel with 1 client in it. Messages to the channel go to the
- server and then nowhere else.
-
-
-
-
-
-Oikarinen & Reed [Page 11]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-Example 5:
- 2 clients in a channel. All messages traverse a path as if they
- were private messages between the two clients outside a channel.
-
-Example 6:
- Clients 1, 2 and 3 in a channel. All messages to the channel are
- sent to all clients and only those servers which must be traversed
- by the message if it were a private message to a single client. If
- client 1 sends a message, it goes back to client 2 and then via
- server B to client 3.
-
-3.2.3 To a host/server mask
-
- To provide IRC operators with some mechanism to send messages to a
- large body of related users, host and server mask messages are
- provided. These messages are sent to users whose host or server
- information match that of the mask. The messages are only sent to
- locations where users are, in a fashion similar to that of channels.
-
-3.3 One-to-all
-
- The one-to-all type of message is better described as a broadcast
- message, sent to all clients or servers or both. On a large network
- of users and servers, a single message can result in a lot of traffic
- being sent over the network in an effort to reach all of the desired
- destinations.
-
- For some messages, there is no option but to broadcast it to all
- servers so that the state information held by each server is
- reasonably consistent between servers.
-
-3.3.1 Client-to-Client
-
- There is no class of message which, from a single message, results in
- a message being sent to every other client.
-
-3.3.2 Client-to-Server
-
- Most of the commands which result in a change of state information
- (such as channel membership, channel mode, user status, etc) must be
- sent to all servers by default, and this distribution may not be
- changed by the client.
-
-3.3.3 Server-to-Server.
-
- While most messages between servers are distributed to all 'other'
- servers, this is only required for any message that affects either a
- user, channel or server. Since these are the basic items found in
-
-
-
-Oikarinen & Reed [Page 12]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- IRC, nearly all messages originating from a server are broadcast to
- all other connected servers.
-
-4. Message details
-
- On the following pages are descriptions of each message recognized by
- the IRC server and client. All commands described in this section
- must be implemented by any server for this protocol.
-
- Where the reply ERR_NOSUCHSERVER is listed, it means that the
- <server> parameter could not be found. The server must not send any
- other replies after this for that command.
-
- The server to which a client is connected is required to parse the
- complete message, returning any appropriate errors. If the server
- encounters a fatal error while parsing a message, an error must be
- sent back to the client and the parsing terminated. A fatal error
- may be considered to be incorrect command, a destination which is
- otherwise unknown to the server (server, nick or channel names fit
- this category), not enough parameters or incorrect privileges.
-
- If a full set of parameters is presented, then each must be checked
- for validity and appropriate responses sent back to the client. In
- the case of messages which use parameter lists using the comma as an
- item separator, a reply must be sent for each item.
-
- In the examples below, some messages appear using the full format:
-
- :Name COMMAND parameter list
-
- Such examples represent a message from "Name" in transit between
- servers, where it is essential to include the name of the original
- sender of the message so remote servers may send back a reply along
- the correct path.
-
-4.1 Connection Registration
-
- The commands described here are used to register a connection with an
- IRC server as either a user or a server as well as correctly
- disconnect.
-
- A "PASS" command is not required for either client or server
- connection to be registered, but it must precede the server message
- or the latter of the NICK/USER combination. It is strongly
- recommended that all server connections have a password in order to
- give some level of security to the actual connections. The
- recommended order for a client to register is as follows:
-
-
-
-
-Oikarinen & Reed [Page 13]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- 1. Pass message
- 2. Nick message
- 3. User message
-
-4.1.1 Password message
-
-
- Command: PASS
- Parameters: <password>
-
- The PASS command is used to set a 'connection password'. The
- password can and must be set before any attempt to register the
- connection is made. Currently this requires that clients send a PASS
- command before sending the NICK/USER combination and servers *must*
- send a PASS command before any SERVER command. The password supplied
- must match the one contained in the C/N lines (for servers) or I
- lines (for clients). It is possible to send multiple PASS commands
- before registering but only the last one sent is used for
- verification and it may not be changed once registered. Numeric
- Replies:
-
- ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
-
- Example:
-
- PASS secretpasswordhere
-
-4.1.2 Nick message
-
- Command: NICK
- Parameters: <nickname> [ <hopcount> ]
-
- NICK message is used to give user a nickname or change the previous
- one. The <hopcount> parameter is only used by servers to indicate
- how far away a nick is from its home server. A local connection has
- a hopcount of 0. If supplied by a client, it must be ignored.
-
- If a NICK message arrives at a server which already knows about an
- identical nickname for another client, a nickname collision occurs.
- As a result of a nickname collision, all instances of the nickname
- are removed from the server's database, and a KILL command is issued
- to remove the nickname from all other server's database. If the NICK
- message causing the collision was a nickname change, then the
- original (old) nick must be removed as well.
-
- If the server recieves an identical NICK from a client which is
- directly connected, it may issue an ERR_NICKCOLLISION to the local
- client, drop the NICK command, and not generate any kills.
-
-
-
-Oikarinen & Reed [Page 14]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- Numeric Replies:
-
- ERR_NONICKNAMEGIVEN ERR_ERRONEUSNICKNAME
- ERR_NICKNAMEINUSE ERR_NICKCOLLISION
-
- Example:
-
- NICK Wiz ; Introducing new nick "Wiz".
-
- :WiZ NICK Kilroy ; WiZ changed his nickname to Kilroy.
-
-4.1.3 User message
-
- Command: USER
- Parameters: <username> <hostname> <servername> <realname>
-
- The USER message is used at the beginning of connection to specify
- the username, hostname, servername and realname of s new user. It is
- also used in communication between servers to indicate new user
- arriving on IRC, since only after both USER and NICK have been
- received from a client does a user become registered.
-
- Between servers USER must to be prefixed with client's NICKname.
- Note that hostname and servername are normally ignored by the IRC
- server when the USER command comes from a directly connected client
- (for security reasons), but they are used in server to server
- communication. This means that a NICK must always be sent to a
- remote server when a new user is being introduced to the rest of the
- network before the accompanying USER is sent.
-
- It must be noted that realname parameter must be the last parameter,
- because it may contain space characters and must be prefixed with a
- colon (':') to make sure this is recognised as such.
-
- Since it is easy for a client to lie about its username by relying
- solely on the USER message, the use of an "Identity Server" is
- recommended. If the host which a user connects from has such a
- server enabled the username is set to that as in the reply from the
- "Identity Server".
-
- Numeric Replies:
-
- ERR_NEEDMOREPARAMS ERR_ALREADYREGISTRED
-
- Examples:
-
-
- USER guest tolmoon tolsun :Ronnie Reagan
-
-
-
-Oikarinen & Reed [Page 15]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- ; User registering themselves with a
- username of "guest" and real name
- "Ronnie Reagan".
-
-
- :testnick USER guest tolmoon tolsun :Ronnie Reagan
- ; message between servers with the
- nickname for which the USER command
- belongs to
-
-4.1.4 Server message
-
- Command: SERVER
- Parameters: <servername> <hopcount> <info>
-
- The server message is used to tell a server that the other end of a
- new connection is a server. This message is also used to pass server
- data over whole net. When a new server is connected to net,
- information about it be broadcast to the whole network. <hopcount>
- is used to give all servers some internal information on how far away
- all servers are. With a full server list, it would be possible to
- construct a map of the entire server tree, but hostmasks prevent this
- from being done.
-
- The SERVER message must only be accepted from either (a) a connection
- which is yet to be registered and is attempting to register as a
- server, or (b) an existing connection to another server, in which
- case the SERVER message is introducing a new server behind that
- server.
-
- Most errors that occur with the receipt of a SERVER command result in
- the connection being terminated by the destination host (target
- SERVER). Error replies are usually sent using the "ERROR" command
- rather than the numeric since the ERROR command has several useful
- properties which make it useful here.
-
- If a SERVER message is parsed and attempts to introduce a server
- which is already known to the receiving server, the connection from
- which that message must be closed (following the correct procedures),
- since a duplicate route to a server has formed and the acyclic nature
- of the IRC tree broken.
-
- Numeric Replies:
-
- ERR_ALREADYREGISTRED
-
- Example:
-
-
-
-
-Oikarinen & Reed [Page 16]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server
- ; New server test.oulu.fi introducing
- itself and attempting to register. The
- name in []'s is the hostname for the
- host running test.oulu.fi.
-
-
-:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
- ; Server tolsun.oulu.fi is our uplink
- for csd.bu.edu which is 5 hops away.
-
-4.1.5 Oper
-
- Command: OPER
- Parameters: <user> <password>
-
- OPER message is used by a normal user to obtain operator privileges.
- The combination of <user> and <password> are required to gain
- Operator privileges.
-
- If the client sending the OPER command supplies the correct password
- for the given user, the server then informs the rest of the network
- of the new operator by issuing a "MODE +o" for the clients nickname.
-
- The OPER message is client-server only.
-
- Numeric Replies:
-
- ERR_NEEDMOREPARAMS RPL_YOUREOPER
- ERR_NOOPERHOST ERR_PASSWDMISMATCH
-
- Example:
-
- OPER foo bar ; Attempt to register as an operator
- using a username of "foo" and "bar" as
- the password.
-
-4.1.6 Quit
-
- Command: QUIT
- Parameters: [<Quit message>]
-
- A client session is ended with a quit message. The server must close
- the connection to a client which sends a QUIT message. If a "Quit
- Message" is given, this will be sent instead of the default message,
- the nickname.
-
- When netsplits (disconnecting of two servers) occur, the quit message
-
-
-
-Oikarinen & Reed [Page 17]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- is composed of the names of two servers involved, separated by a
- space. The first name is that of the server which is still connected
- and the second name is that of the server that has become
- disconnected.
-
- If, for some other reason, a client connection is closed without the
- client issuing a QUIT command (e.g. client dies and EOF occurs
- on socket), the server is required to fill in the quit message with
- some sort of message reflecting the nature of the event which
- caused it to happen.
-
- Numeric Replies:
-
- None.
-
- Examples:
-
- QUIT :Gone to have lunch ; Preferred message format.
-
-4.1.7 Server quit message
-
- Command: SQUIT
- Parameters: <server> <comment>
-
- The SQUIT message is needed to tell about quitting or dead servers.
- If a server wishes to break the connection to another server it must
- send a SQUIT message to the other server, using the the name of the
- other server as the server parameter, which then closes its
- connection to the quitting server.
-
- This command is also available operators to help keep a network of
- IRC servers connected in an orderly fashion. Operators may also
- issue an SQUIT message for a remote server connection. In this case,
- the SQUIT must be parsed by each server inbetween the operator and
- the remote server, updating the view of the network held by each
- server as explained below.
-
- The <comment> should be supplied by all operators who execute a SQUIT
- for a remote server (that is not connected to the server they are
- currently on) so that other operators are aware for the reason of
- this action. The <comment> is also filled in by servers which may
- place an error or similar message here.
-
- Both of the servers which are on either side of the connection being
- closed are required to to send out a SQUIT message (to all its other
- server connections) for all other servers which are considered to be
- behind that link.
-
-
-
-
-Oikarinen & Reed [Page 18]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- Similarly, a QUIT message must be sent to the other connected servers
- rest of the network on behalf of all clients behind that link. In
- addition to this, all channel members of a channel which lost a
- member due to the split must be sent a QUIT message.
-
- If a server connection is terminated prematurely (e.g. the server on
- the other end of the link died), the server which detects
- this disconnection is required to inform the rest of the network
- that the connection has closed and fill in the comment field
- with something appropriate.
-
- Numeric replies:
-
- ERR_NOPRIVILEGES ERR_NOSUCHSERVER
-
- Example:
-
- SQUIT tolsun.oulu.fi :Bad Link ? ; the server link tolson.oulu.fi has
- been terminated because of "Bad Link".
-
- :Trillian SQUIT cm22.eng.umd.edu :Server out of control
- ; message from Trillian to disconnect
- "cm22.eng.umd.edu" from the net
- because "Server out of control".
-
-4.2 Channel operations
-
- This group of messages is concerned with manipulating channels, their
- properties (channel modes), and their contents (typically clients).
- In implementing these, a number of race conditions are inevitable
- when clients at opposing ends of a network send commands which will
- ultimately clash. It is also required that servers keep a nickname
- history to ensure that wherever a <nick> parameter is given, the
- server check its history in case it has recently been changed.
-
-4.2.1 Join message
-
- Command: JOIN
- Parameters: <channel>{,<channel>} [<key>{,<key>}]
-
- The JOIN command is used by client to start listening a specific
- channel. Whether or not a client is allowed to join a channel is
- checked only by the server the client is connected to; all other
- servers automatically add the user to the channel when it is received
- from other servers. The conditions which affect this are as follows:
-
- 1. the user must be invited if the channel is invite-only;
-
-
-
-
-Oikarinen & Reed [Page 19]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- 2. the user's nick/username/hostname must not match any
- active bans;
-
- 3. the correct key (password) must be given if it is set.
-
- These are discussed in more detail under the MODE command (see
- section 4.2.3 for more details).
-
- Once a user has joined a channel, they receive notice about all
- commands their server receives which affect the channel. This
- includes MODE, KICK, PART, QUIT and of course PRIVMSG/NOTICE. The
- JOIN command needs to be broadcast to all servers so that each server
- knows where to find the users who are on the channel. This allows
- optimal delivery of PRIVMSG/NOTICE messages to the channel.
-
- If a JOIN is successful, the user is then sent the channel's topic
- (using RPL_TOPIC) and the list of users who are on the channel (using
- RPL_NAMREPLY), which must include the user joining.
-
- Numeric Replies:
-
- ERR_NEEDMOREPARAMS ERR_BANNEDFROMCHAN
- ERR_INVITEONLYCHAN ERR_BADCHANNELKEY
- ERR_CHANNELISFULL ERR_BADCHANMASK
- ERR_NOSUCHCHANNEL ERR_TOOMANYCHANNELS
- RPL_TOPIC
-
- Examples:
-
- JOIN #foobar ; join channel #foobar.
-
- JOIN &foo fubar ; join channel &foo using key "fubar".
-
- JOIN #foo,&bar fubar ; join channel #foo using key "fubar"
- and &bar using no key.
-
- JOIN #foo,#bar fubar,foobar ; join channel #foo using key "fubar".
- and channel #bar using key "foobar".
-
- JOIN #foo,#bar ; join channels #foo and #bar.
-
- :WiZ JOIN #Twilight_zone ; JOIN message from WiZ
-
-4.2.2 Part message
-
- Command: PART
- Parameters: <channel>{,<channel>}
-
-
-
-
-Oikarinen & Reed [Page 20]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- The PART message causes the client sending the message to be removed
- from the list of active users for all given channels listed in the
- parameter string.
-
- Numeric Replies:
-
- ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
- ERR_NOTONCHANNEL
-
- Examples:
-
- PART #twilight_zone ; leave channel "#twilight_zone"
-
- PART #oz-ops,&group5 ; leave both channels "&group5" and
- "#oz-ops".
-
-4.2.3 Mode message
-
- Command: MODE
-
- The MODE command is a dual-purpose command in IRC. It allows both
- usernames and channels to have their mode changed. The rationale for
- this choice is that one day nicknames will be obsolete and the
- equivalent property will be the channel.
-
- When parsing MODE messages, it is recommended that the entire message
- be parsed first and then the changes which resulted then passed on.
-
-4.2.3.1 Channel modes
-
- Parameters: <channel> {[+|-]|o|p|s|i|t|n|b|v} [<limit>] [<user>]
- [<ban mask>]
-
- The MODE command is provided so that channel operators may change the
- characteristics of `their' channel. It is also required that servers
- be able to change channel modes so that channel operators may be
- created.
-
- The various modes available for channels are as follows:
-
- o - give/take channel operator privileges;
- p - private channel flag;
- s - secret channel flag;
- i - invite-only channel flag;
- t - topic settable by channel operator only flag;
- n - no messages to channel from clients on the outside;
- m - moderated channel;
- l - set the user limit to channel;
-
-
-
-Oikarinen & Reed [Page 21]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- b - set a ban mask to keep users out;
- v - give/take the ability to speak on a moderated channel;
- k - set a channel key (password).
-
- When using the 'o' and 'b' options, a restriction on a total of three
- per mode command has been imposed. That is, any combination of 'o'
- and
-
-4.2.3.2 User modes
-
- Parameters: <nickname> {[+|-]|i|w|s|o}
-
- The user MODEs are typically changes which affect either how the
- client is seen by others or what 'extra' messages the client is sent.
- A user MODE command may only be accepted if both the sender of the
- message and the nickname given as a parameter are both the same.
-
- The available modes are as follows:
-
- i - marks a users as invisible;
- s - marks a user for receipt of server notices;
- w - user receives wallops;
- o - operator flag.
-
- Additional modes may be available later on.
-
- If a user attempts to make themselves an operator using the "+o"
- flag, the attempt should be ignored. There is no restriction,
- however, on anyone `deopping' themselves (using "-o"). Numeric
- Replies:
-
- ERR_NEEDMOREPARAMS RPL_CHANNELMODEIS
- ERR_CHANOPRIVSNEEDED ERR_NOSUCHNICK
- ERR_NOTONCHANNEL ERR_KEYSET
- RPL_BANLIST RPL_ENDOFBANLIST
- ERR_UNKNOWNMODE ERR_NOSUCHCHANNEL
-
- ERR_USERSDONTMATCH RPL_UMODEIS
- ERR_UMODEUNKNOWNFLAG
-
- Examples:
-
- Use of Channel Modes:
-
-MODE #Finnish +im ; Makes #Finnish channel moderated and
- 'invite-only'.
-
-MODE #Finnish +o Kilroy ; Gives 'chanop' privileges to Kilroy on
-
-
-
-Oikarinen & Reed [Page 22]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- channel #Finnish.
-
-MODE #Finnish +v Wiz ; Allow WiZ to speak on #Finnish.
-
-MODE #Fins -s ; Removes 'secret' flag from channel
- #Fins.
-
-MODE #42 +k oulu ; Set the channel key to "oulu".
-
-MODE #eu-opers +l 10 ; Set the limit for the number of users
- on channel to 10.
-
-MODE &oulu +b ; list ban masks set for channel.
-
-MODE &oulu +b *!*@* ; prevent all users from joining.
-
-MODE &oulu +b *!*@*.edu ; prevent any user from a hostname
- matching *.edu from joining.
-
- Use of user Modes:
-
-:MODE WiZ -w ; turns reception of WALLOPS messages
- off for WiZ.
-
-:Angel MODE Angel +i ; Message from Angel to make themselves
- invisible.
-
-MODE WiZ -o ; WiZ 'deopping' (removing operator
- status). The plain reverse of this
- command ("MODE WiZ +o") must not be
- allowed from users since would bypass
- the OPER command.
-
-4.2.4 Topic message
-
- Command: TOPIC
- Parameters: <channel> [<topic>]
-
- The TOPIC message is used to change or view the topic of a channel.
- The topic for channel <channel> is returned if there is no <topic>
- given. If the <topic> parameter is present, the topic for that
- channel will be changed, if the channel modes permit this action.
-
- Numeric Replies:
-
- ERR_NEEDMOREPARAMS ERR_NOTONCHANNEL
- RPL_NOTOPIC RPL_TOPIC
- ERR_CHANOPRIVSNEEDED
-
-
-
-Oikarinen & Reed [Page 23]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- Examples:
-
- :Wiz TOPIC #test :New topic ;User Wiz setting the topic.
-
- TOPIC #test :another topic ;set the topic on #test to "another
- topic".
-
- TOPIC #test ; check the topic for #test.
-
-4.2.5 Names message
-
- Command: NAMES
- Parameters: [<channel>{,<channel>}]
-
- By using the NAMES command, a user can list all nicknames that are
- visible to them on any channel that they can see. Channel names
- which they can see are those which aren't private (+p) or secret (+s)
- or those which they are actually on. The <channel> parameter
- specifies which channel(s) to return information about if valid.
- There is no error reply for bad channel names.
-
- If no <channel> parameter is given, a list of all channels and their
- occupants is returned. At the end of this list, a list of users who
- are visible but either not on any channel or not on a visible channel
- are listed as being on `channel' "*".
-
- Numerics:
-
- RPL_NAMREPLY RPL_ENDOFNAMES
-
- Examples:
-
- NAMES #twilight_zone,#42 ; list visible users on #twilight_zone
- and #42 if the channels are visible to
- you.
-
- NAMES ; list all visible channels and users
-
-4.2.6 List message
-
- Command: LIST
- Parameters: [<channel>{,<channel>} [<server>]]
-
- The list message is used to list channels and their topics. If the
- <channel> parameter is used, only the status of that channel
- is displayed. Private channels are listed (without their
- topics) as channel "Prv" unless the client generating the query is
- actually on that channel. Likewise, secret channels are not listed
-
-
-
-Oikarinen & Reed [Page 24]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- at all unless the client is a member of the channel in question.
-
- Numeric Replies:
-
- ERR_NOSUCHSERVER RPL_LISTSTART
- RPL_LIST RPL_LISTEND
-
- Examples:
-
- LIST ; List all channels.
-
- LIST #twilight_zone,#42 ; List channels #twilight_zone and #42
-
-4.2.7 Invite message
-
- Command: INVITE
- Parameters: <nickname> <channel>
-
- The INVITE message is used to invite users to a channel. The
- parameter <nickname> is the nickname of the person to be invited to
- the target channel <channel>. There is no requirement that the
- channel the target user is being invited to must exist or be a valid
- channel. To invite a user to a channel which is invite only (MODE
- +i), the client sending the invite must be recognised as being a
- channel operator on the given channel.
-
- Numeric Replies:
-
- ERR_NEEDMOREPARAMS ERR_NOSUCHNICK
- ERR_NOTONCHANNEL ERR_USERONCHANNEL
- ERR_CHANOPRIVSNEEDED
- RPL_INVITING RPL_AWAY
-
- Examples:
-
- :Angel INVITE Wiz #Dust ; User Angel inviting WiZ to channel
- #Dust
-
- INVITE Wiz #Twilight_Zone ; Command to invite WiZ to
- #Twilight_zone
-
-4.2.8 Kick command
-
- Command: KICK
- Parameters: <channel> <user> [<comment>]
-
- The KICK command can be used to forcibly remove a user from a
- channel. It 'kicks them out' of the channel (forced PART).
-
-
-
-Oikarinen & Reed [Page 25]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- Only a channel operator may kick another user out of a channel.
- Each server that receives a KICK message checks that it is valid
- (ie the sender is actually a channel operator) before removing
- the victim from the channel.
-
- Numeric Replies:
-
- ERR_NEEDMOREPARAMS ERR_NOSUCHCHANNEL
- ERR_BADCHANMASK ERR_CHANOPRIVSNEEDED
- ERR_NOTONCHANNEL
-
- Examples:
-
-KICK &Melbourne Matthew ; Kick Matthew from &Melbourne
-
-KICK #Finnish John :Speaking English
- ; Kick John from #Finnish using
- "Speaking English" as the reason
- (comment).
-
-:WiZ KICK #Finnish John ; KICK message from WiZ to remove John
- from channel #Finnish
-
-NOTE:
- It is possible to extend the KICK command parameters to the
-following:
-
-<channel>{,<channel>} <user>{,<user>} [<comment>]
-
-4.3 Server queries and commands
-
- The server query group of commands has been designed to return
- information about any server which is connected to the network. All
- servers connected must respond to these queries and respond
- correctly. Any invalid response (or lack thereof) must be considered
- a sign of a broken server and it must be disconnected/disabled as
- soon as possible until the situation is remedied.
-
- In these queries, where a parameter appears as "<server>", it will
- usually mean it can be a nickname or a server or a wildcard name of
- some sort. For each parameter, however, only one query and set of
- replies is to be generated.
-
-4.3.1 Version message
-
- Command: VERSION
- Parameters: [<server>]
-
-
-
-
-Oikarinen & Reed [Page 26]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- The VERSION message is used to query the version of the server
- program. An optional parameter <server> is used to query the version
- of the server program which a client is not directly connected to.
-
- Numeric Replies:
-
- ERR_NOSUCHSERVER RPL_VERSION
-
- Examples:
-
- :Wiz VERSION *.se ; message from Wiz to check the version
- of a server matching "*.se"
-
- VERSION tolsun.oulu.fi ; check the version of server
- "tolsun.oulu.fi".
-
-4.3.2 Stats message
-
- Command: STATS
- Parameters: [<query> [<server>]]
-
- The stats message is used to query statistics of certain server. If
- <server> parameter is omitted, only the end of stats reply is sent
- back. The implementation of this command is highly dependent on the
- server which replies, although the server must be able to supply
- information as described by the queries below (or similar).
-
- A query may be given by any single letter which is only checked by
- the destination server (if given as the <server> parameter) and is
- otherwise passed on by intermediate servers, ignored and unaltered.
- The following queries are those found in the current IRC
- implementation and provide a large portion of the setup information
- for that server. Although these may not be supported in the same way
- by other versions, all servers should be able to supply a valid reply
- to a STATS query which is consistent with the reply formats currently
- used and the purpose of the query.
-
- The currently supported queries are:
-
- c - returns a list of servers which the server may connect
- to or allow connections from;
- h - returns a list of servers which are either forced to be
- treated as leaves or allowed to act as hubs;
- i - returns a list of hosts which the server allows a client
- to connect from;
- k - returns a list of banned username/hostname combinations
- for that server;
- l - returns a list of the server's connections, showing how
-
-
-
-Oikarinen & Reed [Page 27]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- long each connection has been established and the traffic
- over that connection in bytes and messages for each
- direction;
- m - returns a list of commands supported by the server and
- the usage count for each if the usage count is non zero;
- o - returns a list of hosts from which normal clients may
- become operators;
- y - show Y (Class) lines from server's configuration file;
- u - returns a string showing how long the server has been up.
-
- Numeric Replies:
-
- ERR_NOSUCHSERVER
- RPL_STATSCLINE RPL_STATSNLINE
- RPL_STATSILINE RPL_STATSKLINE
- RPL_STATSQLINE RPL_STATSLLINE
- RPL_STATSLINKINFO RPL_STATSUPTIME
- RPL_STATSCOMMANDS RPL_STATSOLINE
- RPL_STATSHLINE RPL_ENDOFSTATS
-
- Examples:
-
-STATS m ; check the command usage for the server
- you are connected to
-
-:Wiz STATS c eff.org ; request by WiZ for C/N line
- information from server eff.org
-
-4.3.3 Links message
-
- Command: LINKS
- Parameters: [[<remote server>] <server mask>]
-
- With LINKS, a user can list all servers which are known by the server
- answering the query. The returned list of servers must match the
- mask, or if no mask is given, the full list is returned.
-
- If <remote server> is given in addition to <server mask>, the LINKS
- command is forwarded to the first server found that matches that name
- (if any), and that server is then required to answer the query.
-
- Numeric Replies:
-
- ERR_NOSUCHSERVER
- RPL_LINKS RPL_ENDOFLINKS
-
- Examples:
-
-
-
-
-Oikarinen & Reed [Page 28]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-LINKS *.au ; list all servers which have a name
- that matches *.au;
-
-:WiZ LINKS *.bu.edu *.edu ; LINKS message from WiZ to the first
- server matching *.edu for a list of
- servers matching *.bu.edu.
-
-4.3.4 Time message
-
- Command: TIME
- Parameters: [<server>]
-
- The time message is used to query local time from the specified
- server. If the server parameter is not given, the server handling the
- command must reply to the query.
-
- Numeric Replies:
-
- ERR_NOSUCHSERVER RPL_TIME
-
- Examples:
-
- TIME tolsun.oulu.fi ; check the time on the server
- "tolson.oulu.fi"
-
- Angel TIME *.au ; user angel checking the time on a
- server matching "*.au"
-
-4.3.5 Connect message
-
- Command: CONNECT
- Parameters: <target server> [<port> [<remote server>]]
-
- The CONNECT command can be used to force a server to try to establish
- a new connection to another server immediately. CONNECT is a
- privileged command and is to be available only to IRC Operators. If
- a remote server is given then the CONNECT attempt is made by that
- server to <target server> and <port>.
-
- Numeric Replies:
-
- ERR_NOSUCHSERVER ERR_NOPRIVILEGES
- ERR_NEEDMOREPARAMS
-
- Examples:
-
-CONNECT tolsun.oulu.fi ; Attempt to connect a server to
- tolsun.oulu.fi
-
-
-
-Oikarinen & Reed [Page 29]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-:WiZ CONNECT eff.org 6667 csd.bu.edu
- ; CONNECT attempt by WiZ to get servers
- eff.org and csd.bu.edu connected on port
- 6667.
-
-4.3.6 Trace message
-
- Command: TRACE
- Parameters: [<server>]
-
- TRACE command is used to find the route to specific server. Each
- server that processes this message must tell the sender about it by
- sending a reply indicating it is a pass-through link, forming a chain
- of replies similar to that gained from using "traceroute". After
- sending this reply back, it must then send the TRACE message to the
- next server until given server is reached. If the <server> parameter
- is omitted, it is recommended that TRACE command send a message to
- the sender telling which servers the current server has direct
- connection to.
-
- If the destination given by "<server>" is an actual server, then the
- destination server is required to report all servers and users which
- are connected to it, although only operators are permitted to see
- users present. If the destination given by <server> is a nickname,
- they only a reply for that nickname is given.
-
- Numeric Replies:
-
- ERR_NOSUCHSERVER
-
- If the TRACE message is destined for another server, all intermediate
- servers must return a RPL_TRACELINK reply to indicate that the TRACE
- passed through it and where its going next.
-
- RPL_TRACELINK
- A TRACE reply may be composed of any number of the following numeric
- replies.
-
- RPL_TRACECONNECTING RPL_TRACEHANDSHAKE
- RPL_TRACEUNKNOWN RPL_TRACEOPERATOR
- RPL_TRACEUSER RPL_TRACESERVER
- RPL_TRACESERVICE RPL_TRACENEWTYPE
- RPL_TRACECLASS
-
- Examples:
-
-TRACE *.oulu.fi ; TRACE to a server matching *.oulu.fi
-
-
-
-
-Oikarinen & Reed [Page 30]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-:WiZ TRACE AngelDust ; TRACE issued by WiZ to nick AngelDust
-
-4.3.7 Admin command
-
- Command: ADMIN
- Parameters: [<server>]
-
- The admin message is used to find the name of the administrator of
- the given server, or current server if <server> parameter is omitted.
- Each server must have the ability to forward ADMIN messages to other
- servers.
-
- Numeric Replies:
-
- ERR_NOSUCHSERVER
- RPL_ADMINME RPL_ADMINLOC1
- RPL_ADMINLOC2 RPL_ADMINEMAIL
-
- Examples:
-
- ADMIN tolsun.oulu.fi ; request an ADMIN reply from
- tolsun.oulu.fi
-
- :WiZ ADMIN *.edu ; ADMIN request from WiZ for first
- server found to match *.edu.
-
-4.3.8 Info command
-
- Command: INFO
- Parameters: [<server>]
-
- The INFO command is required to return information which describes
- the server: its version, when it was compiled, the patchlevel, when
- it was started, and any other miscellaneous information which may be
- considered to be relevant.
-
- Numeric Replies:
-
- ERR_NOSUCHSERVER
- RPL_INFO RPL_ENDOFINFO
-
- Examples:
-
- INFO csd.bu.edu ; request an INFO reply from
- csd.bu.edu
-
- :Avalon INFO *.fi ; INFO request from Avalon for first
- server found to match *.fi.
-
-
-
-Oikarinen & Reed [Page 31]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- INFO Angel ; request info from the server that
- Angel is connected to.
-
-4.4 Sending messages
-
- The main purpose of the IRC protocol is to provide a base for clients
- to communicate with each other. PRIVMSG and NOTICE are the only
- messages available which actually perform delivery of a text message
- from one client to another - the rest just make it possible and try
- to ensure it happens in a reliable and structured manner.
-
-4.4.1 Private messages
-
- Command: PRIVMSG
- Parameters: <receiver>{,<receiver>} <text to be sent>
-
- PRIVMSG is used to send private messages between users. <receiver>
- is the nickname of the receiver of the message. <receiver> can also
- be a list of names or channels separated with commas.
-
- The <receiver> parameter may also me a host mask (#mask) or server
- mask ($mask). In both cases the server will only send the PRIVMSG
- to those who have a server or host matching the mask. The mask must
- have at least 1 (one) "." in it and no wildcards following the
- last ".". This requirement exists to prevent people sending messages
- to "#*" or "$*", which would broadcast to all users; from
- experience, this is abused more than used responsibly and properly.
- Wildcards are the '*' and '?' characters. This extension to
- the PRIVMSG command is only available to Operators.
-
- Numeric Replies:
-
- ERR_NORECIPIENT ERR_NOTEXTTOSEND
- ERR_CANNOTSENDTOCHAN ERR_NOTOPLEVEL
- ERR_WILDTOPLEVEL ERR_TOOMANYTARGETS
- ERR_NOSUCHNICK
- RPL_AWAY
-
- Examples:
-
-:Angel PRIVMSG Wiz :Hello are you receiving this message ?
- ; Message from Angel to Wiz.
-
-PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br ;
- Message to Angel.
-
-PRIVMSG jto@tolsun.oulu.fi :Hello !
- ; Message to a client on server
-
-
-
-Oikarinen & Reed [Page 32]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- tolsun.oulu.fi with username of "jto".
-
-PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.
- ; Message to everyone on a server which
- has a name matching *.fi.
-
-PRIVMSG #*.edu :NSFNet is undergoing work, expect interruptions
- ; Message to all users who come from a
- host which has a name matching *.edu.
-
-4.4.2 Notice
-
- Command: NOTICE
- Parameters: <nickname> <text>
-
- The NOTICE message is used similarly to PRIVMSG. The difference
- between NOTICE and PRIVMSG is that automatic replies must never be
- sent in response to a NOTICE message. This rule applies to servers
- too - they must not send any error reply back to the client on
- receipt of a notice. The object of this rule is to avoid loops
- between a client automatically sending something in response to
- something it received. This is typically used by automatons (clients
- with either an AI or other interactive program controlling their
- actions) which are always seen to be replying lest they end up in a
- loop with another automaton.
-
- See PRIVMSG for more details on replies and examples.
-
-4.5 User based queries
-
- User queries are a group of commands which are primarily concerned
- with finding details on a particular user or group users. When using
- wildcards with any of these commands, if they match, they will only
- return information on users who are 'visible' to you. The visibility
- of a user is determined as a combination of the user's mode and the
- common set of channels you are both on.
-
-4.5.1 Who query
-
- Command: WHO
- Parameters: [<name> [<o>]]
-
- The WHO message is used by a client to generate a query which returns
- a list of information which 'matches' the <name> parameter given by
- the client. In the absence of the <name> parameter, all visible
- (users who aren't invisible (user mode +i) and who don't have a
- common channel with the requesting client) are listed. The same
- result can be achieved by using a <name> of "0" or any wildcard which
-
-
-
-Oikarinen & Reed [Page 33]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- will end up matching every entry possible.
-
- The <name> passed to WHO is matched against users' host, server, real
- name and nickname if the channel <name> cannot be found.
-
- If the "o" parameter is passed only operators are returned according
- to the name mask supplied.
-
- Numeric Replies:
-
- ERR_NOSUCHSERVER
- RPL_WHOREPLY RPL_ENDOFWHO
-
- Examples:
-
- WHO *.fi ; List all users who match against
- "*.fi".
-
- WHO jto* o ; List all users with a match against
- "jto*" if they are an operator.
-
-4.5.2 Whois query
-
- Command: WHOIS
- Parameters: [<server>] <nickmask>[,<nickmask>[,...]]
-
- This message is used to query information about particular user. The
- server will answer this message with several numeric messages
- indicating different statuses of each user which matches the nickmask
- (if you are entitled to see them). If no wildcard is present in the
- <nickmask>, any information about that nick which you are allowed to
- see is presented. A comma (',') separated list of nicknames may be
- given.
-
- The latter version sends the query to a specific server. It is
- useful if you want to know how long the user in question has been
- idle as only local server (ie. the server the user is directly
- connected to) knows that information, while everything else is
- globally known.
-
- Numeric Replies:
-
- ERR_NOSUCHSERVER ERR_NONICKNAMEGIVEN
- RPL_WHOISUSER RPL_WHOISCHANNELS
- RPL_WHOISCHANNELS RPL_WHOISSERVER
- RPL_AWAY RPL_WHOISOPERATOR
- RPL_WHOISIDLE ERR_NOSUCHNICK
- RPL_ENDOFWHOIS
-
-
-
-Oikarinen & Reed [Page 34]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- Examples:
-
- WHOIS wiz ; return available user information
- about nick WiZ
-
- WHOIS eff.org trillian ; ask server eff.org for user
- information about trillian
-
-4.5.3 Whowas
-
- Command: WHOWAS
- Parameters: <nickname> [<count> [<server>]]
-
- Whowas asks for information about a nickname which no longer exists.
- This may either be due to a nickname change or the user leaving IRC.
- In response to this query, the server searches through its nickname
- history, looking for any nicks which are lexically the same (no wild
- card matching here). The history is searched backward, returning the
- most recent entry first. If there are multiple entries, up to
- <count> replies will be returned (or all of them if no <count>
- parameter is given). If a non-positive number is passed as being
- <count>, then a full search is done.
-
- Numeric Replies:
-
- ERR_NONICKNAMEGIVEN ERR_WASNOSUCHNICK
- RPL_WHOWASUSER RPL_WHOISSERVER
- RPL_ENDOFWHOWAS
-
- Examples:
-
- WHOWAS Wiz ; return all information in the nick
- history about nick "WiZ";
-
- WHOWAS Mermaid 9 ; return at most, the 9 most recent
- entries in the nick history for
- "Mermaid";
-
- WHOWAS Trillian 1 *.edu ; return the most recent history for
- "Trillian" from the first server found
- to match "*.edu".
-
-4.6 Miscellaneous messages
-
- Messages in this category do not fit into any of the above categories
- but are nonetheless still a part of and required by the protocol.
-
-
-
-
-
-Oikarinen & Reed [Page 35]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-4.6.1 Kill message
-
- Command: KILL
- Parameters: <nickname> <comment>
-
- The KILL message is used to cause a client-server connection to be
- closed by the server which has the actual connection. KILL is used
- by servers when they encounter a duplicate entry in the list of valid
- nicknames and is used to remove both entries. It is also available
- to operators.
-
- Clients which have automatic reconnect algorithms effectively make
- this command useless since the disconnection is only brief. It does
- however break the flow of data and can be used to stop large amounts
- of being abused, any user may elect to receive KILL messages
- generated for others to keep an 'eye' on would be trouble spots.
-
- In an arena where nicknames are required to be globally unique at all
- times, KILL messages are sent whenever 'duplicates' are detected
- (that is an attempt to register two users with the same nickname) in
- the hope that both of them will disappear and only 1 reappear.
-
- The comment given must reflect the actual reason for the KILL. For
- server-generated KILLs it usually is made up of details concerning
- the origins of the two conflicting nicknames. For users it is left
- up to them to provide an adequate reason to satisfy others who see
- it. To prevent/discourage fake KILLs from being generated to hide
- the identify of the KILLer, the comment also shows a 'kill-path'
- which is updated by each server it passes through, each prepending
- its name to the path.
-
- Numeric Replies:
-
- ERR_NOPRIVILEGES ERR_NEEDMOREPARAMS
- ERR_NOSUCHNICK ERR_CANTKILLSERVER
-
-
- KILL David (csd.bu.edu <- tolsun.oulu.fi)
- ; Nickname collision between csd.bu.edu
- and tolson.oulu.fi
-
-
- NOTE:
- It is recommended that only Operators be allowed to kill other users
- with KILL message. In an ideal world not even operators would need
- to do this and it would be left to servers to deal with.
-
-
-
-
-
-Oikarinen & Reed [Page 36]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-4.6.2 Ping message
-
- Command: PING
- Parameters: <server1> [<server2>]
-
- The PING message is used to test the presence of an active client at
- the other end of the connection. A PING message is sent at regular
- intervals if no other activity detected coming from a connection. If
- a connection fails to respond to a PING command within a set amount
- of time, that connection is closed.
-
- Any client which receives a PING message must respond to <server1>
- (server which sent the PING message out) as quickly as possible with
- an appropriate PONG message to indicate it is still there and alive.
- Servers should not respond to PING commands but rely on PINGs from
- the other end of the connection to indicate the connection is alive.
- If the <server2> parameter is specified, the PING message gets
- forwarded there.
-
- Numeric Replies:
-
- ERR_NOORIGIN ERR_NOSUCHSERVER
-
- Examples:
-
- PING tolsun.oulu.fi ; server sending a PING message to
- another server to indicate it is still
- alive.
-
- PING WiZ ; PING message being sent to nick WiZ
-
-4.6.3 Pong message
-
- Command: PONG
- Parameters: <daemon> [<daemon2>]
-
- PONG message is a reply to ping message. If parameter <daemon2> is
- given this message must be forwarded to given daemon. The <daemon>
- parameter is the name of the daemon who has responded to PING message
- and generated this message.
-
- Numeric Replies:
-
- ERR_NOORIGIN ERR_NOSUCHSERVER
-
- Examples:
-
- PONG csd.bu.edu tolsun.oulu.fi ; PONG message from csd.bu.edu to
-
-
-
-Oikarinen & Reed [Page 37]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- tolsun.oulu.fi
-
-4.6.4 Error
-
- Command: ERROR
- Parameters: <error message>
-
- The ERROR command is for use by servers when reporting a serious or
- fatal error to its operators. It may also be sent from one server to
- another but must not be accepted from any normal unknown clients.
-
- An ERROR message is for use for reporting errors which occur with a
- server-to-server link only. An ERROR message is sent to the server
- at the other end (which sends it to all of its connected operators)
- and to all operators currently connected. It is not to be passed
- onto any other servers by a server if it is received from a server.
-
- When a server sends a received ERROR message to its operators, the
- message should be encapsulated inside a NOTICE message, indicating
- that the client was not responsible for the error.
-
- Numerics:
-
- None.
-
- Examples:
-
- ERROR :Server *.fi already exists; ERROR message to the other server
- which caused this error.
-
- NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists
- ; Same ERROR message as above but sent
- to user WiZ on the other server.
-
-5. OPTIONALS
-
- This section describes OPTIONAL messages. They are not required in a
- working server implementation of the protocol described herein. In
- the absence of the option, an error reply message must be generated
- or an unknown command error. If the message is destined for another
- server to answer then it must be passed on (elementary parsing
- required) The allocated numerics for this are listed with the
- messages below.
-
-5.1 Away
-
- Command: AWAY
- Parameters: [message]
-
-
-
-Oikarinen & Reed [Page 38]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- With the AWAY message, clients can set an automatic reply string for
- any PRIVMSG commands directed at them (not to a channel they are on).
- The automatic reply is sent by the server to client sending the
- PRIVMSG command. The only replying server is the one to which the
- sending client is connected to.
-
- The AWAY message is used either with one parameter (to set an AWAY
- message) or with no parameters (to remove the AWAY message).
-
- Numeric Replies:
-
- RPL_UNAWAY RPL_NOWAWAY
-
- Examples:
-
- AWAY :Gone to lunch. Back in 5 ; set away message to "Gone to lunch.
- Back in 5".
-
- :WiZ AWAY ; unmark WiZ as being away.
-
-
-5.2 Rehash message
-
- Command: REHASH
- Parameters: None
-
- The rehash message can be used by the operator to force the server to
- re-read and process its configuration file.
-
- Numeric Replies:
-
- RPL_REHASHING ERR_NOPRIVILEGES
-
-Examples:
-
-REHASH ; message from client with operator
- status to server asking it to reread its
- configuration file.
-
-5.3 Restart message
-
- Command: RESTART
- Parameters: None
-
- The restart message can only be used by an operator to force a server
- restart itself. This message is optional since it may be viewed as a
- risk to allow arbitrary people to connect to a server as an operator
- and execute this command, causing (at least) a disruption to service.
-
-
-
-Oikarinen & Reed [Page 39]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- The RESTART command must always be fully processed by the server to
- which the sending client is connected and not be passed onto other
- connected servers.
-
- Numeric Replies:
-
- ERR_NOPRIVILEGES
-
- Examples:
-
- RESTART ; no parameters required.
-
-5.4 Summon message
-
- Command: SUMMON
- Parameters: <user> [<server>]
-
- The SUMMON command can be used to give users who are on a host
- running an IRC server a message asking them to please join IRC. This
- message is only sent if the target server (a) has SUMMON enabled, (b)
- the user is logged in and (c) the server process can write to the
- user's tty (or similar).
-
- If no <server> parameter is given it tries to summon <user> from the
- server the client is connected to is assumed as the target.
-
- If summon is not enabled in a server, it must return the
- ERR_SUMMONDISABLED numeric and pass the summon message onwards.
-
- Numeric Replies:
-
- ERR_NORECIPIENT ERR_FILEERROR
- ERR_NOLOGIN ERR_NOSUCHSERVER
- RPL_SUMMONING
-
- Examples:
-
- SUMMON jto ; summon user jto on the server's host
-
- SUMMON jto tolsun.oulu.fi ; summon user jto on the host which a
- server named "tolsun.oulu.fi" is
- running.
-
-
-5.5 Users
-
- Command: USERS
- Parameters: [<server>]
-
-
-
-Oikarinen & Reed [Page 40]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- The USERS command returns a list of users logged into the server in a
- similar format to who(1), rusers(1) and finger(1). Some people
- may disable this command on their server for security related
- reasons. If disabled, the correct numeric must be returned to
- indicate this.
-
- Numeric Replies:
-
- ERR_NOSUCHSERVER ERR_FILEERROR
- RPL_USERSSTART RPL_USERS
- RPL_NOUSERS RPL_ENDOFUSERS
- ERR_USERSDISABLED
-
- Disabled Reply:
-
- ERR_USERSDISABLED
-
- Examples:
-
-USERS eff.org ; request a list of users logged in on
- server eff.org
-
-:John USERS tolsun.oulu.fi ; request from John for a list of users
- logged in on server tolsun.oulu.fi
-
-5.6 Operwall message
-
- Command: WALLOPS
- Parameters: Text to be sent to all operators currently online
-
- Sends a message to all operators currently online. After
- implementing WALLOPS as a user command it was found that it was
- often and commonly abused as a means of sending a message to a lot
- of people (much similar to WALL). Due to this it is recommended
- that the current implementation of WALLOPS be used as an
- example by allowing and recognising only servers as the senders of
- WALLOPS.
-
- Numeric Replies:
-
- ERR_NEEDMOREPARAMS
-
- Examples:
-
- :csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua; WALLOPS
- message from csd.bu.edu announcing a
- CONNECT message it received and acted
- upon from Joshua.
-
-
-
-Oikarinen & Reed [Page 41]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-5.7 Userhost message
-
- Command: USERHOST
- Parameters: <nickname>{<space><nickname>}
-
- The USERHOST command takes a list of up to 5 nicknames, each
- separated by a space character and returns a list of information
- about each nickname that it found. The returned list has each reply
- separated by a space.
-
- Numeric Replies:
-
- RPL_USERHOST ERR_NEEDMOREPARAMS
-
- Examples:
-
- USERHOST Wiz Michael Marty p ;USERHOST request for information on
- nicks "Wiz", "Michael", "Marty" and "p"
-
-5.8 Ison message
-
- Command: ISON
- Parameters: <nickname>{<space><nickname>}
-
- The ISON command was implemented to provide a quick and efficient
- means to get a response about whether a given nickname was currently
- on IRC. ISON only takes one (1) parameter: a space-separated list of
- nicks. For each nickname in the list that is present, the server
- adds that to its reply string. Thus the reply string may return
- empty (none of the given nicks are present), an exact copy of the
- parameter string (all of them present) or as any other subset of the
- set of nicks given in the parameter. The only limit on the number
- of nicks that may be checked is that the combined length must not be
- too large as to cause the server to chop it off so it fits in 512
- characters.
-
- ISON is only be processed by the server local to the client sending
- the command and thus not passed onto other servers for further
- processing.
-
- Numeric Replies:
-
- RPL_ISON ERR_NEEDMOREPARAMS
-
- Examples:
-
- ISON phone trillian WiZ jarlek Avalon Angel Monstah
- ; Sample ISON request for 7 nicks.
-
-
-
-Oikarinen & Reed [Page 42]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-6. REPLIES
-
- The following is a list of numeric replies which are generated in
- response to the commands given above. Each numeric is given with its
- number, name and reply string.
-
-6.1 Error Replies.
-
- 401 ERR_NOSUCHNICK
- "<nickname> :No such nick/channel"
-
- - Used to indicate the nickname parameter supplied to a
- command is currently unused.
-
- 402 ERR_NOSUCHSERVER
- "<server name> :No such server"
-
- - Used to indicate the server name given currently
- doesn't exist.
-
- 403 ERR_NOSUCHCHANNEL
- "<channel name> :No such channel"
-
- - Used to indicate the given channel name is invalid.
-
- 404 ERR_CANNOTSENDTOCHAN
- "<channel name> :Cannot send to channel"
-
- - Sent to a user who is either (a) not on a channel
- which is mode +n or (b) not a chanop (or mode +v) on
- a channel which has mode +m set and is trying to send
- a PRIVMSG message to that channel.
-
- 405 ERR_TOOMANYCHANNELS
- "<channel name> :You have joined too many \
- channels"
- - Sent to a user when they have joined the maximum
- number of allowed channels and they try to join
- another channel.
-
- 406 ERR_WASNOSUCHNICK
- "<nickname> :There was no such nickname"
-
- - Returned by WHOWAS to indicate there is no history
- information for that nickname.
-
- 407 ERR_TOOMANYTARGETS
- "<target> :Duplicate recipients. No message \
-
-
-
-Oikarinen & Reed [Page 43]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- delivered"
-
- - Returned to a client which is attempting to send a
- PRIVMSG/NOTICE using the user@host destination format
- and for a user@host which has several occurrences.
-
- 409 ERR_NOORIGIN
- ":No origin specified"
-
- - PING or PONG message missing the originator parameter
- which is required since these commands must work
- without valid prefixes.
-
- 411 ERR_NORECIPIENT
- ":No recipient given (<command>)"
- 412 ERR_NOTEXTTOSEND
- ":No text to send"
- 413 ERR_NOTOPLEVEL
- "<mask> :No toplevel domain specified"
- 414 ERR_WILDTOPLEVEL
- "<mask> :Wildcard in toplevel domain"
-
- - 412 - 414 are returned by PRIVMSG to indicate that
- the message wasn't delivered for some reason.
- ERR_NOTOPLEVEL and ERR_WILDTOPLEVEL are errors that
- are returned when an invalid use of
- "PRIVMSG $<server>" or "PRIVMSG #<host>" is attempted.
-
- 421 ERR_UNKNOWNCOMMAND
- "<command> :Unknown command"
-
- - Returned to a registered client to indicate that the
- command sent is unknown by the server.
-
- 422 ERR_NOMOTD
- ":MOTD File is missing"
-
- - Server's MOTD file could not be opened by the server.
-
- 423 ERR_NOADMININFO
- "<server> :No administrative info available"
-
- - Returned by a server in response to an ADMIN message
- when there is an error in finding the appropriate
- information.
-
- 424 ERR_FILEERROR
- ":File error doing <file op> on <file>"
-
-
-
-Oikarinen & Reed [Page 44]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- - Generic error message used to report a failed file
- operation during the processing of a message.
-
- 431 ERR_NONICKNAMEGIVEN
- ":No nickname given"
-
- - Returned when a nickname parameter expected for a
- command and isn't found.
-
- 432 ERR_ERRONEUSNICKNAME
- "<nick> :Erroneus nickname"
-
- - Returned after receiving a NICK message which contains
- characters which do not fall in the defined set. See
- section x.x.x for details on valid nicknames.
-
- 433 ERR_NICKNAMEINUSE
- "<nick> :Nickname is already in use"
-
- - Returned when a NICK message is processed that results
- in an attempt to change to a currently existing
- nickname.
-
- 436 ERR_NICKCOLLISION
- "<nick> :Nickname collision KILL"
-
- - Returned by a server to a client when it detects a
- nickname collision (registered of a NICK that
- already exists by another server).
-
- 441 ERR_USERNOTINCHANNEL
- "<nick> <channel> :They aren't on that channel"
-
- - Returned by the server to indicate that the target
- user of the command is not on the given channel.
-
- 442 ERR_NOTONCHANNEL
- "<channel> :You're not on that channel"
-
- - Returned by the server whenever a client tries to
- perform a channel effecting command for which the
- client isn't a member.
-
- 443 ERR_USERONCHANNEL
- "<user> <channel> :is already on channel"
-
- - Returned when a client tries to invite a user to a
- channel they are already on.
-
-
-
-Oikarinen & Reed [Page 45]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- 444 ERR_NOLOGIN
- "<user> :User not logged in"
-
- - Returned by the summon after a SUMMON command for a
- user was unable to be performed since they were not
- logged in.
-
- 445 ERR_SUMMONDISABLED
- ":SUMMON has been disabled"
-
- - Returned as a response to the SUMMON command. Must be
- returned by any server which does not implement it.
-
- 446 ERR_USERSDISABLED
- ":USERS has been disabled"
-
- - Returned as a response to the USERS command. Must be
- returned by any server which does not implement it.
-
- 451 ERR_NOTREGISTERED
- ":You have not registered"
-
- - Returned by the server to indicate that the client
- must be registered before the server will allow it
- to be parsed in detail.
-
- 461 ERR_NEEDMOREPARAMS
- "<command> :Not enough parameters"
-
- - Returned by the server by numerous commands to
- indicate to the client that it didn't supply enough
- parameters.
-
- 462 ERR_ALREADYREGISTRED
- ":You may not reregister"
-
- - Returned by the server to any link which tries to
- change part of the registered details (such as
- password or user details from second USER message).
-
-
- 463 ERR_NOPERMFORHOST
- ":Your host isn't among the privileged"
-
- - Returned to a client which attempts to register with
- a server which does not been setup to allow
- connections from the host the attempted connection
- is tried.
-
-
-
-Oikarinen & Reed [Page 46]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- 464 ERR_PASSWDMISMATCH
- ":Password incorrect"
-
- - Returned to indicate a failed attempt at registering
- a connection for which a password was required and
- was either not given or incorrect.
-
- 465 ERR_YOUREBANNEDCREEP
- ":You are banned from this server"
-
- - Returned after an attempt to connect and register
- yourself with a server which has been setup to
- explicitly deny connections to you.
-
- 467 ERR_KEYSET
- "<channel> :Channel key already set"
- 471 ERR_CHANNELISFULL
- "<channel> :Cannot join channel (+l)"
- 472 ERR_UNKNOWNMODE
- "<char> :is unknown mode char to me"
- 473 ERR_INVITEONLYCHAN
- "<channel> :Cannot join channel (+i)"
- 474 ERR_BANNEDFROMCHAN
- "<channel> :Cannot join channel (+b)"
- 475 ERR_BADCHANNELKEY
- "<channel> :Cannot join channel (+k)"
- 481 ERR_NOPRIVILEGES
- ":Permission Denied- You're not an IRC operator"
-
- - Any command requiring operator privileges to operate
- must return this error to indicate the attempt was
- unsuccessful.
-
- 482 ERR_CHANOPRIVSNEEDED
- "<channel> :You're not channel operator"
-
- - Any command requiring 'chanop' privileges (such as
- MODE messages) must return this error if the client
- making the attempt is not a chanop on the specified
- channel.
-
- 483 ERR_CANTKILLSERVER
- ":You cant kill a server!"
-
- - Any attempts to use the KILL command on a server
- are to be refused and this error returned directly
- to the client.
-
-
-
-
-Oikarinen & Reed [Page 47]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- 491 ERR_NOOPERHOST
- ":No O-lines for your host"
-
- - If a client sends an OPER message and the server has
- not been configured to allow connections from the
- client's host as an operator, this error must be
- returned.
-
- 501 ERR_UMODEUNKNOWNFLAG
- ":Unknown MODE flag"
-
- - Returned by the server to indicate that a MODE
- message was sent with a nickname parameter and that
- the a mode flag sent was not recognized.
-
- 502 ERR_USERSDONTMATCH
- ":Cant change mode for other users"
-
- - Error sent to any user trying to view or change the
- user mode for a user other than themselves.
-
-6.2 Command responses.
-
- 300 RPL_NONE
- Dummy reply number. Not used.
-
- 302 RPL_USERHOST
- ":[<reply>{<space><reply>}]"
-
- - Reply format used by USERHOST to list replies to
- the query list. The reply string is composed as
- follows:
-
- <reply> ::= <nick>['*'] '=' <'+'|'-'><hostname>
-
- The '*' indicates whether the client has registered
- as an Operator. The '-' or '+' characters represent
- whether the client has set an AWAY message or not
- respectively.
-
- 303 RPL_ISON
- ":[<nick> {<space><nick>}]"
-
- - Reply format used by ISON to list replies to the
- query list.
-
- 301 RPL_AWAY
- "<nick> :<away message>"
-
-
-
-Oikarinen & Reed [Page 48]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- 305 RPL_UNAWAY
- ":You are no longer marked as being away"
- 306 RPL_NOWAWAY
- ":You have been marked as being away"
-
- - These replies are used with the AWAY command (if
- allowed). RPL_AWAY is sent to any client sending a
- PRIVMSG to a client which is away. RPL_AWAY is only
- sent by the server to which the client is connected.
- Replies RPL_UNAWAY and RPL_NOWAWAY are sent when the
- client removes and sets an AWAY message.
-
- 311 RPL_WHOISUSER
- "<nick> <user> <host> * :<real name>"
- 312 RPL_WHOISSERVER
- "<nick> <server> :<server info>"
- 313 RPL_WHOISOPERATOR
- "<nick> :is an IRC operator"
- 317 RPL_WHOISIDLE
- "<nick> <integer> :seconds idle"
- 318 RPL_ENDOFWHOIS
- "<nick> :End of /WHOIS list"
- 319 RPL_WHOISCHANNELS
- "<nick> :{[@|+]<channel><space>}"
-
- - Replies 311 - 313, 317 - 319 are all replies
- generated in response to a WHOIS message. Given that
- there are enough parameters present, the answering
- server must either formulate a reply out of the above
- numerics (if the query nick is found) or return an
- error reply. The '*' in RPL_WHOISUSER is there as
- the literal character and not as a wild card. For
- each reply set, only RPL_WHOISCHANNELS may appear
- more than once (for long lists of channel names).
- The '@' and '+' characters next to the channel name
- indicate whether a client is a channel operator or
- has been granted permission to speak on a moderated
- channel. The RPL_ENDOFWHOIS reply is used to mark
- the end of processing a WHOIS message.
-
- 314 RPL_WHOWASUSER
- "<nick> <user> <host> * :<real name>"
- 369 RPL_ENDOFWHOWAS
- "<nick> :End of WHOWAS"
-
- - When replying to a WHOWAS message, a server must use
- the replies RPL_WHOWASUSER, RPL_WHOISSERVER or
- ERR_WASNOSUCHNICK for each nickname in the presented
-
-
-
-Oikarinen & Reed [Page 49]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- list. At the end of all reply batches, there must
- be RPL_ENDOFWHOWAS (even if there was only one reply
- and it was an error).
-
- 321 RPL_LISTSTART
- "Channel :Users Name"
- 322 RPL_LIST
- "<channel> <# visible> :<topic>"
- 323 RPL_LISTEND
- ":End of /LIST"
-
- - Replies RPL_LISTSTART, RPL_LIST, RPL_LISTEND mark
- the start, actual replies with data and end of the
- server's response to a LIST command. If there are
- no channels available to return, only the start
- and end reply must be sent.
-
- 324 RPL_CHANNELMODEIS
- "<channel> <mode> <mode params>"
-
- 331 RPL_NOTOPIC
- "<channel> :No topic is set"
- 332 RPL_TOPIC
- "<channel> :<topic>"
-
- - When sending a TOPIC message to determine the
- channel topic, one of two replies is sent. If
- the topic is set, RPL_TOPIC is sent back else
- RPL_NOTOPIC.
-
- 341 RPL_INVITING
- "<channel> <nick>"
-
- - Returned by the server to indicate that the
- attempted INVITE message was successful and is
- being passed onto the end client.
-
- 342 RPL_SUMMONING
- "<user> :Summoning user to IRC"
-
- - Returned by a server answering a SUMMON message to
- indicate that it is summoning that user.
-
- 351 RPL_VERSION
- "<version>.<debuglevel> <server> :<comments>"
-
- - Reply by the server showing its version details.
- The <version> is the version of the software being
-
-
-
-Oikarinen & Reed [Page 50]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- used (including any patchlevel revisions) and the
- <debuglevel> is used to indicate if the server is
- running in "debug mode".
-
- The "comments" field may contain any comments about
- the version or further version details.
-
- 352 RPL_WHOREPLY
- "<channel> <user> <host> <server> <nick> \
- <H|G>[*][@|+] :<hopcount> <real name>"
- 315 RPL_ENDOFWHO
- "<name> :End of /WHO list"
-
- - The RPL_WHOREPLY and RPL_ENDOFWHO pair are used
- to answer a WHO message. The RPL_WHOREPLY is only
- sent if there is an appropriate match to the WHO
- query. If there is a list of parameters supplied
- with a WHO message, a RPL_ENDOFWHO must be sent
- after processing each list item with <name> being
- the item.
-
- 353 RPL_NAMREPLY
- "<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]"
- 366 RPL_ENDOFNAMES
- "<channel> :End of /NAMES list"
-
- - To reply to a NAMES message, a reply pair consisting
- of RPL_NAMREPLY and RPL_ENDOFNAMES is sent by the
- server back to the client. If there is no channel
- found as in the query, then only RPL_ENDOFNAMES is
- returned. The exception to this is when a NAMES
- message is sent with no parameters and all visible
- channels and contents are sent back in a series of
- RPL_NAMEREPLY messages with a RPL_ENDOFNAMES to mark
- the end.
-
- 364 RPL_LINKS
- "<mask> <server> :<hopcount> <server info>"
- 365 RPL_ENDOFLINKS
- "<mask> :End of /LINKS list"
-
- - In replying to the LINKS message, a server must send
- replies back using the RPL_LINKS numeric and mark the
- end of the list using an RPL_ENDOFLINKS reply.
-
- 367 RPL_BANLIST
- "<channel> <banid>"
- 368 RPL_ENDOFBANLIST
-
-
-
-Oikarinen & Reed [Page 51]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- "<channel> :End of channel ban list"
-
- - When listing the active 'bans' for a given channel,
- a server is required to send the list back using the
- RPL_BANLIST and RPL_ENDOFBANLIST messages. A separate
- RPL_BANLIST is sent for each active banid. After the
- banids have been listed (or if none present) a
- RPL_ENDOFBANLIST must be sent.
-
- 371 RPL_INFO
- ":<string>"
- 374 RPL_ENDOFINFO
- ":End of /INFO list"
-
- - A server responding to an INFO message is required to
- send all its 'info' in a series of RPL_INFO messages
- with a RPL_ENDOFINFO reply to indicate the end of the
- replies.
-
- 375 RPL_MOTDSTART
- ":- <server> Message of the day - "
- 372 RPL_MOTD
- ":- <text>"
- 376 RPL_ENDOFMOTD
- ":End of /MOTD command"
-
- - When responding to the MOTD message and the MOTD file
- is found, the file is displayed line by line, with
- each line no longer than 80 characters, using
- RPL_MOTD format replies. These should be surrounded
- by a RPL_MOTDSTART (before the RPL_MOTDs) and an
- RPL_ENDOFMOTD (after).
-
- 381 RPL_YOUREOPER
- ":You are now an IRC operator"
-
- - RPL_YOUREOPER is sent back to a client which has
- just successfully issued an OPER message and gained
- operator status.
-
- 382 RPL_REHASHING
- "<config file> :Rehashing"
-
- - If the REHASH option is used and an operator sends
- a REHASH message, an RPL_REHASHING is sent back to
- the operator.
-
- 391 RPL_TIME
-
-
-
-Oikarinen & Reed [Page 52]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- "<server> :<string showing server's local time>"
-
- - When replying to the TIME message, a server must send
- the reply using the RPL_TIME format above. The string
- showing the time need only contain the correct day and
- time there. There is no further requirement for the
- time string.
-
- 392 RPL_USERSSTART
- ":UserID Terminal Host"
- 393 RPL_USERS
- ":%-8s %-9s %-8s"
- 394 RPL_ENDOFUSERS
- ":End of users"
- 395 RPL_NOUSERS
- ":Nobody logged in"
-
- - If the USERS message is handled by a server, the
- replies RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS and
- RPL_NOUSERS are used. RPL_USERSSTART must be sent
- first, following by either a sequence of RPL_USERS
- or a single RPL_NOUSER. Following this is
- RPL_ENDOFUSERS.
-
- 200 RPL_TRACELINK
- "Link <version & debug level> <destination> \
- <next server>"
- 201 RPL_TRACECONNECTING
- "Try. <class> <server>"
- 202 RPL_TRACEHANDSHAKE
- "H.S. <class> <server>"
- 203 RPL_TRACEUNKNOWN
- "???? <class> [<client IP address in dot form>]"
- 204 RPL_TRACEOPERATOR
- "Oper <class> <nick>"
- 205 RPL_TRACEUSER
- "User <class> <nick>"
- 206 RPL_TRACESERVER
- "Serv <class> <int>S <int>C <server> \
- <nick!user|*!*>@<host|server>"
- 208 RPL_TRACENEWTYPE
- "<newtype> 0 <client name>"
- 261 RPL_TRACELOG
- "File <logfile> <debug level>"
-
- - The RPL_TRACE* are all returned by the server in
- response to the TRACE message. How many are
- returned is dependent on the the TRACE message and
-
-
-
-Oikarinen & Reed [Page 53]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- whether it was sent by an operator or not. There
- is no predefined order for which occurs first.
- Replies RPL_TRACEUNKNOWN, RPL_TRACECONNECTING and
- RPL_TRACEHANDSHAKE are all used for connections
- which have not been fully established and are either
- unknown, still attempting to connect or in the
- process of completing the 'server handshake'.
- RPL_TRACELINK is sent by any server which handles
- a TRACE message and has to pass it on to another
- server. The list of RPL_TRACELINKs sent in
- response to a TRACE command traversing the IRC
- network should reflect the actual connectivity of
- the servers themselves along that path.
- RPL_TRACENEWTYPE is to be used for any connection
- which does not fit in the other categories but is
- being displayed anyway.
-
- 211 RPL_STATSLINKINFO
- "<linkname> <sendq> <sent messages> \
- <sent bytes> <received messages> \
- <received bytes> <time open>"
- 212 RPL_STATSCOMMANDS
- "<command> <count>"
- 213 RPL_STATSCLINE
- "C <host> * <name> <port> <class>"
- 214 RPL_STATSNLINE
- "N <host> * <name> <port> <class>"
- 215 RPL_STATSILINE
- "I <host> * <host> <port> <class>"
- 216 RPL_STATSKLINE
- "K <host> * <username> <port> <class>"
- 218 RPL_STATSYLINE
- "Y <class> <ping frequency> <connect \
- frequency> <max sendq>"
- 219 RPL_ENDOFSTATS
- "<stats letter> :End of /STATS report"
- 241 RPL_STATSLLINE
- "L <hostmask> * <servername> <maxdepth>"
- 242 RPL_STATSUPTIME
- ":Server Up %d days %d:%02d:%02d"
- 243 RPL_STATSOLINE
- "O <hostmask> * <name>"
- 244 RPL_STATSHLINE
- "H <hostmask> * <servername>"
-
- 221 RPL_UMODEIS
- "<user mode string>"
-
-
-
-
-Oikarinen & Reed [Page 54]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- - To answer a query about a client's own mode,
- RPL_UMODEIS is sent back.
-
- 251 RPL_LUSERCLIENT
- ":There are <integer> users and <integer> \
- invisible on <integer> servers"
- 252 RPL_LUSEROP
- "<integer> :operator(s) online"
- 253 RPL_LUSERUNKNOWN
- "<integer> :unknown connection(s)"
- 254 RPL_LUSERCHANNELS
- "<integer> :channels formed"
- 255 RPL_LUSERME
- ":I have <integer> clients and <integer> \
- servers"
-
- - In processing an LUSERS message, the server
- sends a set of replies from RPL_LUSERCLIENT,
- RPL_LUSEROP, RPL_USERUNKNOWN,
- RPL_LUSERCHANNELS and RPL_LUSERME. When
- replying, a server must send back
- RPL_LUSERCLIENT and RPL_LUSERME. The other
- replies are only sent back if a non-zero count
- is found for them.
-
- 256 RPL_ADMINME
- "<server> :Administrative info"
- 257 RPL_ADMINLOC1
- ":<admin info>"
- 258 RPL_ADMINLOC2
- ":<admin info>"
- 259 RPL_ADMINEMAIL
- ":<admin info>"
-
- - When replying to an ADMIN message, a server
- is expected to use replies RLP_ADMINME
- through to RPL_ADMINEMAIL and provide a text
- message with each. For RPL_ADMINLOC1 a
- description of what city, state and country
- the server is in is expected, followed by
- details of the university and department
- (RPL_ADMINLOC2) and finally the administrative
- contact for the server (an email address here
- is required) in RPL_ADMINEMAIL.
-
-
-
-
-
-
-
-Oikarinen & Reed [Page 55]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-6.3 Reserved numerics.
-
- These numerics are not described above since they fall into one of
- the following categories:
-
- 1. no longer in use;
-
- 2. reserved for future planned use;
-
- 3. in current use but are part of a non-generic 'feature' of
- the current IRC server.
-
- 209 RPL_TRACECLASS 217 RPL_STATSQLINE
- 231 RPL_SERVICEINFO 232 RPL_ENDOFSERVICES
- 233 RPL_SERVICE 234 RPL_SERVLIST
- 235 RPL_SERVLISTEND
- 316 RPL_WHOISCHANOP 361 RPL_KILLDONE
- 362 RPL_CLOSING 363 RPL_CLOSEEND
- 373 RPL_INFOSTART 384 RPL_MYPORTIS
- 466 ERR_YOUWILLBEBANNED 476 ERR_BADCHANMASK
- 492 ERR_NOSERVICEHOST
-
-7. Client and server authentication
-
- Clients and servers are both subject to the same level of
- authentication. For both, an IP number to hostname lookup (and
- reverse check on this) is performed for all connections made to the
- server. Both connections are then subject to a password check (if
- there is a password set for that connection). These checks are
- possible on all connections although the password check is only
- commonly used with servers.
-
- An additional check that is becoming of more and more common is that
- of the username responsible for making the connection. Finding the
- username of the other end of the connection typically involves
- connecting to an authentication server such as IDENT as described in
- RFC 1413.
-
- Given that without passwords it is not easy to reliably determine who
- is on the other end of a network connection, use of passwords is
- strongly recommended on inter-server connections in addition to any
- other measures such as using an ident server.
-
-8. Current implementations
-
- The only current implementation of this protocol is the IRC server,
- version 2.8. Earlier versions may implement some or all of the
- commands described by this document with NOTICE messages replacing
-
-
-
-Oikarinen & Reed [Page 56]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- many of the numeric replies. Unfortunately, due to backward
- compatibility requirements, the implementation of some parts of this
- document varies with what is laid out. On notable difference is:
-
- * recognition that any LF or CR anywhere in a message marks the
- end of that message (instead of requiring CR-LF);
-
- The rest of this section deals with issues that are mostly of
- importance to those who wish to implement a server but some parts
- also apply directly to clients as well.
-
-8.1 Network protocol: TCP - why it is best used here.
-
- IRC has been implemented on top of TCP since TCP supplies a reliable
- network protocol which is well suited to this scale of conferencing.
- The use of multicast IP is an alternative, but it is not widely
- available or supported at the present time.
-
-8.1.1 Support of Unix sockets
-
- Given that Unix domain sockets allow listen/connect operations, the
- current implementation can be configured to listen and accept both
- client and server connections on a Unix domain socket. These are
- recognized as sockets where the hostname starts with a '/'.
-
- When providing any information about the connections on a Unix domain
- socket, the server is required to supplant the actual hostname in
- place of the pathname unless the actual socket name is being asked
- for.
-
-8.2 Command Parsing
-
- To provide useful 'non-buffered' network IO for clients and servers,
- each connection is given its own private 'input buffer' in which the
- results of the most recent read and parsing are kept. A buffer size
- of 512 bytes is used so as to hold 1 full message, although, this
- will usually hold several commands. The private buffer is parsed
- after every read operation for valid messages. When dealing with
- multiple messages from one client in the buffer, care should be taken
- in case one happens to cause the client to be 'removed'.
-
-8.3 Message delivery
-
- It is common to find network links saturated or hosts to which you
- are sending data unable to send data. Although Unix typically
- handles this through the TCP window and internal buffers, the server
- often has large amounts of data to send (especially when a new
- server-server link forms) and the small buffers provided in the
-
-
-
-Oikarinen & Reed [Page 57]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- kernel are not enough for the outgoing queue. To alleviate this
- problem, a "send queue" is used as a FIFO queue for data to be sent.
- A typical "send queue" may grow to 200 Kbytes on a large IRC network
- with a slow network connection when a new server connects.
-
- When polling its connections, a server will first read and parse all
- incoming data, queuing any data to be sent out. When all available
- input is processed, the queued data is sent. This reduces the number
- of write() system calls and helps TCP make bigger packets.
-
-8.4 Connection 'Liveness'
-
- To detect when a connection has died or become unresponsive, the
- server must ping each of its connections that it doesn't get a
- response from in a given amount of time.
-
- If a connection doesn't respond in time, its connection is closed
- using the appropriate procedures. A connection is also dropped if
- its sendq grows beyond the maximum allowed, because it is better to
- close a slow connection than have a server process block.
-
-8.5 Establishing a server to client connection
-
- Upon connecting to an IRC server, a client is sent the MOTD (if
- present) as well as the current user/server count (as per the LUSER
- command). The server is also required to give an unambiguous message
- to the client which states its name and version as well as any other
- introductory messages which may be deemed appropriate.
-
- After dealing with this, the server must then send out the new user's
- nickname and other information as supplied by itself (USER command)
- and as the server could discover (from DNS/authentication servers).
- The server must send this information out with NICK first followed by
- USER.
-
-8.6 Establishing a server-server connection.
-
- The process of establishing of a server-to-server connection is
- fraught with danger since there are many possible areas where
- problems can occur - the least of which are race conditions.
-
- After a server has received a connection following by a PASS/SERVER
- pair which were recognised as being valid, the server should then
- reply with its own PASS/SERVER information for that connection as
- well as all of the other state information it knows about as
- described below.
-
- When the initiating server receives a PASS/SERVER pair, it too then
-
-
-
-Oikarinen & Reed [Page 58]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- checks that the server responding is authenticated properly before
- accepting the connection to be that server.
-
-8.6.1 Server exchange of state information when connecting
-
- The order of state information being exchanged between servers is
- essential. The required order is as follows:
-
- * all known other servers;
-
- * all known user information;
-
- * all known channel information.
-
- Information regarding servers is sent via extra SERVER messages, user
- information with NICK/USER/MODE/JOIN messages and channels with MODE
- messages.
-
- NOTE: channel topics are *NOT* exchanged here because the TOPIC
- command overwrites any old topic information, so at best, the two
- sides of the connection would exchange topics.
-
- By passing the state information about servers first, any collisions
- with servers that already exist occur before nickname collisions due
- to a second server introducing a particular nickname. Due to the IRC
- network only being able to exist as an acyclic graph, it may be
- possible that the network has already reconnected in another
- location, the place where the collision occurs indicating where the
- net needs to split.
-
-8.7 Terminating server-client connections
-
- When a client connection closes, a QUIT message is generated on
- behalf of the client by the server to which the client connected. No
- other message is to be generated or used.
-
-8.8 Terminating server-server connections
-
- If a server-server connection is closed, either via a remotely
- generated SQUIT or 'natural' causes, the rest of the connected IRC
- network must have its information updated with by the server which
- detected the closure. The server then sends a list of SQUITs (one
- for each server behind that connection) and a list of QUITs (again,
- one for each client behind that connection).
-
-
-
-
-
-
-
-Oikarinen & Reed [Page 59]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-8.9 Tracking nickname changes
-
- All IRC servers are required to keep a history of recent nickname
- changes. This is required to allow the server to have a chance of
- keeping in touch of things when nick-change race conditions occur
- with commands which manipulate them. Commands which must trace nick
- changes are:
-
- * KILL (the nick being killed)
-
- * MODE (+/- o,v)
-
- * KICK (the nick being kicked)
-
- No other commands are to have nick changes checked for.
-
- In the above cases, the server is required to first check for the
- existence of the nickname, then check its history to see who that
- nick currently belongs to (if anyone!). This reduces the chances of
- race conditions but they can still occur with the server ending up
- affecting the wrong client. When performing a change trace for an
- above command it is recommended that a time range be given and
- entries which are too old ignored.
-
- For a reasonable history, a server should be able to keep previous
- nickname for every client it knows about if they all decided to
- change. This size is limited by other factors (such as memory, etc).
-
-8.10 Flood control of clients
-
- With a large network of interconnected IRC servers, it is quite easy
- for any single client attached to the network to supply a continuous
- stream of messages that result in not only flooding the network, but
- also degrading the level of service provided to others. Rather than
- require every 'victim' to be provide their own protection, flood
- protection was written into the server and is applied to all clients
- except services. The current algorithm is as follows:
-
- * check to see if client's `message timer' is less than
- current time (set to be equal if it is);
-
- * read any data present from the client;
-
- * while the timer is less than ten seconds ahead of the current
- time, parse any present messages and penalize the client by
- 2 seconds for each message;
-
- which in essence means that the client may send 1 message every 2
-
-
-
-Oikarinen & Reed [Page 60]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- seconds without being adversely affected.
-
-8.11 Non-blocking lookups
-
- In a real-time environment, it is essential that a server process do
- as little waiting as possible so that all the clients are serviced
- fairly. Obviously this requires non-blocking IO on all network
- read/write operations. For normal server connections, this was not
- difficult, but there are other support operations that may cause the
- server to block (such as disk reads). Where possible, such activity
- should be performed with a short timeout.
-
-8.11.1 Hostname (DNS) lookups
-
- Using the standard resolver libraries from Berkeley and others has
- meant large delays in some cases where replies have timed out. To
- avoid this, a separate set of DNS routines were written which were
- setup for non-blocking IO operations and then polled from within the
- main server IO loop.
-
-8.11.2 Username (Ident) lookups
-
- Although there are numerous ident libraries for use and inclusion
- into other programs, these caused problems since they operated in a
- synchronous manner and resulted in frequent delays. Again the
- solution was to write a set of routines which would cooperate with
- the rest of the server and work using non-blocking IO.
-
-8.12 Configuration File
-
- To provide a flexible way of setting up and running the server, it is
- recommended that a configuration file be used which contains
- instructions to the server on the following:
-
- * which hosts to accept client connections from;
-
- * which hosts to allow to connect as servers;
-
- * which hosts to connect to (both actively and
- passively);
-
- * information about where the server is (university,
- city/state, company are examples of this);
-
- * who is responsible for the server and an email address
- at which they can be contacted;
-
- * hostnames and passwords for clients which wish to be given
-
-
-
-Oikarinen & Reed [Page 61]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- access to restricted operator commands.
-
- In specifying hostnames, both domain names and use of the 'dot'
- notation (127.0.0.1) should both be accepted. It must be possible to
- specify the password to be used/accepted for all outgoing and
- incoming connections (although the only outgoing connections are
- those to other servers).
-
- The above list is the minimum requirement for any server which wishes
- to make a connection with another server. Other items which may be
- of use are:
-
- * specifying which servers other server may introduce;
-
- * how deep a server branch is allowed to become;
-
- * hours during which clients may connect.
-
-8.12.1 Allowing clients to connect
-
- A server should use some sort of 'access control list' (either in the
- configuration file or elsewhere) that is read at startup and used to
- decide what hosts clients may use to connect to it.
-
- Both 'deny' and 'allow' should be implemented to provide the required
- flexibility for host access control.
-
-8.12.2 Operators
-
- The granting of operator privileges to a disruptive person can have
- dire consequences for the well-being of the IRC net in general due to
- the powers given to them. Thus, the acquisition of such powers
- should not be very easy. The current setup requires two 'passwords'
- to be used although one of them is usually easy guessed. Storage of
- oper passwords in configuration files is preferable to hard coding
- them in and should be stored in a crypted format (ie using crypt(3)
- from Unix) to prevent easy theft.
-
-8.12.3 Allowing servers to connect
-
- The interconnection of server is not a trivial matter: a bad
- connection can have a large impact on the usefulness of IRC. Thus,
- each server should have a list of servers to which it may connect and
- which servers may connect to it. Under no circumstances should a
- server allow an arbitrary host to connect as a server. In addition
- to which servers may and may not connect, the configuration file
- should also store the password and other characteristics of that
- link.
-
-
-
-Oikarinen & Reed [Page 62]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-8.12.4 Administrivia
-
- To provide accurate and valid replies to the ADMIN command (see
- section 4.3.7), the server should find the relevant details in the
- configuration.
-
-8.13 Channel membership
-
- The current server allows any registered local user to join upto 10
- different channels. There is no limit imposed on non-local users so
- that the server remains (reasonably) consistant with all others on a
- channel membership basis
-
-9. Current problems
-
- There are a number of recognized problems with this protocol, all of
- which hope to be solved sometime in the near future during its
- rewrite. Currently, work is underway to find working solutions to
- these problems.
-
-9.1 Scalability
-
- It is widely recognized that this protocol does not scale
- sufficiently well when used in a large arena. The main problem comes
- from the requirement that all servers know about all other servers
- and users and that information regarding them be updated as soon as
- it changes. It is also desirable to keep the number of servers low
- so that the path length between any two points is kept minimal and
- the spanning tree as strongly branched as possible.
-
-9.2 Labels
-
- The current IRC protocol has 3 types of labels: the nickname, the
- channel name and the server name. Each of the three types has its
- own domain and no duplicates are allowed inside that domain.
- Currently, it is possible for users to pick the label for any of the
- three, resulting in collisions. It is widely recognized that this
- needs reworking, with a plan for unique names for channels and nicks
- that don't collide being desirable as well as a solution allowing a
- cyclic tree.
-
-9.2.1 Nicknames
-
- The idea of the nickname on IRC is very convenient for users to use
- when talking to each other outside of a channel, but there is only a
- finite nickname space and being what they are, its not uncommon for
- several people to want to use the same nick. If a nickname is chosen
- by two people using this protocol, either one will not succeed or
-
-
-
-Oikarinen & Reed [Page 63]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
- both will removed by use of KILL (4.6.1).
-
-9.2.2 Channels
-
- The current channel layout requires that all servers know about all
- channels, their inhabitants and properties. Besides not scaling
- well, the issue of privacy is also a concern. A collision of
- channels is treated as an inclusive event (both people who create the
- new channel are considered to be members of it) rather than an
- exclusive one such as used to solve nickname collisions.
-
-9.2.3 Servers
-
- Although the number of servers is usually small relative to the
- number of users and channels, they two currently required to be known
- globally, either each one separately or hidden behind a mask.
-
-9.3 Algorithms
-
- In some places within the server code, it has not been possible to
- avoid N^2 algorithms such as checking the channel list of a set
- of clients.
-
- In current server versions, there are no database consistency checks,
- each server assumes that a neighbouring server is correct. This
- opens the door to large problems if a connecting server is buggy or
- otherwise tries to introduce contradictions to the existing net.
-
- Currently, because of the lack of unique internal and global labels,
- there are a multitude of race conditions that exist. These race
- conditions generally arise from the problem of it taking time for
- messages to traverse and effect the IRC network. Even by changing to
- unique labels, there are problems with channel-related commands being
- disrupted.
-
-10. Current support and availability
-
- Mailing lists for IRC related discussion:
- Future protocol: ircd-three-request@eff.org
- General discussion: operlist-request@eff.org
-
- Software implemenations
- cs.bu.edu:/irc
- nic.funet.fi:/pub/irc
- coombs.anu.edu.au:/pub/irc
-
- Newsgroup: alt.irc
-
-
-
-
-Oikarinen & Reed [Page 64]
-
-RFC 1459 Internet Relay Chat Protocol May 1993
-
-
-Security Considerations
-
- Security issues are discussed in sections 4.1, 4.1.1, 4.1.3, 5.5, and
- 7.
-
-12. Authors' Addresses
-
- Jarkko Oikarinen
- Tuirantie 17 as 9
- 90500 OULU
- FINLAND
-
- Email: jto@tolsun.oulu.fi
-
-
- Darren Reed
- 4 Pateman Street
- Watsonia, Victoria 3087
- Australia
-
- Email: avalon@coombs.anu.edu.au
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Oikarinen & Reed [Page 65]
- \ No newline at end of file
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 19:11:42 +0000