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

[Ted Lemon <[e-mail]>]

Awesome, thanks! :)

I think it's fine if we just wait to see what DNSOP says about ANY.

On Mon, Oct 29, 2018 at 4:45 PM Tom Pusateri <[e-mail]> wrote:

> Continuing on… Comments inline.
>
> > On Oct 26, 2018, at 5:28 PM, Ted Lemon <[e-mail]> 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
>
>