Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
Ondřej Surý <ondrej.sury@nic.cz> Wed, 04 March 2009 20:32 UTC
Return-Path: <ondrej.sury@nic.cz>
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 730AF28C490 for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 12:32:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.42
X-Spam-Level:
X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=0.656, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3]
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 OMkPQGp+bAW5 for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 12:32:34 -0800 (PST)
Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id D8AB528C48F for <ietf@ietf.org>; Wed, 4 Mar 2009 12:32:33 -0800 (PST)
Received: by fxm24 with SMTP id 24so3070871fxm.37 for <ietf@ietf.org>; Wed, 04 Mar 2009 12:33:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.117.194 with SMTP id s2mr244577faq.83.1236198780746; Wed, 04 Mar 2009 12:33:00 -0800 (PST)
In-Reply-To: <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> <20090304200424.GB25180@vacation.karoshi.com.>
Date: Wed, 04 Mar 2009 21:33:00 +0100
Message-ID: <e90946380903041233l2685f576h66261f7308de6358@mail.gmail.com>
Subject: Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
From: Ondřej Surý <ondrej.sury@nic.cz>
To: bmanning@vacation.karoshi.com
Content-Type: multipart/alternative; boundary="001636c5b47e32bc0b046450f515"
X-Mailman-Approved-At: Thu, 05 Mar 2009 09:28:08 -0800
Cc: Paul Vixie <vixie@isc.org>, Chris Thompson <cet1@cam.ac.uk>, ietf@ietf.org, namedroppers@ops.ietf.org
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:32:35 -0000
On Wed, Mar 4, 2009 at 9:04 PM, <bmanning@vacation.karoshi.com> wrote: > we now return you to your rant. Sorry, if I sounded too harsh. my error here - Paul said DNS does no ordering... he did not specify > ordering of what. Order of RRs in zone file is not relevant for the order "on the wire". DNS (as in DNS protocol) does no ordering. Ondrej. > --bill > > > On Wed, Mar 04, 2009 at 07:54:37PM +0000, Chris Thompson wrote: > > On Mar 4 2009, OndE ej 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 > > > -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz <sip%3Aondrej.sury@nic.cz> tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 -----------------------------------------
- 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