rfc1183.txt

bind 9.3结合mysql数据库

   Also, a standard address binding reference will facilitate other
   experiments in the use of X.25 and ISDN, especially in serious
   inter-operability testing.  The majority of work in such a test is
   establishing the n-squared entries in static tables.

   Finally, the RRs are intended for use in a proposal [13] by one of
   the authors for a possible next-generation internet.

3.1. The X25 RR

   The X25 RR is defined with mnemonic X25 and type code 19 (decimal).

   X25 has the following format:

   <owner> <ttl> <class> X25 <PSDN-address>

   <PSDN-address> is required in all X25 RRs.

   <PSDN-address> identifies the PSDN (Public Switched Data Network)
   address in the X.121 [10] numbering plan associated with <owner>.
   Its format in master files is a <character-string> syntactically
   identical to that used in TXT and HINFO.




Everhart, Mamakos, Ullmann & Mockapetris                        [Page 6]

RFC 1183                 New DNS RR Definitions             October 1990


   The format of X25 is class insensitive.  X25 RRs cause no additional
   section processing.

   The <PSDN-address> is a string of decimal digits, beginning with the
   4 digit DNIC (Data Network Identification Code), as specified in
   X.121. National prefixes (such as a 0) MUST NOT be used.

   For example:

   Relay.Prime.COM.  X25       311061700956

