Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"

Warren Kumari <warren@kumari.net> Wed, 06 July 2016 18:13 UTC

Return-Path: <warren@kumari.net>
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 3C56B12B019 for <dnsop@ietfa.amsl.com>; Wed, 6 Jul 2016 11:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 J8yL2S-h29Hs for <dnsop@ietfa.amsl.com>; Wed, 6 Jul 2016 11:13:07 -0700 (PDT)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D9512B04D for <dnsop@ietf.org>; Wed, 6 Jul 2016 11:13:06 -0700 (PDT)
Received: by mail-lf0-x235.google.com with SMTP id h129so160078840lfh.1 for <dnsop@ietf.org>; Wed, 06 Jul 2016 11:13:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UPuSk6Eng52m44nFjpmw+iE5fx39+AI28OmCcdTfhNs=; b=txqzt85GL+++f02J3URfljzkTv8qtTPPO8euUsZn94Gd9ite+eeTk27cj2viqGreBv HNAwVzI+3fNDns4rz9N6nZAvOnjYdR80W7S0q1lV8MAivKm/KaAdHlTlFJlN+7DBF4lN +eaWThP001URluDiSGXFOO8+KXiywje07BUfZfST3MlsC1FAYyaMd7ZIh2BdLaa5Kmr4 uX74xREeTd4JQ4aBByIz/Jgw4KAh1K42j1ry+fKrY1qCBCxkTJU29S8YCN0V1qby3R4Y d30DjBFzz5+91l4NE1H/9e62sr58MWLLf2AQn1THtF6DwUx3dcyw6VGAIwNKKKCX9l5P 7i+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UPuSk6Eng52m44nFjpmw+iE5fx39+AI28OmCcdTfhNs=; b=P5b8d25TQRgua2MXSs2+NtorfA7KaLMqgs1qOZiJKEuHLYUPQurcbYp7xU+6kNpotT ul5U7gYbYzH+RukrptsdJa+SPobeXNjnjiY/lg7VQK2rg99bek534W0F+t2lkgFGOXE7 XHWrQhqCBVhnC4jnEywerfzhm9OEQMhc0YJ5hH+Q1OYkh5L2HleqXzgalxj2i2EJ8x0T fxy8it1w+6BgfC/fs6VU0HWp7UxseZVfpf3w7nL/vBxaEiGbDn/0uzM9PUQ041EEKKaz oNyKPAtYZu5sijRG0Y02J5JSHWBAODWQP7Dpg61T+DyUzfV3xYCzeLoHbN5zotsmjkX8 kn7g==
X-Gm-Message-State: ALyK8tKwx62sFu358dN33KoKkxM8jqPCclOiGwkXLfwMzEd54Ef4pDgqE1Na6eHHymYTj2u38NO7vm3rGX5HJeD0
X-Received: by 10.25.143.132 with SMTP id r126mr5084376lfd.160.1467828785007; Wed, 06 Jul 2016 11:13:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.114.187.234 with HTTP; Wed, 6 Jul 2016 11:12:34 -0700 (PDT)
In-Reply-To: <3FEEE970-032F-498A-BACC-D232F79C3159@vpnc.org>
References: <20160701075116.24678.59997.idtracker@ietfa.amsl.com> <20160706.180940.1170484542745240536.fujiwara@jprs.co.jp> <435414e8-2b20-b9d0-7707-14016fae1163@bellis.me.uk> <3FEEE970-032F-498A-BACC-D232F79C3159@vpnc.org>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 06 Jul 2016 14:12:34 -0400
Message-ID: <CAHw9_i+s1C+rJxqQETQb14Y8MU66pMwKRts-UR8E0hHeqNH2tw@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6F8NbaIwcuXa51M40suy2jxvVwM>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 06 Jul 2016 18:13:09 -0000

On Wed, Jul 6, 2016 at 10:34 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> On 6 Jul 2016, at 3:54, Ray Bellis wrote:
>
>> On 06/07/2016 10:09, fujiwara@jprs.co.jp wrote:
>>>
>>> * My idea
>>>
>>>   I prefer multiple query sections (with some restrictions)
>>>   and merged answers.
>>>
>>>   multiple query examples may be
>>>     NAME A + NAME AAAA + MX
>>>     NAME A + NAME AAAA + _443._tcp.NAME TLSA
>>>     NAME A + NAME AAAA + _sip._udp.NAME SRV + _sips._tcp.NAME SRV + ...
>>>
>>>   Many people may dislike QDCOUNT != 1.
>>>   EDNS0 option which contain additional query section may be possible.
>>
>>
>> and there's my idea (draft-bellis-dnsext-multi-qtypes-02) which only
>> permits a single QNAME, but supports additional QTYPEs via an EDNS0
>> option.
>
>
> Of these three solutions to the same problem, I prefer Ray's. It seems less
> work to implement and less likely to trip up naively-implemented DNS stacks.


These solve different use cases.

The multiple query example, and multiple TYPEs are interesting, but
solves a different problem -- for multiple queries/ TYPEs  the
requestor needs to already know *what* other questions it needs to
ask;  in many cases (for example, loading resources on a web page,
resolving SRV targets, etc) the requestor doesn't know this until it
has started doing work, and only then can it discover what else it
needs.

For example, when I load https://www.paypal.com the page will cause me
to load resources from t.paypal.com, b.stats.paypal.com, c.paypal.com
and slc.stats.paypal.com.

www.yahoo.com needs resources from geo.yahoo.com, comet.yahoo.com and
beap-bc.yahoo.com.
Without resolving www.yahoo.com and fetching / parsing the HTML I have
no way of knowing what other names I'll need.

Resolving  _xmpp-client._tcp.jabber.org gives me back:
_xmpp-client._tcp.jabber.org. 899 IN SRV 30 30 5222 hermes2.jabber.org.

I now need to make a separate query for hermes2.jabber.org -- I
wouldn't know that until the first query completes.

W


>
> --Paul Hoffman
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf