Subject: First draft of EDNS0 interop test

From: "Scott Rose" <[email-masked]>
Date: Thu, 26 May 2005 10:15:44 -0400

This probably won't be posted as an official Internet Draft yet, since it's
only a test plan and not an interoperability test.  Comments most welcome -
looking to make this test plan better before producing the formal write up
of the EDNS0 interop test.

Please note the comment on Test 10 below - it addresses Section 5.3 in
RFC2671, which has been noted before on namedroppers to be a possible
ambiguity in the spec.

Scott

----------------------------------------------------------------------------
--

Network Working Group                                         J. Quanaim
Internet-Draft                                                    Lucent
Expires: November 27, 2005                                       S. Rose
                                                                    NIST
                                                            May 26, 2005

 Interoperability Test for Extension Mechanism for DNS (EDNS) Version 0
                      draft-qr-rfc2671-interop-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 27, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   The Extension Mechanism for DNS (EDNS) is described in RFC 2671 and
   is a base pre-requisite for other extensions to the DNS such as
   DNSSEC and IPv6 support.  This document lays out a plan to test the
   interoperability of clients and servers that claim EDNS version 0
   implementation.

Quanaim & Rose          Expires November 27, 2005               [Page 1]

Internet-Draft                EDNS0-Interop                     May 2005

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Tests  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1   Non-EDNS0 Aware Client Request to a Non-EDNS0 Aware
           Server . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2   Non-EDNS0 Aware Client Request to an EDNS0 Aware Server  .  4
     2.3   EDNS0 Aware Client Request to a Non-EDNS0 Aware Server . .  4
     2.4   EDNS0 Client Request to an EDNS0 Aware Server  . . . . . .  5
   3.  Candidate Software . . . . . . . . . . . . . . . . . . . . . .  7
   4.  External issues  . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1   Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2   Informative References . . . . . . . . . . . . . . . . . . 11
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
       Intellectual Property and Copyright Statements . . . . . . . . 12

Quanaim & Rose          Expires November 27, 2005               [Page 2]

Internet-Draft                EDNS0-Interop                     May 2005

1.  Introduction

   The Extension Mechanisms for DNS (EDNS0) expands the DNS message
   format allowing for larger DNS packets, additional signaling, and
   more error types.  It does this while preserving the original format
   of the DNS message and should therefore be backwards compatible.
   EDNS0 defines a new RR, OPT to provide this functionality.  Please
   refer to RFC2671 [1] for further details.

Quanaim & Rose          Expires November 27, 2005               [Page 3]

Internet-Draft                EDNS0-Interop                     May 2005

2.  Tests

   The following matrix shows the possible interactions between a client
   and server of which each may or may not be EDNS0 aware.  Furthermore,
   a server may be either authoritative or caching.  The section
   describing the exchange is listed in the corresponding cell.

                        .---------------------------------.
                        | non-EDNS0 server | EDNS0 server |
     .------------------+------------------+--------------|
     | non-EDNS0 client |                1 |            2 |
     |------------------+------------------+--------------|
     | EDNS0 client     |                3 |            4 |
     '----------------------------------------------------'

   To test a caching server, a valid EDNS0 client and server are needed.
   The caching server should be placed between them to resolve requests.

2.1  Non-EDNS0 Aware Client Request to a Non-EDNS0 Aware Server

   There are no test cases as this should be considered within RFC 1035.
   EDNS0 does not affect these transactions.

2.2  Non-EDNS0 Aware Client Request to an EDNS0 Aware Server

   A DNS response message should never contain an unsolicited OPT RR.
   An OPT RR should only be provided in a response to a request that
   contained an OPT RR.  Therefore, no EDNS0 functionally is expected in
   these tests.

      Test 1:  Send non-EDNS0 query with expected result < 512 bytes.

      Expected result:  Non-EDNS0 response

      Test 2:  Send non-EDNS0 query with expected result > 512 bytes

      Expected result:  Non-EDNS0 response truncated (TC bit set)

      Test 3:  Send non-EDNS0 query for DNSSEC type (QTYPE=DNSKEY)

      Expected result:  Non-EDNS0 response

2.3  EDNS0 Aware Client Request to a Non-EDNS0 Aware Server

   A non-EDNS0 aware server may generate any of the basic DNS error

Quanaim & Rose          Expires November 27, 2005               [Page 4]

