PMDF System Manager's Guide

Domain literals are handled specially during the rewriting process. If a domain literal appearing in the domain portion of an address does not match a rewrite rule pattern as-is, the literal is interpreted as a group of strings separated by periods and surrounded by square brackets.⁹ The rightmost string is removed and the search is repeated. If this does not work the next string is removed, and so on until only empty brackets are left. If the search for empty brackets fails, the entire domain literal is removed and rewriting proceeds with the next section of the domain address, if there is one. No asterisks are used in the internal processing of domain literals; when an entire domain literal is replaced by an asterisk the number of asterisks corresponds to the number of elements in the domain literal.

Like normal domain/host specifications, domain literals are also tried in most specific to least specific order. The first rule whose pattern matches will be the one used to rewrite the host/domain specification. If there are two identical patterns in the rules list, the one which appears first will be used.

As an example, suppose the address iris@[198.162.3.40] is to be rewritten. The rewriter looks for [198.162.3.40], then [198.162.3.], then [198.162.], then [198.], then [], then [*.*.*.*], and finally the match-all rule ".".

When domain literals are combined with domain names the number of lookup attempts gets to be quite large. This is not normal usage and its use is strongly discouraged. For example, the address iris@[1.2].a.[3.4].b would generate requests for:

[1.2].a.[3.4].b [1.].a.[3.4].b [].a.[3.4].b [*.*].a.[3.4].b .a.[3.4].b [*.*].*.[3.4].b .[3.4].b [*.*].*.[3.].b .[3.].b [*.*].*.[].b .[].b [*.*].*.[*.*].b .b [*.*].*.[*.*].* .