Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

Ondřej Surý <ondrej.sury@nic.cz> Wed, 04 March 2009 18:19 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 A47A73A6B94 for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 10:19:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.29
X-Spam-Level:
X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=0.786, 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 8dKMEtcotm2t for <ietf@core3.amsl.com>; Wed, 4 Mar 2009 10:19:37 -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 0CC043A698D for <ietf@ietf.org>; Wed, 4 Mar 2009 10:19:35 -0800 (PST)
Received: by fxm24 with SMTP id 24so3020606fxm.37 for <ietf@ietf.org>; Wed, 04 Mar 2009 10:20:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.122.15 with SMTP id j15mr164402far.10.1236190802878; Wed, 04 Mar 2009 10:20:02 -0800 (PST)
In-Reply-To: <20090304175748.GB24212@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.>
Date: Wed, 04 Mar 2009 19:20:02 +0100
Message-ID: <e90946380903041020l212909c0sa071be8c833e2e80@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="001636c5a723ae222004644f199a"
X-Mailman-Approved-At: Thu, 05 Mar 2009 09:27:50 -0800
Cc: Paul Vixie <vixie@isc.org>, 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 18:19:38 -0000

On Wed, Mar 4, 2009 at 6:57 PM, <bmanning@vacation.karoshi.com> wrote:

> On Wed, Mar 04, 2009 at 05:11:47PM +0000, Paul Vixie wrote:
> > > > i disagree.  dns-based load balancing is an unfortunate overloading
> and
> > > > should never be done.  RFC 3484 is correct as it is.
> > >
> > > Why is it right for topology-ignorant clients to override
> topology-aware
> > > DNS servers based on wishful thinking about RIR address allocation
> > > policies?
> >
> > neither a client or a server can be guaranteed topology-aware.  dns
> leaves
> > ordering deliberately undefined and encourages applications to use their
> > own best judgement.
> >
>
>         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.

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