Solaris Naming Administration Guide

Appendix D FNS Reference Formats and Syntax

This appendix contains supplemental information about the use of DNS text (TXT) records and the use of X.500 attributes in XFN references.

DNS Text Record Format for 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 will need to enter information into DNS TXT resource records. This information will then be used to construct an XFN reference for that subordinate naming system. This appendix describes the format of these DNS TXT records.

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

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

X.500 Attribute Syntax for XFN References

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.

Object Classes

Two new object classes, XFN and XFN-supplement, are introduced to support XFN references. The XFN object class is not relevant in FNS since SunSoft's 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:

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"