NOTICE: As of 2023-01-24 this Trac wiki has migrated to the new IETF wiki at ​https://wiki.ietf.org/group/dnssd

Welcome to the DNS Service Discovery WG Wiki

For help on how to edit these Wiki pages, see WikiFormatting

dns-sd implementations to play with - asked for at IETF 93

• ohybridproxy (GPL, static command line configuration, POSIX-ish platform): ​https://github.com/sbyx/ohybridproxy/
• hnetd (GPL, dynamic autoconfiguration of multiple homenet routers): ​http://www.homewrt.org (or ​http://www.openwrt.org if former is broken; install hnet-full, edit /etc/config/network, and you're done)

LLQ Options Discussion at IETF 91

UDP and TCP or TCP only?

1. Standardize existing UDP draft draft-sekar-dns-llq and add TCP support
2. Deprecate UDP and only standardize TCP

Same Packet Format?

1. Use existing DNS packet format with LLQ option but drop setup and possibly refresh
2. Create new protocol for connection oriented LLQ only, not bound by existing DNS packet format

TLS

1. Require TLS for TCP and DTLS for UDP?
2. If we require TLS, do we need to support STARTTLS?

DNSSEC

1. require TSIG and/or SIG0?

Recommendations from the meeting

• Simplify the protocol by just using TCP
• Require TLS but don't support STARTTLS (may need a new default port number)
• DNSSEC is optional
• Using existing packet format would be easier for DNSSEC support (Sullivan only vocal advocate for new format). We could poll the list.

What should dnssd WG standardize?

(from WG meeting discussion, IETF 90, 7/2014; ​http://www.ietf.org/proceedings/90/slides/slides-90-dnssd-5.pdf)

1. Proxying mDNS/DNS

• Proxy between dns-sd over mDNS and dns-sd over unicast DNS
• Need to be able to publish and resolve services
• Potential solution: draft-cheshire-mdnsext-hybrid-01
• Related label issue: draft-sullivan-dnssd-mdns-dns-interop-00

2. Service discovery zone enumeration

• We use the word ‘zone’ here in the absence of anything better – probably unrelated to “DNSzone”
  • "Scope" isn't a good choice, either, because of confusion with multicast scopes
• How do clients (people, devices) and advertisers (services) discover what zones are available?
• A zone could be based on various attributes:
  • Network topology
  • Physical location
  • Organizational group
  • ???
• One attribute can be expressed in FQDN hierarchy
• Challenge: handling/enumerating physical locations, e.g. “this room”, or “this hotel”, or administraLve operaLon, e.g. “IETF”

3. Change notification

• Service Discovery can be an interactive process - for example, a service browsing window
  • New services need to be displayed as they become available
  • Services need to be retracted when no longer available
• Likely will lose some immediacy in responses when extending dns-sd
  • How do proxies fit into the architecture
  • What is ‘stale’ information?
• Should we push ahead with a form of DNS-LLQ here (see above)?