3. SYNTAX OF KX RECORD
A KX record has the DNS TYPE of "KX" and a numeric value of 36. A KX
record is a member of the Internet ("IN") CLASS in the DNS. Each KX
record is associated with a <domain-name> entry in the DNS. A KX
record has the following textual syntax:
<domain-name> IN KX <domain-name>
For this description, let the <domain-name> item to the left of the
"KX" string be called <domain-name 1> and the <domain-name> item to
the right of the "KX" string be called <domain-name 2>.
is a non-negative integer.
Internet nodes about to initiate a key exchange with <domain-name 1>
should instead contact <domain-name 2> to initiate the key exchange
for a security service between the initiator and <domain-name 2>. If
more than one KX record exists for <domain-name 1>, then the
field is used to indicate preference among the systems
delegated to. Lower values are preferred over higher values. The
<domain-name 2> is authorised to provide key exchange services on
behalf of <domain-name 1>. The <domain-name 2> MUST have a CNAME
record, an A record, or an AAAA record associated with it.
3.1 KX RDATA format
The KX DNS record has the following RDATA format:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ EXCHANGER /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
PREFERENCE A 16 bit non-negative integer which specifies the
preference given to this RR among other KX records
at the same owner. Lower values are preferred.
EXCHANGER A <domain-name> which specifies a host willing to
act as a mail exchange for the owner name.
RFC 2230 DNS Key Exchange Delegation Record November 1997
KX records MUST cause type A additional section processing for the
host specified by EXCHANGER. In the event that the host processing
the DNS transaction supports IPv6, KX records MUST also cause type
AAAA additional section processing.
The KX RDATA field MUST NOT be compressed.
4. SECURITY CONSIDERATIONS
KX records MUST always be signed using the method(s) defined by the
DNS Security extensions specified in [RFC-2065]. All unsigned KX
records MUST be ignored because of the security vulnerability caused
by assuming that unsigned records are valid. All signed KX records
whose signatures do not correctly validate MUST be ignored because of
the potential security vulnerability in trusting an invalid KX
record.
KX records MUST be ignored by systems not implementing Secure DNS
because such systems have no mechanism to authenticate the KX record.
If a node does not have a permanent DNS entry and some form of
Dynamic DNS Update is in use, then those dynamic DNS updates MUST be
fully authenticated to prevent an adversary from injecting false DNS
records (especially the KX, A, and PTR records) into the Domain Name
System. If false records were inserted into the DNS without being
signed by the Secure DNS mechanisms, then a denial-of-service attack
results. If false records were inserted into the DNS and were
(erroneously) signed by the signing authority, then an active attack
results.
Myriad serious security vulnerabilities can arise if the restrictions
throuhout this document are not strictly adhered to. Implementers
should carefully consider the openly published issues relating to DNS
security [Bell95,Vixie95] as they build their implementations.
Readers should also consider the security considerations discussed in
the DNS Security Extensions document [RFC-2065].
5. REFERENCES
[RFC-1825] Atkinson, R., "IP Authentication Header", RFC 1826,
August 1995.
[RFC-1827] Atkinson, R., "IP Encapsulating Security Payload",
RFC 1827, August 1995.
=5= |