Re: [dnsext] duplicate RRs and resulting RRSIG
Doug Barton <dougb@dougbarton.us> Wed, 04 January 2012 21:48 UTC
Return-Path: <dougb@dougbarton.us>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB14211E80BF for <dnsext@ietfa.amsl.com>; Wed, 4 Jan 2012 13:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.516
X-Spam-Level:
X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtZluGLDY9L2 for <dnsext@ietfa.amsl.com>; Wed, 4 Jan 2012 13:48:14 -0800 (PST)
Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by ietfa.amsl.com (Postfix) with ESMTP id 21EB311E80A6 for <dnsext@ietf.org>; Wed, 4 Jan 2012 13:48:13 -0800 (PST)
Received: (qmail 23112 invoked by uid 399); 4 Jan 2012 21:48:12 -0000
Received: from unknown (HELO 172-17-198-245.globalsuite.net) (dougb@dougbarton.us@12.207.105.210) by mail2.fluidhosting.com with ESMTPAM; 4 Jan 2012 21:48:12 -0000
X-Originating-IP: 12.207.105.210
X-Sender: dougb@dougbarton.us
Message-ID: <4F04C91A.3040408@dougbarton.us>
Date: Wed, 04 Jan 2012 13:48:10 -0800
From: Doug Barton <dougb@dougbarton.us>
Organization: http://SupersetSolutions.com/
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20111222 Thunderbird/9.0
MIME-Version: 1.0
To: bert hubert <bert.hubert@netherlabs.nl>
References: <CA+wr5LX8DbiGZnxEtQxRMsiW3Y+RnVHMZsBnuge=783BTL5PiQ@mail.gmail.com> <CACU5sDm8UZMqkL_jp-jrz5P6S_mOi8mYdi9xNUp7J=5k85d8zA@mail.gmail.com> <20120104205520.GA17188@xs.powerdns.com>
In-Reply-To: <20120104205520.GA17188@xs.powerdns.com>
X-Enigmail-Version: undefined
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "dnsext@ietf.org" <dnsext@ietf.org>
Subject: Re: [dnsext] duplicate RRs and resulting RRSIG
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jan 2012 21:48:15 -0000
On 01/04/2012 12:55, bert hubert wrote: >> putting the RRset in canonical form, it MUST treat this as a protocol >> > error. If the implementation chooses to handle this protocol error >> > in the spirit of the robustness principle (being liberal in what it >> > accepts), it MUST remove all but one of the duplicate RR(s) for the >> > purposes of calculating the canonical form of the RRset. > > This is exciting language - you MUST do A, but if you don't THEN you MUST do > B ;-) We'll go for B. It's not either/or. You MUST treat this as a protocol error (i.e., you cannot let the data proceed in its current condition). The option is in how you HANDLE the protocol error. You can either kick it back to the user in terms of failing to load the zone, or you can fix it up internally and proceed. Personally, I think it's better to kick it back to the user. Otherwise, how will they learn? Doug -- You can observe a lot just by watching. -- Yogi Berra Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
- [dnsext] duplicate RRs and resulting RRSIG bert hubert
- Re: [dnsext] duplicate RRs and resulting RRSIG Mohan Parthasarathy
- Re: [dnsext] duplicate RRs and resulting RRSIG bmanning
- Re: [dnsext] duplicate RRs and resulting RRSIG bert hubert
- Re: [dnsext] duplicate RRs and resulting RRSIG Doug Barton
- Re: [dnsext] duplicate RRs and resulting RRSIG SM
- Re: [dnsext] duplicate RRs and resulting RRSIG Marco Davids (SIDN)
- Re: [dnsext] duplicate RRs and resulting RRSIG Tony Finch
- Re: [dnsext] duplicate RRs and resulting RRSIG Tony Finch