Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
bmanning@vacation.karoshi.com Wed, 04 March 2009 20:04 UTC
Return-Path: <bmanning@karoshi.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1BB28C0CF for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 12:04:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.33
X-Spam-Level:
X-Spam-Status: No, score=-5.33 tagged_above=-999 required=5 tests=[AWL=1.269, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 Wq29bJPJrei4 for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 12:04:36 -0800 (PST)
Received: from vacation.karoshi.com (vacation.karoshi.com [198.32.6.68]) by core3.amsl.com (Postfix) with ESMTP id 3A40B28C170 for <ietf@ietf.org>; Wed, 4 Mar 2009 12:04:06 -0800 (PST)
Received: from karoshi.com (localhost.localdomain [127.0.0.1]) by vacation.karoshi.com (8.12.8/8.12.8) with ESMTP id n24K4Pff025275; Wed, 4 Mar 2009 20:04:25 GMT
Received: (from bmanning@localhost) by karoshi.com (8.12.8/8.12.8/Submit) id n24K4Olk025274; Wed, 4 Mar 2009 20:04:24 GMT
Date: Wed, 04 Mar 2009 20:04:24 +0000
From: bmanning@vacation.karoshi.com
To: Chris Thompson <cet1@cam.ac.uk>
Subject: Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
Message-ID: <20090304200424.GB25180@vacation.karoshi.com.>
References: <alpine.LSU.2.00.0903041400220.8701@hermes-2.csi.cam.ac.uk> <20563.1236179832@nsa.vix.com> <alpine.LSU.2.00.0903041531250.8701@hermes-2.csi.cam.ac.uk> <25914.1236186707@nsa.vix.com> <20090304175748.GB24212@vacation.karoshi.com.> <e90946380903041020l212909c0sa071be8c833e2e80@mail.gmail.com> <Prayer.1.3.1.0903041954370.14031@hermes-2.csi.cam.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Prayer.1.3.1.0903041954370.14031@hermes-2.csi.cam.ac.uk>
User-Agent: Mutt/1.4.1i
X-Mailman-Approved-At: Thu, 05 Mar 2009 09:26:31 -0800
Cc: ietf@ietf.org, Paul Vixie <vixie@isc.org>, bmanning@vacation.karoshi.com, namedroppers@ops.ietf.org, Ondřej Surý <ondrej.sury@nic.cz>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2009 20:04:37 -0000
my error here - Paul said DNS does no ordering... he did not specify ordering of what. we now return you to your rant. --bill On Wed, Mar 04, 2009 at 07:54:37PM +0000, Chris Thompson wrote: > On Mar 4 2009, OndEej SurC= wrote: > > >On Wed, Mar 4, 2009 at 6:57 PM, <bmanning@vacation.karoshi.com> wrote: > [...] > >> DNSSEC does reorder RRSets within a zone. Which is a new feature. > > > >When we started talking about order of RRSets? This is purely discussion > >about order of RRs in RRSet. Order of RRSets in zone is irrelevant before > >DNSSEC and also after DNSSEC. Nothing depends on order of RRSets > >at least in my best knowledge. > > I took Bill to mean "DNSSEC does reorder RRs within an RRset" anyway, as > I don't know in what other sense DNSSEC is relevant at all. > > But the canonical ordering of RRs within an RRset for signing purposes > says nothing about the presentation order in the answers to DNS queries. > And in fact a certain well-known nameserver implementation not unassociated > with Paul still supports all the rrset-order and sortlist controls, which > work for secured zones as well as unsecured ones. > > -- > Chris Thompson > Email: cet1@cam.ac.uk >
- RFC 3484 section 6 rule 9 causing more operationa… Tony Finch
- Re: RFC 3484 section 6 rule 9 causing more operat… Andrew Sullivan
- Re: RFC 3484 section 6 rule 9 causing more operat… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Tony Finch
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Tony Finch
- RE: [dnsext] RFC 3484 section 6 rule 9 causing mo… Christian Huitema
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Florian Weimer
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Nicholas Weaver
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Ondřej Surý
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Paul Vixie
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Mark Andrews
- Re: RFC 3484 section 6 rule 9 causing more operat… Jari Arkko
- Re: RFC 3484 section 6 rule 9 causing more operat… Tim Chown
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… bmanning
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Chris Thompson
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Florian Weimer
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Florian Weimer
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Florian Weimer
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Ondřej Surý
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Ondřej Surý
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Paul Vixie
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Paul Vixie
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Paul Vixie
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Tony Finch
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Paul Vixie
- Re: [dnsext] RFC 3484 section 6 rule 9 causing mo… Paul Vixie
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Paul Vixie
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Danny Mayer
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Ask Bjørn Hansen
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Florian Weimer
- Re: [dnsext] Re: RFC 3484 section 6 rule 9 causin… Danny Mayer
- Re: RFC 3484 section 6 rule 9 causing more operat… Arifumi Matsumoto