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