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

Tom Pusateri <> Thu, 11 July 2019 21:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43E2E120112; Thu, 11 Jul 2019 14:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HpwI8zS2pFZI; Thu, 11 Jul 2019 14:46:44 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7DA801200F8; Thu, 11 Jul 2019 14:46:44 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 62625347B2; Thu, 11 Jul 2019 17:46:43 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\))
From: Tom Pusateri <>
In-Reply-To: <>
Date: Thu, 11 Jul 2019 17:46:42 -0400
Cc: Stuart Cheshire <>, Eric Rescorla <>, DNSSD <>,, David Schinazi <>, Robert Sparks <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Ted Lemon <>
X-Mailer: Apple Mail (2.3564)
Archived-At: <>
Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Jul 2019 21:46:46 -0000

> On Jul 11, 2019, at 2:20 PM, Tom Pusateri <> wrote:
> But I think it would be helpful to outline the actual errors that could occur on either end and verify this works in every case. Sending as much information to the other side as possible is helpful for determining bugs. TCP RST signaling doesn’t convey much information.
> Tom

Here are all the places a TCP RST was suggested in -20. These are all likely BUGS.

1. CLIENT receives SUBSCRIBE from server
2. SERVER receives duplicate SUBSCRIBE
3. CLIENT receives PUSH with no change notifications
4. CLIENT receives PUSH notification with ‘collective remove’ TTL and non-zero RDLEN
5. CLIENT receives PUSH notification with DNS message length larger than 16k

In cases 1, 3, 4, 5, and 6, the CLIENT will likely mark the SERVER as buggy, close the connection and not try to reconnect for a period of time or use another SERVER if available. A RETRY DELAY isn’t applicable and the CLIENT can close the connection either with a TCP RST or a TLS close_notify. The consensus seems to be to send a TCP RST in this case.

In case 2, the SERVER should send a RETRY DELAY TLV and then send a TLS close_notify or it could wait for the CLIENT to close_notify or RST but the SERVER shouldn’t RST because it wants the CLIENT to get the RETRY DELAY.

There are also cases where the server sends a RETRY DELAY TLV because of a SUBSCRIBE error and the CLIENT is supposed to close the connection. However, if the CLIENT does not close the connection, the SERVER may choose to close it in which case it should close with TLS close_notify to make sure the RETRY DELAY is received.

I think it would be better for the CLIENT to try to send a TLS close_notify after receiving a RETRY DELAY so it can resume later especially in the cases when a SUBSCRIBE fails.