Internet-Draft                EDNS0-Interop                     May 2005

   responses such as NOTIMPL, FORMERR, or SERVFAIL in response to an
   EDNS0 request.  Additionally, a DNS server not supporting EDNS0 may
   ignore the OPT RR and respond without such functionality.

      Test 4:  Send EDNS0 request

      Expected result:  Error response or request dropped

      Test 5:  Send request for OPT RR (QTYPE=OPT)

      Expected result:  Error response

2.4  EDNS0 Client Request to an EDNS0 Aware Server

   In these series of tests, both the client and server use EDNS0 as
   documented in RFC2671[1].  However, a client may introduce other
   extensions or later versions of EDNS to test server response codes.

      Test 6:  Send request with a single OPT RR using normal EDNS0
      semantics.

      Expected result:  Normal DNS response with EDNS0 enabled

      Test 7:  Send request with two OPT RRs of different values.

      Expected result:  Error response (BADVERS)

      Test 8:  Send request with EDNS0 version = 3

      Expected result:  Error response of BADVER

      Test 9:  Send request for OPT RR (QTYPE=OPT)

      Expected result:  Error response

      AUTHOR'S COMMENT: The next test may be unnecessary.  However, it is
      the author's opinion that Section 5.3 of RFC 2671 [1] does not
      fully address how receivers should handle unknown extensions
      provided that the version numbers match.

      Test 10:  Send request with unknown extension in OPT RDATA

Quanaim & Rose          Expires November 27, 2005               [Page 5]

Internet-Draft                EDNS0-Interop                     May 2005

      Expected result:  Undefined, possible error code response.

Quanaim & Rose          Expires November 27, 2005               [Page 6]

Internet-Draft                EDNS0-Interop                     May 2005

3.  Candidate Software

   Below is the first list of possible candidate software for the
   interoperability tests described above.  Non-EDNS aware servers and
   clients are necessary for the tests described in Sections 2.1 and
   2.2.  This list is by no means complete and suggestions for
   additional implementations are welcome.

   Authoritative Servers: BIND (8.4.X, 9.3.X), NSD (2.1.X, 2.2.X),
      dnsjava.

   Caching Servers: BIND (8.4.X, 9.3.X)

   Clients: dnsjava, dig(libresolv), NET::DNS (perl).

   No EDNS Support: MaraDNS, djbdns, Posadis.

Quanaim & Rose          Expires November 27, 2005               [Page 7]

Internet-Draft                EDNS0-Interop                     May 2005

4.  External issues

   While outside the scope of this document, many existing firewall
   implementations block DNS packets using EDNS0 because of an outdated
   belief that DNS UDP packets should not exceed the size of 512 bytes.

Quanaim & Rose          Expires November 27, 2005               [Page 8]

Internet-Draft                EDNS0-Interop                     May 2005

5.  IANA Considerations

   This document does not specify any new IANA considerations.

Quanaim & Rose          Expires November 27, 2005               [Page 9]

Internet-Draft                EDNS0-Interop                     May 2005

6.  Security Considerations

   This document does not address any security considerations with using
   ENDS.

Quanaim & Rose          Expires November 27, 2005              [Page 10]

Internet-Draft                EDNS0-Interop                     May 2005

7.  References

7.1  Normative References

   [1]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
        August 1999.

7.2  Informative References

   [2]  Mockapetris, P., "Domain names - implementation and
        specification", STD 13, RFC 1035, November 1987.

   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
        "DNS Security Introduction and Requirements", RFC 4033,
        March 2005.

   [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
        "Resource Records for the DNS Security Extensions", RFC 4034,
        March 2005.

   [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
        "Protocol Modifications for the DNS Security Extensions",
        RFC 4035, March 2005.

Authors' Addresses

   Joe Quanaim
   Lucent Technologies
   2C-338 600-700 Mountain Avenue
   Murray Hill, NJ  07974
   USA

   Email: [email-masked]

   Scott Rose
   National Institute for Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899-8920
   USA

   Email: [email-masked]

Quanaim & Rose          Expires November 27, 2005              [Page 11]

Internet-Draft                EDNS0-Interop                     May 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP 11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementers or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Quanaim & Rose          Expires November 27, 2005              [Page 12]

Internet-Draft                EDNS0-Interop                     May 2005

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Quanaim & Rose          Expires November 27, 2005              [Page 13]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>