PROXY  WHOIS  RQUOTE  TEXTS  SOFT  FOREX  BBOARD
 Music  Philosophy  Code  Literature  Russian

= ROOT|Technical|RFC|rfc2230.txt =

page 5 of 7




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=

1|2|3|4| < PREV = PAGE 5 = NEXT > |6|7

UP TO ROOT | UP TO DIR | TO FIRST PAGE

Google
 


E-mail Facebook Google Digg del.icio.us BlinkList Fark Furl Ma.gnolia Netscape NewsVine Reddit Slashdot Spurl StumbleUpon Technorati YahooMyWeb LiveJournal Blogmarks TwitThis Live News2.ru BobrDobr.ru Memori.ru MoeMesto.ru

0.0216999 wallclock secs ( 0.01 usr + 0.01 sys = 0.02 CPU)