Internet DRAFT - draft-tlmd-push-dnssd-additional
draft-tlmd-push-dnssd-additional
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]