This appendix contains supplemental information about the use of DNS text (TXT) records and the use of X.500 attributes in XFN references.
The Solaris environment conforms to the XFN specification for federating global naming systems within DNS. In order to federate a naming system under DNS, you need to enter information into DNS TXT resource records. This information is then used to construct an XFN reference for that subordinate naming system. This appendix describes the format of these DNS TXT records.
See Chapter 26, FNS and Global Naming Systems, for the procedures needed to federate DNS.
For details on how to manipulate records in DNS in general, see DNS and BIND in a Nutshell, by Paul Albitz and Crickett Liu (O'Reilly and Associates, 1992).
The reference type of an XFN reference is constructed from a TXT record that begins with the XFNREF tag. It has the following format:
TXT "XFNREF rformat reftype" |
If spaces occur within the string appearing after TXT, such spaces must be escaped, or the entire string must be enclosed within double quotation marks. The three fields, XFNREF, rformat and reftype, are separated using space (spaces and tabs). rformat specifies format of the reference type identifier. It can be one of the following:
reftype specifies the contents of the reference type identifier.
If no XFNREF TXT record exists, the reference type defaults to an identifier XFN_SERVICE, with an FN_ID_STRING format. If more than one XFNREF TXT record exists, the handling of the record is undefined. The following TXT record is equivalent to the default XFNREF:
TXT "XFNREF STRING XFN_SERVICE" |
The address information for an XFN reference is constructed using TXT records with tags prefixed with the XFN string. Multiple addresses may be specified for a single reference. Records with the same tag are grouped and passed to the handler for each group. Each handler generates zero or more addresses from its group of TXT records and appends the addresses to the reference. The XFNREF tag is special in that it is used only to construct the reference type and thus, it is excluded from the address-construction process.
The syntax of address TXT records is as follows:
XFNaddress_type_tag address_specific_data |
The two fields, XFN_address_type_tag and address_specific_data, are separated using space (spaces and tabs). The address_type_tag specifies the handler to be used for address_specific_data.
TXT records have a limitation of 2K bytes of characters per record. If the address-specific data is too long to be stored in a single TXT record, multiple TXT records may be used, as shown:
TXT "XFNaddress_type_tag address_specific_data1" TXT "XFNaddress_type_tag address_specific_data2" |
When the tag-specific handler is called, both records are passed to it. The handler is responsible for determining the order in which these two lines need to be interpreted.
The order in which TXT records appear is not significant. If lines with different tags are present, lines with the same tag are grouped together before the tag-specific handler is called. In the following example, the handler for tag1 will be called with two text lines, and the handler for tag2 will be called with three text lines.
TXT "XFNtag1 address_specific_data1" TXT "XFNtag2 address_specific_data2" TXT "XFNtag1 address_specific_data3" TXT "XFNtag2 address_specific_data4" TXT "XFNtag2 address_specific_data5" |
Here are some examples of TXT records that can be used for XFN references.
Example 1
TXT "XFNREF STRING XFN_SERVICE" TXT "XFNNISPLUS doc.com. nismaster 129.144.40.23" |
Example 2
TXT "XFNREF OID 1.3.22.1.6.1.3" TXT "XFNDCE (1 fd33328c4-2a4b-11ca-af85-09002b1c89bb...)" |
The following is an example of a DNS table with a subordinate naming system bound in it.
$ORIGIN test.doc.com @ IN SOA foo root.eng.doc.com ( 100 ;; Serial 3600 ;; Refresh 3600 ;; Retry 3600 ;; Expire 3600 ;; Minimum ) NS nshost TXT "XFNREF STRING XFN_SERVICE" TXT "XFNNISPLUS doc.com. nismaster 129.144.40.23" nshost IN A 129.144.40.21 |
This section contains supplemental information about the use of X.500 attributes for XFN references. In order to permit an XFN reference to be stored as an attribute in X.500, the directory schema must be modified to support the object classes and attributes defined in this appendix.
See Chapter 26, FNS and Global Naming Systems, for the procedures needed to federate X.500.
See Managing the X.500 Client Toolkit for information about modifying the X.500 directory schema.
Two new object classes, XFN and XFN-supplement, are introduced to support XFN references. The XFN object class is not relevant in FNS since the Sun Microsystems X.500 directory product cannot support the introduction of new compound ASN.1 syntaxes. Instead, FNS uses the XFN-supplement object class.
The two new object classes are defined in ASN.1 as follows:
xFN OBJECT-CLASS ::= { SUBCLASS OF { top } KIND auxiliary MAY CONTAIN { objectReferenceId | objectReference | nNSReferenceId | nNSReference } ID id-oc-xFN } id-oc-xFN OBJECT IDENTIFIER ::= { iso(1) member-body(2) ansi(840) sun(113536) ds-oc-xFN(24) } xFNSupplement OBJECT-CLASS ::= { SUBCLASS OF { top } KIND auxiliary MAY CONTAIN { objectReferenceString | nNSReferenceString } ID id-oc-xFNSupplement } id-oc-xFNSupplement OBJECT IDENTIFIER ::= { iso(1) member-body(2) ansi(840) sun(113536) ds-oc-xFNSupplement(25) } |
The XFN-supplement object class is defined as an auxiliary object class so that it may be inherited by all X.500 object classes. It is defined with two optional attributes:
objectReferenceString is used to hold an XFN reference to the object itself.
nNSReferenceString is used to hold an XFN reference to a next naming system.
Both attributes are defined in ASN.1 as follows:
objectReferenceString ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { id-at-objectReferenceString } } id-at-objectReferenceString OBJECT IDENTIFIER ::= { iso(1) member-body(2) ansi(840) sun(113536) ds-at-objectReferenceString(30) } nNSReferenceString ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch SINGLE VALUE TRUE ID { id-at-nNSReferenceString } } id-at-nNSReferenceString OBJECT IDENTIFIER ::= { iso(1) member-body(2) ansi(840) sun(113536) ds-at-nNSReferenceString(31) } |
Both objectReferenceString and nNSReferenceString store XFN references in a string form. Their octet string syntax is further constrained to conform to the following BNF definition:
<ref> ::= <id> '$' <ref-addr-set> <ref-addr-set> ::= <ref-addr> | <ref-addr> '$' <ref-addr-set> <ref-addr> ::= <id> '$' <addr-set> <addr> ::= <hex-string> <id> ::= 'id' '$' <string> | 'uuid' '$' <uuid-string> | 'oid' '$' <oid-string> <string> ::= <char> | <char> <string> <char> ::= <PCS> | '\' <PCS> <PCS> ::= // Portable Character Set: // !"#$%&'()*+,-./0123456789:;<=>? // @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_ // `abcdefghijklmnopqrstuvwxyz{|}~ <uuid-string> ::= <uuid-char> | <uuid-char> <uuid-string> <uuid-char> ::= <hex-digit> | '-' <oid-string> ::= <oid-char> | <oid-char> <oid-string> <oid-char> ::= <digit> | '.' <hex-string> ::= <hex-octet> | <hex-octet> <hex-string> <hex-octet> ::= <hex-digit> <hex-digit> <hex-digit> ::= <digit> | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'A' | 'B' | 'C' | 'D' | 'E' | 'F' <digit> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' |
The following example is a string form XFN reference:
id$onc_fn_enterprise$id$onc_fn_nisplus_root$0000000f77697a2e636fd2e2062696762696700 |
The example uses an XFN reference of type onc_fn_enterprise. It contains the address type onc_fn_nisplus_root and a single address value. The address value is an XDR-encoded string, comprising the domain name, doc.com, followed by the host name, cygnus.
An XFN reference may be added to an X.500 entry by using the FNS command fnattr, as in this example:
# fnattr -a .../c=us/o=doc object-class top organization xfn-supplement |
creates a new entry called c=us/o=doc and adds an object class attribute with the values top, organization , and XFN-supplement.
The FNS command fnbind binds the NIS+ reference to the named entry and links X.500 to the root of the NIS+ namespace. (Note the use of a trailing slash in the name argument to fnbind.)
# fnbind -r .../c=us/o=doc/ onc_fn_enterprise onc_fn_nisplus_root "doc.com. cygnus" |