3.2. The ISDN RR

   The ISDN RR is defined with mnemonic ISDN and type code 20 (decimal).

   An ISDN (Integrated Service Digital Network) number is simply a
   telephone number.  The intent of the members of the CCITT is to
   upgrade all telephone and data network service to a common service.

   The numbering plan (E.163/E.164) is the same as the familiar
   international plan for POTS (an un-official acronym, meaning Plain
   Old Telephone Service).  In E.166, CCITT says "An E.163/E.164
   telephony subscriber may become an ISDN subscriber without a number
   change."

   ISDN has the following format:

   <owner> <ttl> <class> ISDN <ISDN-address> <sa>

   The <ISDN-address> field is required; <sa> is optional.

   <ISDN-address> identifies the ISDN number of <owner> and DDI (Direct
   Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and
   PSTN (Public Switched Telephone Network) numbering plan.  E.163
   defines the country codes, and E.164 the form of the addresses.  Its
   format in master files is a <character-string> syntactically
   identical to that used in TXT and HINFO.

   <sa> specifies the subaddress (SA).  The format of <sa> in master
   files is a <character-string> syntactically identical to that used in
   TXT and HINFO.

   The format of ISDN is class insensitive.  ISDN RRs cause no
   additional section processing.

   The <ISDN-address> is a string of characters, normally decimal
   digits, beginning with the E.163 country code and ending with the DDI
   if any.  Note that ISDN, in Q.931, permits any IA5 character in the



Everhart, Mamakos, Ullmann & Mockapetris                        [Page 7]

RFC 1183                 New DNS RR Definitions             October 1990


   general case.

   The <sa> is a string of hexadecimal digits.  For digits 0-9, the
   concrete encoding in the Q.931 call setup information element is
   identical to BCD.

   For example:

   Relay.Prime.COM.   IN   ISDN      150862028003217
   sh.Prime.COM.      IN   ISDN      150862028003217 004

   (Note: "1" is the country code for the North American Integrated
   Numbering Area, i.e., the system of "area codes" familiar to people
   in those countries.)

   The RR data is the ASCII representation of the digits.  It is encoded
   as one or two <character-string>s, i.e., count followed by
   characters.

   CCITT recommendation E.166 [9] defines prefix escape codes for the
   representation of ISDN (E.163/E.164) addresses in X.121, and PSDN
   (X.121) addresses in E.164.  It specifies that the exact codes are a
   "national matter", i.e., different on different networks.  A host
   connected to the ISDN may be able to use both the X25 and ISDN
   addresses, with the local prefix added.

3.3. The Route Through RR

   The Route Through RR is defined with mnemonic RT and type code 21
   (decimal).

   The RT resource record provides a route-through binding for hosts
   that do not have their own direct wide area network addresses.  It is
   used in much the same way as the MX RR.

   RT has the following format:

   <owner> <ttl> <class> RT <preference> <intermediate-host>

   Both RDATA fields are required in all RT RRs.

   The first field, <preference>, is a 16 bit integer, representing the
   preference of the route.  Smaller numbers indicate more preferred
   routes.

   <intermediate-host> is the domain name of a host which will serve as
   an intermediate in reaching the host specified by <owner>.  The DNS
   RRs associated with <intermediate-host> are expected to include at



Everhart, Mamakos, Ullmann & Mockapetris                        [Page 8]

RFC 1183                 New DNS RR Definitions             October 1990


   least one A, X25, or ISDN record.

   The format of the RT RR is class insensitive.  RT records cause type
   X25, ISDN, and A additional section processing for <intermediate-
   host>.

   For example,

   sh.prime.com.      IN   RT   2    Relay.Prime.COM.
                      IN   RT   10   NET.Prime.COM.
   *.prime.com.       IN   RT   90   Relay.Prime.COM.

   When a host is looking up DNS records to attempt to route a datagram,
   it first looks for RT records for the destination host, which point
   to hosts with address records (A, X25, ISDN) compatible with the wide
   area networks available to the host.  If it is itself in the set of
   RT records, it discards any RTs with preferences higher or equal to
   its own.  If there are no (remaining) RTs, it can then use address
   records of the destination itself.

   Wild-card RTs are used exactly as are wild-card MXs.  RT's do not
   "chain"; that is, it is not valid to use the RT RRs found for a host
   referred to by an RT.

   The concrete encoding is identical to the MX RR.

REFERENCES and BIBLIOGRAPHY

   [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
       Information Center, SRI International, November 1987.

   [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
       Network Information Center, SRI International, November, 1987.

   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
       1034, USC/Information Sciences Institute, November 1987.

   [4] Mockapetris, P., "Domain Names - Implementation and
       Specification", RFC 1035, USC/Information Sciences Institute,
       November 1987.

   [5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review,
       7(3), pp. 61-69, March 1989.

   [6] Zahn, et al., "Network Computing Architecture", Prentice-Hall,
       1989.

   [7] International Telegraph and Telephone Consultative Committee,



Everhart, Mamakos, Ullmann & Mockapetris                        [Page 9]

RFC 1183                 New DNS RR Definitions             October 1990


       "Numbering Plan for the International Telephone Service", CCITT
       Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988,
       Fascicle II.2 ("Blue Book").

   [8] International Telegraph and Telephone Consultative Committee,
       "Numbering Plan for the ISDN Era", CCITT Recommendations E.164.,
       IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue
       Book").

   [9] International Telegraph and Telephone Consultative Committee.
       "Numbering Plan Interworking in the ISDN Era", CCITT
       Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988,
       Fascicle II.2 ("Blue Book").

  [10] International Telegraph and Telephone Consultative Committee,
       "International Numbering Plan for the Public Data Networks",
       CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne,
       1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978;
       amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne,
       1988.

  [11] Korb, J., "Standard for the Transmission of IP datagrams Over
       Public Data Networks", RFC 877, Purdue University, September
       1983.

  [12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February
       1989.

  [13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer
       (unpublished), July 1990.

  [14] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
       RFC 1101, USC/Information Sciences Institute, April 1989.

Security Considerations

   Security issues are not addressed in this memo.














Everhart, Mamakos, Ullmann & Mockapetris                       [Page 10]

RFC 1183                 New DNS RR Definitions             October 1990


Authors' Addresses

   Craig F. Everhart
   Transarc Corporation
   The Gulf Tower
   707 Grant Street
   Pittsburgh, PA  15219

   Phone: [phone]

   EMail: [e-mail]


   Louis A. Mamakos
   Network Infrastructure Group
   Computer Science Center
   University of Maryland
   College Park, MD 20742-2411

   Phone: [phone]

   Email: [e-mail]


   Robert Ullmann 10-30
   Prime Computer, Inc.
   500 Old Connecticut Path
   Framingham, MA 01701

   Phone: [phone] ext 1736

   Email: [e-mail]


   Paul Mockapetris
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: [phone]

   EMail: [e-mail]









Everhart, Mamakos, Ullmann & Mockapetris                       [Page 11]