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
-----------------------------------------