Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20

Ted Lemon <mellon@fugue.com> Wed, 03 July 2019 15:12 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788201204D1 for <dnssd@ietfa.amsl.com>; Wed, 3 Jul 2019 08:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 B0GkaCfz7aYI for <dnssd@ietfa.amsl.com>; Wed, 3 Jul 2019 08:12:19 -0700 (PDT)
Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 182DA1204AC for <dnssd@ietf.org>; Wed, 3 Jul 2019 08:12:16 -0700 (PDT)
Received: by mail-qt1-x842.google.com with SMTP id i34so1566932qta.6 for <dnssd@ietf.org>; Wed, 03 Jul 2019 08:12:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Lk6/Wzdy4cLroMht7AgIFVLm/NLGbevekn6ilCqoRRU=; b=WNVvu5L2lsxrgjHJ85U+OR3e+eyvQLIg7Jmpxwg/iyNrX9/vK9w7n25hm/9x9theyz 2yPjYFn8fK7wqRehfapzVBU/83uAz8bQrrXrqfRmIBGsA7Asts9WreegreXwpdEhZHzL GpAugPtxjP2Sqi076jPUkg5MNZzO+B+zqIESH+AF+ifFQ7KZ9raSjFM6VYozGdwR+icf Dbze1RAOCbpsnZxbWZswQLEsOPXQYrBk4fP6zWErFMwYA5c0efbzwLqDaUZFLQDg641a zcFRXipR66FFOMoH7gk3b8laIA4Rk+4D/brI6iVcy8bI+lHJ840hEXJ4gtLSKXRBg0rT w/6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Lk6/Wzdy4cLroMht7AgIFVLm/NLGbevekn6ilCqoRRU=; b=d6xmj/kXH1kecYr4wD2BbP63yc0SzEuZrG/ZIKFx66tu1yuse3zjt694IK7vhdQs87 6KSbDFZkX9e1n0CsQoJG1krIAvxXRG+1dpogHuCgxU1++9HJrA4aYkUpUH/NNQOJsC2/ 93Lre6Y6HdidfqnzzdWhjg9CQBQ4t7LVoX8N/2d5Mcz7TWzj2KbH2HrwiRCVIF47Nibg Q5BUH7EksgPk3XtHbCe5sSZscZ2J/Za8rux0cngHGl/ANVdfgsGWKbC0Vyh9zg/15M9x G1ApttH3JFoE7XKjJo4tGjvKBuyH1NX2spU32YYu3hAr6QQSxsql5DqRLI4qSs3i6Ryo 9u6w==
X-Gm-Message-State: APjAAAWufklNOn3nGhSBhsYmzwFgAtNQhBlMjrignL0S2w4bU66OBzwk J2Ugsqga+DesFhHnSXLqfVc1rQ==
X-Google-Smtp-Source: APXvYqwC8xhM70Hfd0I+Lus3jryX0zXisJk4kwLWGac2ONFa3X8TxAOuQylgPelc7JtNz6nk0pzCdA==
X-Received: by 2002:ac8:234a:: with SMTP id b10mr31626756qtb.261.1562166735003; Wed, 03 Jul 2019 08:12:15 -0700 (PDT)
Received: from ?IPv6:2001:470:c1a2:1:a062:1585:ff05:9bdc? ([2001:470:c1a2:1:a062:1585:ff05:9bdc]) by smtp.gmail.com with ESMTPSA id u4sm1036838qkb.16.2019.07.03.08.12.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 08:12:14 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <31B20480-C368-46FE-8D5E-654584358EF2@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5AB41AA7-2B57-4BE3-9B27-0532B5E9133A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 3 Jul 2019 11:12:11 -0400
In-Reply-To: <a1812b4c-d443-fd36-ed51-bf054170efe6@nostrum.com>
Cc: Tom Pusateri <pusateri@bangj.com>, draft-ietf-dnssd-push.all@ietf.org, gen-art@ietf.org, dnssd@ietf.org, IETF <ietf@ietf.org>
To: Robert Sparks <rjsparks@nostrum.com>
References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> <a1812b4c-d443-fd36-ed51-bf054170efe6@nostrum.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/vLNIkAg_oYq0Mw46U02rA0vP5pU>
Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2019 15:12:26 -0000

On Jul 3, 2019, at 10:45 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
> And I think that's a problem.
> 
> What does a NOTIMP mean to the client? Most of the draft says "The server doesn't implement DSO". It doesn't say "doesn't implement DSO for this particular set of bits in this query". Section 6.2.2 says the client should assume a retry delay of 1 hour before talking to the server (the resolver) again.
> 
> Now, other parts of the document imply "for this particular set of bits" - in the overview, near the bottom of page 5, it says to use NOTIMP (actually it says NOTIMPL, maybe those are different things and I'm confused?) if a message is received for a class other than "IN" and the server has only implemented push for "IN". Again, that "assume a retry delay" kicks in.

Robert, first, thanks for doing a really thorough review of this document.  This is much appreciated.   This particular insight is one that I think is really important.   I think your initial take on this is correct: if a resolver receives NOTIMP or DSONI from upstream, what this means is “fail,” not “not implemented,” from the perspective of the resolver.   The resolver knows what the client is asking, and can’t do it.  That’s SERVFAIL, not NOTIMP or DSONI.

I think your subsequent point about terminating connections is also correct: we do not want a billion broken clients hammering on servers.  However, the DSO document actually specifies how to deal with this: the server can tell the client to shut up for a period of time, and this is explicitly recommended for situations like this.   The advantage of failing in cases like this is that it causes the implementation to not work, which then motivates the implementor to fix it.

And thanks for the advice about how to terminate TLS connections—I had missed that nuance.  Are TLS implementations actually able to do this (to reject RST packets)?