RFC1464 Using the Domain Name System To Store Arbitrary StringAttributes

1464 Using the Domain Name System To Store Arbitrary StringAttributes. R. Rosenbaum. May 1993. (Format: TXT=7953 bytes) (Status: EXPERIMENTAL)

日本語訳
RFC一覧

参照

Network Working Group                                       R. Rosenbaum
Request for Comments: 1464                 Digital Equipment Corporation
                                                                May 1993


                     Using the Domain Name System
                  To Store Arbitrary String Attributes

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  Discussion and suggestions for improvement are requested.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   While the Domain Name System (DNS) [2,3] is generally used to store
   predefined types of information (e.g., addresses of hosts), it is
   possible to use it to store information that has not been previously
   classified.

   This paper describes a simple means to associate arbitrary string
   information (ASCII text) with attributes that have not been defined
   by the DNS.  It uses DNS TXT resource records to store the
   information.  It requires no change to current DNS implementations.

1.  Introduction

   The Domain Name System is designed to store information that has both
   a predefined type and structure.  Examples include IP addresses of
   hosts and names of mail exchangers.  It would be useful to take
   advantage of the widespread use and scaleability of the DNS to store
   information that has not been previously defined.

   This paper proposes the use of the DNS TXT resource record (defined
   in STD 13, RFC 1035) to contain new types of information.  The
   principal advantage of such an approach is that it requires no change
   to most existing DNS servers.  It is not intended to replace the
   process by which new resource records are defined and implemented.

2.  Format of TXT record

   To store new types of information, the TXT record uses a structured
   format in its TXT-DATA field.  The format consists of the attribute
   name followed by the value of the attribute.  The name and value are
   separated by an equals sign (=).



Rosenbaum                                                       [Page 1]

RFC 1464          Storing Arbitrary Attributes in DNS           May 1993


   For example, the following TXT records contain attributes specified
   in this fashion:

        host.widgets.com   IN   TXT   "printer=lpr5"
        sam.widgets.com    IN   TXT   "favorite drink=orange juice"

   The general syntax is:

           TXT "="

   Attribute Names

   Any printable ASCII character is permitted for the attribute name.
   If an equals sign is embedded in the attribute name, it must be
   quoted with a preceding grave accent (or backquote: "`").  A
   backquote must also be quoted with an additional "`".

   Attribute Name Matching Rules

   The attribute name is considered case-insensitive.  For example, a
   lookup of the attribute "Favorite Drink" would match a TXT record
   containing "favorite drink=Earl Grey tea".

   During lookups, TXT records that do not contain an unquoted "=" are
   ignored.  TXT records that seem to contain a null attribute name,
   that is, the TXT-DATA starts with the character "=", are also
   ignored.

   Leading and trailing whitespace (spaces and tabs) in the attribute
   name are ignored unless they are quoted (with a "`").  For example,
   "abc" matches " abc" but does not match "` abc".

   Note that most DNS server implementations require a backslash (\) or
   double quote (") in a text string to be quoted with a preceding
   backslash.  Accent grave ("`") was chosen as a quoting character in
   this syntax to avoid confusion with "\" (and remove the need for
   confusing strings that include sequences like "\\\\").

   Attribute Values

   All printable ASCII characters are permitted in the attribute value.
   No characters need to be quoted with a "`".  In other words, the
   first unquoted equals sign in the TXT record is the name/value
   delimiter.  All subsequent characters are part of the value.

   Once again, note that in most implementations the backslash character
   is an active quoting character (and must, itself, be quoted).




Rosenbaum                                                       [Page 2]

RFC 1464          Storing Arbitrary Attributes in DNS           May 1993


   All whitespace in the attribute value is returned to the requestor
   (it is up to the application to decide if it is significant.)

   Examples

    indicates a space character.

   Attribute    Attribute       Internal Form           External Form
   Name         Value           (server to resolver)    (TXT record)

   color        blue            color=blue              "color=blue"
   equation     a=4             equation=a=4            "equation=a=4"
   a=a          true            a`=a=true               "a`=a=true"
   a\=a false           a\`=a=false             "a\\`=a=false"
   =            \=              `==\=                   "`==\\="

   string       "Cat"           string="Cat"            "string=\"Cat\""
   string2      `abc`           string2=``abc``         "string2=``abc``"
   novalue                      novalue=                "novalue="
   a b          c d             a b=c d                 "a b=c d"
   abc      123         abc` =123           "abc` =123 "

3.  Application Usage

   The attributes can be accessed by the standard resolver library, but
   it is recommended that a library routine designed specially for this
   attribute format be used.  Such a routine might provide an analogue
   to gethostbyname:

         getattributebyname(objectname,          name of object
                            attributename,       name of attribute
                            attributevalue,      pointer to buffer
                            attributevaluelen)   length of buffer

   This routine would remove all quoting characters before returning the
   information to the caller.  A more complex routine could return
   attributes with multiple values, or several different attributes.

4.  Attribute Name Registration

   To permit ease of interoperability and to reduce the chance of naming
   conflicts, a registration process for well known attribute names
   might be established.  This could be a periodically updated list of
   names and/or adherence to other name registration mechanisms such as
   published object identifiers.

   This paper does not address attribute name registration.




Rosenbaum                                                       [Page 3]

RFC 1464          Storing Arbitrary Attributes in DNS           May 1993


5.  Restrictions

   Some DNS server implementations place limits on the size or number of
   TXT records associated with a particular owner.  Certain
   implementations may not support TXT records at all.

6.  REFERENCES and BIBLIOGRAPHY

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

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

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

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

7.  Security Considerations

   Security issues are not discussed in this memo.

8. Author's Address

   Rich Rosenbaum
   Digital Equipment Corporation
   550 King Street, LKG2-2/Z7
   Littleton, MA  01460-1289

   Phone: 508-486-5922
   Email: rosenbaum@lkg.dec.com

















一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

DROP TABLE テーブルを削除する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る