Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling

fujiwara@jprs.co.jp Wed, 13 December 2017 09:35 UTC

Return-Path: <fujiwara@jprs.co.jp>
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 37F9C126C26 for <dnsop@ietfa.amsl.com>; Wed, 13 Dec 2017 01:35:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TmidSDXRjiX3 for <dnsop@ietfa.amsl.com>; Wed, 13 Dec 2017 01:35:35 -0800 (PST)
Received: from off-send01.osa.jprs.co.jp (off-send01.osa.jprs.co.jp [IPv6:2001:218:3001:17::10]) (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 EB454120726 for <dnsop@ietf.org>; Wed, 13 Dec 2017 01:35:34 -0800 (PST)
Received: from off-sendsmg01.osa.jprs.co.jp (off-sendsmg01.osa.jprs.co.jp [172.23.8.61]) by off-send01.osa.jprs.co.jp (8.14.4/8.14.4) with ESMTP id vBD9Ykiu020031; Wed, 13 Dec 2017 18:34:46 +0900
Received: from off-sendsmg01.osa.jprs.co.jp (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 7D9EA180064; Wed, 13 Dec 2017 18:34:45 +0900 (JST)
Received: from localhost (off-cpu05.osa.jprs.co.jp [172.23.4.15]) by off-sendsmg01.osa.jprs.co.jp (Postfix) with ESMTP id 64FD9180062; Wed, 13 Dec 2017 18:34:45 +0900 (JST)
Date: Wed, 13 Dec 2017 18:34:45 +0900
Message-Id: <20171213.183445.832770140485799062.fujiwara@jprs.co.jp>
To: bert.hubert@powerdns.com
Cc: bortzmeyer@nic.fr, dnsop@ietf.org, zuopeng@cnnic.cn
From: fujiwara@jprs.co.jp
In-Reply-To: <20171213084342.GA30523@server.ds9a.nl> <201712131731058457451@cnnic.cn>
References: <2017121315404971736813@cnnic.cn> <20171213081823.GA8970@laperouse.bortzmeyer.org> <20171213084342.GA30523@server.ds9a.nl>
X-Mailer: Mew version 6.5 on Emacs 24.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1690-8.1.0.1062-23526.006
X-TM-AS-Result: No--4.126-5.0-31-10
X-imss-scan-details: No--4.126-5.0-31-10
X-TMASE-MatchedRID: ZkuSgFxpyLxCXIGdsOwlUu5i6weAmSDKYawhvkuLgj6qvcIF1TcLYPQL +hgJKJXqLijzT5kwmq2vECmMzxONBgywtQMJ4fTXNNHZMWDTEbffhzT0GN4TqwqijJkZo/CIhXb KIPDU0Z0OXeeeOgXHpsfp86duhKp33SpvKpFNsJHY5KPiokD1BsnlJe2gk8vI+Cckfm+bb6AFT3 a8cOBy92PkGLzI2ZYGdvnJzbdWYwmHTNZBcJlnyJN65fjGjYMQfS0Ip2eEHny+qryzYw2E8BrGY ONctsq1rV0OiiNL0xhEcGY6dokS78RB0bsfrpPInxMyeYT53RmkadwNQ4A1gYO4AeXr6ilGcbrC J9589x+U9PaDjQiEAm2bANz+7eMPUibKYhTT94i91b/J3dYr2m5Cx3VvoXhzzRLU+BmL/4t3/oa PLwjy+HnXg2kr3EZEKOkmtqFJYyK76He9E4ATPVZca9RSYo/b
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/y4jwQz1cbvIPqd1XgySGiLYvEt0>
Subject: Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 13 Dec 2017 09:35:37 -0000

> From: bert hubert <bert.hubert@powerdns.com>
> 3) Serve up multiple copies of the same A record, and weigh like this:
> www IN A 1.2.3.4
> www IN A 1.2.3.4
> www IN A 10.11.12.13
> And hope that record shuffling will deliver the 2:1 ratio

Same RDATA is not allowed by RFC 2181.

| 5. Resource Record Sets
|
|   Each DNS Resource Record (RR) has a label, class, type, and data.  It
|   is meaningless for two records to ever have label, class, type and
|   data all equal - servers should suppress such duplicates if
|   encountered.  It is however possible for most record types to exist
|   with the same label, class and type, but with different data.  Such a
|   group of records is hereby defined to be a Resource Record Set
|   (RRSet).

> 1) Get browsers to honour RFC 2782

  RFC 6763 DNS-Based Service Discovery shows "_http._tcp" service usage.

> From: "zuopeng@cnnic.cn" <zuopeng@cnnic.cn>
> (1) RFC2782 does not solve the problem of using multi-CDN  (multiple CNAME cannot coexist);
>     here we can use multipile weighted CNMAEXs (need to coexist with CNAME) to accomplish this;
>     besides, weighted CNAMEXs can control traffic ratio among several CDN providers;

  You can add many SRV RRs. (merge SRV RRs from multi-CDN).

> (2) RFC2782 requires browser's support;
>     Using this method, a browser has no idea about weighted AX/AAAAXs. 
>     It requires no change of browsers.

  Softwares that support DNS-SD may support _http._tcp.

--
Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>