DNS-Based Service Discovery

Cheshire, Krochmal

zeroconf mdns slp service discovery multicast network configuration

@misc{cheshire:ietf-2010b,
  author={Stuart Cheshire and Marc Krochmal},
  title={{DNS}-Based Service Discovery},
  series={Standards Track Internet Draft},
  number={draft-cheshire-dnsext-dns-sd-07},
  publisher={{IETF}},
  organization={{Internet Engineering Task Force}},
  year={2010},
  month={October},
  howpublished={\url{http://tools.ietf.org/id/draft-cheshire-dnsext-dns-sd-07.txt}},
}

DNS is ubiquitous, familiar, should/must be capitalized on for wide deployment

Three necessary properties

• Query for services of a given type in a logical domain, get a list in response
• Ability to bind a particular named instance to its interface (IP, port, etc)
• Relatively persistent instance names
  • I.e., keeping the same printer name so people don't have to continually reselecting it

DNS labels limited to 63 octets, full domain names to 255 octets

Some service systems decouple service name from its unique ID

• What happens if two services are given the same name? Will be confusing
• What if device is replaced? User must delete cached resolutions or change unique ID of new device to match
• What if device is moved/no longer appropriate? Unique ID will still exist, be confusing

SRV records are used because they include port numbers...

TXT record is used to store additional data

• E.g., print queue or file server volume
• Hard length limit at 65535; mDNS has limit of about 8900; usually makes sense to be at most a few hundred bytes
• Standard DNS message is 512 bytes
• Arbitrary key/value pairs
• Keys should only be nine characters long
  • Case insensitive, but spaces are important
  • Only need to be unique within namespace of a particular service type
  • Keys may only appear once per record
  • Four possible key results
    • Attribute not present
    • Attribute present, no value
    • Attribute present, empty value
    • Attribute present, non-empty value
  • Values can be arbitrary binary data

Service type broken into two components: _<application>:_<transport>

• <transport> is always either tcp or udp; other protocols should just say udp
• <application> is no more than 15 characters, following host name rules
  • <application> indicator must be chosen carefully
  • <application> can have a subtype
    • Two levels, type and subtype, is the limit
    • May be up to 63 octets

Awkward flagship protocol mechanism helps manage case of multiple protocols doing essentially the same thing

Designed with live service list displays in mind; when choosing services:

• Initial list of services displayed almost immediately
• Continues to update as more matches are discovered
• Stale service listings should be removed as they expire
• Should recognize and adjust to local host changes, e.g., plugging in a new network or pulling out a wireless card