Including Additional Records for DNSSD in DNS Push Subscriptions
draft-tlmd-push-dnssd-additional-00

Internet Engineering Task Force                                 T. Lemon
Internet-Draft                                                Apple Inc.
Intended status: Standards Track                                   D. Ma
Expires: 5 September 2024                                           ZDNS
                                                            4 March 2024

    Including Additional Records for DNSSD in DNS Push Subscriptions
                  draft-tlmd-push-dnssd-additional-00

Abstract

   This document extends DNS Push Notifications by providing ways for
   DNS Push subscribers to track additional data as well as direct
   answers to DNS questions.  This is analogous to the support for
   additional data specified for multicast DNS, for example.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 5 September 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Lemon & Ma              Expires 5 September 2024                [Page 1]
Internet-Draft         DNS Push DNSSD Additionals             March 2024

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  DNS-SD additional records overview  . . . . . . . . . . .   2
     1.2.  Extensions to DNS Push  . . . . . . . . . . . . . . . . .   4
   2.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   4.  Informative References  . . . . . . . . . . . . . . . . . . .   5
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   DNS Push Notifications [RFC8765] defines a mechanism based on DNS
   Stateful Operations [RFC8490] which allows DNS clients to track
   changes that are made to DNS RRsets (Section 4 of [RFC7719])
   associated with specific owner (Section 4 of [RFC7719]) names.

   This allows DNS Service Discovery [RFC6763] clients using DNS
   [RFC1035] to implement long-lived queries to track the arrival of new
   information about DNS services.  However, when a DNS Push update
   indicates that a service is available, the DNS Push client needs to
   do additional DNS lookups or create additional DNS Push queries in
   order to get the information required to actually use the service.

   This introduces additional latency and creates additional work once a
   DNS service has been selected: where with mDNS, we generally get all
   the information we need to actually use a service in the additional
   section of the same mDNS response that included the list of services,
   this is not possible with DNS Push as currently defined.

   This document therefure extends the DNS Push specification to specify
   a way to include additional data specific to DNSSD [RFC6763] in DNS
   Push subscriptions.

1.1.  DNS-SD additional records overview

   DNS Service Discovery generally consists of three steps:

   *  Browsing for services

   *  Choosing a service

   *  Using a service

   Services are discovered within one or more browsing domains, referred
   to as "Legacy Browsing Domains" in [RFC6763].  To discover a service,
   we take the service name and prepend it to each legacy browsing

Lemon & Ma              Expires 5 September 2024                [Page 2]
Internet-Draft         DNS Push DNSSD Additionals             March 2024

   domain, and then ask for a list of PTR records under that name.  So
   for instance, for a printer service, the service name might be
   '_printer._tcp' and we might look for it in the
   'services.example.com' browsing domain.  So we'd subscribe to DNS
   Push on the name '_printer._tcp.service.example.com.

   Because this is a DNS Push query, the list of services needn't be
   static, but at any given point we may decide to actually choose one
   of the services and use it.  This may be because of a user choice, or
   it may be part of some automatic process.  In either case, we might
   choose one specific service.  Or we might want to choose all services
   of a particular subtype.  Or we might just want any service of a
   particular type or subtype.

   Consider the case where we want to choose a specific service.  The
   user might look at the list of services discovered so far, which we
   update in the user interface whenever it's visible, whenever we get
   an add or remove event through the DNS Push subscription.  When the
   user selects a particular printer, to use the previous example, we
   weill then need to figure out everything that is required to connect
   to and actually use that printer service.

   To do this, we will first look for SRV and TXT records under the
   owner name that is contained in the target of the PTR response for
   that printer that we got through the DNS Push subscription.  Every
   PTR record has a target.  In the case of DNS-SD, when we are
   browsing, the target in the PTR record for each browse response is
   the name of a service instance.  Each service instance will have one
   or more PTR and SRV records associated with it.

   Suppose the printer the user chose was an Acme Corp X-1000 printer,
   with the service instance name "Acme X-1000".  We will then need DNS
   responses for "Acme X-1000"._printer._tcp.services.example.com.  Once
   we have at least one PTR and at least one TXT record for that name,
   we can look up the IP address of the host providing the service,
   which will be the target hostname of the SRV record.  This will
   require looking up both A and AAAA records.

   You can see that from a single convenient DNS Push query, we have
   graduated to as many as four additional queries, which can either be
   DNS Push queries or regular DNS queries.  However, notice also that
   we didn't know in advance what name we'd use for either the TXT and
   SRV queries, or for the A and AAAA queries.  So now we have to wait
   for one round trip to start the second set of queries, and another
   round trip to start the third set of queries.

