Multicast DNS

Cheshire, Krochmal

zeroconf mdns slp service discovery multicast network configuration

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

Must work with less configuration as devices get smaller, more portable, ubiquitous

• DNS must operate in absence of infrastructure or during infrastructure failure
• Similar to AppleTalk

IP TTL used to prevent loops

Declares a link local namespace suffixed by ".local."

• Similar to IPv4 169.254/16 and IPv6 FE80::/10
• Queries for such names must go to mDNS groups 224.0.0.251 or FF02::FB
• Similarly for lookups for names ending in 254.169.in-addr.arpa., 8.e.f.ip6.arpa., 9.e.f.ip6.arpa., a.e.f.ip6.arpa., and b.e.f.ip6.arpa.

Shared resources Unique resources

Even more important to use DNSSEC or other security mechanisms in multicast context to ensure valid responses for global name searches

Must manage name conflicts

Up to 255 bytes in labels

Three kinds of behaviors

• One shot queries
  • Same as traditional DNS, generally only listens to first response
  • Does not participate in forwarding queries?
• One shot queries accumulating multiple responses
  • Continues retransmitting query (with exponential backoff) until it has accumulated enough responses
• Continuous ongoing queries
  • Naive constant polling too much of a burden on the network
  • Exponentially backoff queries; may cap interval at 60 minutes
  • Only do this when there is an active consumer of the data on the host
  • Stops if a unique resource is returned, rather than shared resources

Responses go back via multicast so that other hosts may see them

• Clients may request a unicast response
• Should be used when waking or first booting, to prevent flooding the network with many requests
• If responder has not multicast responses recently, it may ignore that request and multicast it back

Known answer suppression in repeat queries

• Records with more than half TTL left are included in query
• Responders that would give an answer included in query do not transmit unless down to half TTL
• These may be chained across multiple packets

Multiple queries may be combined into one query packet

Hosts listen to queries from other hosts and do not duplicate if the same

Hosts only given answers for records they are authoritatively responsible for

Negative responses only sent for unique resources

Shared resource responses should be jittered; unique resource responses do not need to be

Nodes waking up must probe for their unique records

• Any hosts which believe they own them should reply immediately
• Conflicts resolved by lexicographic comparisons determining the winner