Re: [dnsext] Practical question about backwards compatibility and new proposals

Andras Gustafsson <gson@araneus.fi> Thu, 16 September 2010 07:26 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666E23A6819; Thu, 16 Sep 2010 00:26:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yMeFq-fZd8I; Thu, 16 Sep 2010 00:26:56 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 021D23A6767; Thu, 16 Sep 2010 00:26:56 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1Ow8l9-000Et2-A4 for namedroppers-data0@psg.com; Thu, 16 Sep 2010 07:19:55 +0000
Received: from gusev.araneus.fi ([83.145.227.89]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <gson@araneus.fi>) id 1Ow8l5-000EsZ-Tm for namedroppers@ops.ietf.org; Thu, 16 Sep 2010 07:19:52 +0000
Received: from guava.gson.org (guava.gson.org [83.145.227.105]) by gusev.araneus.fi (Postfix) with ESMTP id 347A691843; Thu, 16 Sep 2010 10:19:48 +0300 (EEST)
Received: by guava.gson.org (Postfix, from userid 101) id C187D75E8A; Thu, 16 Sep 2010 10:19:47 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19601.50451.243072.792474@guava.gson.org>
Date: Thu, 16 Sep 2010 10:19:47 +0300
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: namedroppers@ops.ietf.org
Subject: Re: [dnsext] Practical question about backwards compatibility and new proposals
In-Reply-To: <AANLkTi=8Q-QZJo4Js_tUEg_WK0wDPv2rEumvMp+QfTeG@mail.gmail.com>
References: <AANLkTi=8Q-QZJo4Js_tUEg_WK0wDPv2rEumvMp+QfTeG@mail.gmail.com>
X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf)
From: Andras Gustafsson <gson@araneus.fi>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

Brian Dickson wrote:
> RFC 3597 is about "handling" unknown RR types, but I presume that to be
> rather narrow, in that the new RR type/class is the qtype/class, not
> something that shows up in an answer as "extra stuff" in the answer, or in
> the "additional" section.
> 
> Is this (caching of new RR types in answer to questions that *aren't* the
> new RR type) something that is specified, one way or the other, anywhere
> yet?

There was some discussion related to this last year, starting with

  http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02683.html

To reiterate what I said then, I think the concepts of "RRs of unknown
type" and "unexpected RRs appearing in some section of a message"
should be treated as orthogonal.  For example, a type MX record
occurring in the answer section of a response to a type A query is an
unexpected RR, but it is not of unknown type.

RFC 3597 deals with unknown types, but I don't think the treatment
of unexpected RRs is currently specified anywhere.  Existing
implementations tend to ignore them when they occur in the answer
section of a response, and may or may not cache them when they occur
in the additional section depending on spoofing defense strategy.

If we end up specifying the treatment of unexpected/unsolicited RRs,
I think whatever treatment we specify should be the same whether the
type is known or unknown.
-- 
Andreas Gustafsson, gson@araneus.fi