IETF Logo Mail Archive

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

Andrew Sullivan <ajs@anvilwalrusden.com> Thu, 20 July 2017 16:51 UTC

Return-Path: <ajs@anvilwalrusden.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 E7C91131A76 for <dnsop@ietfa.amsl.com>; Thu, 20 Jul 2017 09:51:19 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=NvzAYpDY; dkim=pass (1024-bit key) header.d=yitter.info header.b=X7EANCkC
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 dnphsNFqQZjo for <dnsop@ietfa.amsl.com>; Thu, 20 Jul 2017 09:51:18 -0700 (PDT)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6069131714 for <dnsop@ietf.org>; Thu, 20 Jul 2017 09:51:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id F21D0BD996 for <dnsop@ietf.org>; Thu, 20 Jul 2017 16:50:47 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500569447; bh=8iY4DaymIuGK0n0BCN5ATONVeTMbRtYdFUBY+MfO2Qc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=NvzAYpDY+OPkZeoWECS4gkzyKAZOBTJ5iPXfLZ3ldweT9vUSuUeiTcPqfXe1ZFe0P FHwbTGIjSx8LfWpGNLSjBToaG4rmw3C6yB1pb1cDPYhP6CsUrxlhKMst24wdDwMWNF ZkqBoXvMAu/Mt8ySV3kUQKQxC/CPqpjOYvV3AAhs=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijeXt_VcxQWw for <dnsop@ietf.org>; Thu, 20 Jul 2017 16:50:46 +0000 (UTC)
Date: Thu, 20 Jul 2017 12:50:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1500569446; bh=8iY4DaymIuGK0n0BCN5ATONVeTMbRtYdFUBY+MfO2Qc=; h=Date:From:To:Subject:References:In-Reply-To:From; b=X7EANCkC34za+aEMiVyYbZs+p1AvivB7cW8PO6yfrApPku+WUmoodKPbCeQpEEDvd PeY7bjhTToMEvjz14zAtAVTSCSVmnMaTxVlUtOwcpPHwBCMxba8XLWq4jBAv0K1d+B Oxdex04nx08LLvznhlBjPeZE73Viss4zbWN4tY1E=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info>
References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bb1oY7w6RpqSb8JiHHJe9MSNjE4>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt
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: Thu, 20 Jul 2017 16:51:20 -0000

On Thu, Jul 20, 2017 at 06:45:25PM +0200, Ondřej Surý wrote:
> Is this useful for DNS at all, or is this targeted at DNS-SD only?

I can think of at least one way it would be useful.  Large
authoritatives often have a clear population of query sources that ask
a lot -- the "top talkers".  It would be excellent if those clients
stood up TCP connections and kept them in place because then (1) the
server could treat their TCP connections as long-lived and (2) the
server could treat new UDP packets from those IPs as suspect.  The
current TCP handling makes this mostly suck, and the
session-signalling approach makes it suck less.

But it's certainly another step along the way to DNSbis by accident.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

v2.23.0 | Report a Bug | By Email