Re: [DNSOP] ?==?utf-8?q? BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)

"Petr Spacek" <petr.spacek@nic.cz> Tue, 19 June 2018 06:42 UTC

Return-Path: <petr.spacek@nic.cz>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03CE12E039 for <dnsop@ietfa.amsl.com>; Mon, 18 Jun 2018 23:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npa2sJ9S7Mkc for <dnsop@ietfa.amsl.com>; Mon, 18 Jun 2018 23:42:07 -0700 (PDT)
Received: from kalendar.nic.cz (kalendar.nic.cz [217.31.204.159]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4618130DC1 for <dnsop@ietf.org>; Mon, 18 Jun 2018 23:42:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by kalendar.nic.cz (Postfix) with ESMTP id 9643241E67; Tue, 19 Jun 2018 08:42:05 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
In-Reply-To: <CAHPuVdWGic-odTKYCzmqUBc7tmxsweCFz-_5wOrJLauf73HqBw@mail.gmail.com>
From: "Petr Spacek" <petr.spacek@nic.cz>
X-Forward: 127.0.0.1
Date: Tue, 19 Jun 2018 08:42:05 +0200
Cc: =?utf-8?q?Darcy_Kevin_=28FCA=29?= <kevin.darcy@fcagroup.com>, =?utf-8?q?dnsop=40ietf=2Eorg_WG?= <dnsop@ietf.org>
To: "Shumon Huque" <shuque@gmail.com>
MIME-Version: 1.0
Message-ID: <3bb4-5b28a580-3-7df37800@111341361>
User-Agent: SOGoMail 3.2.10
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PUp9aCaiVu039NsTIXf__CgftsA>
Subject: Re: [DNSOP] =?utf-8?q?=3F=3D=3D=3Futf-8=3Fq=3F__BCP_on_rrset_orderin?= =?utf-8?q?g_for_round-robin=3F_Also_head=27s_up_on_bind_9=2E12_bug_=28sor?= =?utf-8?q?ting_rrsets_by_default=29?=
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2018 06:42:11 -0000

On Tuesday, June 19, 2018 01:21 CEST, Shumon Huque <shuque@gmail.com> wrote: 
 
> On Mon, Jun 18, 2018 at 7:05 PM Darcy Kevin (FCA) <kevin.darcy@fcagroup.com>
> wrote:
> 
> > RFC 6724 specifically says: "Rules 9 and 10 MAY be superseded if the
> > implementation has other
> > means of sorting destination addresses. For example, if the
> > implementation somehow knows which destination addresses will result
> > in the 'best' communications performance."
> >
> > So, technically, if an implementation chooses a method of "the exact order
> > in which I received the address records from my upstream resolver" as a way
> > to produce the "'best' communication performance", given the circumstances,
> > then that is technically not a violation of the standard. The local
> > optimization is to trust the upstream resolver to Do The Right Thing. It's
> > not always a wise choice, but most of the time it's better than sorting
> > based on prefix-length matching (right?)
> >
> > RFC 6724 is, after all, about *default* address selection (that word is
> > even in the title of the RFC). Defaults are made to be superseded -- that's
> > kind of the definition of what a default *is*.
> >
> 
> This whole thread is about "defaults"  though!
> 
> Application deployers attempting to rely (rightly or wrongly) on load
> balancing of addresses presented by name resolution APIs will have
> preferences for a particular default that allows them to achieve that goal.
> 
> (I'm well aware that the spec allows and that OSes provide knobs to tweak
> the address selection algorithm - I've lost track of how many times I've
> edited my gai.conf file to do various kinds of tests!)

Hello dnsop,

I believe that discussion about protocol level/resolver behavior is going to be
purely academic because DoH is going to cache whole messages and that's it.

Do you think that having different behavior on "classic" DNS and DoH is a good idea?

-- 
Petr Špacek  @  CZ.NIC