IETF 114: Extensions for Scalable DNS Service Discovery WG

Thursday 2022-07-28 17:30 EDT (21:30 UTC)

AD: Éric Vyncke
Chairs: David Schinazi, Chris Box
Note Takers: Stuart Cheshire, David Black
Jabber Scribe: David Schinazi

Welcome from chairs

Including NOTE WELL

DNS Directorate, Éric Vyncke

Soon-to-be-formed, deal with DNS aspects of drafts (WG and individual)
across the IETF. Find DNS issues long before IETF Last Call.

Enable WG chairs to request DNS directorate early review. Eric is
looking for volunteers to be reviewers for the DNS directorate.

WG Document updates

Service Registration Protocol for DNS-Based Service Discovery

draft-ietf-dnssd-srp-14

Ted presented a summary of document changes.

Has been in WGLC for about a year, 2nd WGLC coming soon, then draft will
be sent to IESG.

An EDNS0 option to negotiate Leases on DNS Updates

draft-ietf-dnssd-update-lease-02

Ted presented a summary of document changes. WGLC coming soon at same
time as SRP WGLC.

Ted explained subtle distinction between Refresh and Update messages -
message itself doesn't indicate which it is, so server has to infer
Refresh from other info (otherwise, message handled as an Update).

Advertising Proxy for DNS-SD Service Registration Protocol

draft-ietf-dnssd-advertising-proxy-01

Ted presented a summary of document changes. This draft is not close to
WGLC.

This draft is primarily about Advertising proxies that are also SRP
servers.

Volunteers to review draft:
Jonathan Hui
Joey Deng

Éric Vyncke suggests bundling the three documents to be reviewed
together by the IESG (except of course if the WG decides not to wait).

Individual Draft updates

Automatic Replication of DNS-SD Service Registration Protocol Zones

draft-lemon-srp-replication-02

Two implementations (Apple and Google), working on getting them to
interoperate.

Ted would like to see WG adopt this draft. Adoption call for this draft
expected to start after WGLC completes for two drafts above (so as not
to distract from completing WGLC and progressing those documents in a
timely fashion).

Multicast DNS conflict resolution using the Time Since Received (TSR) RR

draft-tllq-tsr-02

First-come-first served is wrong for proxies, as replication updates
cause problems because old data is "first" and updates are not
synchronized. (For classical Multicast DNS, the oldest data has
precedence and “wins” when there is a name conflict. For these proxies,
the newest data should win when it is inconsistent with old stale data.)

WG Discussion

Discussion of non-local scope of unicast DNSSD - Ted presents slides.

Stuart Cheshire: The “dig” command shown on Ted’s slides is there to
illustrate the underpinnings of how your iPhone finds the ietf114
printer (even though your iPhone is not on the same link as the ietf114
printer and wouldn’t find it using link-local Multicast DNS).

Stuart: Problem scenario is that constantly using multicast to ask home
network for printers results in all the light switches repeatedly saying
"Nope, I'm still a light switch". It would be better to just ask the
coordinating home pod, particularly as multicast does not work all that
well on larger WiFi networks.

Discovery Proxy provides same answers that mDNS would have provided but
in response to a unicast. Need to enable both clients and servers to
discover the proxy in order to avoid multicast in both cases.

NVM Express over Fabrics (NVMe-oF) (successor to iSCSI; not an IETF
protocol) is another use case that is currently using Multicast DNS, and
could benefit from these new protocol developments to move more traffic
to unicast.