ietf-corpus

rfc-2163

Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)

C. Allocchio
date1998-01 streamIETF areaapp wgmixer statusPROPOSED STANDARD pages26 canonicalhttps://www.rfc-editor.org/rfc/rfc2163 doi10.17487/RFC2163
This memo is the complete technical specification to store in the Internet Domain Name System (DNS) the mapping information (MCGAM) needed by MIXER conformant e-mail gateways and other tools to map RFC822 domain names into X.400 O/R names and vice versa. [STANDARDS-TRACK]

obsoletes

updated by

Extracted elements (22)

design-rationale §4

A new PX resource record was created rather than reusing existing DNS RR types (e.g., PTR) to avoid clashes with existing data structures and to provide an appropriate data structure for the specific format and syntax of MCGAM rules, as well as to allow flexibility for future development.

dns, email

design-rationale §2

DNS distribution of MCGAM is preferred over static tables because it avoids fetching and storing entire mapping tables, allows timely updates, supports full authority delegation, enables remote debugging of gateway mappings, and is accessible to a broad range of tools such as address converters and user agents.

dns, email

design-rationale §4.4

The DNS authority delegation model eliminates the gate1/gate2 ambiguity inherent in static tables: the authority controlling an RFC822 DNS zone exclusively decides whether its domain uses Standard Attributes (table2) or DDA encoding (gate2), and similarly for X.400 zones choosing between SA (table1) and LHS encoding (gate1).

dns, email

design-rationale §4.1

The PREFERENCE field was added to PX RDATA (mirroring MX record semantics) to address the practical problem that some X.400 ADMD providers do not accept messages with a blank ADMD, requiring a way to specify multiple mappings with priority ordering for domains with multiple connectivity.

dns, email

design-rationale §3

The X.400 name space is anchored under national ISO country top-level domains (via X42D.cc) rather than a new global root branch, because X.400 is inherently country-oriented and lacks an international root concept. This moves coordination to the national level where it is more tractable and aligns with the Internet regionalization process.

dns, email

interoperability-note §4.1

The PREFERENCE value extension and explicit exact-match DNS entries are not available in MIXER static tables. Their use is strongly discouraged when interworking with any table-based gateway or application, and they should be considered reserved for future use in current deployments.

dns, email

interoperability-note §1

This memo obsoletes RFC 1664 and maintains full backward compatibility with it. DNS software implementations supporting RFC 1664 support this specification with no modification; the primary addition is full support for the MIXER 'gate1' table.

dns, email

normative-requirement §4.3 MUST

All fully qualified <domain-name> elements in PX records — including <name>, MAP822, and MAPX400 — must end with a trailing '.' (root label) per standard DNS conventions.

dns, email

normative-requirement §10 SHOULD

Clients using PX records SHOULD ensure that routing and address translations are based only on authoritative DNS answers, to prevent misdirection of mail via forged PX responses.

dns, email, security

normative-requirement §4.1 SHOULD

For current use, the PREFERENCE value in the PX record specification SHOULD be fixed to a value of 50, and only wildcard specifications SHOULD be used when specifying <name> values, to maintain interoperability with MIXER static table-based gateways.

dns, email

normative-requirement §5 SHOULD

If a DNS query for a PX record results in a timeout, the gateway operation MUST be delayed and retried later. If a DNS error code is returned, an error message should be logged and the gateway operation delayed as for timeout.

dns, email

normative-requirement §3 MUST NOT

Local mappings (not intended for global use) MUST NOT be included in DNS PX records. If local mappings are used, they must be stored using static local tables, analogously to local static host tables.

dns, email

normative-requirement §10 SHOULD

Once DNS Security mechanisms (RFC 2065) become more widely deployed, clients SHOULD employ those mechanisms to verify the authenticity and integrity of PX records.

dns, email, security

protocol-element §3

A new X.400 O/R name space is defined in DNS by placing a reserved label 'X42D' under each national ISO two-letter country code top-level domain (e.g., X42D.it, X42D.de). Under X42D the hierarchy follows X.400 structure: ADMD, PRMD, O, OU. This anchors X.400 'table1' and 'gate1' mapping entries in the DNS.

dns, email

protocol-element §4.4

Gate table entries ('gate1' and 'gate2') are distinguished from standard mapping entries ('table1' and 'table2') by appending the literal '.G.' suffix to the MAPX400 field in PX RDATA. This suffix must be stripped before using the mapping data. Its presence signals that DDA encoding (for gate2) or LHS encoding (for gate1) should be applied.

dns, email

protocol-element §3

MIXER defines four mapping tables stored as PX records: 'table1' (X.400→RFC822) and 'gate1' (X.400→RFC822 via gateway) are stored under the X42D name space using X.400 domain keys; 'table2' (RFC822→X.400) and 'gate2' (RFC822→X.400 via gateway) are stored in the normal RFC822 domain name space.

dns, email

protocol-element §4.2.3

The Country Code Convention specifies that the 'C-cc' component of an X.400 domain in <domain-name> syntax MUST be omitted when forming the DNS <name> key for 'table1' or 'gate1' entries, because the country code is already implicit in the X42D.cc zone. For example, 'ADMD$acme.C$fr' becomes the key 'ADMD-acme.X42D.fr.'

dns, email

protocol-element §5

The DNS query mechanism for MIXER mapping uses wildcard PX records (e.g., '*.net2.it. IN PX 50 ...') to provide implicit wildcard matching consistent with MCGAM semantics. DNS natively returns the longest matching rule in a single query, so no iterative multi-query search is required.

dns, email

protocol-element §4

The PX (Pointer to X.400/RFC822 mapping) DNS resource record is defined with class IN and numeric value 26. It stores MIXER Conformant Global Address Mapping (MCGAM) rules in the DNS, replacing the need for centrally maintained static tables.

dns, email

protocol-element §4.2.1

X.400 O/R name attributes are encoded into DNS <domain-name> syntax via an escape mechanism: missing attributes map to bare <attr-label>, blank attributes append 'b', hyphens map to '-h-', quoted dots to '-d-', spaces to '-b-', and other non-alphanumeric characters to their 3-digit decimal ASCII code enclosed in hyphens. A trailing hyphen in the translation is omitted.

dns, email

security-consideration §10

An attacker who delivers incorrect PX records can cause forged originator addresses, misdirected mail to unauthorized recipients, or forced routing through compromised gateways. Attack vectors include compromising a DNS server, sending counterfeit responses to DNS queries, or returning incorrect additional section data in response to unrelated queries.

dns, email, security

wire-format §4

PX RDATA consists of three fields: PREFERENCE (16-bit integer, lower values preferred), MAP822 (a <domain-name> containing the RFC822 domain part of the MCGAM), and MAPX400 (a <domain-name> containing the X.400 O/R address in DNS-compatible syntax). Standard DNS conventions including wildcards, abbreviations, and message compression apply.

dns, email