Lemon & Ma              Expires 5 September 2024                [Page 3]
Internet-Draft         DNS Push DNSSD Additionals             March 2024

   Section 12 of [RFC6763] recommends that DNS servers that have support
   for DNS-SD include all of this information in the additional section
   of the DNS response.  However, DNS Push explicitly forbids including
   responses to a DNS Push subscription with different owner names than
   the name provided in the original subscription.

1.2.  Extensions to DNS Push

   When sending a DNS Push request, the DNS Push client MAY include a
   DNS Push Additional Request secondary TLV.  This TLV indicates to the
   DNS PUsh server that it should include relevant additional records of
   a specified type, and specifies a limit as to the number of DNS Push
   responses that can trigger additional data.

   A DNS Push Additional Request TLV consists of:

   *  Count - The number of records matching the original DNS Push query
      that are allowed to trigger additional data subscriptions.

   *  RRtypes - One or more RRtypes.

   A DNS Push subscription requests records of a particular type (or the
   "any" type) and a particular class, that are published with a
   specific owner name.  Each record provided in response to a DNS Push
   subscription can in principle trigger the provision of additional
   data.  In the case of a regular DNS-SD browse, the RRtype being
   subscribed is 'PTR', the class is 'IN', and the owner name is the
   service name constructed as described in Section 4 of [RFC6763].

   Whenever a DNS Push subscription is made that includes the DNS Push
   Additional Request secondary TLV, the DNS Push should include a
   "additional requests" data structure representing additional DNS Push
   subscription sets that can be added automatically based on responses
   to the base subscription.  This can have at most the number of
   entries specified in Count.  Each entry is a subscription set.

   When a DNS Push add response is generated, the DNS Push server first
   checks to see if the RR in the response is of a type that has a
   target (e.g., SRV, PTR, NS).  The DNS Push server then checks to see
   if there is space in this data structure for an additional
   subcription.  If there is, it adds one using the target of the DNS
   Push response.  The new subscription is then given its own
   "additional requests" data structure with the same limit.  Responses
   to this new subscription are handled in the same way, using the
   "additional requests" data structure for the new subscription.

   To be contineud...

Lemon & Ma              Expires 5 September 2024                [Page 4]
Internet-Draft         DNS Push DNSSD Additionals             March 2024

2.  Security Considerations

   TBD.

3.  IANA Considerations

   TBD.

4.  Informative References

5.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/info/rfc6763>.

   [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", RFC 7719, DOI 10.17487/RFC7719, December
              2015, <https://www.rfc-editor.org/info/rfc7719>.

   [RFC8490]  Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
              Lemon, T., and T. Pusateri, "DNS Stateful Operations",
              RFC 8490, DOI 10.17487/RFC8490, March 2019,
              <https://www.rfc-editor.org/info/rfc8490>.

   [RFC8765]  Pusateri, T. and S. Cheshire, "DNS Push Notifications",
              RFC 8765, DOI 10.17487/RFC8765, June 2020,
              <https://www.rfc-editor.org/info/rfc8765>.

Authors' Addresses

   Ted Lemon
   Apple Inc.
   One Apple Park Way
   Cupertino, California 95014
   United States of America
   Email: mellon@fugue.com

Lemon & Ma              Expires 5 September 2024                [Page 5]
Internet-Draft         DNS Push DNSSD Additionals             March 2024

   Di Ma
   ZDNS
   Floor 21, Block B, Greenland Center
   Chaoyang
   Beijing, 100102
   China
   Email: madi@zdns.cn

Lemon & Ma              Expires 5 September 2024                [Page 6]