archive-gr.com » GR » T » TEIPIR.GR

Total: 878

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".

  • words any opaque auth structure is an auth flavor enumeration followed by bytes which are opaque to uninterpreted by the RPC protocol implementation The interpretation and semantics of the data contained within the authentication fields is specified by individual independent authentication protocol specifications Section 9 defines the various authentication protocols If authentication parameters were rejected the reply message contains information stating why they were rejected Sun Microsystems Page 6 RFC 1057 Remote Procedure Call Version 2 June 1988 7 3 Program Number Assignment Program numbers are given out in groups of hexadecimal 20000000 decimal 536870912 according to the following chart 0 1fffffff defined by Sun 20000000 3fffffff defined by user 40000000 5fffffff transient 60000000 7fffffff reserved 80000000 9fffffff reserved a0000000 bfffffff reserved c0000000 dfffffff reserved e0000000 ffffffff reserved The first group is a range of numbers administered by Sun Microsystems and should be identical for all sites The second range is for applications peculiar to a particular site This range is intended primarily for debugging new programs When a site develops an application that might be of general interest that application should be given an assigned number in the first range The third group is for applications that generate program numbers dynamically The final groups are reserved for future use and should not be used 7 4 Other Uses of the RPC Protocol The intended use of this protocol is for calling remote procedures Normally each call message is matched with a reply message However the protocol itself is a message passing protocol with which other non procedure call protocols can be implemented Sun currently uses or perhaps abuses the RPC message protocol for the batching or pipelining and broadcast remote procedure calls 7 4 1 Batching Batching is useful when a client wishes to send an arbitrarily large sequence of call messages to a server Batching typically uses reliable byte stream protocols like TCP for its transport In the case of batching the client never waits for a reply from the server and the server does not send replies to batch calls A sequence of batch calls is usually terminated by a legitimate remote procedure call operation in order to flush the pipeline and get positive acknowledgement 7 4 2 Broadcast Remote Procedure Calls In broadcast protocols the client sends a broadcast call to the network and waits for numerous replies This requires the use of packet based protocols like UDP as its transport protocol Servers Sun Microsystems Page 7 RFC 1057 Remote Procedure Call Version 2 June 1988 that support broadcast protocols only respond when the call is successfully processed and are silent in the face of errors Broadcast calls use the Port Mapper RPC service to achieve their semantics See Appendix A for more information 8 THE RPC MESSAGE PROTOCOL This section defines the RPC message protocol in the XDR data description language 9 enum msg type CALL 0 REPLY 1 A reply to a call message can take on two forms The message was either accepted or rejected enum reply stat MSG ACCEPTED 0 MSG DENIED 1 Given that a call message was accepted the following is the status of an attempt to call a remote procedure enum accept stat SUCCESS 0 RPC executed successfully PROG UNAVAIL 1 remote hasn t exported program PROG MISMATCH 2 remote can t support version PROC UNAVAIL 3 program can t support procedure GARBAGE ARGS 4 procedure can t decode params Reasons why a call message was rejected enum reject stat RPC MISMATCH 0 RPC version number 2 AUTH ERROR 1 remote can t authenticate caller Sun Microsystems Page 8 RFC 1057 Remote Procedure Call Version 2 June 1988 Why authentication failed enum auth stat AUTH BADCRED 1 bad credentials seal broken AUTH REJECTEDCRED 2 client must begin new session AUTH BADVERF 3 bad verifier seal broken AUTH REJECTEDVERF 4 verifier expired or replayed AUTH TOOWEAK 5 rejected for security reasons The RPC message All messages start with a transaction identifier xid followed by a two armed discriminated union The union s discriminant is a msg type which switches to one of the two types of the message The xid of a REPLY message always matches that of the initiating CALL message NB The xid field is only used for clients matching reply messages with call messages or for servers detecting retransmissions the service side cannot treat this id as any type of sequence number struct rpc msg unsigned int xid union switch msg type mtype case CALL call body cbody case REPLY reply body rbody body Body of an RPC call In version 2 of the RPC protocol specification rpcvers must be equal to 2 The fields prog vers and proc specify the remote program its version number and the procedure within the remote program to be called After these fields are two authentication parameters cred authentication credentials and verf authentication verifier The two authentication parameters are followed by the parameters to the remote procedure which are specified by the specific program protocol Sun Microsystems Page 9 RFC 1057 Remote Procedure Call Version 2 June 1988 struct call body unsigned int rpcvers must be equal to two 2 unsigned int prog unsigned int vers unsigned int proc opaque auth cred opaque auth verf procedure specific parameters start here Body of a reply to an RPC call union reply body switch reply stat stat case MSG ACCEPTED accepted reply areply case MSG DENIED rejected reply rreply reply Reply to an RPC call that was accepted by the server There could be an error even though the call was accepted The first field is an authentication verifier that the server generates in order to validate itself to the client It is followed by a union whose discriminant is an enum accept stat The SUCCESS arm of the union is protocol specific The PROG UNAVAIL PROC UNAVAIL and GARBAGE ARGS arms of the union are void The PROG MISMATCH arm specifies the lowest and highest version numbers of the remote program supported by the server Sun Microsystems Page 10 RFC 1057 Remote Procedure Call Version 2 June 1988 struct accepted reply opaque auth verf union switch accept stat stat case SUCCESS opaque results 0 procedure specific results start here case PROG MISMATCH struct unsigned int low unsigned int high mismatch info default Void Cases include PROG UNAVAIL PROC UNAVAIL and GARBAGE ARGS void reply data Reply to an RPC call that was rejected by the server The call can be rejected for two reasons either the server is not running a compatible version of the RPC protocol RPC MISMATCH or the server refuses to authenticate the caller AUTH ERROR In case of an RPC version mismatch the server returns the lowest and highest supported RPC version numbers In case of refused authentication failure status is returned union rejected reply switch reject stat stat case RPC MISMATCH struct unsigned int low unsigned int high mismatch info case AUTH ERROR auth stat stat Sun Microsystems Page 11 RFC 1057 Remote Procedure Call Version 2 June 1988 9 AUTHENTICATION PROTOCOLS As previously stated authentication parameters are opaque but open ended to the rest of the RPC protocol This section defines some flavors of authentication implemented at and supported by Sun Other sites are free to invent new authentication types with the same rules of flavor number assignment as there is for program number assignment 9 1 Null Authentication Often calls must be made where the client does not know its identity or the server does not care who the client is In this case the flavor value the discriminant of the opaque auth s union of the RPC message s credentials verifier and reply verifier is AUTH NULL The bytes of the opaque auth s body are undefined It is recommended that the opaque length be zero 9 2 UNIX Authentication The client may wish to identify itself as it is identified on a UNIX tm system The value of the credential s discriminant of an RPC call message is AUTH UNIX The bytes of the credential s opaque body encode the the following structure struct auth unix unsigned int stamp string machinename unsigned int uid unsigned int gid unsigned int gids The stamp is an arbitrary ID which the caller machine may generate The machinename is the name of the caller s machine like krypton The uid is the caller s effective user ID The gid is the caller s effective group ID The gids is a counted array of groups which contain the caller as a member The verifier accompanying the credentials should be of AUTH NULL defined above Note these credentials are only unique within a particular domain of machine names uids and gids Inter domain naming is beyond the scope of this document The value of the discriminant of the reply verifier received in the reply message from the server may be AUTH NULL or AUTH SHORT In the case of AUTH SHORT the bytes of the reply verifier s string encode an opaque structure This new opaque structure may now be passed to the server instead of the original AUTH UNIX flavor Sun Microsystems Page 12 RFC 1057 Remote Procedure Call Version 2 June 1988 credentials The server may keep a cache which maps shorthand opaque structures passed back by way of an AUTH SHORT style reply verifier to the original credentials of the caller The caller can save network bandwidth and server cpu cycles by using the new credentials The server may flush the shorthand opaque structure at any time If this happens the remote procedure call message will be rejected due to an authentication error The reason for the failure will be AUTH REJECTEDCRED At this point the client may wish to try the original AUTH UNIX style of credentials 9 3 DES Authentication UNIX authentication suffers from three major problems 1 The naming is too UNIX oriented 2 There is no universal name uid and gid space 3 There is no verifier so credentials can easily be faked DES authentication attempts to address these problems 9 3 1 Naming The first problem is handled by addressing the client by a simple string of characters instead of by an operating system specific integer This string of characters is known as the netname or network name of the client The server is not allowed to interpret the contents of the client s name in any other way except to identify the client Thus netnames should be unique for every client in the Internet It is up to each operating system s implementation of DES authentication to generate netnames for its users that insure this uniqueness when they call upon remote servers Operating systems already know how to distinguish users local to their systems It is usually a simple matter to extend this mechanism to the network For example a UNIX user at Sun with a user ID of 515 might be assigned the following netname unix 515 sun com This netname contains three items that serve to insure it is unique Going backwards there is only one naming domain called sun com in the Internet Within this domain there is only one UNIX user with user ID 515 However there may be another user on another operating system for example VMS within the same naming domain that by coincidence happens to have the same user ID To insure that these two users can be distinguished we add the operating system name So one user is unix 515 sun com and the other is vms 515 sun com Sun Microsystems Page 13 RFC 1057 Remote Procedure Call Version 2 June 1988 The first field is actually a naming method rather than an operating system name It happens that today there is almost a one to one correspondence between naming methods and operating systems If the world could agree on a naming standard the first field could be the name of that standard instead of an operating system name 9 3 2 DES Authentication Verifiers Unlike UNIX authentication DES authentication does have a verifier so the server can validate the client s credential and vice versa The contents of this verifier is primarily an encrypted timestamp The server can decrypt this timestamp and if it is close to the real time then the client must have encrypted it correctly The only way the client could encrypt it correctly is to know the conversation key of the RPC session And if the client knows the conversation key then it must be the real client The conversation key is a DES 5 key which the client generates and passes to the server in its first RPC call The conversation key is encrypted using a public key scheme in this first transaction The particular public key scheme used in DES authentication is Diffie Hellman 3 with 192 bit keys The details of this encryption method are described later The client and the server need the same notion of the current time in order for all of this to work perhaps by using the Network Time Protocol 4 If network time synchronization cannot be guaranteed then the client can determine the server s time before beginning the conversation using a simpler time request protocol The way a server determines if a client timestamp is valid is somewhat complicated For any other transaction but the first the server just checks for two things 1 the timestamp is greater than the one previously seen from the same client 2 the timestamp has not expired A timestamp is expired if the server s time is later than the sum of the client s timestamp plus what is known as the client s window The window is a number the client passes encrypted to the server in its first transaction You can think of it as a lifetime for the credential This explains everything but the first transaction In the first transaction the server checks only that the timestamp has not expired If this was all that was done though then it would be quite easy for the client to send random data in place of the Sun Microsystems Page 14 RFC 1057 Remote Procedure Call Version 2 June 1988 timestamp with a fairly good chance of succeeding As an added check the client sends an encrypted item in the first transaction known as the window verifier which must be equal to the window minus 1 or the server will reject the credential The client too must check the verifier returned from the server to be sure it is legitimate The server sends back to the client the encrypted timestamp it received from the client minus one second If the client gets anything different than this it will reject it 9 3 3 Nicknames and Clock Synchronization After the first transaction the server s DES authentication subsystem returns in its verifier to the client an integer nickname which the client may use in its further transactions instead of passing its netname encrypted DES key and window every time The nickname is most likely an index into a table on the server which stores for each client its netname decrypted DES key and window Though they originally were synchronized the client s and server s clocks can get out of sync again When this happens the client RPC subsystem most likely will get back RPC AUTHERROR at which point it should resynchronize A client may still get the RPC AUTHERROR error even though it is synchronized with the server The reason is that the server s nickname table is a limited size and it may flush entries whenever it wants A client should resend its original credential in this case and the server will give it a new nickname If a server crashes the entire nickname table gets flushed and all clients will have to resend their original credentials 9 3 4 DES Authentication Protocol Specification There are two kinds of credentials one in which the client uses its full network name and one in which it uses its nickname just an unsigned integer given to it by the server The client must use its fullname in its first transaction with the server in which the server will return to the client its nickname The client may use its nickname in all further transactions with the server There is no requirement to use the nickname but it is wise to use it for performance reasons enum authdes namekind ADN FULLNAME 0 ADN NICKNAME 1 Sun Microsystems Page 15 RFC 1057 Remote Procedure Call Version 2 June 1988 A 64 bit block of encrypted DES data typedef opaque des block 8 Maximum length of a network user s name const MAXNETNAMELEN 255 A fullname contains the network name of the client an encrypted conversation key and the window The window is actually a lifetime for the credential If the time indicated in the verifier timestamp plus the window has past then the server should expire the request and not grant it To insure that requests are not replayed the server should insist that timestamps are greater than the previous one seen unless it is the first transaction In the first transaction the server checks instead that the window verifier is one less than the window struct authdes fullname string name name of client des block key PK encrypted conversation key opaque window 4 encrypted window A credential is either a fullname or a nickname union authdes cred switch authdes namekind adc namekind case ADN FULLNAME authdes fullname adc fullname case ADN NICKNAME int adc nickname A timestamp encodes the time since midnight March 1 1970 struct timestamp unsigned int seconds seconds unsigned int useconds and microseconds Verifier client variety The window verifier is only used in the first transaction In conjunction with a fullname credential these items are packed into the following structure before being encrypted Sun Microsystems Page 16 RFC 1057 Remote Procedure Call Version 2 June 1988 struct adv

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc1057.txt (2016-02-14)
    Open archived version from archive



  • 1042 IP and ARP on IEEE 802 Networks February 1988 For IEEE 802 3 A particular implementation of an IEEE 802 3 Physical Layer is denoted using a three field notation The three fields are data rate in megabit second medium type and maximum segment length in hundreds of meters One combination of of 802 3 parameters is 10BASE5 which specifies a 10 megabit second transmission rate baseband medium and 500 meter segments This correspondes to the specifications of the familiar Ethernet network The MAC header contains 6 2 octets of source address 6 2 octets of destination address and 2 octets of length The MAC trailer contains 4 octets of Frame Check Sequence FCS for a total of 18 10 octets IEEE 802 3 networks have a minimum packet size that depends on the transmission rate For type 10BASE5 802 3 networks the minimum packet size is 64 octets IEEE 802 3 networks have a maximum packet size which depends on the transmission rate For type 10BASE5 802 3 networks the maximum packet size is 1518 octets including all octets between the destination address and the FCS inclusive This allows 1518 18 MAC header trailer 8 LLC SNAP header 1492 for the IP datagram including the IP header Note that 1492 is not equal to 1500 which is the MTU for Ethernet networks For IEEE 802 4 The MAC header contains 1 octet of frame control 6 2 octets of source address and 6 2 octets of destination address The MAC trailer contains 4 octets of Frame Check Sequence FCS for a total of 17 9 octets IEEE 802 4 networks have no minimum packet size IEEE 802 4 networks have a maximum packet size of 8191 octets including all octets between the frame control and the FCS inclusive This allows 8191 17 MAC header trailer 8 LLC SNAP header 8166 for the IP datagram including the IP header Postel Reynolds Page 7 RFC 1042 IP and ARP on IEEE 802 Networks February 1988 For IEEE 802 5 The current standard for token ring s IEEE 802 5 1985 specifies the operation of single ring networks However most implementations of 802 5 have added extensions for multi ring networks using source routing of packets at the MAC layer There is now a Draft Addendum to IEEE 802 5 Enhancement for Multi Ring Networks which attempts to standardize these extensions Unfortunately the most recent draft November 10 1987 is still rapidly evolving More importantly it differs significantly from the existing implementations Therefore the existing implementations of 802 5 13 are described but no attempt is made to specify any future standard The MAC header contains 1 octet of access control 1 octet of frame control 6 2 octets of source address 6 2 octets of destination address and for multi ring networks 0 to 18 octets of Routing Information Field RIF The MAC trailer contains 4 octets of FCS for a total of 18 10 to 36 28 octets There is one additional octet of frame status after the FCS Multi Ring Extension Details The presence of a Routing Information Field is indicated by the Most Significant Bit MSB of the source address called the Routing Information Indicator RII If the RII equals zero a RIF is not present If the RII equals 1 the RIF is present Although the RII is indicated in the source address it is not part of a stations MAC layer address In particular the MSB of a destination address is the individual group address indicator and if set will cause such frames to be interpreted as multicasts Implementations should be careful to reset the RII to zero before passing source addresses to other protocol layers which may be confused by their presence The RIF consists of a two octet Routing Control RC field followed by 0 to 8 two octet Route Designator RD fields The RC for all routes broadcast frames is formatted as follows 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 B LTH D LF r Note that each tick mark represents one bit position Postel Reynolds Page 8 RFC 1042 IP and ARP on IEEE 802 Networks February 1988 B Broadcast Indicators 3 bits The Broadcast Indicators are used to indicate the routing desired for a particular frame A frame may be routed through a single specified route through every distinct non repeating route in a multi ring network or through a single route determined by a spanning tree algorithm such that the frame appears on every ring exactly once The values which may be used at this time are in binary 000 Non broadcast specific route 100 All routes broadcast global broadcast 110 Single route broadcast limited broadcast All other values are reserved for future use LTH Length 5 bits The Length bits are used to indicate the length or the RI field including the RC and RD fields Only even values between 2 and 30 inclusive are allowed D Direction Bit 1 bit The D bit specifies the order of the RD fields If D equals 1 the routing designator fields are specified in reverse order LF Largest Frame 3 bits The LF bits specify the maximum MTU supported by all bridges along a specific route All multi ring broadcast frames should be transmitted with a value at least as large as the supported MTU The values used are LF binary MAC MTU IP MTU 000 552 508 001 1064 1020 010 2088 2044 011 4136 4092 100 8232 8188 All other values are reserved for future use The receiver should compare the LF received with the MTU If the LF is greater than or equal to the MTU then no action is taken however if the LF is less than the MTU Postel Reynolds Page 9 RFC 1042 IP and ARP on IEEE 802 Networks February 1988 the frame is rejected There are actually three possible actions if

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc1042.txt (2016-02-14)
    Open archived version from archive


  • domains To join one of these a DA needs to be aware of the purpose for which it was intended ARPA is a temporary domain It is by default appended to the names of hosts that have not yet joined a domain When the system was begun in 1984 the names of all hosts in the Official DoD Internet Host Table maintained by the NIC were changed by adding of the label ARPA in order to accelerate a transition to the domain naming system Another reason for the blanket name changes was to force hosts to become accustomed to using the new style names and to modifiy their network software if necessary This was done on a network wide basis and was directed by DCA in DDN Management Bulletin No 22 Hosts that fall into this domain will eventually move to other branches of the domain tree Stahl Page 4 RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 COM is meant to incorporate subdomains of companies and businesses EDU was initiated to accommodate subdomains set up by universities and other educational institutions GOV exists to act as parent domain for subdomains set up by government agencies MIL was initiated to act as parent to subdomains that are developed by military organizations NET was introduced as a parent domain for various network type organizations Organizations that belong within this top level domain are generic or network specific such as network service centers and consortia NET also encompasses network management related organizations such as information centers and operations centers ORG exists as a parent to subdomains that do not clearly fall within the other top level domains This may include technical support groups professional societies or similar organizations One of the guidelines in effect in the domain naming system is that a host should have only one name regardless of what networks it is connected to This implies that in general domain names should not include routing information or addresses For example a host that has one network connection to the Interent and another to BITNET should use the same name when talking to either network For a description of the syntax of domain names please refer to Section 3 of RFC 1034 VERIFICATION OF DATA The verification process can be accomplished in several ways One of these is through the NIC WHOIS server If he has access to WHOIS the DA can type the commmand whois domain The reply from WHOIS will supply the following the name and address of the organization owning the domain the name of the domain its administrative technical and zone contacts the host names and network addresses of sites providing name service for the domain Stahl Page 5 RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 Example whois domain rice edu Rice University RICE DOM Advanced Studies and Research Houston TX 77001 Domain Name RICE EDU Administrative Contact Kennedy Ken KK28 Kennedy LLL CRG ARPA 713 527 4834 Technical Contact Zone Contact Riffle Vicky R VRR rif RICE EDU 713 527 8101 ext 3844 Domain servers RICE EDU 128 42 5 1 PENDRAGON CS PURDUE EDU 128 10 2 5 Alternatively the DA can send an electronic mail message to SERVICE SRI NIC ARPA In the subject line of the message header the DA should type whois domain The requested information will be returned via electronic mail This method is convenient for sites that do not have access to the NIC WHOIS service The initial application for domain authorization should be submitted via electronic mail if possible to HOSTMASTER SRI NIC ARPA The questionnaire described in the appendix may be used or a separate application can be FTPed from host SRI NIC ARPA The information provided by the administrator will be reviewed by hostmaster personnel for completeness There will most likely be a few exchanges of correspondence via electronic mail the preferred method of communication prior to authorization of the domain HOW TO GET MORE INFORMATION An informational table of the top level domains and their root servers is contained in the file NETINFO DOMAINS TXT online at SRI NIC ARPA This table can be obtained by FTPing the file Alternatively the information can be acquired by opening a TCP or UDP connection to the NIC Host Name Server port 101 on SRI NIC ARPA and invoking the command ALL DOM Stahl Page 6 RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 The following online files all available by FTP from SRI NIC ARPA contain pertinent domain information NETINFO DOMAINS TXT a table of all top level domains and the network addresses of the machines providing domain name service for them It is updated each time a new top level domain is approved NETINFO DOMAIN INFO TXT contains a concise list of all top level and second level domain names registered with the NIC and is updated monthly NETINFO DOMAIN CONTACTS TXT also contains a list of all the top level and second level domains but includes the administrative technical and zone contacts for each as well NETINFO DOMAIN TEMPLATE TXT contains the questionnaire to be completed before registering a top level or second level domain For either general or specific information on the domain system do one or more of the following 1 Send electronic mail to HOSTMASTER SRI NIC ARPA 2 Call the toll free NIC hotline at 800 235 3155 3 Use FTP to get background RFCs and other files maintained online at the NIC Some pertinent RFCs are listed below in the REFERENCES section of this memo Stahl Page 7 RFC 1032 DOMAIN ADMINISTRATORS GUIDE November 1987 REFERENCES The references listed here provide important background information on the domain naming system Path names of the online files available via anonymous FTP from the SRI NIC ARPA host are noted in brackets 1 Defense Communications Agency DDN Defense Communications System DDN Management Bulletin No 22 Domain Names Transition March 1984 DDN NEWS DDN MGT BULLETIN 22 TXT 2 Defense Communications Agency DDN Defense Communications System DDN

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc1032.txt (2016-02-14)
    Open archived version from archive


  • named SRI NIC ARPA may want to have the nickname NIC ARPA In that case the following RR would be used NIC ARPA CNAME SRI NIC ARPA There must not be any other RRs associated with a nickname of the same class Nicknames are also useful when a host changes it s name In that case it is usually a good idea to have a CNAME pointer so that people still using the old name will get to the right place Lottor Page 7 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 HINFO Host Info HINFO The HINFO record gives information about a particular host The data is two strings separated by whitespace The first string is a hardware description and the second is software The hardware is usually a manufacturer name followed by a dash and model designation The software string is usually the name of the operating system Official HINFO types can be found in the latest Assigned Numbers RFC the latest of which is RFC 1010 The Hardware type is called the Machine name and the Software type is called the System name Some sample HINFO records SRI NIC ARPA HINFO DEC 2060 TOPS20 UCBARPA Berkeley EDU HINFO VAX 11 780 UNIX WKS Well Known Services WKS The WKS record is used to list Well Known Services a host provides WKS s are defined to be services on port numbers below 256 The WKS record lists what services are available at a certain address using a certain protocol The common protocols are TCP or UDP A sample WKS record for a host offering the same services on all address would look like Official protocol names can be found in the latest Assigned Numbers RFC the latest of which is RFC 1010 SRI NIC ARPA WKS 10 0 0 51 TCP TELNET FTP SMTP WKS 10 0 0 51 UDP TIME WKS 26 0 0 73 TCP TELNET FTP SMTP WKS 26 0 0 73 UDP TIME MX Mail Exchanger See RFC 974 for more details MX MX records specify where mail for a domain name should be delivered There may be multiple MX records for a particular name The preference value specifies the order a mailer should try multiple MX records when delivering mail Zero is the highest preference Multiple records for the same name may have the same preference Lottor Page 8 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 A host BAR FOO COM may want its mail to be delivered to the host PO FOO COM and would then use the MX record BAR FOO COM MX 10 PO FOO COM A host BAZ FOO COM may want its mail to be delivered to one of three different machines in the following order BAZ FOO COM MX 10 PO1 FOO COM MX 20 PO2 FOO COM MX 30 PO3 FOO COM An entire domain of hosts not connected to the Internet may want their mail to go through a mail gateway that knows how to deliver mail to them If they would like mail addressed to any host in the domain FOO COM to go through the mail gateway they might use FOO COM MX 10 RELAY CS NET FOO COM MX 20 RELAY CS NET Note that you can specify a wildcard in the MX record to match on anything in FOO COM but that it won t match a plain FOO COM IN ADDR ARPA The structure of names in the domain system is set up in a hierarchical way such that the address of a name can be found by tracing down the domain tree contacting a server for each label of the name Because of this indexing based on name there is no easy way to translate a host address back into its host name In order to do the reverse translation easily a domain was created that uses hosts addresses as part of a name that then points to the data for that host In this way there is now an index to hosts RRs based on their address This address mapping domain is called IN ADDR ARPA Within that domain are subdomains for each network based on network number Also for consistency and natural groupings the 4 octets of a host number are reversed For example the ARPANET is net 10 That means there is a domain called 10 IN ADDR ARPA Within this domain there is a PTR RR at 51 0 0 10 IN ADDR that points to the RRs for the host SRI NIC ARPA who s address is 10 0 0 51 Since the NIC is also on the MILNET Net 26 address 26 0 0 73 there is also a PTR RR at 73 0 0 26 IN ADDR ARPA that points to the same RR s for SRI NIC ARPA The format of these special pointers is defined below along with the examples for the NIC Lottor Page 9 RFC 1033 DOMAIN OPERATIONS GUIDE November 1987 PTR PTR The PTR record is used to let special names point to some other location in the domain tree They are mainly used in the IN ADDR ARPA records for translation of addresses to names PTR s should use official names and not aliases For example host SRI NIC ARPA with addresses 10 0 0 51 and 26 0 0 73 would have the following records in the respective zone files for net 10 and net 26 51 0 0 10 IN ADDR ARPA PTR SRI NIC ARPA 73 0 0 26 IN ADDR ARPA PTR SRI NIC ARPA GATEWAY PTR s The IN ADDR tree is also used to locate gateways on a particular network Gateways have the same kind of PTR RRs as hosts as above but in addition they have other PTRs used to locate them by network number alone These records have only 1 2 or 3 octets as part of the name depending on whether they are class A B or C

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc1033.txt (2016-02-14)
    Open archived version from archive


  • send mail to Mockapetris ISI EDU might ask the resolver for mail information about ISI EDU resulting in a query for QNAME ISI EDU QTYPE MX QCLASS IN The response s answer section would be ISI EDU MX 10 VENERA ISI EDU MX 10 VAXA ISI EDU while the additional section might be VAXA ISI EDU A 10 2 0 27 A 128 9 0 33 VENERA ISI EDU A 10 1 0 52 A 128 9 0 32 Because the server assumes that if the requester wants mail exchange information it will probably want the addresses of the mail exchanges soon afterward Note that the QCLASS construct requires special interpretation regarding authority Since a particular name server may not know all of the classes available in the domain system it can never know if it is authoritative for all classes Hence responses to QCLASS queries can Mockapetris Page 17 RFC 1034 Domain Concepts and Facilities November 1987 never be authoritative 3 7 2 Inverse queries Optional Name servers may also support inverse queries that map a particular resource to a domain name or domain names that have that resource For example while a standard query might map a domain name to a SOA RR the corresponding inverse query might map the SOA RR back to the domain name Implementation of this service is optional in a name server but all name servers must at least be able to understand an inverse query message and return a not implemented error response The domain system cannot guarantee the completeness or uniqueness of inverse queries because the domain system is organized by domain name rather than by host address or any other resource type Inverse queries are primarily useful for debugging and database maintenance activities Inverse queries may not return the proper TTL and do not indicate cases where the identified RR is one of a set for example one address for a host having multiple addresses Therefore the RRs returned in inverse queries should never be cached Inverse queries are NOT an acceptable method for mapping host addresses to host names use the IN ADDR ARPA domain instead A detailed discussion of inverse queries is contained in RFC 1035 3 8 Status queries Experimental To be defined 3 9 Completion queries Obsolete The optional completion services described in RFCs 882 and 883 have been deleted Redesigned services may become available in the future or the opcodes may be reclaimed for other use 4 NAME SERVERS 4 1 Introduction Name servers are the repositories of information that make up the domain database The database is divided up into sections called zones which are distributed among the name servers While name servers can have several optional functions and sources of data the essential task of a name server is to answer queries using data in its zones By design Mockapetris Page 18 RFC 1034 Domain Concepts and Facilities November 1987 name servers can answer queries in a simple manner the response can always be generated using only local data and either contains the answer to the question or a referral to other name servers closer to the desired information A given zone will be available from several name servers to insure its availability in spite of host or communication link failure By administrative fiat we require every zone to be available on at least two servers and many zones have more redundancy than that A given name server will typically support one or more zones but this gives it authoritative information about only a small section of the domain tree It may also have some cached non authoritative data about other parts of the tree The name server marks its responses to queries so that the requester can tell whether the response comes from authoritative data or not 4 2 How the database is divided into zones The domain database is partitioned in two ways by class and by cuts made in the name space between nodes The class partition is simple The database for any class is organized delegated and maintained separately from all other classes Since by convention the name spaces are the same for all classes the separate classes can be thought of as an array of parallel namespace trees Note that the data attached to nodes will be different for these different parallel classes The most common reasons for creating a new class are the necessity for a new data format for existing types or a desire for a separately managed version of the existing name space Within a class cuts in the name space can be made between any two adjacent nodes After all cuts are made each group of connected name space is a separate zone The zone is said to be authoritative for all names in the connected region Note that the cuts in the name space may be in different places for different classes the name servers may be different etc These rules mean that every zone has at least one node and hence domain name for which it is authoritative and all of the nodes in a particular zone are connected Given the tree structure every zone has a highest node which is closer to the root than any other node in the zone The name of this node is often used to identify the zone It would be possible though not particularly useful to partition the name space so that each domain name was in a separate zone or so that all nodes were in a single zone Instead the database is partitioned at points where a particular organization wants to take over control of Mockapetris Page 19 RFC 1034 Domain Concepts and Facilities November 1987 a subtree Once an organization controls its own zone it can unilaterally change the data in the zone grow new tree sections connected to the zone delete existing nodes or delegate new subzones under its zone If the organization has substructure it may want to make further internal partitions to achieve nested delegations of name space control In some cases such divisions are made purely to make database maintenance more convenient 4 2 1 Technical considerations The data that describes a zone has four major parts Authoritative data for all nodes within the zone Data that defines the top node of the zone can be thought of as part of the authoritative data Data that describes delegated subzones i e cuts around the bottom of the zone Data that allows access to name servers for subzones sometimes called glue data All of this data is expressed in the form of RRs so a zone can be completely described in terms of a set of RRs Whole zones can be transferred between name servers by transferring the RRs either carried in a series of messages or by FTPing a master file which is a textual representation The authoritative data for a zone is simply all of the RRs attached to all of the nodes from the top node of the zone down to leaf nodes or nodes above cuts around the bottom edge of the zone Though logically part of the authoritative data the RRs that describe the top node of the zone are especially important to the zone s management These RRs are of two types name server RRs that list one per RR all of the servers for the zone and a single SOA RR that describes zone management parameters The RRs that describe cuts around the bottom of the zone are NS RRs that name the servers for the subzones Since the cuts are between nodes these RRs are NOT part of the authoritative data of the zone and should be exactly the same as the corresponding RRs in the top node of the subzone Since name servers are always associated with zone boundaries NS RRs are only found at nodes which are the top node of some zone In the data that makes up a zone NS RRs are found at the top node of the Mockapetris Page 20 RFC 1034 Domain Concepts and Facilities November 1987 zone and are authoritative and at cuts around the bottom of the zone where they are not authoritative but never in between One of the goals of the zone structure is that any zone have all the data required to set up communications with the name servers for any subzones That is parent zones have all the information needed to access servers for their children zones The NS RRs that name the servers for subzones are often not enough for this task since they name the servers but do not give their addresses In particular if the name of the name server is itself in the subzone we could be faced with the situation where the NS RRs tell us that in order to learn a name server s address we should contact the server using the address we wish to learn To fix this problem a zone contains glue RRs which are not part of the authoritative data and are address RRs for the servers These RRs are only necessary if the name server s name is below the cut and are only used as part of a referral response 4 2 2 Administrative considerations When some organization wants to control its own domain the first step is to identify the proper parent zone and get the parent zone s owners to agree to the delegation of control While there are no particular technical constraints dealing with where in the tree this can be done there are some administrative groupings discussed in RFC 1032 which deal with top level organization and middle level zones are free to create their own rules For example one university might choose to use a single zone while another might choose to organize by subzones dedicated to individual departments or schools RFC 1033 catalogs available DNS software an discusses administration procedures Once the proper name for the new subzone is selected the new owners should be required to demonstrate redundant name server support Note that there is no requirement that the servers for a zone reside in a host which has a name in that domain In many cases a zone will be more accessible to the internet at large if its servers are widely distributed rather than being within the physical facilities controlled by the same organization that manages the zone For example in the current DNS one of the name servers for the United Kingdom or UK domain is found in the US This allows US hosts to get UK data without using limited transatlantic bandwidth As the last installation step the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so 4 3 Name server internals Mockapetris Page 21 RFC 1034 Domain Concepts and Facilities November 1987 4 3 1 Queries and responses The principal activity of name servers is to answer standard queries Both the query and its response are carried in a standard message format which is described in RFC 1035 The query contains a QTYPE QCLASS and QNAME which describe the types and classes of desired information and the name of interest The way that the name server answers the query depends upon whether it is operating in recursive mode or not The simplest mode for the server is non recursive since it can answer queries using only local information the response contains an error the answer or a referral to some other server closer to the answer All name servers must implement non recursive queries The simplest mode for the client is recursive since in this mode the name server acts in the role of a resolver and returns either an error or the answer but never referrals This service is optional in a name server and the name server may also choose to restrict the clients which can use recursive mode Recursive service is helpful in several situations a relatively simple requester that lacks the ability to use anything other than a direct answer to the question a request that needs to cross protocol or other boundaries and can be sent to a server which can act as intermediary a network where we want to concentrate the cache rather than having a separate cache for each client Non recursive service is appropriate if the requester is capable of pursuing referrals and interested in information which will aid future requests The use of recursive mode is limited to cases where both the client and the name server agree to its use The agreement is negotiated through the use of two bits in query and response messages The recursion available or RA bit is set or cleared by a name server in all responses The bit is true if the name server is willing to provide recursive service for the client regardless of whether the client requested recursive service That is RA signals availability rather than use Mockapetris Page 22 RFC 1034 Domain Concepts and Facilities November 1987 Queries contain a bit called recursion desired or RD This bit specifies specifies whether the requester wants recursive service for this query Clients may request recursive service from any name server though they should depend upon receiving it only from servers which have previously sent an RA or servers which have agreed to provide service through private agreement or some other means outside of the DNS protocol The recursive mode occurs when a query with RD set arrives at a server which is willing to provide recursive service the client can verify that recursive mode was used by checking that both RA and RD are set in the reply Note that the name server should never perform recursive service unless asked via RD since this interferes with trouble shooting of name servers and their databases If recursive service is requested and available the recursive response to a query will be one of the following The answer to the query possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer A name error indicating that the name does not exist This may include CNAME RRs that indicate that the original query name was an alias for a name which does not exist A temporary error indication If recursive service is not requested or is not available the non recursive response will be one of the following An authoritative name error indicating that the name does not exist A temporary error indication Some combination of RRs that answer the question together with an indication whether the data comes from a zone or is cached A referral to name servers which have zones which are closer ancestors to the name than the server sending the reply RRs that the name server thinks will prove useful to the requester Mockapetris Page 23 RFC 1034 Domain Concepts and Facilities November 1987 4 3 2 Algorithm The actual algorithm used by the name server will depend on the local OS and data structures used to store RRs The following algorithm assumes that the RRs are organized in several tree structures one for each zone and another for the cache 1 Set or clear the value of recursion available in the response depending on whether the name server is willing to provide recursive service If recursive service is available and requested via the RD bit in the query go to step 5 otherwise step 2 2 Search the available zones for the zone which is the nearest ancestor to QNAME If such a zone is found go to step 3 otherwise step 4 3 Start matching down label by label in the zone The matching process can terminate several ways a If the whole of QNAME is matched we have found the node If the data at the node is a CNAME and QTYPE doesn t match CNAME copy the CNAME RR into the answer section of the response change QNAME to the canonical name in the CNAME RR and go back to step 1 Otherwise copy all RRs which match QTYPE into the answer section and go to step 6 b If a match would take us out of the authoritative data we have a referral This happens when we encounter a node with NS RRs marking cuts along the bottom of a zone Copy the NS RRs for the subzone into the authority section of the reply Put whatever addresses are available into the additional section using glue RRs if the addresses are not available from authoritative data or the cache Go to step 4 c If at some label a match is impossible i e the corresponding label does not exist look to see if a the label exists If the label does not exist check whether the name we are looking for is the original QNAME in the query Mockapetris Page 24 RFC 1034 Domain Concepts and Facilities November 1987 or a name we have followed due to a CNAME If the name is original set an authoritative name error in the response and exit Otherwise just exit If the label does exist match RRs at that node against QTYPE If any match copy them into the answer section but set the owner of the RR to be QNAME and not the node with the label Go to step 6 4 Start matching down in the cache If QNAME is found in the cache copy all RRs attached to it that match QTYPE into the answer section If there was no delegation from authoritative data look for the best one from the cache and put it in the authority section Go to step 6 5 Using the local resolver or a copy of its algorithm see resolver section of this memo to answer the query Store the results including any intermediate CNAMEs in the answer section of the response 6 Using local data only attempt to add other RRs which may be useful to the additional section of the query Exit 4 3 3 Wildcards In the previous algorithm special treatment was given to RRs with owner names starting with the label Such RRs are called wildcards Wildcard RRs can be thought of as instructions for synthesizing RRs When the appropriate conditions are met the name server creates RRs with an owner name equal to the query name and contents taken from the wildcard RRs This facility is most often used to create a zone which will be used to forward mail from the Internet to some other mail system The general idea is that any name in that zone which is presented to server in a query will be assumed to exist with certain properties unless explicit evidence exists to the contrary Note that the use of the term zone here instead of domain is intentional such defaults do not propagate across zone boundaries although a subzone may choose to achieve that appearance by setting up similar defaults The contents of the wildcard RRs follows the usual rules and formats for RRs The wildcards in the zone have an owner name that controls the query names they will match The owner name of the wildcard RRs is of the form where is any domain name should not contain other labels and should be in the authoritative data of the zone The wildcards potentially apply to descendants of but not to itself Another way Mockapetris Page 25 RFC 1034 Domain Concepts and Facilities November 1987 to look at this is that the label always matches at least one whole label and sometimes more but always whole labels Wildcard RRs do not apply When the query is in another zone That is delegation cancels the wildcard defaults When the query name or a name between the wildcard domain and the query name is know to exist For example if a wildcard RR has an owner name of X and the zone also contains RRs attached to B X the wildcards would apply to queries for name Z X presuming there is no explicit information for Z X but not to B X A B X or X A label appearing in a query name has no special effect but can be used to test for wildcards in an authoritative zone such a query is the only way to get a response containing RRs with an owner name with in it The result of such a query should not be cached Note that the contents of the wildcard RRs are not modified when used to synthesize RRs To illustrate the use of wildcard RRs suppose a large company with a large non IP TCP network wanted to create a mail gateway If the company was called X COM and IP TCP capable gateway machine was called A X COM the following RRs might be entered into the COM zone X COM MX 10 A X COM X COM MX 10 A X COM A X COM A 1 2 3 4 A X COM MX 10 A X COM A X COM MX 10 A X COM This would cause any MX query for any domain name ending in X COM to return an MX RR pointing at A X COM Two wildcard RRs are required since the effect of the wildcard at X COM is inhibited in the A X COM subtree by the explicit data for A X COM Note also that the explicit MX data at X COM and A X COM is required and that none of the RRs above would match a query name of XX COM 4 3 4 Negative response caching Optional The DNS provides an optional service which allows name servers to distribute and resolvers to cache negative results with TTLs For Mockapetris Page 26 RFC 1034 Domain Concepts and Facilities November 1987 example a name server can distribute a TTL along with a name error indication and a resolver receiving such information is allowed to assume that the name does not exist during the TTL period without consulting authoritative data Similarly a resolver can make a query with a QTYPE which matches multiple types and cache the fact that some of the types are not present This feature can be particularly important in a system which implements naming shorthands that use search lists beacuse a popular shorthand which happens to require a suffix toward the end of the search list will generate multiple name errors whenever it is used The method is that a name server may add an SOA RR to the additional section of a response when that response is authoritative The SOA must be that of the zone which was the source of the authoritative data in the answer section or name error if applicable The MINIMUM field of the SOA controls the length of time that the negative result may be cached Note that in some circumstances the answer section may contain multiple owner names In this case the SOA mechanism should only be used for the data which matches QNAME which is the only authoritative data in this section Name servers and resolvers should never attempt to add SOAs to the additional section of a non authoritative response or attempt to infer results which are not directly stated in an authoritative response There are several reasons for this including cached information isn t usually enough to match up RRs and their zone names SOA RRs may be cached due to direct SOA queries and name servers are not required to output the SOAs in the authority section This feature is optional although a refined version is expected to become part of the standard protocol in the future Name servers are not required to add the SOA RRs in all authoritative responses nor are resolvers required to cache negative results Both are recommended All resolvers and recursive name servers are required to at least be able to ignore the SOA RR when it is present in a response Some experiments have also been proposed which will use this feature The idea is that if cached data is known to come from a particular zone and if an authoritative copy of the zone s SOA is obtained and if the zone s SERIAL has not changed since the data was cached then the TTL of the cached data can be reset to the zone MINIMUM value if it is smaller This usage is mentioned for planning purposes only and is not recommended as yet Mockapetris Page 27 RFC 1034 Domain Concepts and Facilities November 1987 4 3 5 Zone maintenance and transfers Part of the job of a zone administrator is to maintain the zones at all of the name servers which are authoritative for the zone When the inevitable changes are made they must be distributed to all of the name servers While this distribution can be accomplished using FTP or some other ad hoc procedure the preferred method is the zone transfer part of the DNS protocol The general model of automatic zone transfer or refreshing is that one of the name servers is the master or primary for the zone Changes are coordinated at the primary typically by editing a master file for the zone After editing the administrator signals the master server to load the new zone The other non master or secondary servers for the zone periodically check for changes at a selectable interval and obtain new zone copies when changes have been made To detect changes secondaries just check the SERIAL field of the SOA for the zone In addition to whatever other changes are made the SERIAL field in the SOA of the zone is always advanced whenever any change is made to the zone The advancing can be a simple increment or could be based on the write date and time of the master file etc The purpose is to make it possible to determine which of two copies of a zone is more recent by comparing serial numbers Serial number advances and comparisons use sequence space arithmetic so there is a theoretic limit on how fast a zone can be updated basically that old copies must die out before the serial number covers half of its 32 bit range In practice the only concern is that the compare operation deals properly with comparisons around the boundary between the most positive and most negative 32 bit numbers The periodic polling of the secondary servers is controlled by parameters in the SOA RR for the zone which set the minimum acceptable polling intervals The parameters are called REFRESH RETRY and EXPIRE Whenever a new zone is loaded in a secondary the secondary waits REFRESH seconds before checking with the primary for a new serial If this check cannot be completed new checks are started every RETRY seconds The check is a simple query to the primary for the SOA RR of the zone If the serial field in the secondary s zone copy is equal to the serial returned by the primary then no changes have occurred and the REFRESH interval wait is restarted If the secondary finds it impossible to perform a serial check for the EXPIRE interval it must assume that its copy of the zone is obsolete an discard it When the poll shows that the zone has changed then the secondary server must request a zone transfer via an AXFR request for the zone The AXFR may cause an error such as refused but normally is answered by a sequence of response messages The first and last messages must contain Mockapetris Page 28 RFC 1034 Domain Concepts and Facilities November 1987 the data for the top authoritative node of the zone Intermediate messages carry all of the other RRs from the zone including both authoritative and non authoritative RRs The stream of messages allows the secondary to construct a copy of the zone Because accuracy is essential TCP or some other reliable protocol must be used for AXFR requests Each secondary server is required to perform the following operations against the master but may also optionally perform these operations against other secondary servers This strategy can improve the transfer process when the primary is unavailable due to host downtime or network problems or when a secondary server has better network access to an intermediate secondary than to the primary 5 RESOLVERS 5 1 Introduction Resolvers are programs that interface user programs to domain name servers In the simplest case a resolver receives a request from a user program e g mail programs TELNET FTP in the form of a subroutine call system call etc and returns the desired information in a form compatible with the local host s data formats The resolver is located on the same machine as the program that requests the resolver s services but it may need to consult name servers on other hosts Because a resolver may need to consult several name servers or may have the requested information in a local cache the amount of time that a resolver will take to complete can vary quite a bit from milliseconds to several seconds A very important goal of the resolver is to eliminate network delay and name server load from most requests by answering them from its cache of prior results It follows that caches which are shared by multiple processes users machines etc are more efficient than non shared caches 5 2 Client resolver interface 5 2 1 Typical functions The client interface to the resolver is influenced by the local host s conventions but the typical resolver client interface has three functions 1 Host name to host address translation This function is often defined to mimic a previous HOSTS TXT Mockapetris Page 29 RFC 1034 Domain Concepts and Facilities November 1987 based function Given a character string the caller wants one or more 32 bit IP addresses Under the DNS it translates into a request for type A RRs Since the DNS does not preserve the order of RRs this function may choose to sort the returned addresses or select the best address if the service returns only one choice to the client Note that a multiple address return is recommended but a single address may be the only way to emulate prior HOSTS TXT services 2 Host address to host name translation This function will often follow the form of previous functions Given a 32 bit IP address the caller wants a character string The octets of the IP address are reversed used as name components and suffixed with IN ADDR ARPA A type PTR query is used to get the RR with the primary name of the host For example a request for the host name corresponding to IP address 1 2 3 4 looks for PTR RRs for domain name 4 3 2 1 IN ADDR ARPA 3 General lookup function This function retrieves arbitrary information from the DNS and has no counterpart in previous systems The caller supplies a QNAME QTYPE and QCLASS and wants all of the matching RRs This function will often use the DNS format for all RR data instead of the local host s and returns all RR content e g TTL instead of a processed form with local quoting conventions When the resolver performs the indicated function it usually has one of the following results to pass back to the client One or more RRs giving the requested data In this case the resolver returns the answer in the appropriate format A name error NE This happens when the referenced name does not exist For example a user may have mistyped a host name A data not found error This happens when the referenced name exists but data of the appropriate type does not For example a host address Mockapetris Page 30 RFC 1034 Domain Concepts and Facilities November 1987 function applied to a mailbox name would return this error since the name exists but no address RR is present It is important to note that the functions for translating between host names and addresses may combine the name error and data not found error conditions into a single type of error return but the general function should not One reason for this is that applications may ask first for one type of information about a name followed by a second request to the same name for some other type of information if the two errors are combined then useless queries may slow the application 5 2 2 Aliases While attempting to resolve a particular request the resolver may find that the name in question is an alias For example the resolver might find that the name given for host name to address translation is an alias when it finds the CNAME RR If possible the alias condition should be signalled back from the resolver to the client In most cases a resolver simply restarts the query at the new name when it encounters a CNAME However when performing the general function the resolver should not pursue aliases when the CNAME RR matches the query type This allows queries which ask whether an alias is present For example if the query type is CNAME the user is interested in the CNAME RR itself and not the RRs at the name it points to Several special conditions can occur with aliases Multiple levels of aliases should be avoided due to their lack of efficiency but should not be signalled as an error Alias loops and aliases which point to non existent names should be caught and an error condition passed back to the client 5 2 3 Temporary failures In a less than perfect world all resolvers will occasionally be unable to resolve a particular request This condition can be caused by a resolver which becomes separated from the rest of the network due to a link failure or gateway problem or less often by coincident failure or unavailability of all servers for a particular domain It is essential that this sort of condition should not be signalled as a name or data not present error to applications This sort of behavior is annoying to humans and can wreak havoc when mail systems use the DNS While in some cases it is possible to deal with such a temporary problem by blocking the request indefinitely this is usually not a good choice particularly when the client is a server process that could move on to Mockapetris Page 31 RFC 1034 Domain Concepts and Facilities November 1987 other tasks The recommended solution is to always have temporary failure as one of the possible results of a resolver function even though this may make emulation of existing HOSTS TXT functions more difficult 5 3 Resolver internals Every resolver implementation uses slightly different algorithms and typically spends much more logic dealing with errors of various sorts than typical occurances This section outlines a recommended basic strategy for resolver operation but leaves details to RFC 1035 5 3 1 Stub resolvers One option for implementing a resolver is to move the resolution function out of the local machine and into a name server which supports recursive queries This can provide an easy method of providing domain service in a PC which lacks the resources to perform the resolver function or can centralize the cache for a whole local network or organization All that the remaining stub needs is a list of name server addresses that will perform the recursive requests This type of resolver presumably needs the information in a configuration file since it probably lacks the sophistication to locate it in the domain database The user also needs to verify that the listed servers

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc1034.txt (2016-02-14)
    Open archived version from archive


  • 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 Mockapetris Page 33 RFC 1035 Domain Implementation and Specification November 1987 ORIGIN INCLUDE 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 then the owner name is reset contents take one of the following forms 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 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 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 ISI MAILBOXES TXT Where the file 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

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc1035.txt (2016-02-14)
    Open archived version from archive


  • According to IEEE specifications the NaN not a number is system dependent and should not be used externally 3 7 Double precision Floating point The standard defines the encoding for the double precision floating point data type double 64 bits or 8 bytes The encoding used is the IEEE standard for normalized double precision floating point numbers 3 The standard encodes the following three fields which describe the double precision floating point number S The sign of the number Values 0 and 1 represent positive and negative respectively One bit E The exponent of the number base 2 11 bits are devoted to this field The exponent is biased by 1023 F The fractional part of the number s mantissa base 2 52 bits are devoted to this field Therefore the floating point number is described by 1 S 2 E Bias 1 F SUN Microsystems Page 5 RFC 1014 External Data Representation June 1987 It is declared as follows double identifier byte 0 byte 1 byte 2 byte 3 byte 4 byte 5 byte 6 byte 7 S E F 1 DOUBLE PRECISION FLOATING POINT Just as the most and least significant bytes of a number are 0 and 3 the most and least significant bits of a double precision floating point number are 0 and 63 The beginning bit and most significant bit offsets of S E and F are 0 1 and 12 respectively Note that these numbers refer to the mathematical positions of the bits and NOT to their actual physical locations which vary from medium to medium The IEEE specifications should be consulted concerning the encoding for signed zero signed infinity overflow and denormalized numbers underflow 3 According to IEEE specifications the NaN not a number is system dependent and should not be used externally 3 8 Fixed length Opaque Data At times fixed length uninterpreted data needs to be passed among machines This data is called opaque and is declared as follows opaque identifier n where the constant n is the static number of bytes necessary to contain the opaque data If n is not a multiple of four then the n bytes are followed by enough 0 to 3 residual zero bytes r to make the total byte count of the opaque object a multiple of four 0 1 byte 0 byte 1 byte n 1 0 0 FIXED LENGTH OPAQUE 3 9 Variable length Opaque Data The standard also provides for variable length counted opaque data SUN Microsystems Page 6 RFC 1014 External Data Representation June 1987 defined as a sequence of n numbered 0 through n 1 arbitrary bytes to be the number n encoded as an unsigned integer as described below and followed by the n bytes of the sequence Byte m of the sequence always precedes byte m 1 of the sequence and byte 0 of the sequence always follows the sequence s length count If n is not a multiple of four then the n bytes are followed by enough 0 to 3 residual zero bytes r to make the total byte count a multiple of four Variable length opaque data is declared in the following way opaque identifier or opaque identifier 0 1 2 3 4 5 length n byte0 byte1 n 1 0 0 VARIABLE LENGTH OPAQUE It is an error to encode a length greater than the maximum described in the specification 3 10 String The standard defines a string of n numbered 0 through n 1 ASCII bytes to be the number n encoded as an unsigned integer as described above and followed by the n bytes of the string Byte m of the string always precedes byte m 1 of the string and byte 0 of the string always follows the string s length If n is not a multiple of four then the n bytes are followed by enough 0 to 3 residual zero bytes r to make the total byte count a multiple of four Counted byte strings are declared as follows SUN Microsystems Page 7 RFC 1014 External Data Representation June 1987 string object or string object 0 1 2 3 4 5 length n byte0 byte1 n 1 0 0 STRING It is an error to encode a length greater than the maximum described in the specification 3 11 Fixed length Array Declarations for fixed length arrays of homogeneous elements are in the following form type name identifier n Fixed length arrays of elements numbered 0 through n 1 are encoded by individually encoding the elements of the array in their natural order 0 through n 1 Each element s size is a multiple of four bytes Though all elements are of the same type the elements may have different sizes For example in a fixed length array of strings all elements are of type string yet each element will vary in its length element 0 element 1 element n 1 FIXED LENGTH ARRAY SUN Microsystems Page 8 RFC 1014 External Data Representation June 1987 3 12 Variable length Array Counted arrays provide the ability to encode variable length arrays of homogeneous elements The array is encoded as the element count n an unsigned integer followed by the encoding of each of the array s elements starting with element 0 and progressing through element n 1 The declaration for variable length arrays follows this form type name identifier or type name identifier COUNTED ARRAY It is an error to encode a value of n that is greater than the maximum described in the specification 3 13 Structure Structures are declared as follows struct component declaration A component declaration B identifier The components of the structure are encoded in the order of their declaration in the structure Each component s size is a multiple of four bytes though the components may be different sizes component A component B STRUCTURE 3 14 Discriminated Union A discriminated union is a type composed of a discriminant followed by a type selected from a

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc1014.txt (2016-02-14)
    Open archived version from archive


  • confine to window is not viewable The request fails with status InvalidTime if the specified time is earlier than the last pointer grab time or later than the current server time otherwise the last pointer grab time is set to the specified time with CurrentTime replaced by the current server time UngrabPointer time TIMESTAMP or CurrentTime Releases the pointer if this client has it actively grabbed from either GrabPointer or GrabButton or from a normal button press and releases any queued events The request has no effect if the specified time is earlier than the last pointer grab time or is later than the current server time This request generates EnterNotify and LeaveNotify events An UngrabPointer is performed automatically if the event window or confine to window for an active pointer grab becomes not viewable GrabButton modifiers SETofKEYMASK or AnyModifier button BUTTON or AnyButton grab window WINDOW owner events BOOL event mask SETofPOINTEREVENT pointer mode keyboard mode Synchronous Asynchronous confine to WINDOW or None cursor CURSOR or None M I T Page 42 RFC 1013 June 1987 Errors Cursor Window Value Access This request establishes a passive grab In the future if the specified button is pressed when the specified modifier keys are down and no other buttons or modifier keys are down and grab window contains the pointer and the confine to window if any is viewable and these constraints are not satisfied for any ancestor then the pointer is actively grabbed as described in GrabPointer the last pointer grab time is set to the time at which the button was pressed as transmitted in the ButtonPress event and the ButtonPress event is reported The interpretation of the remaining arguments is as for GrabPointer The active grab is terminated automatically when all buttons are released independent of the state of modifier keys A modifiers of AnyModifier is equivalent to issuing the request for all possible modifier combinations A button of AnyButton is equivalent to issuing the request for all possible buttons An Access error is generated if some other client has already issued a GrabButton with the same button key combination on the same window When using AnyModifier or AnyButton the request fails completely no grabs are established if there is a combination The request has no effect on an active grab UngrabButton modifiers SETofKEYMASK or AnyModifier button BUTTON or AnyButton grab window WINDOW Errors Window Releases the passive button key combination on the specified window if it was grabbed by this client A modifiers of AnyModifier is equivalent to issuing the request for all possible modifier combinations A button of AnyButton is equivalent to issuing the request for all possible buttons Has no effect on an active grab ChangeActivePointerGrab event mask SETofPOINTEREVENT cursor CURSOR or None time TIMESTAMP or CurrentTime Errors Cursor M I T Page 43 RFC 1013 June 1987 Changes the specified dynamic parameters if the pointer is actively grabbed by the client and the specified time is no earlier than the last pointer grab time and no later than the current server time The interpretation of event mask and cursor are as in GrabPointer The event mask is always augmented to include ButtonPress and ButtonRelease Has no effect on the passive parameters of a GrabButton GrabKeyboard grab window WINDOW owner events BOOL pointer mode keyboard mode Synchronous Asynchronous time TIMESTAMP or CurrentTime status Success AlreadyGrabbed Frozen InvalidTime NotViewable Errors Window Value Actively grabs control of the keyboard Further key events are reported only to the grabbing client The request overrides any active keyboard grab by this client If owner events is False all generated key events are reported with respect to grab window If owner events is True then if a generated key event would normally be reported to this client it is reported normally otherwise the event is reported with respect to the grab window Both KeyPress and KeyRelease events are always reported independent of any event selection made by the client Pointer mode controls further processing of pointer events and keyboard mode controls further processing of keyboard events If the mode is Asynchronous event processing continues normally if the device is currently frozen by this client then processing of events for the device is resumed If the mode is Synchronous the device as seen via the protocol appears to freeze and no further events for that device are generated by the server until the grabbing client issues a releasing AllowEvents request Actual device changes are not lost while the device is frozen they are simply queued for later processing This request generates FocusIn and FocusOut events The request fails with status AlreadyGrabbed if the keyboard is actively grabbed by some other client The M I T Page 44 RFC 1013 June 1987 request fails with status Frozen if the keyboard is frozen by an active grab of another client The request fails with status NotViewable if grab window is not viewable The request fails with status InvalidTime if the specified time is earlier than the last keyboard grab time or later than the current server time otherwise the last keyboard grab time is set to the specified time with CurrentTime replaced by the current server time UngrabKeyboard time TIMESTAMP or CurrentTime Releases the keyboard if this client has it actively grabbed from either GrabKeyboard or GrabKey and releases any queued events The request has no effect if the specified time is earlier than the last keyboard grab time or is later than the current server time This request generates FocusIn and FocusOut events An UngrabKeyboard is performed automatically if the event window for an active keyboard grab becomes not viewable GrabKey key KEYCODE or AnyNonModifier modifiers SETofKEYMASK or AnyModifier grab window WINDOW owner events BOOL pointer mode keyboard mode Synchronous Asynchronous Errors Window Value Access This request establishes a passive grab on the keyboard In the future if the specified key which can itself be a modifier key is pressed when the specified modifier keys are down and no other modifier keys are down and the KeyPress event would be generated in grab window or one of its inferiors and these constraints are not satisfied for any ancestor then the keyboard is actively grabbed as described in GrabKeyboard the last keyboard grab time is transmitted in set to the time at which the key was pressed as in the KeyPress event and the KeyPress event is reported The interpretation of the remaining arguments is as for GrabKeyboard The active grab is terminated automatically when the specified key has been released independent of the state of the modifier keys A modifiers of AnyModifier is equivalent to issuing the request for all possible modifier combinations A key of AnyNonModifier is equivalent to issuing the request for M I T Page 45 RFC 1013 June 1987 all possible non modifier key codes An Access error is generated if some other client has issued a GrabKey with the same key combination on the same window When using AnyModifier or AnyNonModifier the request fails completely no grabs are established if there is a conflicting grab for any combination UngrabKey key KEYCODE or AnyNonModifier modifiers SETofKEYMASK or AnyModifier grab window WINDOW Errors Window Releases the key combination on the specified window if it was grabbed by this client A modifiers of AnyModifier is equivalent to issuing the request for all possible modifier combinations A key of AnyNonModifier is equivalent to issuing the request for all possible non modifier key codes Has no effect on an active grab AllowEvents mode AsyncPointer SyncPointer ReplayPointer AsyncKeyboard SyncKeyboard ReplayKeyboard time TIMESTAMP or CurrentTime Errors Value Releases some queued events if the client has caused a device to freeze The request has no effect if the specified time is earlier than the last grab time of the most recent active grab for the client or if the specified time is later than the current server time For AsyncPointer if the pointer is frozen by the client pointer event processing continues normally If the pointer is frozen twice by the client on behalf of two separate grabs AsyncPointer thaws for both AsyncPointer has no effect if the pointer is not frozen by the client but the pointer need not be grabbed by the client For SyncPointer if the pointer is frozen and actively grabbed by the client pointer event processing continues normally until the next ButtonPress or ButtonRelease event is reported to the client at which time the pointer again appears to freeze However if the reported event causes the pointer grab to be released then the pointer does not freeze SyncPointer has no effect if the pointer is not frozen by the client or if the pointer is not grabbed by M I T Page 46 RFC 1013 June 1987 the client For ReplayPointer if the pointer is actively grabbed by the client and is frozen as the result of an event having been sent to the client either from the activation of a GrabButton or from a previous AllowEvents with mode SyncPointer but not from a GrabPointer then the pointer grab is released and that event is completely reprocessed but this time ignoring any passive grabs at or above towards the root the grab window of the grab just released The request has no effect if the pointer is not grabbed by the client or if the pointer is not frozen as the result of an event For AsyncKeyboard if the keyboard is frozen by the client keyboard event processing continues normally If the pointer is frozen twice by the client on behalf of two separate grabs AsyncPointer thaws for both AsyncKeyboard has no effect if the keyboard is not frozen by the client but the keyboard need not be grabbed by the client For SyncKeyboard if the keyboard is frozen and actively grabbed by the client keyboard event processing continues normally until the next KeyPress or KeyRelease event is reported to the client at which time the keyboard again appears to freeze However if the reported event causes the keyboard grab to be released then the keyboard does not freeze SyncKeyboard has no effect if the keyboard is not frozen by the client or if the keyboard is not grabbed by the client For ReplayKeyboard if the keyboard is actively grabbed by the client and is frozen as the result of an event having been sent to the client either from the activation of a GrabKey or from a previous AllowEvents with mode SyncKeyboard but not from a GrabKeyboard then the keyboard grab is released and that event is completely reprocessed but this time ignoring any passive grabs at or above towards the root the grab window of the grab just released The request has no effect if the keyboard is not grabbed by the client or if the keyboard is notfrozen as the result of an event AsyncPointer SyncPointer and Replay Pointer have no effect on processing of keyboard events AsyncKeyboard SyncKeyboard and ReplayKeyboard have no effect on processing of pointer events It is possible for both a pointer grab and a keyboard grab to be active simultaneously by the same or different M I T Page 47 RFC 1013 June 1987 clients If a device is frozen on behalf of either grab no event processing is performed for the device It is possible for a single device to be frozen due to both grabs In this case the freeze must be released on behalf of both grabs before events can again be processed GrabServer Disables processing of requests and close downs on all other connections than the one this request arrived on UngrabServer Restarts processing of requests and close downs on other connections QueryPointer window WINDOW root WINDOW child WINDOW or None same screen BOOL root x root y win x win y INT16 mask SETofKEYBUTMASK Errors Window The root window the pointer is currently on and pointer coordinates relative to the root s origin are returned If same screen is False then the pointer is not on the same screen as the argument window and child is None and win x and win y are zero If same screen is True then win x and win y are the pointer coordinates relative to the argument window s origin and child is the child containing the pointer if any The current state of the modifier keys and the buttons are also returned GetMotionEvents start stop TIMESTAMP or CurrentTime window WINDOW events LISTofTIMECOORD where TIMECOORD x y CARD16 time TIMESTAMP Error Window Returns all events in the motion history buffer that fall between the specified start and stop times inclusive and that have coordinates that lie within including M I T Page 48 RFC 1013 June 1987 borders the specified window at its present placement The x and y coordinates are reported relative to the origin of the window TranslateCoordinates src window dst window WINDOW src x src y INT16 same screen BOOL child WINDOW or None dst x dst y INT16 Errors Window The src x and src y coordinates are taken relative to src window s origin and returned as dst x and dst y coordinates relative to dst window s origin If same screen is False then src window and dst window are on different screens and dst x and dst y are zero If the coordinates are contained in a mapped child of dst window then that child is returned WarpPointer src window WINDOW or None dst window WINDOW src x src y INT16 src width src height CARD16 dst x dst y INT16 Errors Window Moves the pointer to dst x dst y relative to dst window s origin If src window is None the move is independent of the current pointer position but if a window is specified the move only takes place if the pointer is currently contained in a visible portion of the specified rectangle of the src window The src x and src y coordinates are relative to src window s origin If src height is zero it is replaced with the current height of src window minus src y If src width is zero it is replaced with the current width of src window minus src x This request cannot be used to move the pointer outside the confine to window of an active pointer grab an attempt will only move the pointer as far as the closest edge of the confine to window M I T Page 49 RFC 1013 June 1987 SetInputFocus focus WINDOW or PointerRoot or None revert to Parent PointerRoot None time TIMESTAMP or CurrentTime Errors Window Value Changes the input focus and the last focus change time The request has no effect if the specified time is earlier than the current last focus change time or is later than the current server time otherwise the last focus change time is set to the specified time with CurrentTime replaced by the current server time If None is specified as the focus all keyboard events are discarded until a new focus window is set In this case therevert to argument is ignored If a window is specified as the focus it becomes the keyboard s focus window If a generated keyboard event would normally be reported to this window or one of its inferiors the event is reported normally otherwise the event is reported with respect to the focus window If PointerRoot is specified as the focus the focus window is dynamically taken to be the root window of whatever screen the pointer is on at each keyboard event In this case the revert to argument is ignored This request generates FocusIn and FocusOut events If the focus window becomes not viewable the new focus window depends on the revert to argument If revert to is Parent the focus reverts to the parent or the closest viewable ancestor and the new revert to value is take to be None If revert to is PointerRoot or None the focus reverts to that value When the focus reverts FocusIn and FocusOut events are generated but the last focus change time is not affected GetInputFocus focus WINDOW or PointerRoot or None revert to Parent PointerRoot None Returns the current focus state QueryKeymap keys LISTofCARD8 M I T Page 50 RFC 1013 June 1987 Returns a bit vector for the keyboard each one bit indicates that the corresponding key is currently pressed The vector is represented as 32 bytes Byte N from 0 contains the bits for keys 8N to 8N 7 with the least significant bit in the byte representing key 8N OpenFont fid FONT name STRING8 Errors IDChoice Name Alloc Loads the specified font if necessary and associates identifier fid with it The font can be used as a source for any drawable The font name should use the ASCII encoding and upper lower case does not matter CloseFont font FONT Errors Font Deletes the association between the resource id and the font The font itself will be freed when no other resource references it QueryFont font FONT or GCONTEXT font info FONTINFO char infos LISTofCHARINFO where FONTINFO draw direction LeftToRight RightToLeft min char or byte2 max char or byte2 CARD16 min byte1 max byte1 CARD8 all chars exist BOOL default char CARD16 min bounds CHARINFO max bounds CHARINFO font ascent INT16 font descent INT16 properties LISTofFONTPROP FONTPROP name ATOM value INT32 or CARD32 CHARINFO left side bearing INT16 right side bearing INT16 character width INT16 ascent INT16 descent INT16 attributes CARD16 M I T Page 51 RFC 1013 June 1987 Errors Font Returns logical information about a font The draw direction is essentially just a hint indicating whether most char infos have a positive LeftToRight or a negative RightToLeft character width metric The core protocol defines no support for vertical text If min byte1 and max byte1 are both zero then min char or byte2 specifies the linear character index corresponding to the first elementb of char infos and max char or byte2 specifies the linear character index of the last element If either min byte1 or max byte1 are non zero then both min char or byte2 and max char or byte2 will be less than 256 and the two byte character index values corresponding to char infos element N counting from 0 are byte1 N D min byte1 byte2 N D min char or byte2 where D max char or byte2 min char or byte2 1 integer division integer modulus If char infos has length zero then min bounds and max bounds will be identical and the effective char infos is one filled with this char info of length L D max byte1 min byte1 1 That is all glyphs in the specified linear or matrix range have the same information as given by min bounds and max bounds If all chars exist is True then all characters in char infos have non zero bounding boxes The default char specifies the character that will be used when an undefined or non existent character is used Note that default char is a CARD16 not CHAR2B for a font using two byte matrix format the default char has byte1 in the most significant byte and byte2 in the least significant byte If the default char itself specifies an undefined or non existent character then no printing is performed for an undefined or non existent character The min bounds and max bounds contain the minimum and maximum values of each individual CHARINFO component over all char infos ignoring non existent characters The bounding box of the font i e the smallest rectangle enclosing the shape obtained by superimposing all characters at the same origin x y has its upper left coordinate at M I T Page 52 RFC 1013 June 1987 x min bounds left side bearing y max bounds ascent with a width of max bounds right side bearing min bounds left side bearing and a height of max bounds ascent max bounds descent The font ascent is the logical extent of the font above the baseline for determining line spacing Specific characters may extend beyond this The font descent is the logical extent of the font at or below the baseline for determining line spacing Specific characters may extend beyond this If the baseline is at Y coordinate y then the logical extent of the font is inclusive between the Y coordinate values y font ascent and y font descent 1 A font is not guaranteed to have any properties Whether a property value is signed or unsigned must be derived from a prior knowledge of the property When possible fonts should have at least the following properties note that the trailing colon is not part of the name and that upper lower case matters MIN SPACE CARD32 The minimum interword spacing in pixels NORM SPACE CARD32 The normal interword spacing in pixels MAX SPACE CARD32 The maximum interword spacing in pixels SUBSCRIPT X INT32 SUBSCRIPT Y INT32 Offsets from the character origin where subscripts should begin in pixels If the origin is at x y then subscripts should begin at x SubscriptX y SubscriptY UNDERLINE POSITION INT32 Y offset from the baseline to the top of an underline in pixels If the baseline is Y coordinate y then the top of the underline is at y UnderlinePosition UNDERLINE THICKNESS CARD32 Thickness of the underline in pixels STRIKEOUT ASCENT INT32 STRIKEOUT DESCENT INT32 Vertical extents for boxing or voiding characters in pixels If the baseline is at Y coordinate y then the top of the strikeout box is at y StrikeoutAscent and the height of the box is StrikeoutAscent StrikeoutDescent ITALIC ANGLE INT32 The angle of characters in the font in degrees M I T Page 53 RFC 1013 June 1987 scaled by 64 relative to the three oclock position from the character origin with positive indicating counterclockwise motion as in Arc requests X HEIGHT INT32 1 ex as in TeX but expressed in units of pixels Often the height of lowercase x QUAD WIDTH INT32 1 em as in TeX but expressed in units of pixels Often the width of the digits 0 9 WEIGHT CARD32 The weight or boldness of the font expressed as a value between 0 and 1000 POINT SIZE CARD32 The point size expressed in 1 10ths of this font at the ideal resolution There are 72 27 points to the inch RESOLUTION CARD32 The number of pixels per point expressed in 1 100ths at which this font was created For a character origin at x y the bounding box of a character i e the smallest rectangle enclosing the character s shape described in terms of CHARINFO components is a rectangle with its upper left corner at x left side bearing y ascent with a width of right side bearing left side bearing and a height of ascent descent and the origin for the next character is defined to be x character width y Note that the baseline is logically viewed as being just below non descending characters when descent is zero only pixels with Y coordinates less than y are drawn and that the origin is logically viewed as being coincident with the left edge of a non kerned character when left side bearing is zero no pixels with X coordinate less than x are drawn Note that CHARINFO metric values can be negative A non existent character is represented with all CHARINFO components zero The interpretation of the per character attributes field is undefined by the core protocol QueryTextExtents font FONT or GCONTEXT items STRING16 M I T Page 54 RFC 1013 June 1987 draw direction LeftToRight RightToLeft font ascent INT16 font descent INT16 overall ascent INT16 overall descent INT16 overall width INT32 overall left INT32 overall right INT32 Errors Font Returns the logical extents of the specified string of characters in the specified font Draw direction font ascent and font descent are as described in QueryFont Overall ascent is the maximum of the ascent metrics of all characters in the string and overall descent is the maximum of the descent metrics Overall width is the sum of the character width metrics of all characters in the string For each character in the string let W be the sum of the character width metrics of all characters preceding it in the string let L be the left side bearing metric of the character plus W and let R be the right side bearing metric of the character plus W Overall left is the minimum L of all characters in the string and overall right is the maximum R For fonts defined with linear indexing rather than two byte matrix indexing the server will interpret each CHAR2B as a 16 bit number that has been transmitted most significant byte first i e byte1 of the CHAR2B is taken as the most significant byte If the font has no defined default char then undefined characters in the string are taken to have all zero metrics ListFonts pattern STRING8 max names CARD16 names LISTofSTRING8 Returns a list of length at most max names of names of fonts matching the pattern The pattern should use the ASCII encoding and upper lower case does not matter In the pattern the character octal value 77 will match any single character and the character octal value 52 will match any number of characters The returned names are in lower case M I T Page 55 RFC 1013 June 1987 ListFontsWithInfo pattern STRING8 max names CARD16 fonts LISTofFONTDATA where FONTDATA name STRING8 info FONTINFO FONTINFO Like ListFonts but also returns information about each font The information returned for each font is identical to what QueryFont would return except that the per character metrics are not returned SetFontPath path LISTofSTRING8 Errors Value Defines the search path for font lookup There is only one search path per server not one per client The interpretation of the strings is operating system dependent but they are intended to specify directories to be searched in the order listed Setting the path to the empty list restores the default path defined for the server As a side effect of executing this request the server is guaranteed to flush all cached information about fonts for which there currently are no explicit resource ids allocated The meaning of an error from this request is system specific GetFontPath path LISTofSTRING8 Returns the current search path for fonts CreatePixmap pid PIXMAP drawable DRAWABLE depth CARD8 width height CARD16 Errors IDChoice Drawable Value Alloc M I T Page 56 RFC 1013 June 1987 Creates a pixmap and assigns the identifier pid to it Width and height must be non zero Depth must be one of the depths supported by root of the specified drawable The initial contents of the pixmap are undefined It is legal to pass an InputOnly window as a drawable to this request FreePixmap pixmap PIXMAP Errors Pixmap Deletes the association between the resource id and the pixmap The pixmap storage will be freed when no other resource references it CreateGC cid GCONTEXT drawable DRAWABLE value mask BITMASK value list LISTofVALUE Errors IDChoice Drawable Pixmap Font Match Value Alloc Creates a graphics context and assigns the identifier cid to it The gcontext can be used with any destination drawable having the same root and depth as the specified drawable The value mask and value list specify which components are to be explicitly initialized The context components are alu function Clear And AndReverse Copy AndInverted Noop Xor Or Nor Equiv Invert OrReverse CopyInverted OrInverted Nand Set plane mask CARD32 foreground CARD32 background CARD32 line width CARD16 line style Solid OnOffDash DoubleDash cap style NotLast Butt Round Projecting join style Miter Round Bevel fill style Solid Tiled OpaqueStippled Stippled fill rule EvenOdd Winding arc mode Chord PieSlice tile PIXMAP stipple PIXMAP tile stipple x origin INT16 tile stipple y origin INT16 font FONT M I T Page 57 RFC 1013 June 1987 subwindow mode ClipByChildren IncludeInferiors graphics exposures BOOL clip x origin INT16 clip y origin INT16 clip mask PIXMAP or None dash offset CARD16 dash list CARD8 In graphics operations given a source and destination pixel the result is computed bitwise on corresponding bits of the pixels That is a boolean operation is performed in each bit plane The plane mask restricts the operation to a subset of planes That is the result is src FUNC dst AND plane mask OR dst AND NOT plane mask Range checking is not performed on the values for foreground background or plane mask they are simply truncated to the appropriate number of bits The meanings of the alu functions are Clear 0 And src AND dst AndReverse src AND NOT dst Copy src AndInverted NOT src AND dst NoOp dst Xor src XOR dst Or src OR dst Nor NOT src AND NOT dst Equiv NOT src XOR dst Invert NOT dst OrReverse src OR NOT dst CopyInverted NOT src OrInverted NOT src OR dst NAnd NOT src OR NOT dst Set 1 Line width is measured in pixels and can be greater than or equal to one a wide line or the special value zero a thin line Wide lines are drawn centered on the path described by the graphics request Unless otherwise specified by the join or cap style the bounding box of a wide line with endpoints x1 y1 x2 y2 and width w is a rectangle with vertices at the following real coordinates x1 w sn 2 y1 w cs 2 x1 w sn 2 y1 w cs 2 x2 w sn 2 y2 w cs 2 x2 w sn 2 y2 w cs 2 M I T Page 58 RFC 1013 June 1987 where sn is the sine of the angle of the line and cs is the cosine of the angle of the line A pixel is part of the line and hence drawn if the center of the pixel is fully inside the bounding box which is viewed as having infinitely thin edges If the center of the pixel is exactly on the bounding box it is part of the line if and only if the interior is immediately to its right x increasing direction Pixels with centers on a horizontal edge are a special case and are part of the line if and only if the interior is immediately below y increasing direction Note that this description is a mathematical model describing the pixels that are drawn for a wide line and does not imply that trigonometry is required to implement such a model Real or fixed point arithmetic is recommended for computing the corners of the line endpoints for lines greater than one pixel in width Thin lines zero line width are one pixel wide lines drawn using an unspecified device dependent algorithm for example Bresenham There are only two constraints on this algorithm First if a line is drawn unclipped from x1 y1 to x2 y2 and another line is drawn unclipped from x1 dx y1 dy to x2 dx y2 dy then a point x y is touched by drawing the first line if and only if the point x dx y dy is touched by drawing the second line Second the effective set of points comprising a line cannot be affected by clipping that is a point is touched in a clipped line if and only if the point lies inside the clipping region and the point would be touched by the line when drawn unclipped Note that a wide line drawn from x1 y1 to x2 y2 always draws the same pixels as a wide line drawn from x2 y2 to x1 y1 not counting cap and join styles but this property is not guaranteed for thin lines Also note that jags in adjacent wide lines will always line up properly but this property is not guaranteed for thin lines A line width of zero differs from a line width of one in which pixels are drawn In general drawing a thin line will be faster than drawing a wide line of width one but thin lines may not mix well aesthetically desirable to obtain precise and uniform results across all displays a client should always use a line width of one rather than a line width of zero The line style defines which segments of a line are drawn Solid the full path of the line is drawn DoubleDash the full path of the line is drawn but the segments defined by the even dashes are filled differently than the segments defined by the odd dashes see fill style OnOffDash only the segments defined by the even dashes are drawn and cap style applies to each M I T Page 59 RFC 1013 June 1987 individual segment except NotLast is treated as Butt for internal caps The cap style defines how the endpoints of a path are drawn NotLast equivalent to Butt except that for a line width of zero or one the final endpoint is not drawn Butt square at the endpoint with no projection beyond Round a circular arc with diameter equal to the line width centered on the endpoint equivalent to Butt for line width zero or one Projecting square at the end but the path continues beyond the endpoint for a distance equal to half the line width equivalent to Butt for line width zero or one The join style defines how corners are drawn for wide lines Miter the outer edges of the two lines extend to meet at an angle Round a circular arc with diameter equal to the line width centered on the joinpoint Bevel Butt endpoint styles and then the triangular notch filled The tile stipple and clip origins are interpreted relative to the origin of whatever destination drawable is specified in a graphics request The tile pixmap must have the same root and depth as the gcontext else a Match error The stipple pixmap must have depth one and must have the same root as the gcontext else a Match error For stipple operations the stipple pattern is tiled in a single plane and acts as an additional clip mask to be ANDed with the clip mask Any size pixmap can be used for tiling or stippling although some sizes may be faster to use than others The fill style defines the contents of the source for line text and fill requests For all text and fill requests PolyText8 PolyText16 PolyFillRectangle FillPoly PolyFillArc for line requests PolyLine PolySegment PolyRectangle PolyArc with line style Solid and for the even dashes for line requests with line style OnOffDash or DoubleDash Solid foreground Tiled tile OpaqueStippled a tile with the same width and height as stipple but with background everywhere stipple has a zero and with foreground everywhere stipple has a one Stippled foreground masked by stipple M I T Page 60 RFC 1013 June 1987 For the odd dashes for line requests with line style DoubleDash Solid background Tiled same as for even dashes OpaqueStippled same as for even dashes Stippled background masked by stipple The dash list value allowed here is actually a simplified form of the more general patterns that can be set with SetDashes Specifying a value of N here is equivalent to specifying the two element list N N in SetDashes The value must be non zero The meaning of dash offset and dash list are explained in the SetDashes request The clip mask restricts writes to the destination drawable only pixels where the clip mask has a one bit are drawn It affects all graphics requests The clip mask does not clip sources The clip mask origin is interpreted relative to the origin of whatever destination drawable is specified in a graphics request If a pixmap is specified as the clip mask it must have depth one and have the same root as the gcontext else a Match error The clip mask can also be set with the SetClipRectangles request For ClipByChildren both source

    Original URL path: http://web.teipir.gr/new/ecs/pelab_1/RFC/rfc1013.txt (2016-02-14)
    Open archived version from archive



  •