Attaching Meaning to Solicitation Class Keywords
Extracted elements (17)
Approaches such as defining an XML-based structure to contain specific meta-data about solicitation class keywords were ruled out. The explicit design goal was to keep the system as simple as possible, merely associating a keyword with a URI that contains an explanation.
The document explicitly chose not to use Straightforward-NAPTR (S-NAPTR) because S-NAPTR does not permit the 'U' flag for terminal lookups and does not support the regular expression field. Since the goal was to find a URI (not just a domain name), S-NAPTR was unsuitable.
Due to domain name case-insensitivity and the ':'-to-'.' substitution rule, the solicitation class keywords 'com.example:ADV', 'com.Example:adv', and 'com:example:ADV' are syntactically equivalent for purposes of this DDDS application.
Wildcards are appropriate for this application, allowing multiple solicitation class keywords sharing a common prefix to point to the same URI. However, implementors and zone administrators should exercise care because wildcards may have unintended effects if multiple types of NAPTR resource records are used.
In the REGEXP field, the extended regular expression MUST be empty and the replacement value MUST contain a valid URI as specified in RFC 3986.
The document retrieved at the URI SHOULD conform to HTML 4.01, including the Accessibility Guidelines contained therein.
The FLAGS field of the NAPTR RR MUST contain the character 'U', the SERVICES field MUST contain only the string 'no-solicit', the REGEXP field MUST contain a valid URI, and the REPLACEMENT field MUST be empty.
The replacement value in the REGEXP field SHOULD contain a URI limited to the 'ftp', 'http', and 'https' schemes.
When multiple NAPTR records are returned, the one(s) with the lowest ORDER value that have a matching SERVICE field MUST be used. Of those with the lowest ORDER value, those with the lowest PREFERENCE SHOULD be used.
A solicitation class keyword (e.g., 'org.example.adv') is transformed into a DNS lookup key by substituting '.' for ':' and reversing the label. For example, 'org.example:ADV' becomes 'ADV.example.org'. This key is then used to query for NAPTR resource records.
Solicitation class keywords are domain-name-based labels in reversed format (e.g., 'com.example.adv'), case-insensitive, with ':' treated equivalently to '.'. The resulting DNS lookup string must respect DNS label length limits (63 chars per label, 253 chars total) and IDN encoding for non-ASCII characters.
The No-Solicit NAPTR application uses a single DNS NAPTR lookup to map a solicitation class keyword to a URI. The DDDS application unique string is a Solicitation Class Keyword as defined in RFC 3865, and the expected output is a URI containing information about that keyword.
There is no central IANA registry for values in the NAPTR 'SERVICE' field. However, IANA maintains an Application Service Tag Registry for S-NAPTR (RFC 3958), and IANA is advised that the 'no-solicit' value for the SERVICE field is in use per this document and should not be used in that registry for other applications.
A malicious sender could insert a large number of solicitation class keywords or improperly formatted keywords, causing a Denial of Service attack via excessive DNS lookups on recipients or overloading a provider at a particular URI. Improperly formatted keywords with non-existent TLDs could attack DNS registry providers or root servers.
A malicious sender or intermediate MTA could insert a solicitation class keyword and use the associated URI to mislead message recipients, for example by falsely indicating official status for a message. Users must take additional steps outside this specification to determine what and whom to believe.
Domain names are not persistent identifiers. A domain name or URI embedded in an email message may in the future be controlled by a different zone administrator, causing the application to yield different or inconsistent results over time.
If DNS lookups are compromised (e.g., without DNSSEC), the application may return a URI with incorrect guidance. Use of 'https:' without DNSSEC creates an unwarranted illusion of authenticity. Even with both DNSSEC and 'https:', clients must ensure the two signature validation contexts are administered by the same domain owner.