Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses

Matthew Pounsett <matt@conundrum.com> Tue, 19 July 2016 08:14 UTC

Return-Path: <matt@conundrum.com>
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 E3C3712D13E for <dnsop@ietfa.amsl.com>; Tue, 19 Jul 2016 01:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=conundrum-com.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 q7RyAQEvgKz2 for <dnsop@ietfa.amsl.com>; Tue, 19 Jul 2016 01:14:01 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 82FD512DCA9 for <dnsop@ietf.org>; Tue, 19 Jul 2016 01:14:00 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id x25so5336003qtx.2 for <dnsop@ietf.org>; Tue, 19 Jul 2016 01:14:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Wv+BYY/i7jze5DHr1BG/PJJK8b3se80gI6QMjXW3Zas=; b=SH7olrLnYmxHR5cpEZ9B13rtDZewoaKRKl1gCGxzHsUp34OEQdGbMA29LIghF+tE+5 LvUNDh/dJIfLh/QFMXbOuN1bFQ4kbDsacRk2udQN0htCPpHQ7mjT6KWxaKz3CxmM4sXv MMKayYkxXOFlu5i4i5pXwDZdncz9z+6XD45piW75z3be+jBLbuPrzhT163MVMpTgVjF4 HmB4+DpRxucKNt7AhaINpZCZ2i1jbxcU9EfhMmgEx7JFoic+WXDtpqY6Zlu5OvbUONCe 7I6NFdtTU7or4bvAa0Ll6PrJ5nOszKNC0LOvKbJ2W4iYyttPGCxxLS79Jhp5QazhiWgg nnqg==
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=Wv+BYY/i7jze5DHr1BG/PJJK8b3se80gI6QMjXW3Zas=; b=Em6OAJrZpcQJWtTgWf8pzRR9Ouj1XxdBlDcwTNwlrDTPqfYbu+jUHQTCS92xmmolv8 iwobQaQSvqjsYMV6ZK1UDSOi2UW+eD5EvOLLdcHXYs5kt9+/eB0yIRv7i8Av2aMhNmlI p+q7d2uP0YOp4IB4WaMACEBO1OcEZkEZdl6Ewch7PJvmgWe5OTX9hWWm9RzLmSWBawHN 4hB6DwfC6orU0gB9FSA04Rqm+yKHgO/s67zWrEetVzkCc3M8A2ut0G6sX4UJGYgYtLoL vLICZemwFKRINgtQgxontMG7dU3iGUncYDG7/clxQuSMEmpTHbbNso78EDqnJwKgfG30 Dl7w==
X-Gm-Message-State: ALyK8tLfEyi98BVpU56kZ+KCsqH8s0Hf+3Ulw33PuQ0EE8fSSbe9gx6nVEiJgq2BLZgzdcIOxEQHGL25Z4g9Xw==
X-Received: by 10.200.46.216 with SMTP id i24mr58722721qta.79.1468916040127; Tue, 19 Jul 2016 01:14:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.46.194 with HTTP; Tue, 19 Jul 2016 01:13:59 -0700 (PDT)
X-Originating-IP: [2001:67c:370:136:c860:19bd:96d0:d0db]
In-Reply-To: <CAPt1N1noytAh7c-CuUpCasf8MHoG8k7xGawYxaXD+cLw++CmNA@mail.gmail.com>
References: <alpine.LRH.2.20.1607181050180.27489@bofh.nohats.ca> <BC65B5D1-C49B-4038-92CD-FF629AB9A75D@fl1ger.de> <CAKr6gn2WEAAm-o2appid9Nq+6p09ff0468RoyfqTRK4KMycMOw@mail.gmail.com> <0D351FB1-DA75-4859-9194-9AA8A054BF53@fl1ger.de> <CAL9jLabVJTzgCQ=TytEeVymwvwzhL4jkcgWf8zhydbjAzsL3dg@mail.gmail.com> <8034847F-2A8B-4A9A-9F9C-034CB4785C72@fl1ger.de> <CAAiTEH8ZYnYLi3Fcz75Du3ehsjYmY8whQ_EQYaKkF7KqD5LqFA@mail.gmail.com> <CAPt1N1noytAh7c-CuUpCasf8MHoG8k7xGawYxaXD+cLw++CmNA@mail.gmail.com>
From: Matthew Pounsett <matt@conundrum.com>
Date: Tue, 19 Jul 2016 10:13:59 +0200
Message-ID: <CAAiTEH8qewLg-E4cc-yJr5RUFOYqBdOPmHxxjV84bGmy=Nc2bA@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Content-Type: multipart/alternative; boundary="001a1147da50c70b970537f8aa49"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/BLz3y8z41cZsJipiPLhmwBHH28w>
Cc: dnsop <dnsop@ietf.org>, Christopher Morrow <christopher.morrow@gmail.com>, Ralf Weber <dns@fl1ger.de>, George Michaelson <ggm@algebras.org>
Subject: Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses
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: Tue, 19 Jul 2016 08:14:08 -0000

On 19 July 2016 at 09:46, Ted Lemon <mellon@fugue.com> wrote:

> I thought the proposal specifically excluded support for this sort of
> query in any case other than for queries from authoritative servers.
>
> I'm not sure what you mean about "this sort of query".    There wouldn't
be any special query sent to recursives.  The response from recursives
could include the additional records called for by the EXTRA records cached
when the authoritative was queried.  I don't see anything about that being
prohibited in the draft... in fact I see no reason for § 6 if it was
prohibited.  There'd be no reason for recursives to ever receive the EXTRA
records themselves.



> On Jul 19, 2016 09:37, "Matthew Pounsett" <matt@conundrum.com> wrote:
>
>>
>>
>> On 19 July 2016 at 09:19, Ralf Weber <dns@fl1ger.de> wrote:
>>
>>> Moin!
>>>
>>> On 19 Jul 2016, at 9:00, Christopher Morrow wrote:
>>>
>>> > On Jul 19, 2016 8:36 AM, "Ralf Weber" <dns@fl1ger.de> wrote:
>>> >>
>>> >>
>>> >> Except that if you have a decent size and hot Cache with refreshing
>>> >> these records will be in there anyway. IMHO you gained nothing, but I
>>> >> agree with Jim Reid that it would be good to have data on this.
>>> >
>>> > Nothing except some DNS round trips.
>>> > How could that matter though?
>>> As said I don't believe we have additional round trips between the
>>> recursive and the authoritative server in most of the cases. That is
>>> what we need data for though. DNS and applications that use DNS have
>>> unbelievable levels of caching. So while this all might apply to you
>>> if you run your own resolver just for you, it's not the case in big
>>> cache deployments most people use (be it their ISP or some big public
>>> resolver).
>>>
>>> While I tend to agree that the optimization gain between the recursive
>> and authoritative server is probably  minimal, the potential gain between
>> the recursive and the stub is huge.  Other than the fact that the
>> explanation focuses on the authoritative, I don't see any reason this needs
>> to be limited to recursive->authoritative conversations.  Indeed, with the
>> OPT signalling a recursive could obtain the EXTRA records and provide the
>> same optimized answers to stubs.
>>
>>
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>