IETF Logo Mail Archive

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

Mark Andrews <marka@isc.org> Fri, 15 June 2018 22:40 UTC

Return-Path: <marka@isc.org>
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 D32EA130DF1 for <dnsop@ietfa.amsl.com>; Fri, 15 Jun 2018 15:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 wZpgT5APcsiv for <dnsop@ietfa.amsl.com>; Fri, 15 Jun 2018 15:40:19 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B3BC12D949 for <dnsop@ietf.org>; Fri, 15 Jun 2018 15:40:19 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 215AC3AB003; Fri, 15 Jun 2018 22:40:19 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 072A516007C; Fri, 15 Jun 2018 22:40:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C754816007D; Fri, 15 Jun 2018 22:40:18 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XJY7KP98c0Co; Fri, 15 Jun 2018 22:40:18 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 4F7BD16007C; Fri, 15 Jun 2018 22:40:18 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-4CFCE1E0-68A5-4624-9554-998172783762"
Mime-Version: 1.0 (1.0)
From: Mark Andrews <marka@isc.org>
X-Mailer: iPhone Mail (15F79)
In-Reply-To: <CAKC-DJimMOtNCSE95kRs6Dy3dC_mxB=8O2WVA7badp8GK2ci-Q@mail.gmail.com>
Date: Sat, 16 Jun 2018 08:40:14 +1000
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <F658CFAA-8DB4-4CBB-85FF-9B5E93E4494E@isc.org>
References: <CAKC-DJimMOtNCSE95kRs6Dy3dC_mxB=8O2WVA7badp8GK2ci-Q@mail.gmail.com>
To: Erik Nygren <erik+ietf@nygren.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4Wn6Mbtx9tbR8e8zuOrFxpBMqAI>
Subject: Re: [DNSOP] BCP on rrset ordering for round-robin? Also head's up on bind 9.12 bug (sorting rrsets by default)
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: Fri, 15 Jun 2018 22:40:22 -0000

What we should be asking is why a service that needs multiple machines isn’t using SRV. It has randomisation between servers explicitly defined along with proportional load balancing. 

It also addresses CNAME at the apex which quite frankly is only used to find the name of the HTTP server for the zone which SRV  is quite capable of doing.

-- 
Mark Andrews

> On 16 Jun 2018, at 01:45, Erik Nygren <erik+ietf@nygren.org> wrote:
> 
> A number of folks have been bitten by a bug in bind 9..12 where it silently changes the default sorting of rrsets to always be sorted (even if the authoritative response wasn't sorted).  This causes problems for services assuming at least some degree of round-robin behavior by clients as now many clients would sent all traffic to only the lowest IP.  Bug details:  https://gitlab.isc.org/isc-projects/bind9/issues/336   If you are upgrading to or have upgraded to bind 9.12 you likely want to take a fix or override in config.
> 
> 
> This raises the question of whether there would be value in a more modern BCP covering round-robin expectations for recursive resolvers?  I suspect many (most?) service operators take at least some degree of DNS round-robin behavior by recursive resolvers as a default.
> 
> I suspect starting assumptions are roughly in the range of:
> 
> * Recursive (and stub?) resolvers (SHOULD/MUST?) do some form of round-robin in RRset responses.
> 
> * There are a variety of ways to implement round-robin (randomize, permute, etc).
> 
> * Server operators need to be aware that round-robin may be a part of a load balancing scheme (especially if capacity is far greater than average demand) but should not be relied on exclusively.  (Perhaps with examples of why...)
> 
> Am I missing something in-terms of an existing BCP to this effect?  There's RFC 1794, but I couldn't find much else (but given the sheer number of DNS RFCs it's very likely I missed one).
> 
> Best, Erik
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

v2.23.0 | Report a Bug | By Email