Thursday November 6, 15:30-17:00 local time, Liffey Hall 2
Chairs: David Schinazi, Chris Box, Florian Obser
___
## Welcome {#welcome}
After seven years in this rôle, David Schinazi is stepping down as
co-chair of DNS-SD.
The Working Group thanked David for his service.
Florian Obser joins us as new co-chair starting with this meeting.
Florian has 20 years experience running Authoritative DNS servers.
Currently employed at RIPE NCC, running one of the root name servers.
Works on OpenBSD in his spare time.
Contributed DHCP client, SLAAC client, validating stub resolver.
First IETF meeting was IETF 95 in Buenos Aires, April 2016.
Served on the DNS directorate.
Ted Lemon gave status update on these two documents, currently in the
final stages of AUTH48 processing.
RFC Editor process not as straightforward as it sometimes is, will need
another round of WG review.
Ray Bellis gave status update on this document.
Draft-05 submitted this morning to address feedback from Esko Dijk.
Question from chairs: Is this document ready for Working Group Last
Call?
Esko Dijk asked for clarification about which numerical qtype values are
permitted.
Ray Bellis: Any qtype that is valid in the Question Section of a DNS
Message is valid as a QTx.
Meta types (OPT RR and 128-255) are not permitted.
DNS servers handle unknown rrtypes by returning the relevant data, and
it doesn’t matter if the server doesn’t know how to interpret that data.
Any experienced DNS implementer should be familiar with this.
Petr Špaček (Internet Systems Consortium): I do not see any problems
with the text, but I would like to hear feedback from client-side (stub
resolver) implementers.
Stuart Cheshire (Apple): I have not implemented this, but, as someone
who has implemented a lot of client-side DNS code in the past, I do not
anticipate any problems with this.
Ted Lemon (Apple): We are in no great hurry here. Getting real-world
operational experience will be valuable. I have implemented the server
side, but not the client side. The reason that Multiple QTYPEs has come
up as an issue again, twelve years after the draft was first written, is
that someone implemented code that uses QDCOUNT=2, and we know there are
reasons this is a bad idea, so we need to standardize a better way of
doing this.
Abtin Keshavarzian (Google): Because Thread is a constrained network and
efficiency is important, OpenThread tries SRV+TXT today using QDCOUNT=2,
and if that fails it falls back to sending two separate queries. We
should be able to switch to using multi-qtypes fairly easily.
Stuart Cheshire: Implementation experience would be good, from Abtin and
others. Apple can help with this.
Tommy Jensen (Microsoft): I’m not quite clear from the text (section
3.2.2) if there are two additional QTYPEs and only one of them
mismatches, will the matching additional be included, or none of them?
Ray Bellis: Let’s discuss this further on the mailing list.
Tommy Jensen: Happy to join the IETF 122 Hackathon if endpoints are
available.
Stuart Cheshire: Should we make a definite plan right now to do this at
the IETF 122 Hackathon?
Chris Box (BT): Chairs support this.
Ben Schwartz (Meta): re Tommy's question, plenty of interesting
interactions - an example section would help a lot.
Ray Bellis: We don’t want to make the draft excessively long. To show
all the failure cases and exceptions would be a lot.
Ben Schwartz: A limited number of examples would help.
Puneet Sood (Google): The draft does not talk abot DNS UDP
fragmentation. It should at a minimum reference IP Fragmentation
Avoidance in DNS over UDP - also RFC 8767 “Serving Stale Data to
Improve DNS Resiliency”.
Ray Bellis: Yes, the document could talk about fragmentation, though any
experienced DNS implementer should be familiar with this alredy. I do
not personally think RFC 8767 is a good idea. It causes no end of
problems.
Puneet Sood: In our implementation we see about 0.1% of queries are
sucessfully resolved due to using RFC 8767, so it does have some value.
Petr Špaček: I would also like to see some examples in the document,
including some illustrative failure cases. How about partial failure?
Ray Bellis: Can you contribute text for this?
Ted Lemon (Apple): If the normative text is unclear, adding examples
doesn’t really address that deficiency. Nicely formatted diagrams are a
lot of work.
Ray Bellis: I think the text is already clear to experienced DNS
implementers. We could add examples to make it more clear to others.
Niall O’Reilly (RIPE): Some carefully selected examples would be
helpful.
Stuart Cheshire: Yes, experienced implementers will know what to do, but
maybe we could accomodate newcomers a bit too, to avoid implementation
errors. Will send suggested text.
Lorenzo Colitti: Not everone in this room is an experienced DNS
implementer, so some more explanatory text would be helpful to prevent
avoidable mistakes.
Ted Lemon (Apple): Is all this information that experienced DNS
implementers are expected to know written down anywhere?
Ray Bellis chuckled. (Ted’s comment was a rhetorical statement to make
the point that it is well known these days that the necessary
information DNS implementers need to know is spread across a great many
RFCs, with no overall “road map” document to guide newcomers.)
Draft-05 published just before the submission deadline, representing an
implementation.
Good practical results, some API issues.
New API approach proposed for discussion and implementation (see
slides)
Next steps: Adopt TSR, which is a prerequsite for Advertising Proxy?
Should we document potential API changes? In this document? Somewhere
else?
Stuart Cheshire: It occurs to me that we could suppress redundant
advertising packets by having the advertising proxy check its cache, and
if it sees it has recent records with the same data received from other
proxies, then it can suppress its own unnecessary announcement packets.
This has the advantage that it can happen automatically and requires no
API changes. It also has the benefit that it only suppresses redundant
packets if the two proxies are actually correctly configured on the same
link. If the two proxies are not seeing each other’s announcements, then
they should not suppress announcement packets.
Greg Choules (ISC): Absolute time is not the same everywhere - how do
you handle that?
Ted Lemon: Times in packets are given relative to “now” (time sent at
sender, and time received at receiver, which are effectively the same
for these purposes). If a receiver wants to work in terms of its local
clock, it subtracts the relative time-since-received in the packet from
its absolute local clock value at the time of reception, and that gives
the receiver a value it can use as an absolute time expressed relative
to its own local absolute local clock value (which need not be
wall-clock time at all — it could be “seconds since boot”). There is an
allowance in the document for packet propagation time to cover the
fraction of a second between transmission time and reception time.
Esko Dijk: I agree with Stuart’s suggestion about automatic announcement
suppression. That belongs in the Advertising Proxy document.
David Schinazi (chair): This document could use a new co-author. Please
volunteer!
Stuart Cheshire: We have plenty of Apple people working on this, and
adding a non-Apple co-author would be great. Publishing as Ted’s
co-author is a good learning experience.
Éric Vyncke: What is actually needed from a new co-author?
Ted Lemon: We don’t want a pro forma co-author if very little is left to
be done.
Chairs: We will ask for adoption and also a co-author on the mailing
list.
Multicast DNS makes extensive use of Additional Records. Delivering
multiple related records in a single DNS message improves network
efficiency by making use of name compression of similar names, which is
especially useful on constrained networks like Thread. DNS Push does not
currently have an equivalent capability. This results in multiple
round-trips to get the same information, and cannot benefit from name
compression. However, unilaterally returning Additional Records for all
DNS Push requests risks generate an excessive amount of data when there
are many matches for the original query.
Esko Dijk: In what conditions would this return an excessive amount of
data?
Ted Lemon: For example, a client querying an SRP server on a Thread
mesh, when the SRP server knows about many entities matching the service
type in a DNS-SD PTR request.
Esko Dijk: In the case of many records returned, the server wouldn’t add
the additional data most likely - similar to how it works for mDNS, only
add if there’s space for it and yields a reasonable size.
Ted Lemon: We do want the client to express whether it wants the
additional data (using a DSO “Additional TLV” for that).
Motivation (from slides/presentation): On Thread (which is only
250kbit/sec), frames over 127 bytes suffer fragmentation, which is
ineffience and increases effective packet loss rates. SRP messages can
easily be much larger than 127 bytes. Already done: label compression,
KEY omission except for host name. Typical SRP message size is 400-1200,
sometimes many at same time (e.g. Border Router restart).
Proposal (from slides/presentation): Entirely reversible message
compression, could be transparant to SRP server. 641 -> 244 bytes
example, or 466->116 without KEY/SIG.
Next steps: Adopt in Thread spec, deploy and test. Do IETF draft?
Stuart Cheshire: What is the scope of this? Is this just for Matter
devices using SRP on Thread? For all devices using SRP on Thread? For
all uses of SRP on all link types? For all uses of general DNS update?
For all DNS messages? The encoding seems very specific to Matter SRP
updates on Thread, which is fine, but we should be very clear about
where this is applicable and where it is not.
Abtin Keshavarzian: Applies to all SRP messages (not only Matter, and
not only on Thread), but not general DNS update or other DNS messages.
Éric Vyncke: Did you look at RFC 8724 “SCHC (Static Context Header
Compression)”?
Abtin Keshavarzian: I looked briefly, but this is very specific to the
SRP message format.
Éric Vyncke: SCHC supports very specific rules for specific protocols.
No need to reinvent the wheel here.
Proposal (from slides/presentation): Sometimes a given service instance
supports more than one variant of its protocol, e.g., a custom data
transfer protocol that can run over HTTP/2, and can run better over
HTTP/3. We want the server to be able to communicate to the client that
multiple variants are avilable, so the client can choose the best one it
supports. Proposal is to specify how to use ALPN field in SVCB records
for DNS-SD service instances, in addition to the current
PTR/TXT/SRV/A/AAAA records, to communicate when alternative variants are
available.
Stuart Cheshire (Apple): To be clear for everyone in the room, although
recently in this group we have talked a lot about Matter and Thread,
this SVCB proposal is unrelated to that. We have asked Gautum to write
an initial draft about this and notify the mailing list when that is
ready. We wanted to take this opportunity to let people know about this
work.
Right now the SVCB and HTTPS DNS records are defined in terms of
hostnames, and a considerable part of that 47-page specification
is devoted to disambiguating names when multiple services are running on
the same hostname, by prepending a scheme name or textual port number
before the hostname. In the case of DNS-SD services we already have a
unique DNS name for each service instance (e.g.,
“Instancename._customtransfer._tcp.domain.”) so we might have an
opportunity to do this in a simpler and more efficient way. That would
also offer the benefit that all records describing a given service
instance would be attached to a single DNS name, and could be secured
using a single key, instead of being scattered across different DNS
names. Today, if a host’s hostname changes, only an instance’s SRV
target host needs to be updated. If record(s) describing the service
attributes are scattered across other DNS names derived from the
hostname, then all those records also need to be removed and recreated
when the hostname changes.
Tommy Pauly (Apple): First approach: We can use SVCB as already defined,
which gives us all kinds of things, like ALPN, without requiring any
normative spec changes. Second approach: Maybe use different
identifiers, or replicate ALPN information elsewhere. Please give
feedback on which way makes sense. We will need to coordinate with
DNSOP.
Skipped due to time constraint, as the participants expressed a
preference to cover item 6 (SVCB and HTTPS) rather than item 7 in the
limited time remaining.
Chris Box celebrated David’s service to the working group and
thanked him. Chris and Florian will be the chairs for 122.
Éric Vyncke: Draft-eckert-anima-brskidiscovery, presented in the
anima meeting this week, has a DNSSD component. Would like this
working group to review this.