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

Andreas Gustafsson <gson@araneus.fi> Fri, 17 September 2010 12:27 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 3B13E3A684D; Fri, 17 Sep 2010 05:27:28 -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 s2+IphqQd7ot; Fri, 17 Sep 2010 05:27:26 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 740F13A6898; Fri, 17 Sep 2010 05:27:26 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1OwZwN-000Jaa-Pp for namedroppers-data0@psg.com; Fri, 17 Sep 2010 12:21:19 +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 1OwZwK-000JZP-PG for namedroppers@ops.ietf.org; Fri, 17 Sep 2010 12:21:17 +0000
Received: from guava.gson.org (guava.gson.org [83.145.227.105]) by gusev.araneus.fi (Postfix) with ESMTP id 168C891844; Fri, 17 Sep 2010 15:21:12 +0300 (EEST)
Received: by guava.gson.org (Postfix, from userid 101) id 029E275F6A; Fri, 17 Sep 2010 15:21:11 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19603.23863.778845.49249@guava.gson.org>
Date: Fri, 17 Sep 2010 15:21:11 +0300
To: Florian Weimer <fweimer@bfk.de>
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, namedroppers@ops.ietf.org
Subject: Re: [dnsext] Practical question about backwards compatibility and new proposals
In-Reply-To: <82y6b0wyjf.fsf@mid.bfk.de>
References: <AANLkTi=8Q-QZJo4Js_tUEg_WK0wDPv2rEumvMp+QfTeG@mail.gmail.com> <19601.50451.243072.792474@guava.gson.org> <82y6b0wyjf.fsf@mid.bfk.de>
X-Mailer: VM 8.0.14 under 21.4.1 (i386--netbsdelf)
From: Andreas 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/>

Florian Weimer wrote:
> > 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.
> 
> Quite apparently, implementations which do not implement DNSSECbis and
> still set the DO bit in queries (because they implement DNSSEC) ignore
> the RRSIG records in the answer, authority, and additional sections of
> responses.  I don't think other RRs would receive different treatment,
> provided that the DO bit is set in the query.

If I'm reading your message correctly, you seem to be agreeing with my
statement "implementations tend to ignore them when they occur in the
answer section" and with the "may not cache" part of "may or may not
cache them when they occur in the additional section".

To demonstrate that both the "may cache" and "may not cache" case
occurs in the wild, I have temporarily delegated the domain
unsolicited.additional.test.araneus.fi to an authoritative server that
responds to a type A query with an unexpected TXT record in the
additional section.

For example, when using the BIND 9 resolver in the OARC DNSSEC
testbed:

  dig unsolicited.additional.test.araneus.fi. A @149.20.64.20

the response does not contain this TXT record, but when using the
Unbound resolver in the same testbed:

  dig unsolicited.additional.test.araneus.fi. A @149.20.64.21

it does, and a second identical query will return a cached copy.
-- 
Andreas Gustafsson, gson@araneus.fi