Re: [dnssd] Working group last call for draft-ietf-dnssd-push

Tom Pusateri <pusateri@bangj.com> Mon, 29 October 2018 20:45 UTC

Return-Path: <pusateri@bangj.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 F0B65131069 for <dnssd@ietfa.amsl.com>; Mon, 29 Oct 2018 13:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7hchmzh2Muh for <dnssd@ietfa.amsl.com>; Mon, 29 Oct 2018 13:45:21 -0700 (PDT)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18585131025 for <dnssd@ietf.org>; Mon, 29 Oct 2018 13:45:21 -0700 (PDT)
Received: from butte.mountain2sea.com (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 4A57121331; Mon, 29 Oct 2018 16:45:20 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <CAPt1N1m1d5Vj1ueC17ksfP7j9+23s0ATtxUwrTnCwmjqEQgtUQ@mail.gmail.com>
Date: Mon, 29 Oct 2018 16:45:19 -0400
Cc: "Jan Komissar (jkomissa)" <jkomissa@cisco.com>, Stuart Cheshire <cheshire@apple.com>, Tim Wicinski <tjw.ietf@gmail.com>, dnssd <dnssd@ietf.org>, David Schinazi <dschinazi@apple.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F8E849EC-2B09-481E-B01E-0805D7B5E11E@bangj.com>
References: <9EDAA7B4-BB78-4CCC-BE0E-A47EF3E0A4A6@apple.com> <DD18BDD4-FFDF-43BC-97E1-8BB846F15702@bangj.com> <C4802C62-E94C-48AE-867F-9A4743A4AEA2@cisco.com> <CAPt1N1m1d5Vj1ueC17ksfP7j9+23s0ATtxUwrTnCwmjqEQgtUQ@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/DlzHgSMVTsA0v1e6TtGVKzHsXGM>
Subject: Re: [dnssd] Working group last call for draft-ietf-dnssd-push
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: Mon, 29 Oct 2018 20:45:24 -0000

Continuing on… Comments inline.

> On Oct 26, 2018, at 5:28 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
> Section 6.1 says:
> 
>    The client begins by opening a DSO Session to its normal configured
>    DNS recursive resolver and requesting a Push Notification
>    subscription.  If this is successful, then the recursive resolver
>    will make appropriate Push Notification subscriptions on the client's
>    behalf, and the client will receive appropriate results.  If the
>    recursive resolver does not support Push Notification subscriptions,
>    then it will return an error code, and the client should proceed to
>    discover the appropriate server for direct communication.  The client
>    MUST also determine which TCP port on the server is listening for
>    connections, which need not be (and often is not) the typical TCP
>    port 53 used for conventional DNS, or TCP port 853 used for DNS over 
> 
>    TLS [RFC7858].
> 
> This is inconsistent with the earlier assertion that the server we are talking to is an authoritative server.   How do we know what zone, if any, the default resolver is authoritative for?   What if it can support some push notifications we want, but for others we need to talk to the authoritative server?   What about TLS?
> 
> I think this text was added based on a comment I made a while back; I think that the behavior defined here may be okay, but there should be some additional text:
> 
>    The client begins by opening a DSO Session to its normal configured
>    DNS recursive resolver and requesting a Push Notification
>    subscription.  This connection is made to the default DNS-over-TLS
> 
>    port.   If this connection is successful, then the recursive resolver
>    will make appropriate Push Notification subscriptions on the client's
>    behalf, and the client will receive appropriate results. 
> 
> 
>    In many contexts, the local recursive resolver will be able to handle
>    push notifications for all zones that the client may need to follow.
>    In other cases, the client may require Push Notifications from more
>    than one zone, and those zones may be served by different servers.
>    It is assumed here, therefore, that the client may need to maintain
>    connections to more than one DNS Push server..
> 
>    In some cases,
>    the recursive resolver may not be able to get answers for a particular
>    zone.   In this case, rather than returning SERVFAIL, the resolver
>    returns NOTAUTH.   This signals the client that queries for this zone
>    can't be handled by the local caching resolver.   For that zone, the
>    client SHOULD contact the zone's DNS Push server itself, even if
>    all other DNS Push queries can be handled by the local resolver.
>    This may be necessary in cases where the client is connected to a VPN,
>    for example, or where the client has a pre-established trust relationship
>    with the owner of the zone that allows the client, but not the local
>    resolver, to successfully get answers for queries in that zone.
> 
>    If the
>    recursive resolver does not support Push Notification subscriptions,
>    then it will return an error code, DSONOTIMPL.   This occurs when the
> 
>    local resolver follows the procedure below and does not find an SRV
>    record indicating support for DNS Push Notifications.
> 
>    In case of either failure, the client should proceed to
>    discover the appropriate server for direct communication.  The client
> 
>    MUST also determine which TCP port on the server is listening for
>    connections, which need not be (and often is not) the typical TCP
>    port 53 used for conventional DNS, or TCP port 853 used for DNS over 
> 
>    TLS [RFC7858].

Looks good. Adopted.

> 
> Later in 6.1:
> 
>    3.  If the requested SOA record does not exist, the client will get
>        back a NOERROR/NODATA response or an NXDOMAIN/Name Error
>        response.  In either case, the local resolver SHOULD include the
>        SOA record for the zone of the requested name in the Authority
>        Section.
> 
> 
> That SHOULD is updating RFC1035, I think, although I realize that there's text later claiming it doesn't.   How about "would normally"?   Given that we specify how clients handle the exceptional case, there's no reason to get fussy about this here.   BTW, we really ought to have a document that describes this stuff, so that we can reference it.   It's a fairly common operation.

changed to “would normally”.

> 
> At the bottom of Page 16 (the end of section 6.2.1) it might be good to add some text acknowledging the recent deprecation of ANY queries, and explicitly saying why they are not deprecated here.   This avoids the risk of DNSOP experts tripping on this, although they will probably see the utility.

This is the only thing I didn’t change yet. Looking at https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-07 doesn’t exactly say it’s deprecated and our wording seems consistent with the options given. I don’t understand how this could trip up DNSOP experts.

> The table in 6.2.2 is introduced by saying "Supported RCODEs are as follows:" but then lists NXDOMAIN, for the purpose of explicitly repeating that it is not supported.   Subsequent text also refers to the table as if all the RCODEs are permitted.   This needs to be fixed.   I would take NXDOMAIN out of the table and just be really explicit about how it's not allowed.   6.5.2 has the same issue, with the same cure.

Fixed.

> 
> Also in 6.2.2:
> 
> For RCODE = 2 (SERVFAIL) the delay should be chosen according to the level of server overload and the anticipated duration of that overload. By default, a value of one minute is RECOMMENDED. If a more serious server failure occurs, the delay may be longer in accordance with the specific problem encountered.
> 
> In this case ideally there is more than one server, and the client can try the next one in the list, rather than repeatedly connecting to the same overloaded server.   Or are we assuming the client will look the server up again, and that round-robining will take care of this?

Clarified.

> 
> Also in 6.2.2:
> 
>       This is a misconfiguration, since this server is listed in a
>       "_dns-push-tls._tcp.<zone>" SRV record, but the server itself is
>       not currently configured to support DNS Push Notifications for
>       that zone.  Since it is possible that the misconfiguration may be
>       repaired at any time, the retry delay should not be set too high.
>       By default, a value of 5 minutes is RECOMMENDED.
> 
> 
> Probably ought to say this:
> 
>       If the server being queried is not the local resolver, rhis is a
>       misconfiguration, since this server is listed in a
>       "_dns-push-tls._tcp.<zone>" SRV record, but the server itself is
>       not currently configured to support DNS Push Notifications for
>       that zone.  Since it is possible that the misconfiguration may be
>       repaired at any time, the retry delay should not be set too high.
>       By default, a value of 5 minutes is RECOMMENDED.
> 

Adopted.

> 
> At the end of 6.3.1:
> 
>    The TTL of an added record is stored by the client and decremented as
>    time passes, with the caveat that for as long as a relevant
>    subscription is active, the TTL does not decrement below 1 second.
>    For as long as a relevant subscription remains active, the client
>    SHOULD assume that when a record goes away the server will notify it
>    of that fact.  Consequently, a client does not have to poll to verify
>    that the record is still there.  Once a subscription is cancelled
>    (individually, or as a result of the DSO session being closed) record
>    aging resumes and records are removed from the local cache when their 
> 
>    TTL reaches zero.
> 
> There's a slight problem with this: if the caching resolver is doing these queries on behalf of a client, then it shouldn't be decrementing the TTL.   Also, if we haven't received an update from the server saying that the TTL has a new value, then the TTL doesn't have a new value—it's still whatever the server sent last time.   So it would actually be correct to never decrement the TTL while a subscription is active.   So I would suggest:
> 
>    The TTL of an added record is stored by the client.   While the subscription
>    is active, the TTL is not decremented, because a change to the TTL would
>    produce a new update.
>    For as long as a relevant subscription remains active, the client
>    SHOULD assume that when a record goes away the server will notify it
>    of that fact.  Consequently, a client does not have to poll to verify
>    that the record is still there.  Once a subscription is cancelled
>    (individually, or as a result of the DSO session being closed) record
>    aging for records covered by the subscription resumes and records are
> 
>    removed from the local cache when their 
>    TTL reaches zero.

Sounds good.

> 
> Section 7.4 talks about TLS session resumption and that subscriptions have to be reinstantiated, but implies without stating explicitly that closing a TLS session closes the DSO session.   It might be worth saying that explicitly.   Something like:
> 
>    TLS Session Resumption is permissible on DNS Push Notification
>    servers.  The server may keep TLS state with Session IDs [RFC5246
> ] or
>    operate in stateless mode by sending a Session Ticket [
> RFC5077
> ] to
>    the client for it to store.  However, closing the TLS connection
> 
>    terminates the  the DSO session.  When the TLS session is
>    resumed, the DNS Push Notification server will not have any
>    subscription state and will proceed as with any other new DSO
>    session.  Use of TLS Session Resumption allows a new TLS connection
>    to be set up more quickly, but the client will still have to recreate
>    any desired subscriptions.
> 

Done.

> 
> In section 8, you probably ought to use two tables rather than one.   Also, I don't think you've given enough information for the service name registration.


Split the table and added a “none" port for clarity.

Thanks again!

Tom