rfc6762.txt 181 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178117911801181118211831184118511861187118811891190119111921193119411951196119711981199120012011202120312041205120612071208120912101211121212131214121512161217121812191220122112221223122412251226122712281229123012311232123312341235123612371238123912401241124212431244124512461247124812491250125112521253125412551256125712581259126012611262126312641265126612671268126912701271127212731274127512761277127812791280128112821283128412851286128712881289129012911292129312941295129612971298129913001301130213031304130513061307130813091310131113121313131413151316131713181319132013211322132313241325132613271328132913301331133213331334133513361337133813391340134113421343134413451346134713481349135013511352135313541355135613571358135913601361136213631364136513661367136813691370137113721373137413751376137713781379138013811382138313841385138613871388138913901391139213931394139513961397139813991400140114021403140414051406140714081409141014111412141314141415141614171418141914201421142214231424142514261427142814291430143114321433143414351436143714381439144014411442144314441445144614471448144914501451145214531454145514561457145814591460146114621463146414651466146714681469147014711472147314741475147614771478147914801481148214831484148514861487148814891490149114921493149414951496149714981499150015011502150315041505150615071508150915101511151215131514151515161517151815191520152115221523152415251526152715281529153015311532153315341535153615371538153915401541154215431544154515461547154815491550155115521553155415551556155715581559156015611562156315641565156615671568156915701571157215731574157515761577157815791580158115821583158415851586158715881589159015911592159315941595159615971598159916001601160216031604160516061607160816091610161116121613161416151616161716181619162016211622162316241625162616271628162916301631163216331634163516361637163816391640164116421643164416451646164716481649165016511652165316541655165616571658165916601661166216631664166516661667166816691670167116721673167416751676167716781679168016811682168316841685168616871688168916901691169216931694169516961697169816991700170117021703170417051706170717081709171017111712171317141715171617171718171917201721172217231724172517261727172817291730173117321733173417351736173717381739174017411742174317441745174617471748174917501751175217531754175517561757175817591760176117621763176417651766176717681769177017711772177317741775177617771778177917801781178217831784178517861787178817891790179117921793179417951796179717981799180018011802180318041805180618071808180918101811181218131814181518161817181818191820182118221823182418251826182718281829183018311832183318341835183618371838183918401841184218431844184518461847184818491850185118521853185418551856185718581859186018611862186318641865186618671868186918701871187218731874187518761877187818791880188118821883188418851886188718881889189018911892189318941895189618971898189919001901190219031904190519061907190819091910191119121913191419151916191719181919192019211922192319241925192619271928192919301931193219331934193519361937193819391940194119421943194419451946194719481949195019511952195319541955195619571958195919601961196219631964196519661967196819691970197119721973197419751976197719781979198019811982198319841985198619871988198919901991199219931994199519961997199819992000200120022003200420052006200720082009201020112012201320142015201620172018201920202021202220232024202520262027202820292030203120322033203420352036203720382039204020412042204320442045204620472048204920502051205220532054205520562057205820592060206120622063206420652066206720682069207020712072207320742075207620772078207920802081208220832084208520862087208820892090209120922093209420952096209720982099210021012102210321042105210621072108210921102111211221132114211521162117211821192120212121222123212421252126212721282129213021312132213321342135213621372138213921402141214221432144214521462147214821492150215121522153215421552156215721582159216021612162216321642165216621672168216921702171217221732174217521762177217821792180218121822183218421852186218721882189219021912192219321942195219621972198219922002201220222032204220522062207220822092210221122122213221422152216221722182219222022212222222322242225222622272228222922302231223222332234223522362237223822392240224122422243224422452246224722482249225022512252225322542255225622572258225922602261226222632264226522662267226822692270227122722273227422752276227722782279228022812282228322842285228622872288228922902291229222932294229522962297229822992300230123022303230423052306230723082309231023112312231323142315231623172318231923202321232223232324232523262327232823292330233123322333233423352336233723382339234023412342234323442345234623472348234923502351235223532354235523562357235823592360236123622363236423652366236723682369237023712372237323742375237623772378237923802381238223832384238523862387238823892390239123922393239423952396239723982399240024012402240324042405240624072408240924102411241224132414241524162417241824192420242124222423242424252426242724282429243024312432243324342435243624372438243924402441244224432444244524462447244824492450245124522453245424552456245724582459246024612462246324642465246624672468246924702471247224732474247524762477247824792480248124822483248424852486248724882489249024912492249324942495249624972498249925002501250225032504250525062507250825092510251125122513251425152516251725182519252025212522252325242525252625272528252925302531253225332534253525362537253825392540254125422543254425452546254725482549255025512552255325542555255625572558255925602561256225632564256525662567256825692570257125722573257425752576257725782579258025812582258325842585258625872588258925902591259225932594259525962597259825992600260126022603260426052606260726082609261026112612261326142615261626172618261926202621262226232624262526262627262826292630263126322633263426352636263726382639264026412642264326442645264626472648264926502651265226532654265526562657265826592660266126622663266426652666266726682669267026712672267326742675267626772678267926802681268226832684268526862687268826892690269126922693269426952696269726982699270027012702270327042705270627072708270927102711271227132714271527162717271827192720272127222723272427252726272727282729273027312732273327342735273627372738273927402741274227432744274527462747274827492750275127522753275427552756275727582759276027612762276327642765276627672768276927702771277227732774277527762777277827792780278127822783278427852786278727882789279027912792279327942795279627972798279928002801280228032804280528062807280828092810281128122813281428152816281728182819282028212822282328242825282628272828282928302831283228332834283528362837283828392840284128422843284428452846284728482849285028512852285328542855285628572858285928602861286228632864286528662867286828692870287128722873287428752876287728782879288028812882288328842885288628872888288928902891289228932894289528962897289828992900290129022903290429052906290729082909291029112912291329142915291629172918291929202921292229232924292529262927292829292930293129322933293429352936293729382939294029412942294329442945294629472948294929502951295229532954295529562957295829592960296129622963296429652966296729682969297029712972297329742975297629772978297929802981298229832984298529862987298829892990299129922993299429952996299729982999300030013002300330043005300630073008300930103011301230133014301530163017301830193020302130223023302430253026302730283029303030313032303330343035303630373038303930403041304230433044304530463047304830493050305130523053305430553056305730583059306030613062306330643065306630673068306930703071307230733074307530763077307830793080308130823083308430853086308730883089309030913092309330943095309630973098309931003101310231033104310531063107310831093110311131123113311431153116311731183119312031213122312331243125312631273128312931303131313231333134313531363137313831393140314131423143314431453146314731483149315031513152315331543155315631573158315931603161316231633164316531663167316831693170317131723173317431753176317731783179318031813182318331843185318631873188318931903191319231933194319531963197319831993200320132023203320432053206320732083209321032113212321332143215321632173218321932203221322232233224322532263227322832293230323132323233323432353236323732383239324032413242324332443245324632473248324932503251325232533254325532563257325832593260326132623263326432653266326732683269327032713272327332743275327632773278327932803281328232833284328532863287328832893290329132923293329432953296329732983299330033013302330333043305330633073308330933103311331233133314331533163317331833193320332133223323332433253326332733283329333033313332333333343335333633373338333933403341334233433344334533463347334833493350335133523353335433553356335733583359336033613362336333643365336633673368336933703371337233733374337533763377337833793380338133823383338433853386338733883389339033913392339333943395339633973398339934003401340234033404340534063407340834093410341134123413341434153416341734183419342034213422342334243425342634273428342934303431343234333434343534363437343834393440344134423443344434453446344734483449345034513452345334543455345634573458345934603461346234633464346534663467346834693470347134723473347434753476347734783479348034813482348334843485348634873488348934903491349234933494349534963497349834993500350135023503350435053506350735083509351035113512351335143515351635173518351935203521352235233524352535263527352835293530353135323533353435353536353735383539354035413542354335443545354635473548354935503551355235533554355535563557355835593560356135623563356435653566356735683569357035713572357335743575357635773578357935803581358235833584358535863587358835893590359135923593359435953596359735983599360036013602360336043605360636073608360936103611361236133614361536163617361836193620362136223623362436253626362736283629363036313632363336343635363636373638363936403641364236433644364536463647364836493650365136523653365436553656365736583659366036613662366336643665366636673668366936703671367236733674367536763677367836793680368136823683368436853686368736883689369036913692369336943695369636973698369937003701370237033704370537063707370837093710371137123713371437153716371737183719372037213722372337243725372637273728372937303731373237333734373537363737373837393740374137423743374437453746374737483749375037513752375337543755375637573758375937603761376237633764376537663767376837693770377137723773377437753776377737783779378037813782378337843785378637873788378937903791379237933794379537963797379837993800380138023803380438053806380738083809381038113812381338143815381638173818381938203821382238233824382538263827382838293830383138323833383438353836383738383839384038413842384338443845384638473848384938503851385238533854385538563857385838593860386138623863386438653866386738683869387038713872387338743875387638773878387938803881388238833884388538863887388838893890389138923893389438953896389738983899390039013902390339043905390639073908390939103911391239133914391539163917391839193920392139223923
  1. Internet Engineering Task Force (IETF) S. Cheshire
  2. Request for Comments: 6762 M. Krochmal
  3. Category: Standards Track Apple Inc.
  4. ISSN: 2070-1721 February 2013
  5. Multicast DNS
  6. Abstract
  7. As networked devices become smaller, more portable, and more
  8. ubiquitous, the ability to operate with less configured
  9. infrastructure is increasingly important. In particular, the ability
  10. to look up DNS resource record data types (including, but not limited
  11. to, host names) in the absence of a conventional managed DNS server
  12. is useful.
  13. Multicast DNS (mDNS) provides the ability to perform DNS-like
  14. operations on the local link in the absence of any conventional
  15. Unicast DNS server. In addition, Multicast DNS designates a portion
  16. of the DNS namespace to be free for local use, without the need to
  17. pay any annual fee, and without the need to set up delegations or
  18. otherwise configure a conventional DNS server to answer for those
  19. names.
  20. The primary benefits of Multicast DNS names are that (i) they require
  21. little or no administration or configuration to set them up, (ii)
  22. they work when no infrastructure is present, and (iii) they work
  23. during infrastructure failures.
  24. Status of This Memo
  25. This is an Internet Standards Track document.
  26. This document is a product of the Internet Engineering Task Force
  27. (IETF). It represents the consensus of the IETF community. It has
  28. received public review and has been approved for publication by the
  29. Internet Engineering Steering Group (IESG). Further information on
  30. Internet Standards is available in Section 2 of RFC 5741.
  31. Information about the current status of this document, any errata,
  32. and how to provide feedback on it may be obtained at
  33. http://www.rfc-editor.org/info/rfc6762.
  34. Cheshire & Krochmal Standards Track [Page 1]
  35. RFC 6762 Multicast DNS February 2013
  36. Copyright Notice
  37. Copyright (c) 2013 IETF Trust and the persons identified as the
  38. document authors. All rights reserved.
  39. This document is subject to BCP 78 and the IETF Trust's Legal
  40. Provisions Relating to IETF Documents
  41. (http://trustee.ietf.org/license-info) in effect on the date of
  42. publication of this document. Please review these documents
  43. carefully, as they describe your rights and restrictions with respect
  44. to this document. Code Components extracted from this document must
  45. include Simplified BSD License text as described in Section 4.e of
  46. the Trust Legal Provisions and are provided without warranty as
  47. described in the Simplified BSD License.
  48. This document may contain material from IETF Documents or IETF
  49. Contributions published or made publicly available before November
  50. 10, 2008. The person(s) controlling the copyright in some of this
  51. material may not have granted the IETF Trust the right to allow
  52. modifications of such material outside the IETF Standards Process.
  53. Without obtaining an adequate license from the person(s) controlling
  54. the copyright in such materials, this document may not be modified
  55. outside the IETF Standards Process, and derivative works of it may
  56. not be created outside the IETF Standards Process, except to format
  57. it for publication as an RFC or to translate it into languages other
  58. than English.
  59. Cheshire & Krochmal Standards Track [Page 2]
  60. RFC 6762 Multicast DNS February 2013
  61. Table of Contents
  62. 1. Introduction ....................................................4
  63. 2. Conventions and Terminology Used in This Document ...............4
  64. 3. Multicast DNS Names .............................................5
  65. 4. Reverse Address Mapping .........................................7
  66. 5. Querying ........................................................8
  67. 6. Responding .....................................................13
  68. 7. Traffic Reduction ..............................................22
  69. 8. Probing and Announcing on Startup ..............................25
  70. 9. Conflict Resolution ............................................31
  71. 10. Resource Record TTL Values and Cache Coherency ................33
  72. 11. Source Address Check ..........................................38
  73. 12. Special Characteristics of Multicast DNS Domains ..............40
  74. 13. Enabling and Disabling Multicast DNS ..........................41
  75. 14. Considerations for Multiple Interfaces ........................42
  76. 15. Considerations for Multiple Responders on the Same Machine ....43
  77. 16. Multicast DNS Character Set ...................................45
  78. 17. Multicast DNS Message Size ....................................46
  79. 18. Multicast DNS Message Format ..................................47
  80. 19. Summary of Differences between Multicast DNS and Unicast DNS ..51
  81. 20. IPv6 Considerations ...........................................52
  82. 21. Security Considerations .......................................52
  83. 22. IANA Considerations ...........................................53
  84. 23. Acknowledgments ...............................................56
  85. 24. References ....................................................56
  86. Appendix A. Design Rationale for Choice of UDP Port Number ........60
  87. Appendix B. Design Rationale for Not Using Hashed Multicast
  88. Addresses .............................................61
  89. Appendix C. Design Rationale for Maximum Multicast DNS Name
  90. Length ................................................62
  91. Appendix D. Benefits of Multicast Responses .......................64
  92. Appendix E. Design Rationale for Encoding Negative Responses ......65
  93. Appendix F. Use of UTF-8 ..........................................66
  94. Appendix G. Private DNS Namespaces ................................67
  95. Appendix H. Deployment History ....................................67
  96. Cheshire & Krochmal Standards Track [Page 3]
  97. RFC 6762 Multicast DNS February 2013
  98. 1. Introduction
  99. Multicast DNS and its companion technology DNS-Based Service
  100. Discovery [RFC6763] were created to provide IP networking with the
  101. ease-of-use and autoconfiguration for which AppleTalk was well-known
  102. [RFC6760]. When reading this document, familiarity with the concepts
  103. of Zero Configuration Networking [Zeroconf] and automatic link-local
  104. addressing [RFC3927] [RFC4862] is helpful.
  105. Multicast DNS borrows heavily from the existing DNS protocol
  106. [RFC1034] [RFC1035] [RFC6195], using the existing DNS message
  107. structure, name syntax, and resource record types. This document
  108. specifies no new operation codes or response codes. This document
  109. describes how clients send DNS-like queries via IP multicast, and how
  110. a collection of hosts cooperate to collectively answer those queries
  111. in a useful manner.
  112. 2. Conventions and Terminology Used in This Document
  113. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  114. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  115. document are to be interpreted as described in "Key words for use in
  116. RFCs to Indicate Requirement Levels" [RFC2119].
  117. When this document uses the term "Multicast DNS", it should be taken
  118. to mean: "Clients performing DNS-like queries for DNS-like resource
  119. records by sending DNS-like UDP query and response messages over IP
  120. Multicast to UDP port 5353". The design rationale for selecting UDP
  121. port 5353 is discussed in Appendix A.
  122. This document uses the term "host name" in the strict sense to mean a
  123. fully qualified domain name that has an IPv4 or IPv6 address record.
  124. It does not use the term "host name" in the commonly used but
  125. incorrect sense to mean just the first DNS label of a host's fully
  126. qualified domain name.
  127. A DNS (or mDNS) packet contains an IP Time to Live (TTL) in the IP
  128. header, which is effectively a hop-count limit for the packet, to
  129. guard against routing loops. Each resource record also contains a
  130. TTL, which is the number of seconds for which the resource record may
  131. be cached. This document uses the term "IP TTL" to refer to the IP
  132. header TTL (hop limit), and the term "RR TTL" or just "TTL" to refer
  133. to the resource record TTL (cache lifetime).
  134. DNS-format messages contain a header, a Question Section, then
  135. Answer, Authority, and Additional Record Sections. The Answer,
  136. Authority, and Additional Record Sections all hold resource records
  137. Cheshire & Krochmal Standards Track [Page 4]
  138. RFC 6762 Multicast DNS February 2013
  139. in the same format. Where this document describes issues that apply
  140. equally to all three sections, it uses the term "Resource Record
  141. Sections" to refer collectively to these three sections.
  142. This document uses the terms "shared" and "unique" when referring to
  143. resource record sets [RFC1034]:
  144. A "shared" resource record set is one where several Multicast DNS
  145. responders may have records with the same name, rrtype, and
  146. rrclass, and several responders may respond to a particular query.
  147. A "unique" resource record set is one where all the records with
  148. that name, rrtype, and rrclass are conceptually under the control
  149. or ownership of a single responder, and it is expected that at
  150. most one responder should respond to a query for that name,
  151. rrtype, and rrclass. Before claiming ownership of a unique
  152. resource record set, a responder MUST probe to verify that no
  153. other responder already claims ownership of that set, as described
  154. in Section 8.1, "Probing". (For fault-tolerance and other
  155. reasons, sometimes it is permissible to have more than one
  156. responder answering for a particular "unique" resource record set,
  157. but such cooperating responders MUST give answers containing
  158. identical rdata for these records. If they do not give answers
  159. containing identical rdata, then the probing step will reject the
  160. data as being inconsistent with what is already being advertised
  161. on the network for those names.)
  162. Strictly speaking, the terms "shared" and "unique" apply to resource
  163. record sets, not to individual resource records. However, it is
  164. sometimes convenient to talk of "shared resource records" and "unique
  165. resource records". When used this way, the terms should be
  166. understood to mean a record that is a member of a "shared" or
  167. "unique" resource record set, respectively.
  168. 3. Multicast DNS Names
  169. A host that belongs to an organization or individual who has control
  170. over some portion of the DNS namespace can be assigned a globally
  171. unique name within that portion of the DNS namespace, such as,
  172. "cheshire.example.com.". For those of us who have this luxury, this
  173. works very well. However, the majority of home computer users do not
  174. have easy access to any portion of the global DNS namespace within
  175. which they have the authority to create names. This leaves the
  176. majority of home computers effectively anonymous for practical
  177. purposes.
  178. Cheshire & Krochmal Standards Track [Page 5]
  179. RFC 6762 Multicast DNS February 2013
  180. To remedy this problem, this document allows any computer user to
  181. elect to give their computers link-local Multicast DNS host names of
  182. the form: "single-dns-label.local.". For example, a laptop computer
  183. may answer to the name "MyComputer.local.". Any computer user is
  184. granted the authority to name their computer this way, provided that
  185. the chosen host name is not already in use on that link. Having
  186. named their computer this way, the user has the authority to continue
  187. utilizing that name until such time as a name conflict occurs on the
  188. link that is not resolved in the user's favor. If this happens, the
  189. computer (or its human user) MUST cease using the name, and SHOULD
  190. attempt to allocate a new unique name for use on that link. These
  191. conflicts are expected to be relatively rare for people who choose
  192. reasonably imaginative names, but it is still important to have a
  193. mechanism in place to handle them when they happen.
  194. This document specifies that the DNS top-level domain ".local." is a
  195. special domain with special semantics, namely that any fully
  196. qualified name ending in ".local." is link-local, and names within
  197. this domain are meaningful only on the link where they originate.
  198. This is analogous to IPv4 addresses in the 169.254/16 prefix or IPv6
  199. addresses in the FE80::/10 prefix, which are link-local and
  200. meaningful only on the link where they originate.
  201. Any DNS query for a name ending with ".local." MUST be sent to the
  202. mDNS IPv4 link-local multicast address 224.0.0.251 (or its IPv6
  203. equivalent FF02::FB). The design rationale for using a fixed
  204. multicast address instead of selecting from a range of multicast
  205. addresses using a hash function is discussed in Appendix B.
  206. Implementers MAY choose to look up such names concurrently via other
  207. mechanisms (e.g., Unicast DNS) and coalesce the results in some
  208. fashion. Implementers choosing to do this should be aware of the
  209. potential for user confusion when a given name can produce different
  210. results depending on external network conditions (such as, but not
  211. limited to, which name lookup mechanism responds faster).
  212. It is unimportant whether a name ending with ".local." occurred
  213. because the user explicitly typed in a fully qualified domain name
  214. ending in ".local.", or because the user entered an unqualified
  215. domain name and the host software appended the suffix ".local."
  216. because that suffix appears in the user's search list. The ".local."
  217. suffix could appear in the search list because the user manually
  218. configured it, or because it was received via DHCP [RFC2132] or via
  219. any other mechanism for configuring the DNS search list. In this
  220. respect the ".local." suffix is treated no differently from any other
  221. search domain that might appear in the DNS search list.
  222. Cheshire & Krochmal Standards Track [Page 6]
  223. RFC 6762 Multicast DNS February 2013
  224. DNS queries for names that do not end with ".local." MAY be sent to
  225. the mDNS multicast address, if no other conventional DNS server is
  226. available. This can allow hosts on the same link to continue
  227. communicating using each other's globally unique DNS names during
  228. network outages that disrupt communication with the greater Internet.
  229. When resolving global names via local multicast, it is even more
  230. important to use DNS Security Extensions (DNSSEC) [RFC4033] or other
  231. security mechanisms to ensure that the response is trustworthy.
  232. Resolving global names via local multicast is a contentious issue,
  233. and this document does not discuss it further, instead concentrating
  234. on the issue of resolving local names using DNS messages sent to a
  235. multicast address.
  236. This document recommends a single flat namespace for dot-local host
  237. names, (i.e., the names of DNS "A" and "AAAA" records, which map
  238. names to IPv4 and IPv6 addresses), but other DNS record types (such
  239. as those used by DNS-Based Service Discovery [RFC6763]) may contain
  240. as many labels as appropriate for the desired usage, up to a maximum
  241. of 255 bytes, plus a terminating zero byte at the end. Name length
  242. issues are discussed further in Appendix C.
  243. Enforcing uniqueness of host names is probably desirable in the
  244. common case, but this document does not mandate that. It is
  245. permissible for a collection of coordinated hosts to agree to
  246. maintain multiple DNS address records with the same name, possibly
  247. for load-balancing or fault-tolerance reasons. This document does
  248. not take a position on whether that is sensible. It is important
  249. that both modes of operation be supported. The Multicast DNS
  250. protocol allows hosts to verify and maintain unique names for
  251. resource records where that behavior is desired, and it also allows
  252. hosts to maintain multiple resource records with a single shared name
  253. where that behavior is desired. This consideration applies to all
  254. resource records, not just address records (host names). In summary:
  255. It is required that the protocol have the ability to detect and
  256. handle name conflicts, but it is not required that this ability be
  257. used for every record.
  258. 4. Reverse Address Mapping
  259. Like ".local.", the IPv4 and IPv6 reverse mapping domains are also
  260. defined to be link-local:
  261. Any DNS query for a name ending with "254.169.in-addr.arpa." MUST
  262. be sent to the mDNS IPv4 link-local multicast address 224.0.0.251
  263. or the mDNS IPv6 multicast address FF02::FB. Since names under
  264. this domain correspond to IPv4 link-local addresses, it is logical
  265. that the local link is the best place to find information
  266. pertaining to those names.
  267. Cheshire & Krochmal Standards Track [Page 7]
  268. RFC 6762 Multicast DNS February 2013
  269. Likewise, any DNS query for a name within the reverse mapping
  270. domains for IPv6 link-local addresses ("8.e.f.ip6.arpa.",
  271. "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST
  272. be sent to the mDNS IPv6 link-local multicast address FF02::FB or
  273. the mDNS IPv4 link-local multicast address 224.0.0.251.
  274. 5. Querying
  275. There are two kinds of Multicast DNS queries: one-shot queries of the
  276. kind made by legacy DNS resolvers, and continuous, ongoing Multicast
  277. DNS queries made by fully compliant Multicast DNS queriers, which
  278. support asynchronous operations including DNS-Based Service Discovery
  279. [RFC6763].
  280. Except in the rare case of a Multicast DNS responder that is
  281. advertising only shared resource records and no unique records, a
  282. Multicast DNS responder MUST also implement a Multicast DNS querier
  283. so that it can first verify the uniqueness of those records before it
  284. begins answering queries for them.
  285. 5.1. One-Shot Multicast DNS Queries
  286. The most basic kind of Multicast DNS client may simply send standard
  287. DNS queries blindly to 224.0.0.251:5353, without necessarily even
  288. being aware of what a multicast address is. This change can
  289. typically be implemented with just a few lines of code in an existing
  290. DNS resolver library. If a name being queried falls within one of
  291. the reserved Multicast DNS domains (see Sections 3 and 4), then,
  292. rather than using the configured Unicast DNS server address, the
  293. query is instead sent to 224.0.0.251:5353 (or its IPv6 equivalent
  294. [FF02::FB]:5353). Typically, the timeout would also be shortened to
  295. two or three seconds. It's possible to make a minimal Multicast DNS
  296. resolver with only these simple changes. These queries are typically
  297. done using a high-numbered ephemeral UDP source port, but regardless
  298. of whether they are sent from a dynamic port or from a fixed port,
  299. these queries MUST NOT be sent using UDP source port 5353, since
  300. using UDP source port 5353 signals the presence of a fully compliant
  301. Multicast DNS querier, as described below.
  302. A simple DNS resolver like this will typically just take the first
  303. response it receives. It will not listen for additional UDP
  304. responses, but in many instances this may not be a serious problem.
  305. If a user types "http://MyPrinter.local." into their web browser, and
  306. their simple DNS resolver just takes the first response it receives,
  307. and the user gets to see the status and configuration web page for
  308. their printer, then the protocol has met the user's needs in this
  309. case.
  310. Cheshire & Krochmal Standards Track [Page 8]
  311. RFC 6762 Multicast DNS February 2013
  312. While a basic DNS resolver like this may be adequate for simple host
  313. name lookup, it may not get ideal behavior in other cases.
  314. Additional refinements to create a fully compliant Multicast DNS
  315. querier are described below.
  316. 5.2. Continuous Multicast DNS Querying
  317. In one-shot queries, the underlying assumption is that the
  318. transaction begins when the application issues a query, and ends when
  319. the first response is received. There is another type of query
  320. operation that is more asynchronous, in which having received one
  321. response is not necessarily an indication that there will be no more
  322. relevant responses, and the querying operation continues until no
  323. further responses are required. Determining when no further
  324. responses are required depends on the type of operation being
  325. performed. If the operation is looking up the IPv4 and IPv6
  326. addresses of another host, then no further responses are required
  327. once a successful connection has been made to one of those IPv4 or
  328. IPv6 addresses. If the operation is browsing to present the user
  329. with a list of DNS-SD services found on the network [RFC6763], then
  330. no further responses are required once the user indicates this to the
  331. user-interface software, e.g., by closing the network browsing window
  332. that was displaying the list of discovered services.
  333. Imagine some hypothetical software that allows users to discover
  334. network printers. The user wishes to discover all printers on the
  335. local network, not only the printer that is quickest to respond.
  336. When the user is actively looking for a network printer to use, they
  337. open a network browsing window that displays the list of discovered
  338. printers. It would be convenient for the user if they could rely on
  339. this list of network printers to stay up to date as network printers
  340. come and go, rather than displaying out-of-date stale information,
  341. and requiring the user explicitly to click a "refresh" button any
  342. time they want to see accurate information (which, from the moment it
  343. is displayed, is itself already beginning to become out-of-date and
  344. stale). If we are to display a continuously updated live list like
  345. this, we need to be able to do it efficiently, without naive constant
  346. polling, which would be an unreasonable burden on the network. It is
  347. not expected that all users will be browsing to discover new printers
  348. all the time, but when a user is browsing to discover service
  349. instances for an extended period, we want to be able to support that
  350. operation efficiently.
  351. Therefore, when retransmitting Multicast DNS queries to implement
  352. this kind of continuous monitoring, the interval between the first
  353. two queries MUST be at least one second, the intervals between
  354. successive queries MUST increase by at least a factor of two, and the
  355. querier MUST implement Known-Answer Suppression, as described below
  356. Cheshire & Krochmal Standards Track [Page 9]
  357. RFC 6762 Multicast DNS February 2013
  358. in Section 7.1. The Known-Answer Suppression mechanism tells
  359. responders which answers are already known to the querier, thereby
  360. allowing responders to avoid wasting network capacity with pointless
  361. repeated transmission of those answers. A querier retransmits its
  362. question because it wishes to receive answers it may have missed the
  363. first time, not because it wants additional duplicate copies of
  364. answers it already received. Failure to implement Known-Answer
  365. Suppression can result in unacceptable levels of network traffic.
  366. When the interval between queries reaches or exceeds 60 minutes, a
  367. querier MAY cap the interval to a maximum of 60 minutes, and perform
  368. subsequent queries at a steady-state rate of one query per hour. To
  369. avoid accidental synchronization when, for some reason, multiple
  370. clients begin querying at exactly the same moment (e.g., because of
  371. some common external trigger event), a Multicast DNS querier SHOULD
  372. also delay the first query of the series by a randomly chosen amount
  373. in the range 20-120 ms.
  374. When a Multicast DNS querier receives an answer, the answer contains
  375. a TTL value that indicates for how many seconds this answer is valid.
  376. After this interval has passed, the answer will no longer be valid
  377. and SHOULD be deleted from the cache. Before the record expiry time
  378. is reached, a Multicast DNS querier that has local clients with an
  379. active interest in the state of that record (e.g., a network browsing
  380. window displaying a list of discovered services to the user) SHOULD
  381. reissue its query to determine whether the record is still valid.
  382. To perform this cache maintenance, a Multicast DNS querier should
  383. plan to retransmit its query after at least 50% of the record
  384. lifetime has elapsed. This document recommends the following
  385. specific strategy.
  386. The querier should plan to issue a query at 80% of the record
  387. lifetime, and then if no answer is received, at 85%, 90%, and 95%.
  388. If an answer is received, then the remaining TTL is reset to the
  389. value given in the answer, and this process repeats for as long as
  390. the Multicast DNS querier has an ongoing interest in the record. If
  391. no answer is received after four queries, the record is deleted when
  392. it reaches 100% of its lifetime. A Multicast DNS querier MUST NOT
  393. perform this cache maintenance for records for which it has no local
  394. clients with an active interest. If the expiry of a particular
  395. record from the cache would result in no net effect to any client
  396. software running on the querier device, and no visible effect to the
  397. human user, then there is no reason for the Multicast DNS querier to
  398. waste network capacity checking whether the record remains valid.
  399. Cheshire & Krochmal Standards Track [Page 10]
  400. RFC 6762 Multicast DNS February 2013
  401. To avoid the case where multiple Multicast DNS queriers on a network
  402. all issue their queries simultaneously, a random variation of 2% of
  403. the record TTL should be added, so that queries are scheduled to be
  404. performed at 80-82%, 85-87%, 90-92%, and then 95-97% of the TTL.
  405. An additional efficiency optimization SHOULD be performed when a
  406. Multicast DNS response is received containing a unique answer (as
  407. indicated by the cache-flush bit being set, described in Section
  408. 10.2, "Announcements to Flush Outdated Cache Entries"). In this
  409. case, there is no need for the querier to continue issuing a stream
  410. of queries with exponentially increasing intervals, since the receipt
  411. of a unique answer is a good indication that no other answers will be
  412. forthcoming. In this case, the Multicast DNS querier SHOULD plan to
  413. issue its next query for this record at 80-82% of the record's TTL,
  414. as described above.
  415. A compliant Multicast DNS querier, which implements the rules
  416. specified in this document, MUST send its Multicast DNS queries from
  417. UDP source port 5353 (the well-known port assigned to mDNS), and MUST
  418. listen for Multicast DNS replies sent to UDP destination port 5353 at
  419. the mDNS link-local multicast address (224.0.0.251 and/or its IPv6
  420. equivalent FF02::FB).
  421. 5.3. Multiple Questions per Query
  422. Multicast DNS allows a querier to place multiple questions in the
  423. Question Section of a single Multicast DNS query message.
  424. The semantics of a Multicast DNS query message containing multiple
  425. questions is identical to a series of individual DNS query messages
  426. containing one question each. Combining multiple questions into a
  427. single message is purely an efficiency optimization and has no other
  428. semantic significance.
  429. 5.4. Questions Requesting Unicast Responses
  430. Sending Multicast DNS responses via multicast has the benefit that
  431. all the other hosts on the network get to see those responses,
  432. enabling them to keep their caches up to date and detect conflicting
  433. responses.
  434. However, there are situations where all the other hosts on the
  435. network don't need to see every response. Some examples are a laptop
  436. computer waking from sleep, the Ethernet cable being connected to a
  437. running machine, or a previously inactive interface being activated
  438. through a configuration change. At the instant of wake-up or link
  439. activation, the machine is a brand new participant on a new network.
  440. Its Multicast DNS cache for that interface is empty, and it has no
  441. Cheshire & Krochmal Standards Track [Page 11]
  442. RFC 6762 Multicast DNS February 2013
  443. knowledge of its peers on that link. It may have a significant
  444. number of questions that it wants answered right away, to discover
  445. information about its new surroundings and present that information
  446. to the user. As a new participant on the network, it has no idea
  447. whether the exact same questions may have been asked and answered
  448. just seconds ago. In this case, triggering a large sudden flood of
  449. multicast responses may impose an unreasonable burden on the network.
  450. To avoid large floods of potentially unnecessary responses in these
  451. cases, Multicast DNS defines the top bit in the class field of a DNS
  452. question as the unicast-response bit. When this bit is set in a
  453. question, it indicates that the querier is willing to accept unicast
  454. replies in response to this specific query, as well as the usual
  455. multicast responses. These questions requesting unicast responses
  456. are referred to as "QU" questions, to distinguish them from the more
  457. usual questions requesting multicast responses ("QM" questions). A
  458. Multicast DNS querier sending its initial batch of questions
  459. immediately on wake from sleep or interface activation SHOULD set the
  460. unicast-response bit in those questions.
  461. When a question is retransmitted (as described in Section 5.2), the
  462. unicast-response bit SHOULD NOT be set in subsequent retransmissions
  463. of that question. Subsequent retransmissions SHOULD be usual "QM"
  464. questions. After the first question has received its responses, the
  465. querier should have a large Known-Answer list (Section 7.1) so that
  466. subsequent queries should elicit few, if any, further responses.
  467. Reverting to multicast responses as soon as possible is important
  468. because of the benefits that multicast responses provide (see
  469. Appendix D). In addition, the unicast-response bit SHOULD be set
  470. only for questions that are active and ready to be sent the moment of
  471. wake from sleep or interface activation. New questions created by
  472. local clients afterwards should be treated as normal "QM" questions
  473. and SHOULD NOT have the unicast-response bit set on the first
  474. question of the series.
  475. When receiving a question with the unicast-response bit set, a
  476. responder SHOULD usually respond with a unicast packet directed back
  477. to the querier. However, if the responder has not multicast that
  478. record recently (within one quarter of its TTL), then the responder
  479. SHOULD instead multicast the response so as to keep all the peer
  480. caches up to date, and to permit passive conflict detection. In the
  481. case of answering a probe question (Section 8.1) with the unicast-
  482. response bit set, the responder should always generate the requested
  483. unicast response, but it may also send a multicast announcement if
  484. the time since the last multicast announcement of that record is more
  485. than a quarter of its TTL.
  486. Cheshire & Krochmal Standards Track [Page 12]
  487. RFC 6762 Multicast DNS February 2013
  488. Unicast replies are subject to all the same packet generation rules
  489. as multicast replies, including the cache-flush bit (Section 10.2)
  490. and (except when defending a unique name against a probe from another
  491. host) randomized delays to reduce network collisions (Section 6).
  492. 5.5. Direct Unicast Queries to Port 5353
  493. In specialized applications there may be rare situations where it
  494. makes sense for a Multicast DNS querier to send its query via unicast
  495. to a specific machine. When a Multicast DNS responder receives a
  496. query via direct unicast, it SHOULD respond as it would for "QU"
  497. questions, as described above in Section 5.4. Since it is possible
  498. for a unicast query to be received from a machine outside the local
  499. link, responders SHOULD check that the source address in the query
  500. packet matches the local subnet for that link (or, in the case of
  501. IPv6, the source address has an on-link prefix) and silently ignore
  502. the packet if not.
  503. There may be specialized situations, outside the scope of this
  504. document, where it is intended and desirable to create a responder
  505. that does answer queries originating outside the local link. Such a
  506. responder would need to ensure that these non-local queries are
  507. always answered via unicast back to the querier, since an answer sent
  508. via link-local multicast would not reach a querier outside the local
  509. link.
  510. 6. Responding
  511. When a Multicast DNS responder constructs and sends a Multicast DNS
  512. response message, the Resource Record Sections of that message must
  513. contain only records for which that responder is explicitly
  514. authoritative. These answers may be generated because the record
  515. answers a question received in a Multicast DNS query message, or at
  516. certain other times that the responder determines than an unsolicited
  517. announcement is warranted. A Multicast DNS responder MUST NOT place
  518. records from its cache, which have been learned from other responders
  519. on the network, in the Resource Record Sections of outgoing response
  520. messages. Only an authoritative source for a given record is allowed
  521. to issue responses containing that record.
  522. The determination of whether a given record answers a given question
  523. is made using the standard DNS rules: the record name must match the
  524. question name, the record rrtype must match the question qtype unless
  525. the qtype is "ANY" (255) or the rrtype is "CNAME" (5), and the record
  526. rrclass must match the question qclass unless the qclass is "ANY"
  527. (255). As with Unicast DNS, generally only DNS class 1 ("Internet")
  528. is used, but should client software use classes other than 1, the
  529. matching rules described above MUST be used.
  530. Cheshire & Krochmal Standards Track [Page 13]
  531. RFC 6762 Multicast DNS February 2013
  532. A Multicast DNS responder MUST only respond when it has a positive,
  533. non-null response to send, or it authoritatively knows that a
  534. particular record does not exist. For unique records, where the host
  535. has already established sole ownership of the name, it MUST return
  536. negative answers to queries for records that it knows not to exist.
  537. For example, a host with no IPv6 address, that has claimed sole
  538. ownership of the name "host.local." for all rrtypes, MUST respond to
  539. AAAA queries for "host.local." by sending a negative answer
  540. indicating that no AAAA records exist for that name. See Section
  541. 6.1, "Negative Responses". For shared records, which are owned by no
  542. single host, the nonexistence of a given record is ascertained by the
  543. failure of any machine to respond to the Multicast DNS query, not by
  544. any explicit negative response. For shared records, NXDOMAIN and
  545. other error responses MUST NOT be sent.
  546. Multicast DNS responses MUST NOT contain any questions in the
  547. Question Section. Any questions in the Question Section of a
  548. received Multicast DNS response MUST be silently ignored. Multicast
  549. DNS queriers receiving Multicast DNS responses do not care what
  550. question elicited the response; they care only that the information
  551. in the response is true and accurate.
  552. A Multicast DNS responder on Ethernet [IEEE.802.3] and similar shared
  553. multiple access networks SHOULD have the capability of delaying its
  554. responses by up to 500 ms, as described below.
  555. If a large number of Multicast DNS responders were all to respond
  556. immediately to a particular query, a collision would be virtually
  557. guaranteed. By imposing a small random delay, the number of
  558. collisions is dramatically reduced. On a full-sized Ethernet using
  559. the maximum cable lengths allowed and the maximum number of repeaters
  560. allowed, an Ethernet frame is vulnerable to collisions during the
  561. transmission of its first 256 bits. On 10 Mb/s Ethernet, this
  562. equates to a vulnerable time window of 25.6 microseconds. On higher-
  563. speed variants of Ethernet, the vulnerable time window is shorter.
  564. In the case where a Multicast DNS responder has good reason to
  565. believe that it will be the only responder on the link that will send
  566. a response (i.e., because it is able to answer every question in the
  567. query message, and for all of those answer records it has previously
  568. verified that the name, rrtype, and rrclass are unique on the link),
  569. it SHOULD NOT impose any random delay before responding, and SHOULD
  570. normally generate its response within at most 10 ms. In particular,
  571. this applies to responding to probe queries with the unicast-response
  572. bit set. Since receiving a probe query gives a clear indication that
  573. some other responder is planning to start using this name in the very
  574. near future, answering such probe queries to defend a unique record
  575. is a high priority and needs to be done without delay. A probe query
  576. Cheshire & Krochmal Standards Track [Page 14]
  577. RFC 6762 Multicast DNS February 2013
  578. can be distinguished from a normal query by the fact that a probe
  579. query contains a proposed record in the Authority Section that
  580. answers the question in the Question Section (for more details, see
  581. Section 8.2, "Simultaneous Probe Tiebreaking").
  582. Responding without delay is appropriate for records like the address
  583. record for a particular host name, when the host name has been
  584. previously verified unique. Responding without delay is *not*
  585. appropriate for things like looking up PTR records used for DNS-Based
  586. Service Discovery [RFC6763], where a large number of responses may be
  587. anticipated.
  588. In any case where there may be multiple responses, such as queries
  589. where the answer is a member of a shared resource record set, each
  590. responder SHOULD delay its response by a random amount of time
  591. selected with uniform random distribution in the range 20-120 ms.
  592. The reason for requiring that the delay be at least 20 ms is to
  593. accommodate the situation where two or more query packets are sent
  594. back-to-back, because in that case we want a responder with answers
  595. to more than one of those queries to have the opportunity to
  596. aggregate all of its answers into a single response message.
  597. In the case where the query has the TC (truncated) bit set,
  598. indicating that subsequent Known-Answer packets will follow,
  599. responders SHOULD delay their responses by a random amount of time
  600. selected with uniform random distribution in the range 400-500 ms, to
  601. allow enough time for all the Known-Answer packets to arrive, as
  602. described in Section 7.2, "Multipacket Known-Answer Suppression".
  603. The source UDP port in all Multicast DNS responses MUST be 5353 (the
  604. well-known port assigned to mDNS). Multicast DNS implementations
  605. MUST silently ignore any Multicast DNS responses they receive where
  606. the source UDP port is not 5353.
  607. The destination UDP port in all Multicast DNS responses MUST be 5353,
  608. and the destination address MUST be the mDNS IPv4 link-local
  609. multicast address 224.0.0.251 or its IPv6 equivalent FF02::FB, except
  610. when generating a reply to a query that explicitly requested a
  611. unicast response:
  612. * via the unicast-response bit,
  613. * by virtue of being a legacy query (Section 6.7), or
  614. * by virtue of being a direct unicast query.
  615. Except for these three specific cases, responses MUST NOT be sent via
  616. unicast, because then the "Passive Observation of Failures"
  617. mechanisms described in Section 10.5 would not work correctly. Other
  618. Cheshire & Krochmal Standards Track [Page 15]
  619. RFC 6762 Multicast DNS February 2013
  620. benefits of sending responses via multicast are discussed in Appendix
  621. D. A Multicast DNS querier MUST only accept unicast responses if
  622. they answer a recently sent query (e.g., sent within the last two
  623. seconds) that explicitly requested unicast responses. A Multicast
  624. DNS querier MUST silently ignore all other unicast responses.
  625. To protect the network against excessive packet flooding due to
  626. software bugs or malicious attack, a Multicast DNS responder MUST NOT
  627. (except in the one special case of answering probe queries) multicast
  628. a record on a given interface until at least one second has elapsed
  629. since the last time that record was multicast on that particular
  630. interface. A legitimate querier on the network should have seen the
  631. previous transmission and cached it. A querier that did not receive
  632. and cache the previous transmission will retry its request and
  633. receive a subsequent response. In the special case of answering
  634. probe queries, because of the limited time before the probing host
  635. will make its decision about whether or not to use the name, a
  636. Multicast DNS responder MUST respond quickly. In this special case
  637. only, when responding via multicast to a probe, a Multicast DNS
  638. responder is only required to delay its transmission as necessary to
  639. ensure an interval of at least 250 ms since the last time the record
  640. was multicast on that interface.
  641. 6.1. Negative Responses
  642. In the early design of Multicast DNS it was assumed that explicit
  643. negative responses would never be needed. A host can assert the
  644. existence of the set of records that it claims to exist, and the
  645. union of all such sets on a link is the set of Multicast DNS records
  646. that exist on that link. Asserting the nonexistence of every record
  647. in the complement of that set -- i.e., all possible Multicast DNS
  648. records that could exist on this link but do not at this moment --
  649. was felt to be impractical and unnecessary. The nonexistence of a
  650. record would be ascertained by a querier querying for it and failing
  651. to receive a response from any of the hosts currently attached to the
  652. link.
  653. However, operational experience showed that explicit negative
  654. responses can sometimes be valuable. One such example is when a
  655. querier is querying for a AAAA record, and the host name in question
  656. has no associated IPv6 addresses. In this case, the responding host
  657. knows it currently has exclusive ownership of that name, and it knows
  658. that it currently does not have any IPv6 addresses, so an explicit
  659. negative response is preferable to the querier having to retransmit
  660. its query multiple times, and eventually give up with a timeout,
  661. before it can conclude that a given AAAA record does not exist.
  662. Cheshire & Krochmal Standards Track [Page 16]
  663. RFC 6762 Multicast DNS February 2013
  664. Any time a responder receives a query for a name for which it has
  665. verified exclusive ownership, for a type for which that name has no
  666. records, the responder MUST (except as allowed in (a) below) respond
  667. asserting the nonexistence of that record using a DNS NSEC record
  668. [RFC4034]. In the case of Multicast DNS the NSEC record is not being
  669. used for its usual DNSSEC [RFC4033] security properties, but simply
  670. as a way of expressing which records do or do not exist with a given
  671. name.
  672. On receipt of a question for a particular name, rrtype, and rrclass,
  673. for which a responder does have one or more unique answers, the
  674. responder MAY also include an NSEC record in the Additional Record
  675. Section indicating the nonexistence of other rrtypes for that name
  676. and rrclass.
  677. Implementers working with devices with sufficient memory and CPU
  678. resources MAY choose to implement code to handle the full generality
  679. of the DNS NSEC record [RFC4034], including bitmaps up to 65,536 bits
  680. long. To facilitate use by devices with limited memory and CPU
  681. resources, Multicast DNS queriers are only REQUIRED to be able to
  682. parse a restricted form of the DNS NSEC record. All compliant
  683. Multicast DNS implementations MUST at least correctly generate and
  684. parse the restricted DNS NSEC record format described below:
  685. o The 'Next Domain Name' field contains the record's own name.
  686. When used with name compression, this means that the 'Next
  687. Domain Name' field always takes exactly two bytes in the
  688. message.
  689. o The Type Bit Map block number is 0.
  690. o The Type Bit Map block length byte is a value in the range 1-32.
  691. o The Type Bit Map data is 1-32 bytes, as indicated by length
  692. byte.
  693. Because this restricted form of the DNS NSEC record is limited to
  694. Type Bit Map block number zero, it cannot express the existence of
  695. rrtypes above 255. Consequently, if a Multicast DNS responder were
  696. to have records with rrtypes above 255, it MUST NOT generate these
  697. restricted-form NSEC records for those names, since to do so would
  698. imply that the name has no records with rrtypes above 255, which
  699. would be false. In such cases a Multicast DNS responder MUST either
  700. (a) emit no NSEC record for that name, or (b) emit a full NSEC record
  701. containing the appropriate Type Bit Map block(s) with the correct
  702. bits set for all the record types that exist. In practice this is
  703. not a significant limitation, since rrtypes above 255 are not
  704. currently in widespread use.
  705. Cheshire & Krochmal Standards Track [Page 17]
  706. RFC 6762 Multicast DNS February 2013
  707. If a Multicast DNS implementation receives an NSEC record where the
  708. 'Next Domain Name' field is not the record's own name, then the
  709. implementation SHOULD ignore the 'Next Domain Name' field and process
  710. the remainder of the NSEC record as usual. In Multicast DNS the
  711. 'Next Domain Name' field is not currently used, but it could be used
  712. in a future version of this protocol, which is why a Multicast DNS
  713. implementation MUST NOT reject or ignore an NSEC record it receives
  714. just because it finds an unexpected value in the 'Next Domain Name'
  715. field.
  716. If a Multicast DNS implementation receives an NSEC record containing
  717. more than one Type Bit Map, or where the Type Bit Map block number is
  718. not zero, or where the block length is not in the range 1-32, then
  719. the Multicast DNS implementation MAY silently ignore the entire NSEC
  720. record. A Multicast DNS implementation MUST NOT ignore an entire
  721. message just because that message contains one or more NSEC record(s)
  722. that the Multicast DNS implementation cannot parse. This provision
  723. is to allow future enhancements to the protocol to be introduced in a
  724. backwards-compatible way that does not break compatibility with older
  725. Multicast DNS implementations.
  726. To help differentiate these synthesized NSEC records (generated
  727. programmatically on-the-fly) from conventional Unicast DNS NSEC
  728. records (which actually exist in a signed DNS zone), the synthesized
  729. Multicast DNS NSEC records MUST NOT have the NSEC bit set in the Type
  730. Bit Map, whereas conventional Unicast DNS NSEC records do have the
  731. NSEC bit set.
  732. The TTL of the NSEC record indicates the intended lifetime of the
  733. negative cache entry. In general, the TTL given for an NSEC record
  734. SHOULD be the same as the TTL that the record would have had, had it
  735. existed. For example, the TTL for address records in Multicast DNS
  736. is typically 120 seconds (see Section 10), so the negative cache
  737. lifetime for an address record that does not exist should also be 120
  738. seconds.
  739. A responder MUST only generate negative responses to queries for
  740. which it has legitimate ownership of the name, rrtype, and rrclass in
  741. question, and can legitimately assert that no record with that name,
  742. rrtype, and rrclass exists. A responder can assert that a specified
  743. rrtype does not exist for one of its names if it knows a priori that
  744. it has exclusive ownership of that name (e.g., names of reverse
  745. address mapping PTR records, which are derived from IP addresses,
  746. which should be unique on the local link) or if it previously claimed
  747. unique ownership of that name using probe queries for rrtype "ANY".
  748. (If it were to use probe queries for a specific rrtype, then it would
  749. only own the name for that rrtype, and could not assert that other
  750. rrtypes do not exist.)
  751. Cheshire & Krochmal Standards Track [Page 18]
  752. RFC 6762 Multicast DNS February 2013
  753. The design rationale for this mechanism for encoding negative
  754. responses is discussed further in Appendix E.
  755. 6.2. Responding to Address Queries
  756. When a Multicast DNS responder sends a Multicast DNS response message
  757. containing its own address records, it MUST include all addresses
  758. that are valid on the interface on which it is sending the message,
  759. and MUST NOT include addresses that are not valid on that interface
  760. (such as addresses that may be configured on the host's other
  761. interfaces). For example, if an interface has both an IPv6 link-
  762. local and an IPv6 routable address, both should be included in the
  763. response message so that queriers receive both and can make their own
  764. choice about which to use. This allows a querier that only has an
  765. IPv6 link-local address to connect to the link-local address, and a
  766. different querier that has an IPv6 routable address to connect to the
  767. IPv6 routable address instead.
  768. When a Multicast DNS responder places an IPv4 or IPv6 address record
  769. (rrtype "A" or "AAAA") into a response message, it SHOULD also place
  770. any records of the other address type with the same name into the
  771. additional section, if there is space in the message. This is to
  772. provide fate sharing, so that all a device's addresses are delivered
  773. atomically in a single message, to reduce the risk that packet loss
  774. could cause a querier to receive only the IPv4 addresses and not the
  775. IPv6 addresses, or vice versa.
  776. In the event that a device has only IPv4 addresses but no IPv6
  777. addresses, or vice versa, then the appropriate NSEC record SHOULD be
  778. placed into the additional section, so that queriers can know with
  779. certainty that the device has no addresses of that kind.
  780. Some Multicast DNS responders treat a physical interface with both
  781. IPv4 and IPv6 address as a single interface with two addresses.
  782. Other Multicast DNS responders may treat this case as logically two
  783. interfaces (one with one or more IPv4 addresses, and the other with
  784. one or more IPv6 addresses), but responders that operate this way
  785. MUST NOT put the corresponding automatic NSEC records in replies they
  786. send (i.e., a negative IPv4 assertion in their IPv6 responses, and a
  787. negative IPv6 assertion in their IPv4 responses) because this would
  788. cause incorrect operation in responders on the network that work the
  789. former way.
  790. 6.3. Responding to Multiquestion Queries
  791. Multicast DNS responders MUST correctly handle DNS query messages
  792. containing more than one question, by answering any or all of the
  793. questions to which they have answers. Unlike single-question
  794. Cheshire & Krochmal Standards Track [Page 19]
  795. RFC 6762 Multicast DNS February 2013
  796. queries, where responding without delay is allowed in appropriate
  797. cases, for query messages containing more than one question, all
  798. (non-defensive) answers SHOULD be randomly delayed in the range
  799. 20-120 ms, or 400-500 ms if the TC (truncated) bit is set. This is
  800. because when a query message contains more than one question, a
  801. Multicast DNS responder cannot generally be certain that other
  802. responders will not also be simultaneously generating answers to
  803. other questions in that query message. (Answers defending a name, in
  804. response to a probe for that name, are not subject to this delay rule
  805. and are still sent immediately.)
  806. 6.4. Response Aggregation
  807. When possible, a responder SHOULD, for the sake of network
  808. efficiency, aggregate as many responses as possible into a single
  809. Multicast DNS response message. For example, when a responder has
  810. several responses it plans to send, each delayed by a different
  811. interval, then earlier responses SHOULD be delayed by up to an
  812. additional 500 ms if that will permit them to be aggregated with
  813. other responses scheduled to go out a little later.
  814. 6.5. Wildcard Queries (qtype "ANY" and qclass "ANY")
  815. When responding to queries using qtype "ANY" (255) and/or qclass
  816. "ANY" (255), a Multicast DNS responder MUST respond with *ALL* of its
  817. records that match the query. This is subtly different from how
  818. qtype "ANY" and qclass "ANY" work in Unicast DNS.
  819. A common misconception is that a Unicast DNS query for qtype "ANY"
  820. will elicit a response containing all matching records. This is
  821. incorrect. If there are any records that match the query, the
  822. response is required only to contain at least one of them, not
  823. necessarily all of them.
  824. This somewhat surprising behavior is commonly seen with caching
  825. (i.e., "recursive") name servers. If a caching server receives a
  826. qtype "ANY" query for which it has at least one valid answer, it is
  827. allowed to return only those matching answers it happens to have
  828. already in its cache, and it is not required to reconsult the
  829. authoritative name server to check if there are any more records that
  830. also match the qtype "ANY" query.
  831. For example, one might imagine that a query for qtype "ANY" for name
  832. "host.example.com" would return both the IPv4 (A) and the IPv6 (AAAA)
  833. address records for that host. In reality, what happens is that it
  834. depends on the history of what queries have been previously received
  835. by intervening caching servers. If a caching server has no records
  836. for "host.example.com", then it will consult another server (usually
  837. Cheshire & Krochmal Standards Track [Page 20]
  838. RFC 6762 Multicast DNS February 2013
  839. the authoritative name server for the name in question), and, in that
  840. case, it will typically return all IPv4 and IPv6 address records.
  841. However, if some other host has recently done a query for qtype "A"
  842. for name "host.example.com", so that the caching server already has
  843. IPv4 address records for "host.example.com" in its cache but no IPv6
  844. address records, then it will return only the IPv4 address records it
  845. already has cached, and no IPv6 address records.
  846. Multicast DNS does not share this property that qtype "ANY" and
  847. qclass "ANY" queries return some undefined subset of the matching
  848. records. When responding to queries using qtype "ANY" (255) and/or
  849. qclass "ANY" (255), a Multicast DNS responder MUST respond with *ALL*
  850. of its records that match the query.
  851. 6.6. Cooperating Multicast DNS Responders
  852. If a Multicast DNS responder ("A") observes some other Multicast DNS
  853. responder ("B") send a Multicast DNS response message containing a
  854. resource record with the same name, rrtype, and rrclass as one of A's
  855. resource records, but *different* rdata, then:
  856. o If A's resource record is intended to be a shared resource
  857. record, then this is no conflict, and no action is required.
  858. o If A's resource record is intended to be a member of a unique
  859. resource record set owned solely by that responder, then this is
  860. a conflict and MUST be handled as described in Section 9,
  861. "Conflict Resolution".
  862. If a Multicast DNS responder ("A") observes some other Multicast DNS
  863. responder ("B") send a Multicast DNS response message containing a
  864. resource record with the same name, rrtype, and rrclass as one of A's
  865. resource records, and *identical* rdata, then:
  866. o If the TTL of B's resource record given in the message is at
  867. least half the true TTL from A's point of view, then no action
  868. is required.
  869. o If the TTL of B's resource record given in the message is less
  870. than half the true TTL from A's point of view, then A MUST mark
  871. its record to be announced via multicast. Queriers receiving
  872. the record from B would use the TTL given by B and, hence, may
  873. delete the record sooner than A expects. By sending its own
  874. multicast response correcting the TTL, A ensures that the record
  875. will be retained for the desired time.
  876. Cheshire & Krochmal Standards Track [Page 21]
  877. RFC 6762 Multicast DNS February 2013
  878. These rules allow multiple Multicast DNS responders to offer the same
  879. data on the network (perhaps for fault-tolerance reasons) without
  880. conflicting with each other.
  881. 6.7. Legacy Unicast Responses
  882. If the source UDP port in a received Multicast DNS query is not port
  883. 5353, this indicates that the querier originating the query is a
  884. simple resolver such as described in Section 5.1, "One-Shot Multicast
  885. DNS Queries", which does not fully implement all of Multicast DNS.
  886. In this case, the Multicast DNS responder MUST send a UDP response
  887. directly back to the querier, via unicast, to the query packet's
  888. source IP address and port. This unicast response MUST be a
  889. conventional unicast response as would be generated by a conventional
  890. Unicast DNS server; for example, it MUST repeat the query ID and the
  891. question given in the query message. In addition, the cache-flush
  892. bit described in Section 10.2, "Announcements to Flush Outdated Cache
  893. Entries", MUST NOT be set in legacy unicast responses.
  894. The resource record TTL given in a legacy unicast response SHOULD NOT
  895. be greater than ten seconds, even if the true TTL of the Multicast
  896. DNS resource record is higher. This is because Multicast DNS
  897. responders that fully participate in the protocol use the cache
  898. coherency mechanisms described in Section 10, "Resource Record TTL
  899. Values and Cache Coherency", to update and invalidate stale data.
  900. Were unicast responses sent to legacy resolvers to use the same high
  901. TTLs, these legacy resolvers, which do not implement these cache
  902. coherency mechanisms, could retain stale cached resource record data
  903. long after it is no longer valid.
  904. 7. Traffic Reduction
  905. A variety of techniques are used to reduce the amount of traffic on
  906. the network.
  907. 7.1. Known-Answer Suppression
  908. When a Multicast DNS querier sends a query to which it already knows
  909. some answers, it populates the Answer Section of the DNS query
  910. message with those answers.
  911. Generally, this applies only to Shared records, not Unique records,
  912. since if a Multicast DNS querier already has at least one Unique
  913. record in its cache then it should not be expecting further different
  914. answers to this question, since the Unique record(s) it already has
  915. comprise the complete answer, so it has no reason to be sending the
  916. query at all. In contrast, having some Shared records in its cache
  917. does not necessarily imply that a Multicast DNS querier will not
  918. Cheshire & Krochmal Standards Track [Page 22]
  919. RFC 6762 Multicast DNS February 2013
  920. receive further answers to this query, and it is in this case that it
  921. is beneficial to use the Known-Answer list to suppress repeated
  922. sending of redundant answers that the querier already knows.
  923. A Multicast DNS responder MUST NOT answer a Multicast DNS query if
  924. the answer it would give is already included in the Answer Section
  925. with an RR TTL at least half the correct value. If the RR TTL of the
  926. answer as given in the Answer Section is less than half of the true
  927. RR TTL as known by the Multicast DNS responder, the responder MUST
  928. send an answer so as to update the querier's cache before the record
  929. becomes in danger of expiration.
  930. Because a Multicast DNS responder will respond if the remaining TTL
  931. given in the Known-Answer list is less than half the true TTL, it is
  932. superfluous for the querier to include such records in the Known-
  933. Answer list. Therefore, a Multicast DNS querier SHOULD NOT include
  934. records in the Known-Answer list whose remaining TTL is less than
  935. half of their original TTL. Doing so would simply consume space in
  936. the message without achieving the goal of suppressing responses and
  937. would, therefore, be a pointless waste of network capacity.
  938. A Multicast DNS querier MUST NOT cache resource records observed in
  939. the Known-Answer Section of other Multicast DNS queries. The Answer
  940. Section of Multicast DNS queries is not authoritative. By placing
  941. information in the Answer Section of a Multicast DNS query, the
  942. querier is stating that it *believes* the information to be true. It
  943. is not asserting that the information *is* true. Some of those
  944. records may have come from other hosts that are no longer on the
  945. network. Propagating that stale information to other Multicast DNS
  946. queriers on the network would not be helpful.
  947. 7.2. Multipacket Known-Answer Suppression
  948. Sometimes a Multicast DNS querier will already have too many answers
  949. to fit in the Known-Answer Section of its query packets. In this
  950. case, it should issue a Multicast DNS query containing a question and
  951. as many Known-Answer records as will fit. It MUST then set the TC
  952. (Truncated) bit in the header before sending the query. It MUST
  953. immediately follow the packet with another query packet containing no
  954. questions and as many more Known-Answer records as will fit. If
  955. there are still too many records remaining to fit in the packet, it
  956. again sets the TC bit and continues until all the Known-Answer
  957. records have been sent.
  958. A Multicast DNS responder seeing a Multicast DNS query with the TC
  959. bit set defers its response for a time period randomly selected in
  960. the interval 400-500 ms. This gives the Multicast DNS querier time
  961. to send additional Known-Answer packets before the responder
  962. Cheshire & Krochmal Standards Track [Page 23]
  963. RFC 6762 Multicast DNS February 2013
  964. responds. If the responder sees any of its answers listed in the
  965. Known-Answer lists of subsequent packets from the querying host, it
  966. MUST delete that answer from the list of answers it is planning to
  967. give (provided that no other host on the network has also issued a
  968. query for that record and is waiting to receive an answer).
  969. If the responder receives additional Known-Answer packets with the TC
  970. bit set, it SHOULD extend the delay as necessary to ensure a pause of
  971. 400-500 ms after the last such packet before it sends its answer.
  972. This opens the potential risk that a continuous stream of Known-
  973. Answer packets could, theoretically, prevent a responder from
  974. answering indefinitely. In practice, answers are never actually
  975. delayed significantly, and should a situation arise where significant
  976. delays did happen, that would be a scenario where the network is so
  977. overloaded that it would be desirable to err on the side of caution.
  978. The consequence of delaying an answer may be that it takes a user
  979. longer than usual to discover all the services on the local network;
  980. in contrast, the consequence of incorrectly answering before all the
  981. Known-Answer packets have been received would be wasted capacity
  982. sending unnecessary answers on an already overloaded network. In
  983. this (rare) situation, sacrificing speed to preserve reliable network
  984. operation is the right trade-off.
  985. 7.3. Duplicate Question Suppression
  986. If a host is planning to transmit (or retransmit) a query, and it
  987. sees another host on the network send a query containing the same
  988. "QM" question, and the Known-Answer Section of that query does not
  989. contain any records that this host would not also put in its own
  990. Known-Answer Section, then this host SHOULD treat its own query as
  991. having been sent. When multiple queriers on the network are querying
  992. for the same resource records, there is no need for them to all be
  993. repeatedly asking the same question.
  994. 7.4. Duplicate Answer Suppression
  995. If a host is planning to send an answer, and it sees another host on
  996. the network send a response message containing the same answer
  997. record, and the TTL in that record is not less than the TTL this host
  998. would have given, then this host SHOULD treat its own answer as
  999. having been sent, and not also send an identical answer itself. When
  1000. multiple responders on the network have the same data, there is no
  1001. need for all of them to respond.
  1002. Cheshire & Krochmal Standards Track [Page 24]
  1003. RFC 6762 Multicast DNS February 2013
  1004. The opportunity for duplicate answer suppression occurs when a host
  1005. has received a query, and is delaying its response for some pseudo-
  1006. random interval up to 500 ms, as described elsewhere in this
  1007. document, and then, before the host sends its response, it sees some
  1008. other host on the network send a response message containing the same
  1009. answer record.
  1010. This feature is particularly useful when Multicast DNS Proxy Servers
  1011. are in use, where there could be more than one proxy on the network
  1012. giving Multicast DNS answers on behalf of some other host (e.g.,
  1013. because that other host is currently asleep and is not itself
  1014. responding to queries).
  1015. 8. Probing and Announcing on Startup
  1016. Typically a Multicast DNS responder should have, at the very least,
  1017. address records for all of its active interfaces. Creating and
  1018. advertising an HINFO record on each interface as well can be useful
  1019. to network administrators.
  1020. Whenever a Multicast DNS responder starts up, wakes up from sleep,
  1021. receives an indication of a network interface "Link Change" event, or
  1022. has any other reason to believe that its network connectivity may
  1023. have changed in some relevant way, it MUST perform the two startup
  1024. steps below: Probing (Section 8.1) and Announcing (Section 8.3).
  1025. 8.1. Probing
  1026. The first startup step is that, for all those resource records that a
  1027. Multicast DNS responder desires to be unique on the local link, it
  1028. MUST send a Multicast DNS query asking for those resource records, to
  1029. see if any of them are already in use. The primary example of this
  1030. is a host's address records, which map its unique host name to its
  1031. unique IPv4 and/or IPv6 addresses. All probe queries SHOULD be done
  1032. using the desired resource record name and class (usually class 1,
  1033. "Internet"), and query type "ANY" (255), to elicit answers for all
  1034. types of records with that name. This allows a single question to be
  1035. used in place of several questions, which is more efficient on the
  1036. network. It also allows a host to verify exclusive ownership of a
  1037. name for all rrtypes, which is desirable in most cases. It would be
  1038. confusing, for example, if one host owned the "A" record for
  1039. "myhost.local.", but a different host owned the "AAAA" record for
  1040. that name.
  1041. Cheshire & Krochmal Standards Track [Page 25]
  1042. RFC 6762 Multicast DNS February 2013
  1043. The ability to place more than one question in a Multicast DNS query
  1044. is useful here, because it can allow a host to use a single message
  1045. to probe for all of its resource records instead of needing a
  1046. separate message for each. For example, a host can simultaneously
  1047. probe for uniqueness of its "A" record and all its SRV records
  1048. [RFC6763] in the same query message.
  1049. When ready to send its Multicast DNS probe packet(s) the host should
  1050. first wait for a short random delay time, uniformly distributed in
  1051. the range 0-250 ms. This random delay is to guard against the case
  1052. where several devices are powered on simultaneously, or several
  1053. devices are connected to an Ethernet hub, which is then powered on,
  1054. or some other external event happens that might cause a group of
  1055. hosts to all send synchronized probes.
  1056. 250 ms after the first query, the host should send a second; then,
  1057. 250 ms after that, a third. If, by 250 ms after the third probe, no
  1058. conflicting Multicast DNS responses have been received, the host may
  1059. move to the next step, announcing. (Note that probing is the one
  1060. exception from the normal rule that there should be at least one
  1061. second between repetitions of the same question, and the interval
  1062. between subsequent repetitions should at least double.)
  1063. When sending probe queries, a host MUST NOT consult its cache for
  1064. potential answers. Only conflicting Multicast DNS responses received
  1065. "live" from the network are considered valid for the purposes of
  1066. determining whether probing has succeeded or failed.
  1067. In order to allow services to announce their presence without
  1068. unreasonable delay, the time window for probing is intentionally set
  1069. quite short. As a result of this, from the time the first probe
  1070. packet is sent, another device on the network using that name has
  1071. just 750 ms to respond to defend its name. On networks that are
  1072. slow, or busy, or both, it is possible for round-trip latency to
  1073. account for a few hundred milliseconds, and software delays in slow
  1074. devices can add additional delay. Hence, it is important that when a
  1075. device receives a probe query for a name that it is currently using,
  1076. it SHOULD generate its response to defend that name immediately and
  1077. send it as quickly as possible. The usual rules about random delays
  1078. before responding, to avoid sudden bursts of simultaneous answers
  1079. from different hosts, do not apply here since normally at most one
  1080. host should ever respond to a given probe question. Even when a
  1081. single DNS query message contains multiple probe questions, it would
  1082. be unusual for that message to elicit a defensive response from more
  1083. than one other host. Because of the mDNS multicast rate-limiting
  1084. Cheshire & Krochmal Standards Track [Page 26]
  1085. RFC 6762 Multicast DNS February 2013
  1086. rules, the probes SHOULD be sent as "QU" questions with the unicast-
  1087. response bit set, to allow a defending host to respond immediately
  1088. via unicast, instead of potentially having to wait before replying
  1089. via multicast.
  1090. During probing, from the time the first probe packet is sent until
  1091. 250 ms after the third probe, if any conflicting Multicast DNS
  1092. response is received, then the probing host MUST defer to the
  1093. existing host, and SHOULD choose new names for some or all of its
  1094. resource records as appropriate. Apparently conflicting Multicast
  1095. DNS responses received *before* the first probe packet is sent MUST
  1096. be silently ignored (see discussion of stale probe packets in Section
  1097. 8.2, "Simultaneous Probe Tiebreaking", below). In the case of a host
  1098. probing using query type "ANY" as recommended above, any answer
  1099. containing a record with that name, of any type, MUST be considered a
  1100. conflicting response and handled accordingly.
  1101. If fifteen conflicts occur within any ten-second period, then the
  1102. host MUST wait at least five seconds before each successive
  1103. additional probe attempt. This is to help ensure that, in the event
  1104. of software bugs or other unanticipated problems, errant hosts do not
  1105. flood the network with a continuous stream of multicast traffic. For
  1106. very simple devices, a valid way to comply with this requirement is
  1107. to always wait five seconds after any failed probe attempt before
  1108. trying again.
  1109. If a responder knows by other means that its unique resource record
  1110. set name, rrtype, and rrclass cannot already be in use by any other
  1111. responder on the network, then it SHOULD skip the probing step for
  1112. that resource record set. For example, when creating the reverse
  1113. address mapping PTR records, the host can reasonably assume that no
  1114. other host will be trying to create those same PTR records, since
  1115. that would imply that the two hosts were trying to use the same IP
  1116. address, and if that were the case, the two hosts would be suffering
  1117. communication problems beyond the scope of what Multicast DNS is
  1118. designed to solve. Similarly, if a responder is acting as a proxy,
  1119. taking over from another Multicast DNS responder that has already
  1120. verified the uniqueness of the record, then the proxy SHOULD NOT
  1121. repeat the probing step for those records.
  1122. 8.2. Simultaneous Probe Tiebreaking
  1123. The astute reader will observe that there is a race condition
  1124. inherent in the previous description. If two hosts are probing for
  1125. the same name simultaneously, neither will receive any response to
  1126. the probe, and the hosts could incorrectly conclude that they may
  1127. both proceed to use the name. To break this symmetry, each host
  1128. populates the query message's Authority Section with the record or
  1129. Cheshire & Krochmal Standards Track [Page 27]
  1130. RFC 6762 Multicast DNS February 2013
  1131. records with the rdata that it would be proposing to use, should its
  1132. probing be successful. The Authority Section is being used here in a
  1133. way analogous to the way it is used as the "Update Section" in a DNS
  1134. Update message [RFC2136] [RFC3007].
  1135. When a host is probing for a group of related records with the same
  1136. name (e.g., the SRV and TXT record describing a DNS-SD service), only
  1137. a single question need be placed in the Question Section, since query
  1138. type "ANY" (255) is used, which will elicit answers for all records
  1139. with that name. However, for tiebreaking to work correctly in all
  1140. cases, the Authority Section must contain *all* the records and
  1141. proposed rdata being probed for uniqueness.
  1142. When a host that is probing for a record sees another host issue a
  1143. query for the same record, it consults the Authority Section of that
  1144. query. If it finds any resource record(s) there which answers the
  1145. query, then it compares the data of that (those) resource record(s)
  1146. with its own tentative data. We consider first the simple case of a
  1147. host probing for a single record, receiving a simultaneous probe from
  1148. another host also probing for a single record. The two records are
  1149. compared and the lexicographically later data wins. This means that
  1150. if the host finds that its own data is lexicographically later, it
  1151. simply ignores the other host's probe. If the host finds that its
  1152. own data is lexicographically earlier, then it defers to the winning
  1153. host by waiting one second, and then begins probing for this record
  1154. again. The logic for waiting one second and then trying again is to
  1155. guard against stale probe packets on the network (possibly even stale
  1156. probe packets sent moments ago by this host itself, before some
  1157. configuration change, which may be echoed back after a short delay by
  1158. some Ethernet switches and some 802.11 base stations). If the
  1159. winning simultaneous probe was from a real other host on the network,
  1160. then after one second it will have completed its probing, and will
  1161. answer subsequent probes. If the apparently winning simultaneous
  1162. probe was in fact just an old stale packet on the network (maybe from
  1163. the host itself), then when it retries its probing in one second, its
  1164. probes will go unanswered, and it will successfully claim the name.
  1165. The determination of "lexicographically later" is performed by first
  1166. comparing the record class (excluding the cache-flush bit described
  1167. in Section 10.2), then the record type, then raw comparison of the
  1168. binary content of the rdata without regard for meaning or structure.
  1169. If the record classes differ, then the numerically greater class is
  1170. considered "lexicographically later". Otherwise, if the record types
  1171. differ, then the numerically greater type is considered
  1172. "lexicographically later". If the rrtype and rrclass both match,
  1173. then the rdata is compared.
  1174. Cheshire & Krochmal Standards Track [Page 28]
  1175. RFC 6762 Multicast DNS February 2013
  1176. In the case of resource records containing rdata that is subject to
  1177. name compression [RFC1035], the names MUST be uncompressed before
  1178. comparison. (The details of how a particular name is compressed is
  1179. an artifact of how and where the record is written into the DNS
  1180. message; it is not an intrinsic property of the resource record
  1181. itself.)
  1182. The bytes of the raw uncompressed rdata are compared in turn,
  1183. interpreting the bytes as eight-bit UNSIGNED values, until a byte is
  1184. found whose value is greater than that of its counterpart (in which
  1185. case, the rdata whose byte has the greater value is deemed
  1186. lexicographically later) or one of the resource records runs out of
  1187. rdata (in which case, the resource record which still has remaining
  1188. data first is deemed lexicographically later). The following is an
  1189. example of a conflict:
  1190. MyPrinter.local. A 169.254.99.200
  1191. MyPrinter.local. A 169.254.200.50
  1192. In this case, 169.254.200.50 is lexicographically later (the third
  1193. byte, with value 200, is greater than its counterpart with value 99),
  1194. so it is deemed the winner.
  1195. Note that it is vital that the bytes are interpreted as UNSIGNED
  1196. values in the range 0-255, or the wrong outcome may result. In the
  1197. example above, if the byte with value 200 had been incorrectly
  1198. interpreted as a signed eight-bit value, then it would be interpreted
  1199. as value -56, and the wrong address record would be deemed the
  1200. winner.
  1201. 8.2.1. Simultaneous Probe Tiebreaking for Multiple Records
  1202. When a host is probing for a set of records with the same name, or a
  1203. message is received containing multiple tiebreaker records answering
  1204. a given probe question in the Question Section, the host's records
  1205. and the tiebreaker records from the message are each sorted into
  1206. order, and then compared pairwise, using the same comparison
  1207. technique described above, until a difference is found.
  1208. The records are sorted using the same lexicographical order as
  1209. described above, that is, if the record classes differ, the record
  1210. with the lower class number comes first. If the classes are the same
  1211. but the rrtypes differ, the record with the lower rrtype number comes
  1212. first. If the class and rrtype match, then the rdata is compared
  1213. bytewise until a difference is found. For example, in the common
  1214. case of advertising DNS-SD services with a TXT record and an SRV
  1215. record, the TXT record comes first (the rrtype value for TXT is 16)
  1216. and the SRV record comes second (the rrtype value for SRV is 33).
  1217. Cheshire & Krochmal Standards Track [Page 29]
  1218. RFC 6762 Multicast DNS February 2013
  1219. When comparing the records, if the first records match perfectly,
  1220. then the second records are compared, and so on. If either list of
  1221. records runs out of records before any difference is found, then the
  1222. list with records remaining is deemed to have won the tiebreak. If
  1223. both lists run out of records at the same time without any difference
  1224. being found, then this indicates that two devices are advertising
  1225. identical sets of records, as is sometimes done for fault tolerance,
  1226. and there is, in fact, no conflict.
  1227. 8.3. Announcing
  1228. The second startup step is that the Multicast DNS responder MUST send
  1229. an unsolicited Multicast DNS response containing, in the Answer
  1230. Section, all of its newly registered resource records (both shared
  1231. records, and unique records that have completed the probing step).
  1232. If there are too many resource records to fit in a single packet,
  1233. multiple packets should be used.
  1234. In the case of shared records (e.g., the PTR records used by DNS-
  1235. Based Service Discovery [RFC6763]), the records are simply placed as
  1236. is into the Answer Section of the DNS response.
  1237. In the case of records that have been verified to be unique in the
  1238. previous step, they are placed into the Answer Section of the DNS
  1239. response with the most significant bit of the rrclass set to one.
  1240. The most significant bit of the rrclass for a record in the Answer
  1241. Section of a response message is the Multicast DNS cache-flush bit
  1242. and is discussed in more detail below in Section 10.2, "Announcements
  1243. to Flush Outdated Cache Entries".
  1244. The Multicast DNS responder MUST send at least two unsolicited
  1245. responses, one second apart. To provide increased robustness against
  1246. packet loss, a responder MAY send up to eight unsolicited responses,
  1247. provided that the interval between unsolicited responses increases by
  1248. at least a factor of two with every response sent.
  1249. A Multicast DNS responder MUST NOT send announcements in the absence
  1250. of information that its network connectivity may have changed in some
  1251. relevant way. In particular, a Multicast DNS responder MUST NOT send
  1252. regular periodic announcements as a matter of course.
  1253. Whenever a Multicast DNS responder receives any Multicast DNS
  1254. response (solicited or otherwise) containing a conflicting resource
  1255. record, the conflict MUST be resolved as described in Section 9,
  1256. "Conflict Resolution".
  1257. Cheshire & Krochmal Standards Track [Page 30]
  1258. RFC 6762 Multicast DNS February 2013
  1259. 8.4. Updating
  1260. At any time, if the rdata of any of a host's Multicast DNS records
  1261. changes, the host MUST repeat the Announcing step described above to
  1262. update neighboring caches. For example, if any of a host's IP
  1263. addresses change, it MUST re-announce those address records. The
  1264. host does not need to repeat the Probing step because it has already
  1265. established unique ownership of that name.
  1266. In the case of shared records, a host MUST send a "goodbye"
  1267. announcement with RR TTL zero (see Section 10.1, "Goodbye Packets")
  1268. for the old rdata, to cause it to be deleted from peer caches, before
  1269. announcing the new rdata. In the case of unique records, a host
  1270. SHOULD omit the "goodbye" announcement, since the cache-flush bit on
  1271. the newly announced records will cause old rdata to be flushed from
  1272. peer caches anyway.
  1273. A host may update the contents of any of its records at any time,
  1274. though a host SHOULD NOT update records more frequently than ten
  1275. times per minute. Frequent rapid updates impose a burden on the
  1276. network. If a host has information to disseminate which changes more
  1277. frequently than ten times per minute, then it may be more appropriate
  1278. to design a protocol for that specific purpose.
  1279. 9. Conflict Resolution
  1280. A conflict occurs when a Multicast DNS responder has a unique record
  1281. for which it is currently authoritative, and it receives a Multicast
  1282. DNS response message containing a record with the same name, rrtype
  1283. and rrclass, but inconsistent rdata. What may be considered
  1284. inconsistent is context sensitive, except that resource records with
  1285. identical rdata are never considered inconsistent, even if they
  1286. originate from different hosts. This is to permit use of proxies and
  1287. other fault-tolerance mechanisms that may cause more than one
  1288. responder to be capable of issuing identical answers on the network.
  1289. A common example of a resource record type that is intended to be
  1290. unique, not shared between hosts, is the address record that maps a
  1291. host's name to its IP address. Should a host witness another host
  1292. announce an address record with the same name but a different IP
  1293. address, then that is considered inconsistent, and that address
  1294. record is considered to be in conflict.
  1295. Whenever a Multicast DNS responder receives any Multicast DNS
  1296. response (solicited or otherwise) containing a conflicting resource
  1297. record in any of the Resource Record Sections, the Multicast DNS
  1298. responder MUST immediately reset its conflicted unique record to
  1299. probing state, and go through the startup steps described above in
  1300. Cheshire & Krochmal Standards Track [Page 31]
  1301. RFC 6762 Multicast DNS February 2013
  1302. Section 8, "Probing and Announcing on Startup". The protocol used in
  1303. the Probing phase will determine a winner and a loser, and the loser
  1304. MUST cease using the name, and reconfigure.
  1305. It is very important that any host receiving a resource record that
  1306. conflicts with one of its own MUST take action as described above.
  1307. In the case of two hosts using the same host name, where one has been
  1308. configured to require a unique host name and the other has not, the
  1309. one that has not been configured to require a unique host name will
  1310. not perceive any conflict, and will not take any action. By
  1311. reverting to Probing state, the host that desires a unique host name
  1312. will go through the necessary steps to ensure that a unique host name
  1313. is obtained.
  1314. The recommended course of action after probing and failing is as
  1315. follows:
  1316. 1. Programmatically change the resource record name in an attempt
  1317. to find a new name that is unique. This could be done by
  1318. adding some further identifying information (e.g., the model
  1319. name of the hardware) if it is not already present in the name,
  1320. or appending the digit "2" to the name, or incrementing a
  1321. number at the end of the name if one is already present.
  1322. 2. Probe again, and repeat as necessary until a unique name is
  1323. found.
  1324. 3. Once an available unique name has been determined, by probing
  1325. without receiving any conflicting response, record this newly
  1326. chosen name in persistent storage so that the device will use
  1327. the same name the next time it is power-cycled.
  1328. 4. Display a message to the user or operator informing them of the
  1329. name change. For example:
  1330. The name "Bob's Music" is in use by another music server on
  1331. the network. Your music collection has been renamed to
  1332. "Bob's Music (2)". If you want to change this name, use
  1333. [describe appropriate menu item or preference dialog here].
  1334. The details of how the user or operator is informed of the new
  1335. name depends on context. A desktop computer with a screen
  1336. might put up a dialog box. A headless server in the closet may
  1337. write a message to a log file, or use whatever mechanism
  1338. (email, SNMP trap, etc.) it uses to inform the administrator of
  1339. error conditions. On the other hand, a headless server in the
  1340. closet may not inform the user at all -- if the user cares,
  1341. Cheshire & Krochmal Standards Track [Page 32]
  1342. RFC 6762 Multicast DNS February 2013
  1343. they will notice the name has changed, and connect to the
  1344. server in the usual way (e.g., via web browser) to configure a
  1345. new name.
  1346. 5. After one minute of probing, if the Multicast DNS responder has
  1347. been unable to find any unused name, it should log an error
  1348. message to inform the user or operator of this fact. This
  1349. situation should never occur in normal operation. The only
  1350. situations that would cause this to happen would be either a
  1351. deliberate denial-of-service attack, or some kind of very
  1352. obscure hardware or software bug that acts like a deliberate
  1353. denial-of-service attack.
  1354. These considerations apply to address records (i.e., host names) and
  1355. to all resource records where uniqueness (or maintenance of some
  1356. other defined constraint) is desired.
  1357. 10. Resource Record TTL Values and Cache Coherency
  1358. As a general rule, the recommended TTL value for Multicast DNS
  1359. resource records with a host name as the resource record's name
  1360. (e.g., A, AAAA, HINFO) or a host name contained within the resource
  1361. record's rdata (e.g., SRV, reverse mapping PTR record) SHOULD be 120
  1362. seconds.
  1363. The recommended TTL value for other Multicast DNS resource records is
  1364. 75 minutes.
  1365. A querier with an active outstanding query will issue a query message
  1366. when one or more of the resource records in its cache are 80% of the
  1367. way to expiry. If the TTL on those records is 75 minutes, this
  1368. ongoing cache maintenance process yields a steady-state query rate of
  1369. one query every 60 minutes.
  1370. Any distributed cache needs a cache coherency protocol. If Multicast
  1371. DNS resource records follow the recommendation and have a TTL of 75
  1372. minutes, that means that stale data could persist in the system for a
  1373. little over an hour. Making the default RR TTL significantly lower
  1374. would reduce the lifetime of stale data, but would produce too much
  1375. extra traffic on the network. Various techniques are available to
  1376. minimize the impact of such stale data, outlined in the five
  1377. subsections below.
  1378. 10.1. Goodbye Packets
  1379. In the case where a host knows that certain resource record data is
  1380. about to become invalid (for example, when the host is undergoing a
  1381. clean shutdown), the host SHOULD send an unsolicited Multicast DNS
  1382. Cheshire & Krochmal Standards Track [Page 33]
  1383. RFC 6762 Multicast DNS February 2013
  1384. response packet, giving the same resource record name, rrtype,
  1385. rrclass, and rdata, but an RR TTL of zero. This has the effect of
  1386. updating the TTL stored in neighboring hosts' cache entries to zero,
  1387. causing that cache entry to be promptly deleted.
  1388. Queriers receiving a Multicast DNS response with a TTL of zero SHOULD
  1389. NOT immediately delete the record from the cache, but instead record
  1390. a TTL of 1 and then delete the record one second later. In the case
  1391. of multiple Multicast DNS responders on the network described in
  1392. Section 6.6 above, if one of the responders shuts down and
  1393. incorrectly sends goodbye packets for its records, it gives the other
  1394. cooperating responders one second to send out their own response to
  1395. "rescue" the records before they expire and are deleted.
  1396. 10.2. Announcements to Flush Outdated Cache Entries
  1397. Whenever a host has a resource record with new data, or with what
  1398. might potentially be new data (e.g., after rebooting, waking from
  1399. sleep, connecting to a new network link, or changing IP address), the
  1400. host needs to inform peers of that new data. In cases where the host
  1401. has not been continuously connected and participating on the network
  1402. link, it MUST first probe to re-verify uniqueness of its unique
  1403. records, as described above in Section 8.1, "Probing".
  1404. Having completed the Probing step, if necessary, the host MUST then
  1405. send a series of unsolicited announcements to update cache entries in
  1406. its neighbor hosts. In these unsolicited announcements, if the
  1407. record is one that has been verified unique, the host sets the most
  1408. significant bit of the rrclass field of the resource record. This
  1409. bit, the cache-flush bit, tells neighboring hosts that this is not a
  1410. shared record type. Instead of merging this new record additively
  1411. into the cache in addition to any previous records with the same
  1412. name, rrtype, and rrclass, all old records with that name, rrtype,
  1413. and rrclass that were received more than one second ago are declared
  1414. invalid, and marked to expire from the cache in one second.
  1415. The semantics of the cache-flush bit are as follows: normally when a
  1416. resource record appears in a Resource Record Section of the DNS
  1417. response it means, "This is an assertion that this information is
  1418. true". When a resource record appears in a Resource Record Section
  1419. of the DNS response with the cache-flush bit set, it means, "This is
  1420. an assertion that this information is the truth and the whole truth,
  1421. and anything you may have heard more than a second ago regarding
  1422. records of this name/rrtype/rrclass is no longer true".
  1423. To accommodate the case where the set of records from one host
  1424. constituting a single unique RRSet is too large to fit in a single
  1425. packet, only cache records that are more than one second old are
  1426. Cheshire & Krochmal Standards Track [Page 34]
  1427. RFC 6762 Multicast DNS February 2013
  1428. flushed. This allows the announcing host to generate a quick burst
  1429. of packets back-to-back on the wire containing all the members of the
  1430. RRSet. When receiving records with the cache-flush bit set, all
  1431. records older than one second are marked to be deleted one second in
  1432. the future. One second after the end of the little packet burst, any
  1433. records not represented within that packet burst will then be expired
  1434. from all peer caches.
  1435. Any time a host sends a response packet containing some members of a
  1436. unique RRSet, it MUST send the entire RRSet, preferably in a single
  1437. packet, or if the entire RRSet will not fit in a single packet, in a
  1438. quick burst of packets sent as close together as possible. The host
  1439. MUST set the cache-flush bit on all members of the unique RRSet.
  1440. Another reason for waiting one second before deleting stale records
  1441. from the cache is to accommodate bridged networks. For example, a
  1442. host's address record announcement on a wireless interface may be
  1443. bridged onto a wired Ethernet and may cause that same host's Ethernet
  1444. address records to be flushed from peer caches. The one-second delay
  1445. gives the host the chance to see its own announcement arrive on the
  1446. wired Ethernet, and immediately re-announce its Ethernet interface's
  1447. address records so that both sets remain valid and live in peer
  1448. caches.
  1449. These rules, about when to set the cache-flush bit and about sending
  1450. the entire rrset, apply regardless of *why* the response message is
  1451. being generated. They apply to startup announcements as described in
  1452. Section 8.3, "Announcing", and to responses generated as a result of
  1453. receiving query messages.
  1454. The cache-flush bit is only set in records in the Resource Record
  1455. Sections of Multicast DNS responses sent to UDP port 5353.
  1456. The cache-flush bit MUST NOT be set in any resource records in a
  1457. response message sent in legacy unicast responses to UDP ports other
  1458. than 5353.
  1459. The cache-flush bit MUST NOT be set in any resource records in the
  1460. Known-Answer list of any query message.
  1461. The cache-flush bit MUST NOT ever be set in any shared resource
  1462. record. To do so would cause all the other shared versions of this
  1463. resource record with different rdata from different responders to be
  1464. immediately deleted from all the caches on the network.
  1465. Cheshire & Krochmal Standards Track [Page 35]
  1466. RFC 6762 Multicast DNS February 2013
  1467. The cache-flush bit does *not* apply to questions listed in the
  1468. Question Section of a Multicast DNS message. The top bit of the
  1469. rrclass field in questions is used for an entirely different purpose
  1470. (see Section 5.4, "Questions Requesting Unicast Responses").
  1471. Note that the cache-flush bit is NOT part of the resource record
  1472. class. The cache-flush bit is the most significant bit of the second
  1473. 16-bit word of a resource record in a Resource Record Section of a
  1474. Multicast DNS message (the field conventionally referred to as the
  1475. rrclass field), and the actual resource record class is the least
  1476. significant fifteen bits of this field. There is no Multicast DNS
  1477. resource record class 0x8001. The value 0x8001 in the rrclass field
  1478. of a resource record in a Multicast DNS response message indicates a
  1479. resource record with class 1, with the cache-flush bit set. When
  1480. receiving a resource record with the cache-flush bit set,
  1481. implementations should take care to mask off that bit before storing
  1482. the resource record in memory, or otherwise ensure that it is given
  1483. the correct semantic interpretation.
  1484. The reuse of the top bit of the rrclass field only applies to
  1485. conventional resource record types that are subject to caching, not
  1486. to pseudo-RRs like OPT [RFC2671], TSIG [RFC2845], TKEY [RFC2930],
  1487. SIG0 [RFC2931], etc., that pertain only to a particular transport
  1488. level message and not to any actual DNS data. Since pseudo-RRs
  1489. should never go into the Multicast DNS cache, the concept of a cache-
  1490. flush bit for these types is not applicable. In particular, the
  1491. rrclass field of an OPT record encodes the sender's UDP payload size,
  1492. and should be interpreted as a sixteen-bit length value in the range
  1493. 0-65535, not a one-bit flag and a fifteen-bit length.
  1494. 10.3. Cache Flush on Topology change
  1495. If the hardware on a given host is able to indicate physical changes
  1496. of connectivity, then when the hardware indicates such a change, the
  1497. host should take this information into account in its Multicast DNS
  1498. cache management strategy. For example, a host may choose to
  1499. immediately flush all cache records received on a particular
  1500. interface when that cable is disconnected. Alternatively, a host may
  1501. choose to adjust the remaining TTL on all those records to a few
  1502. seconds so that if the cable is not reconnected quickly, those
  1503. records will expire from the cache.
  1504. Likewise, when a host reboots, wakes from sleep, or undergoes some
  1505. other similar discontinuous state change, the cache management
  1506. strategy should take that information into account.
  1507. Cheshire & Krochmal Standards Track [Page 36]
  1508. RFC 6762 Multicast DNS February 2013
  1509. 10.4. Cache Flush on Failure Indication
  1510. Sometimes a cache record can be determined to be stale when a client
  1511. attempts to use the rdata it contains, and the client finds that
  1512. rdata to be incorrect.
  1513. For example, the rdata in an address record can be determined to be
  1514. incorrect if attempts to contact that host fail, either because (for
  1515. an IPv4 address on a local subnet) ARP requests for that address go
  1516. unanswered, because (for an IPv6 address with an on-link prefix) ND
  1517. requests for that address go unanswered, or because (for an address
  1518. on a remote network) a router returns an ICMP "Host Unreachable"
  1519. error.
  1520. The rdata in an SRV record can be determined to be incorrect if
  1521. attempts to communicate with the indicated service at the host and
  1522. port number indicated are not successful.
  1523. The rdata in a DNS-SD PTR record can be determined to be incorrect if
  1524. attempts to look up the SRV record it references are not successful.
  1525. The software implementing the Multicast DNS resource record cache
  1526. should provide a mechanism so that clients detecting stale rdata can
  1527. inform the cache.
  1528. When the cache receives this hint that it should reconfirm some
  1529. record, it MUST issue two or more queries for the resource record in
  1530. dispute. If no response is received within ten seconds, then, even
  1531. though its TTL may indicate that it is not yet due to expire, that
  1532. record SHOULD be promptly flushed from the cache.
  1533. The end result of this is that if a printer suffers a sudden power
  1534. failure or other abrupt disconnection from the network, its name may
  1535. continue to appear in DNS-SD browser lists displayed on users'
  1536. screens. Eventually, that entry will expire from the cache
  1537. naturally, but if a user tries to access the printer before that
  1538. happens, the failure to successfully contact the printer will trigger
  1539. the more hasty demise of its cache entries. This is a sensible
  1540. trade-off between good user experience and good network efficiency.
  1541. If we were to insist that printers should disappear from the printer
  1542. list within 30 seconds of becoming unavailable, for all failure
  1543. modes, the only way to achieve this would be for the client to poll
  1544. the printer at least every 30 seconds, or for the printer to announce
  1545. its presence at least every 30 seconds, both of which would be an
  1546. unreasonable burden on most networks.
  1547. Cheshire & Krochmal Standards Track [Page 37]
  1548. RFC 6762 Multicast DNS February 2013
  1549. 10.5. Passive Observation Of Failures (POOF)
  1550. A host observes the multicast queries issued by the other hosts on
  1551. the network. One of the major benefits of also sending responses
  1552. using multicast is that it allows all hosts to see the responses (or
  1553. lack thereof) to those queries.
  1554. If a host sees queries, for which a record in its cache would be
  1555. expected to be given as an answer in a multicast response, but no
  1556. such answer is seen, then the host may take this as an indication
  1557. that the record may no longer be valid.
  1558. After seeing two or more of these queries, and seeing no multicast
  1559. response containing the expected answer within ten seconds, then even
  1560. though its TTL may indicate that it is not yet due to expire, that
  1561. record SHOULD be flushed from the cache. The host SHOULD NOT perform
  1562. its own queries to reconfirm that the record is truly gone. If every
  1563. host on a large network were to do this, it would cause a lot of
  1564. unnecessary multicast traffic. If host A sends multicast queries
  1565. that remain unanswered, then there is no reason to suppose that host
  1566. B or any other host is likely to be any more successful.
  1567. The previous section, "Cache Flush on Failure Indication", describes
  1568. a situation where a user trying to print discovers that the printer
  1569. is no longer available. By implementing the passive observation
  1570. described here, when one user fails to contact the printer, all hosts
  1571. on the network observe that failure and update their caches
  1572. accordingly.
  1573. 11. Source Address Check
  1574. All Multicast DNS responses (including responses sent via unicast)
  1575. SHOULD be sent with IP TTL set to 255. This is recommended to
  1576. provide backwards-compatibility with older Multicast DNS queriers
  1577. (implementing a draft version of this document, posted in February
  1578. 2004) that check the IP TTL on reception to determine whether the
  1579. packet originated on the local link. These older queriers discard
  1580. all packets with TTLs other than 255.
  1581. A host sending Multicast DNS queries to a link-local destination
  1582. address (including the 224.0.0.251 and FF02::FB link-local multicast
  1583. addresses) MUST only accept responses to that query that originate
  1584. from the local link, and silently discard any other response packets.
  1585. Without this check, it could be possible for remote rogue hosts to
  1586. send spoof answer packets (perhaps unicast to the victim host), which
  1587. the receiving machine could misinterpret as having originated on the
  1588. local link.
  1589. Cheshire & Krochmal Standards Track [Page 38]
  1590. RFC 6762 Multicast DNS February 2013
  1591. The test for whether a response originated on the local link is done
  1592. in two ways:
  1593. * All responses received with a destination address in the IP
  1594. header that is the mDNS IPv4 link-local multicast address
  1595. 224.0.0.251 or the mDNS IPv6 link-local multicast address
  1596. FF02::FB are necessarily deemed to have originated on the local
  1597. link, regardless of source IP address. This is essential to
  1598. allow devices to work correctly and reliably in unusual
  1599. configurations, such as multiple logical IP subnets overlayed on
  1600. a single link, or in cases of severe misconfiguration, where
  1601. devices are physically connected to the same link, but are
  1602. currently misconfigured with completely unrelated IP addresses
  1603. and subnet masks.
  1604. * For responses received with a unicast destination address in the
  1605. IP header, the source IP address in the packet is checked to see
  1606. if it is an address on a local subnet. An IPv4 source address
  1607. is determined to be on a local subnet if, for (one of) the
  1608. address(es) configured on the interface receiving the packet, (I
  1609. & M) == (P & M), where I and M are the interface address and
  1610. subnet mask respectively, P is the source IP address from the
  1611. packet, '&' represents the bitwise logical 'and' operation, and
  1612. '==' represents a bitwise equality test. An IPv6 source address
  1613. is determined to be on the local link if, for any of the on-link
  1614. IPv6 prefixes on the interface receiving the packet (learned via
  1615. IPv6 router advertisements or otherwise configured on the host),
  1616. the first 'n' bits of the IPv6 source address match the first
  1617. 'n' bits of the prefix address, where 'n' is the length of the
  1618. prefix being considered.
  1619. Since queriers will ignore responses apparently originating outside
  1620. the local subnet, a responder SHOULD avoid generating responses that
  1621. it can reasonably predict will be ignored. This applies particularly
  1622. in the case of overlayed subnets. If a responder receives a query
  1623. addressed to the mDNS IPv4 link-local multicast address 224.0.0.251,
  1624. from a source address not apparently on the same subnet as the
  1625. responder (or, in the case of IPv6, from a source IPv6 address for
  1626. which the responder does not have any address with the same prefix on
  1627. that interface), then even if the query indicates that a unicast
  1628. response is preferred (see Section 5.4, "Questions Requesting Unicast
  1629. Responses"), the responder SHOULD elect to respond by multicast
  1630. anyway, since it can reasonably predict that a unicast response with
  1631. an apparently non-local source address will probably be ignored.
  1632. Cheshire & Krochmal Standards Track [Page 39]
  1633. RFC 6762 Multicast DNS February 2013
  1634. 12. Special Characteristics of Multicast DNS Domains
  1635. Unlike conventional DNS names, names that end in ".local." have only
  1636. local significance. The same is true of names within the IPv4 link-
  1637. local reverse mapping domain "254.169.in-addr.arpa." and the IPv6
  1638. link-local reverse mapping domains "8.e.f.ip6.arpa.",
  1639. "9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.".
  1640. These names function primarily as protocol identifiers, rather than
  1641. as user-visible identifiers. Even though they may occasionally be
  1642. visible to end users, that is not their primary purpose. As such,
  1643. these names should be treated as opaque identifiers. In particular,
  1644. the string "local" should not be translated or localized into
  1645. different languages, much as the name "localhost" is not translated
  1646. or localized into different languages.
  1647. Conventional Unicast DNS seeks to provide a single unified namespace,
  1648. where a given DNS query yields the same answer no matter where on the
  1649. planet it is performed or to which recursive DNS server the query is
  1650. sent. In contrast, each IP link has its own private ".local.",
  1651. "254.169.in-addr.arpa." and IPv6 link-local reverse mapping
  1652. namespaces, and the answer to any query for a name within those
  1653. domains depends on where that query is asked. (This characteristic
  1654. is not unique to Multicast DNS. Although the original concept of DNS
  1655. was a single global namespace, in recent years, split views,
  1656. firewalls, intranets, DNS geolocation, and the like have increasingly
  1657. meant that the answer to a given DNS query has become dependent on
  1658. the location of the querier.)
  1659. The IPv4 name server address for a Multicast DNS domain is
  1660. 224.0.0.251. The IPv6 name server address for a Multicast DNS domain
  1661. is FF02::FB. These are multicast addresses; therefore, they identify
  1662. not a single host but a collection of hosts, working in cooperation
  1663. to maintain some reasonable facsimile of a competently managed DNS
  1664. zone. Conceptually, a Multicast DNS domain is a single DNS zone;
  1665. however, its server is implemented as a distributed process running
  1666. on a cluster of loosely cooperating CPUs rather than as a single
  1667. process running on a single CPU.
  1668. Multicast DNS domains are not delegated from their parent domain via
  1669. use of NS (Name Server) records, and there is also no concept of
  1670. delegation of subdomains within a Multicast DNS domain. Just because
  1671. a particular host on the network may answer queries for a particular
  1672. record type with the name "example.local." does not imply anything
  1673. about whether that host will answer for the name
  1674. "child.example.local.", or indeed for other record types with the
  1675. name "example.local.".
  1676. Cheshire & Krochmal Standards Track [Page 40]
  1677. RFC 6762 Multicast DNS February 2013
  1678. There are no NS records anywhere in Multicast DNS domains. Instead,
  1679. the Multicast DNS domains are reserved by IANA, and there is
  1680. effectively an implicit delegation of all Multicast DNS domains to
  1681. the 224.0.0.251:5353 and [FF02::FB]:5353 multicast groups, by virtue
  1682. of client software implementing the protocol rules specified in this
  1683. document.
  1684. Multicast DNS zones have no SOA (Start of Authority) record. A
  1685. conventional DNS zone's SOA record contains information such as the
  1686. email address of the zone administrator and the monotonically
  1687. increasing serial number of the last zone modification. There is no
  1688. single human administrator for any given Multicast DNS zone, so there
  1689. is no email address. Because the hosts managing any given Multicast
  1690. DNS zone are only loosely coordinated, there is no readily available
  1691. monotonically increasing serial number to determine whether or not
  1692. the zone contents have changed. A host holding part of the shared
  1693. zone could crash or be disconnected from the network at any time
  1694. without informing the other hosts. There is no reliable way to
  1695. provide a zone serial number that would, whenever such a crash or
  1696. disconnection occurred, immediately change to indicate that the
  1697. contents of the shared zone had changed.
  1698. Zone transfers are not possible for any Multicast DNS zone.
  1699. 13. Enabling and Disabling Multicast DNS
  1700. The option to fail-over to Multicast DNS for names not ending in
  1701. ".local." SHOULD be a user-configured option, and SHOULD be disabled
  1702. by default because of the possible security issues related to
  1703. unintended local resolution of apparently global names. Enabling
  1704. Multicast DNS for names not ending in ".local." may be appropriate on
  1705. a secure isolated network, or on some future network were machines
  1706. exclusively use DNSSEC for all DNS queries, and have Multicast DNS
  1707. responders capable of generating the appropriate cryptographic DNSSEC
  1708. signatures, thereby guarding against spoofing.
  1709. The option to look up unqualified (relative) names by appending
  1710. ".local." (or not) is controlled by whether ".local." appears (or
  1711. not) in the client's DNS search list.
  1712. No special control is needed for enabling and disabling Multicast DNS
  1713. for names explicitly ending with ".local." as entered by the user.
  1714. The user doesn't need a way to disable Multicast DNS for names ending
  1715. with ".local.", because if the user doesn't want to use Multicast
  1716. DNS, they can achieve this by simply not using those names. If a
  1717. user *does* enter a name ending in ".local.", then we can safely
  1718. assume the user's intention was probably that it should work. Having
  1719. user configuration options that can be (intentionally or
  1720. Cheshire & Krochmal Standards Track [Page 41]
  1721. RFC 6762 Multicast DNS February 2013
  1722. unintentionally) set so that local names don't work is just one more
  1723. way of frustrating the user's ability to perform the tasks they want,
  1724. perpetuating the view that, "IP networking is too complicated to
  1725. configure and too hard to use".
  1726. 14. Considerations for Multiple Interfaces
  1727. A host SHOULD defend its dot-local host name on all active interfaces
  1728. on which it is answering Multicast DNS queries.
  1729. In the event of a name conflict on *any* interface, a host should
  1730. configure a new host name, if it wishes to maintain uniqueness of its
  1731. host name.
  1732. A host may choose to use the same name (or set of names) for all of
  1733. its address records on all interfaces, or it may choose to manage its
  1734. Multicast DNS interfaces independently, potentially answering to a
  1735. different name (or set of names) on different interfaces.
  1736. Except in the case of proxying and other similar specialized uses,
  1737. addresses in IPv4 or IPv6 address records in Multicast DNS responses
  1738. MUST be valid for use on the interface on which the response is being
  1739. sent.
  1740. Just as the same link-local IP address may validly be in use
  1741. simultaneously on different links by different hosts, the same link-
  1742. local host name may validly be in use simultaneously on different
  1743. links, and this is not an error. A multihomed host with connections
  1744. to two different links may be able to communicate with two different
  1745. hosts that are validly using the same name. While this kind of name
  1746. duplication should be rare, it means that a host that wants to fully
  1747. support this case needs network programming APIs that allow
  1748. applications to specify on what interface to perform a link-local
  1749. Multicast DNS query, and to discover on what interface a Multicast
  1750. DNS response was received.
  1751. There is one other special precaution that multihomed hosts need to
  1752. take. It's common with today's laptop computers to have an Ethernet
  1753. connection and an 802.11 [IEEE.802.11] wireless connection active at
  1754. the same time. What the software on the laptop computer can't easily
  1755. tell is whether the wireless connection is in fact bridged onto the
  1756. same network segment as its Ethernet connection. If the two networks
  1757. are bridged together, then packets the host sends on one interface
  1758. will arrive on the other interface a few milliseconds later, and care
  1759. must be taken to ensure that this bridging does not cause problems:
  1760. Cheshire & Krochmal Standards Track [Page 42]
  1761. RFC 6762 Multicast DNS February 2013
  1762. When the host announces its host name (i.e., its address records) on
  1763. its wireless interface, those announcement records are sent with the
  1764. cache-flush bit set, so when they arrive on the Ethernet segment,
  1765. they will cause all the peers on the Ethernet to flush the host's
  1766. Ethernet address records from their caches. The Multicast DNS
  1767. protocol has a safeguard to protect against this situation: when
  1768. records are received with the cache-flush bit set, other records are
  1769. not deleted from peer caches immediately, but are marked for deletion
  1770. in one second. When the host sees its own wireless address records
  1771. arrive on its Ethernet interface, with the cache-flush bit set, this
  1772. one-second grace period gives the host time to respond and re-
  1773. announce its Ethernet address records, to reinstate those records in
  1774. peer caches before they are deleted.
  1775. As described, this solves one problem, but creates another, because
  1776. when those Ethernet announcement records arrive back on the wireless
  1777. interface, the host would again respond defensively to reinstate its
  1778. wireless records, and this process would continue forever,
  1779. continuously flooding the network with traffic. The Multicast DNS
  1780. protocol has a second safeguard, to solve this problem: the cache-
  1781. flush bit does not apply to records received very recently, within
  1782. the last second. This means that when the host sees its own Ethernet
  1783. address records arrive on its wireless interface, with the cache-
  1784. flush bit set, it knows there's no need to re-announce its wireless
  1785. address records again because it already sent them less than a second
  1786. ago, and this makes them immune from deletion from peer caches. (See
  1787. Section 10.2.)
  1788. 15. Considerations for Multiple Responders on the Same Machine
  1789. It is possible to have more than one Multicast DNS responder and/or
  1790. querier implementation coexist on the same machine, but there are
  1791. some known issues.
  1792. 15.1. Receiving Unicast Responses
  1793. In most operating systems, incoming *multicast* packets can be
  1794. delivered to *all* open sockets bound to the right port number,
  1795. provided that the clients take the appropriate steps to allow this.
  1796. For this reason, all Multicast DNS implementations SHOULD use the
  1797. SO_REUSEPORT and/or SO_REUSEADDR options (or equivalent as
  1798. appropriate for the operating system in question) so they will all be
  1799. able to bind to UDP port 5353 and receive incoming multicast packets
  1800. addressed to that port. However, unlike multicast packets, incoming
  1801. unicast UDP packets are typically delivered only to the first socket
  1802. to bind to that port. This means that "QU" responses and other
  1803. packets sent via unicast will be received only by the first Multicast
  1804. DNS responder and/or querier on a system. This limitation can be
  1805. Cheshire & Krochmal Standards Track [Page 43]
  1806. RFC 6762 Multicast DNS February 2013
  1807. partially mitigated if Multicast DNS implementations detect when they
  1808. are not the first to bind to port 5353, and in that case they do not
  1809. request "QU" responses. One way to detect if there is another
  1810. Multicast DNS implementation already running is to attempt binding to
  1811. port 5353 without using SO_REUSEPORT and/or SO_REUSEADDR, and if that
  1812. fails it indicates that some other socket is already bound to this
  1813. port.
  1814. 15.2. Multipacket Known-Answer lists
  1815. When a Multicast DNS querier issues a query with too many Known
  1816. Answers to fit into a single packet, it divides the Known-Answer list
  1817. into two or more packets. Multicast DNS responders associate the
  1818. initial truncated query with its continuation packets by examining
  1819. the source IP address in each packet. Since two independent
  1820. Multicast DNS queriers running on the same machine will be sending
  1821. packets with the same source IP address, from an outside perspective
  1822. they appear to be a single entity. If both queriers happened to send
  1823. the same multipacket query at the same time, with different Known-
  1824. Answer lists, then they could each end up suppressing answers that
  1825. the other needs.
  1826. 15.3. Efficiency
  1827. If different clients on a machine were each to have their own
  1828. independent Multicast DNS implementation, they would lose certain
  1829. efficiency benefits. Apart from the unnecessary code duplication,
  1830. memory usage, and CPU load, the clients wouldn't get the benefit of a
  1831. shared system-wide cache, and they would not be able to aggregate
  1832. separate queries into single packets to reduce network traffic.
  1833. 15.4. Recommendation
  1834. Because of these issues, this document encourages implementers to
  1835. design systems with a single Multicast DNS implementation that
  1836. provides Multicast DNS services shared by all clients on that
  1837. machine, much as most operating systems today have a single TCP
  1838. implementation, which is shared between all clients on that machine.
  1839. Due to engineering constraints, there may be situations where
  1840. embedding a "user-level" Multicast DNS implementation in the client
  1841. application software is the most expedient solution, and while this
  1842. will usually work in practice, implementers should be aware of the
  1843. issues outlined in this section.
  1844. Cheshire & Krochmal Standards Track [Page 44]
  1845. RFC 6762 Multicast DNS February 2013
  1846. 16. Multicast DNS Character Set
  1847. Historically, Unicast DNS has been used with a very restricted set of
  1848. characters. Indeed, conventional DNS is usually limited to just
  1849. twenty-six letters, ten digits and the hyphen character, not even
  1850. allowing spaces or other punctuation. Attempts to remedy this for
  1851. Unicast DNS have been badly constrained by the perceived need to
  1852. accommodate old buggy legacy DNS implementations. In reality, the
  1853. DNS specification itself actually imposes no limits on what
  1854. characters may be used in names, and good DNS implementations handle
  1855. any arbitrary eight-bit data without trouble. "Clarifications to the
  1856. DNS Specification" [RFC2181] directly discusses the subject of
  1857. allowable character set in Section 11 ("Name syntax"), and explicitly
  1858. states that DNS names may contain arbitrary eight-bit data. However,
  1859. the old rules for ARPANET host names back in the 1980s required host
  1860. names to be just letters, digits, and hyphens [RFC1034], and since
  1861. the predominant use of DNS is to store host address records, many
  1862. have assumed that the DNS protocol itself suffers from the same
  1863. limitation. It might be accurate to say that there could be
  1864. hypothetical bad implementations that do not handle eight-bit data
  1865. correctly, but it would not be accurate to say that the protocol
  1866. doesn't allow names containing eight-bit data.
  1867. Multicast DNS is a new protocol and doesn't (yet) have old buggy
  1868. legacy implementations to constrain the design choices. Accordingly,
  1869. it adopts the simple obvious elegant solution: all names in Multicast
  1870. DNS MUST be encoded as precomposed UTF-8 [RFC3629] "Net-Unicode"
  1871. [RFC5198] text.
  1872. Some users of 16-bit Unicode have taken to stuffing a "zero-width
  1873. nonbreaking space" character (U+FEFF) at the start of each UTF-16
  1874. file, as a hint to identify whether the data is big-endian or little-
  1875. endian, and calling it a "Byte Order Mark" (BOM). Since there is
  1876. only one possible byte order for UTF-8 data, a BOM is neither
  1877. necessary nor permitted. Multicast DNS names MUST NOT contain a
  1878. "Byte Order Mark". Any occurrence of the Unicode character U+FEFF at
  1879. the start or anywhere else in a Multicast DNS name MUST be
  1880. interpreted as being an actual intended part of the name,
  1881. representing (just as for any other legal unicode value) an actual
  1882. literal instance of that character (in this case a zero-width non-
  1883. breaking space character).
  1884. For names that are restricted to US-ASCII [RFC0020] letters, digits,
  1885. and hyphens, the UTF-8 encoding is identical to the US-ASCII
  1886. encoding, so this is entirely compatible with existing host names.
  1887. For characters outside the US-ASCII range, UTF-8 encoding is used.
  1888. Cheshire & Krochmal Standards Track [Page 45]
  1889. RFC 6762 Multicast DNS February 2013
  1890. Multicast DNS implementations MUST NOT use any other encodings apart
  1891. from precomposed UTF-8 (US-ASCII being considered a compatible subset
  1892. of UTF-8). The reasons for selecting UTF-8 instead of Punycode
  1893. [RFC3492] are discussed further in Appendix F.
  1894. The simple rules for case-insensitivity in Unicast DNS [RFC1034]
  1895. [RFC1035] also apply in Multicast DNS; that is to say, in name
  1896. comparisons, the lowercase letters "a" to "z" (0x61 to 0x7A) match
  1897. their uppercase equivalents "A" to "Z" (0x41 to 0x5A). Hence, if a
  1898. querier issues a query for an address record with the name
  1899. "myprinter.local.", then a responder having an address record with
  1900. the name "MyPrinter.local." should issue a response. No other
  1901. automatic equivalences should be assumed. In particular, all UTF-8
  1902. multibyte characters (codes 0x80 and higher) are compared by simple
  1903. binary comparison of the raw byte values. Accented characters are
  1904. *not* defined to be automatically equivalent to their unaccented
  1905. counterparts. Where automatic equivalences are desired, this may be
  1906. achieved through the use of programmatically generated CNAME records.
  1907. For example, if a responder has an address record for an accented
  1908. name Y, and a querier issues a query for a name X, where X is the
  1909. same as Y with all the accents removed, then the responder may issue
  1910. a response containing two resource records: a CNAME record "X CNAME
  1911. Y", asserting that the requested name X (unaccented) is an alias for
  1912. the true (accented) name Y, followed by the address record for Y.
  1913. 17. Multicast DNS Message Size
  1914. The 1987 DNS specification [RFC1035] restricts DNS messages carried
  1915. by UDP to no more than 512 bytes (not counting the IP or UDP
  1916. headers). For UDP packets carried over the wide-area Internet in
  1917. 1987, this was appropriate. For link-local multicast packets on
  1918. today's networks, there is no reason to retain this restriction.
  1919. Given that the packets are by definition link-local, there are no
  1920. Path MTU issues to consider.
  1921. Multicast DNS messages carried by UDP may be up to the IP MTU of the
  1922. physical interface, less the space required for the IP header (20
  1923. bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).
  1924. In the case of a single Multicast DNS resource record that is too
  1925. large to fit in a single MTU-sized multicast response packet, a
  1926. Multicast DNS responder SHOULD send the resource record alone, in a
  1927. single IP datagram, using multiple IP fragments. Resource records
  1928. this large SHOULD be avoided, except in the very rare cases where
  1929. they really are the appropriate solution to the problem at hand.
  1930. Implementers should be aware that many simple devices do not
  1931. reassemble fragmented IP datagrams, so large resource records SHOULD
  1932. NOT be used except in specialized cases where the implementer knows
  1933. Cheshire & Krochmal Standards Track [Page 46]
  1934. RFC 6762 Multicast DNS February 2013
  1935. that all receivers implement reassembly, or where the large resource
  1936. record contains optional data which is not essential for correct
  1937. operation of the client.
  1938. A Multicast DNS packet larger than the interface MTU, which is sent
  1939. using fragments, MUST NOT contain more than one resource record.
  1940. Even when fragmentation is used, a Multicast DNS packet, including IP
  1941. and UDP headers, MUST NOT exceed 9000 bytes.
  1942. Note that 9000 bytes is also the maximum payload size of an Ethernet
  1943. "Jumbo" packet [Jumbo]. However, in practice Ethernet "Jumbo"
  1944. packets are not widely used, so it is advantageous to keep packets
  1945. under 1500 bytes whenever possible. Even on hosts that normally
  1946. handle Ethernet "Jumbo" packets and IP fragment reassembly, it is
  1947. becoming more common for these hosts to implement power-saving modes
  1948. where the main CPU goes to sleep and hands off packet reception tasks
  1949. to a more limited processor in the network interface hardware, which
  1950. may not support Ethernet "Jumbo" packets or IP fragment reassembly.
  1951. 18. Multicast DNS Message Format
  1952. This section describes specific rules pertaining to the allowable
  1953. values for the header fields of a Multicast DNS message, and other
  1954. message format considerations.
  1955. 18.1. ID (Query Identifier)
  1956. Multicast DNS implementations SHOULD listen for unsolicited responses
  1957. issued by hosts booting up (or waking up from sleep or otherwise
  1958. joining the network). Since these unsolicited responses may contain
  1959. a useful answer to a question for which the querier is currently
  1960. awaiting an answer, Multicast DNS implementations SHOULD examine all
  1961. received Multicast DNS response messages for useful answers, without
  1962. regard to the contents of the ID field or the Question Section. In
  1963. Multicast DNS, knowing which particular query message (if any) is
  1964. responsible for eliciting a particular response message is less
  1965. interesting than knowing whether the response message contains useful
  1966. information.
  1967. Multicast DNS implementations MAY cache data from any or all
  1968. Multicast DNS response messages they receive, for possible future
  1969. use, provided of course that normal TTL aging is performed on these
  1970. cached resource records.
  1971. In multicast query messages, the Query Identifier SHOULD be set to
  1972. zero on transmission.
  1973. Cheshire & Krochmal Standards Track [Page 47]
  1974. RFC 6762 Multicast DNS February 2013
  1975. In multicast responses, including unsolicited multicast responses,
  1976. the Query Identifier MUST be set to zero on transmission, and MUST be
  1977. ignored on reception.
  1978. In legacy unicast response messages generated specifically in
  1979. response to a particular (unicast or multicast) query, the Query
  1980. Identifier MUST match the ID from the query message.
  1981. 18.2. QR (Query/Response) Bit
  1982. In query messages the QR bit MUST be zero.
  1983. In response messages the QR bit MUST be one.
  1984. 18.3. OPCODE
  1985. In both multicast query and multicast response messages, the OPCODE
  1986. MUST be zero on transmission (only standard queries are currently
  1987. supported over multicast). Multicast DNS messages received with an
  1988. OPCODE other than zero MUST be silently ignored.
  1989. 18.4. AA (Authoritative Answer) Bit
  1990. In query messages, the Authoritative Answer bit MUST be zero on
  1991. transmission, and MUST be ignored on reception.
  1992. In response messages for Multicast domains, the Authoritative Answer
  1993. bit MUST be set to one (not setting this bit would imply there's some
  1994. other place where "better" information may be found) and MUST be
  1995. ignored on reception.
  1996. 18.5. TC (Truncated) Bit
  1997. In query messages, if the TC bit is set, it means that additional
  1998. Known-Answer records may be following shortly. A responder SHOULD
  1999. record this fact, and wait for those additional Known-Answer records,
  2000. before deciding whether to respond. If the TC bit is clear, it means
  2001. that the querying host has no additional Known Answers.
  2002. In multicast response messages, the TC bit MUST be zero on
  2003. transmission, and MUST be ignored on reception.
  2004. In legacy unicast response messages, the TC bit has the same meaning
  2005. as in conventional Unicast DNS: it means that the response was too
  2006. large to fit in a single packet, so the querier SHOULD reissue its
  2007. query using TCP in order to receive the larger response.
  2008. Cheshire & Krochmal Standards Track [Page 48]
  2009. RFC 6762 Multicast DNS February 2013
  2010. 18.6. RD (Recursion Desired) Bit
  2011. In both multicast query and multicast response messages, the
  2012. Recursion Desired bit SHOULD be zero on transmission, and MUST be
  2013. ignored on reception.
  2014. 18.7. RA (Recursion Available) Bit
  2015. In both multicast query and multicast response messages, the
  2016. Recursion Available bit MUST be zero on transmission, and MUST be
  2017. ignored on reception.
  2018. 18.8. Z (Zero) Bit
  2019. In both query and response messages, the Zero bit MUST be zero on
  2020. transmission, and MUST be ignored on reception.
  2021. 18.9. AD (Authentic Data) Bit
  2022. In both multicast query and multicast response messages, the
  2023. Authentic Data bit [RFC2535] MUST be zero on transmission, and MUST
  2024. be ignored on reception.
  2025. 18.10. CD (Checking Disabled) Bit
  2026. In both multicast query and multicast response messages, the Checking
  2027. Disabled bit [RFC2535] MUST be zero on transmission, and MUST be
  2028. ignored on reception.
  2029. 18.11. RCODE (Response Code)
  2030. In both multicast query and multicast response messages, the Response
  2031. Code MUST be zero on transmission. Multicast DNS messages received
  2032. with non-zero Response Codes MUST be silently ignored.
  2033. 18.12. Repurposing of Top Bit of qclass in Question Section
  2034. In the Question Section of a Multicast DNS query, the top bit of the
  2035. qclass field is used to indicate that unicast responses are preferred
  2036. for this particular question. (See Section 5.4.)
  2037. 18.13. Repurposing of Top Bit of rrclass in Resource Record Sections
  2038. In the Resource Record Sections of a Multicast DNS response, the top
  2039. bit of the rrclass field is used to indicate that the record is a
  2040. member of a unique RRSet, and the entire RRSet has been sent together
  2041. (in the same packet, or in consecutive packets if there are too many
  2042. records to fit in a single packet). (See Section 10.2.)
  2043. Cheshire & Krochmal Standards Track [Page 49]
  2044. RFC 6762 Multicast DNS February 2013
  2045. 18.14. Name Compression
  2046. When generating Multicast DNS messages, implementations SHOULD use
  2047. name compression wherever possible to compress the names of resource
  2048. records, by replacing some or all of the resource record name with a
  2049. compact two-byte reference to an appearance of that data somewhere
  2050. earlier in the message [RFC1035].
  2051. This applies not only to Multicast DNS responses, but also to
  2052. queries. When a query contains more than one question, successive
  2053. questions in the same message often contain similar names, and
  2054. consequently name compression SHOULD be used, to save bytes. In
  2055. addition, queries may also contain Known Answers in the Answer
  2056. Section, or probe tiebreaking data in the Authority Section, and
  2057. these names SHOULD similarly be compressed for network efficiency.
  2058. In addition to compressing the *names* of resource records, names
  2059. that appear within the *rdata* of the following rrtypes SHOULD also
  2060. be compressed in all Multicast DNS messages:
  2061. NS, CNAME, PTR, DNAME, SOA, MX, AFSDB, RT, KX, RP, PX, SRV, NSEC
  2062. Until future IETF Standards Action [RFC5226] specifying that names in
  2063. the rdata of other types should be compressed, names that appear
  2064. within the rdata of any type not listed above MUST NOT be compressed.
  2065. Implementations receiving Multicast DNS messages MUST correctly
  2066. decode compressed names appearing in the Question Section, and
  2067. compressed names of resource records appearing in other sections.
  2068. In addition, implementations MUST correctly decode compressed names
  2069. appearing within the *rdata* of the rrtypes listed above. Where
  2070. possible, implementations SHOULD also correctly decode compressed
  2071. names appearing within the *rdata* of other rrtypes known to the
  2072. implementers at the time of implementation, because such forward-
  2073. thinking planning helps facilitate the deployment of future
  2074. implementations that may have reason to compress those rrtypes. It
  2075. is possible that no future IETF Standards Action [RFC5226] will be
  2076. created that mandates or permits the compression of rdata in new
  2077. types, but having implementations designed such that they are capable
  2078. of decompressing all known types helps keep future options open.
  2079. One specific difference between Unicast DNS and Multicast DNS is that
  2080. Unicast DNS does not allow name compression for the target host in an
  2081. SRV record, because Unicast DNS implementations before the first SRV
  2082. specification in 1996 [RFC2052] may not decode these compressed
  2083. Cheshire & Krochmal Standards Track [Page 50]
  2084. RFC 6762 Multicast DNS February 2013
  2085. records properly. Since all Multicast DNS implementations were
  2086. created after 1996, all Multicast DNS implementations are REQUIRED to
  2087. decode compressed SRV records correctly.
  2088. In legacy unicast responses generated to answer legacy queries, name
  2089. compression MUST NOT be performed on SRV records.
  2090. 19. Summary of Differences between Multicast DNS and Unicast DNS
  2091. Multicast DNS shares, as much as possible, the familiar APIs, naming
  2092. syntax, resource record types, etc., of Unicast DNS. There are, of
  2093. course, necessary differences by virtue of it using multicast, and by
  2094. virtue of it operating in a community of cooperating peers, rather
  2095. than a precisely defined hierarchy controlled by a strict chain of
  2096. formal delegations from the root. These differences are summarized
  2097. below:
  2098. Multicast DNS...
  2099. * uses multicast
  2100. * uses UDP port 5353 instead of port 53
  2101. * operates in well-defined parts of the DNS namespace
  2102. * has no SOA (Start of Authority) records
  2103. * uses UTF-8, and only UTF-8, to encode resource record names
  2104. * allows names up to 255 bytes plus a terminating zero byte
  2105. * allows name compression in rdata for SRV and other record types
  2106. * allows larger UDP packets
  2107. * allows more than one question in a query message
  2108. * defines consistent results for qtype "ANY" and qclass "ANY" queries
  2109. * uses the Answer Section of a query to list Known Answers
  2110. * uses the TC bit in a query to indicate additional Known Answers
  2111. * uses the Authority Section of a query for probe tiebreaking
  2112. * ignores the Query ID field (except for generating legacy responses)
  2113. * doesn't require the question to be repeated in the response message
  2114. * uses unsolicited responses to announce new records
  2115. * uses NSEC records to signal nonexistence of records
  2116. * defines a unicast-response bit in the rrclass of query questions
  2117. * defines a cache-flush bit in the rrclass of response records
  2118. * uses DNS RR TTL 0 to indicate that a record has been deleted
  2119. * recommends AAAA records in the additional section when responding
  2120. to rrtype "A" queries, and vice versa
  2121. * monitors queries to perform Duplicate Question Suppression
  2122. * monitors responses to perform Duplicate Answer Suppression...
  2123. * ... and Ongoing Conflict Detection
  2124. * ... and Opportunistic Caching
  2125. Cheshire & Krochmal Standards Track [Page 51]
  2126. RFC 6762 Multicast DNS February 2013
  2127. 20. IPv6 Considerations
  2128. An IPv4-only host and an IPv6-only host behave as "ships that pass in
  2129. the night". Even if they are on the same Ethernet, neither is aware
  2130. of the other's traffic. For this reason, each physical link may have
  2131. *two* unrelated ".local." zones, one for IPv4 and one for IPv6.
  2132. Since for practical purposes, a group of IPv4-only hosts and a group
  2133. of IPv6-only hosts on the same Ethernet act as if they were on two
  2134. entirely separate Ethernet segments, it is unsurprising that their
  2135. use of the ".local." zone should occur exactly as it would if they
  2136. really were on two entirely separate Ethernet segments.
  2137. A dual-stack (v4/v6) host can participate in both ".local." zones,
  2138. and should register its name(s) and perform its lookups both using
  2139. IPv4 and IPv6. This enables it to reach, and be reached by, both
  2140. IPv4-only and IPv6-only hosts. In effect, this acts like a
  2141. multihomed host, with one connection to the logical "IPv4 Ethernet
  2142. segment", and a connection to the logical "IPv6 Ethernet segment".
  2143. When such a host generates NSEC records, if it is using the same host
  2144. name for its IPv4 addresses and its IPv6 addresses on that network
  2145. interface, its NSEC records should indicate that the host name has
  2146. both A and AAAA records.
  2147. 21. Security Considerations
  2148. The algorithm for detecting and resolving name conflicts is, by its
  2149. very nature, an algorithm that assumes cooperating participants. Its
  2150. purpose is to allow a group of hosts to arrive at a mutually disjoint
  2151. set of host names and other DNS resource record names, in the absence
  2152. of any central authority to coordinate this or mediate disputes. In
  2153. the absence of any higher authority to resolve disputes, the only
  2154. alternative is that the participants must work together cooperatively
  2155. to arrive at a resolution.
  2156. In an environment where the participants are mutually antagonistic
  2157. and unwilling to cooperate, other mechanisms are appropriate, like
  2158. manually configured DNS.
  2159. In an environment where there is a group of cooperating participants,
  2160. but clients cannot be sure that there are no antagonistic hosts on
  2161. the same physical link, the cooperating participants need to use
  2162. IPsec signatures and/or DNSSEC [RFC4033] signatures so that they can
  2163. distinguish Multicast DNS messages from trusted participants (which
  2164. they process as usual) from Multicast DNS messages from untrusted
  2165. participants (which they silently discard).
  2166. Cheshire & Krochmal Standards Track [Page 52]
  2167. RFC 6762 Multicast DNS February 2013
  2168. If DNS queries for *global* DNS names are sent to the mDNS multicast
  2169. address (during network outages which disrupt communication with the
  2170. greater Internet) it is *especially* important to use DNSSEC, because
  2171. the user may have the impression that he or she is communicating with
  2172. some authentic host, when in fact he or she is really communicating
  2173. with some local host that is merely masquerading as that name. This
  2174. is less critical for names ending with ".local.", because the user
  2175. should be aware that those names have only local significance and no
  2176. global authority is implied.
  2177. Most computer users neglect to type the trailing dot at the end of a
  2178. fully qualified domain name, making it a relative domain name (e.g.,
  2179. "www.example.com"). In the event of network outage, attempts to
  2180. positively resolve the name as entered will fail, resulting in
  2181. application of the search list, including ".local.", if present. A
  2182. malicious host could masquerade as "www.example.com." by answering
  2183. the resulting Multicast DNS query for "www.example.com.local.". To
  2184. avoid this, a host MUST NOT append the search suffix ".local.", if
  2185. present, to any relative (partially qualified) host name containing
  2186. two or more labels. Appending ".local." to single-label relative
  2187. host names is acceptable, since the user should have no expectation
  2188. that a single-label host name will resolve as is. However, users who
  2189. have both "example.com" and "local" in their search lists should be
  2190. aware that if they type "www" into their web browser, it may not be
  2191. immediately clear to them whether the page that appears is
  2192. "www.example.com" or "www.local".
  2193. Multicast DNS uses UDP port 5353. On operating systems where only
  2194. privileged processes are allowed to use ports below 1024, no such
  2195. privilege is required to use port 5353.
  2196. 22. IANA Considerations
  2197. IANA has allocated the UDP port 5353 for the Multicast DNS protocol
  2198. described in this document [SN].
  2199. IANA has allocated the IPv4 link-local multicast address 224.0.0.251
  2200. for the use described in this document [MC4].
  2201. IANA has allocated the IPv6 multicast address set FF0X::FB (where "X"
  2202. indicates any hexadecimal digit from '1' to 'F') for the use
  2203. described in this document [MC6]. Only address FF02::FB (link-local
  2204. scope) is currently in use by deployed software, but it is possible
  2205. that in the future implementers may experiment with Multicast DNS
  2206. using larger-scoped addresses, such as FF05::FB (site-local scope)
  2207. [RFC4291].
  2208. Cheshire & Krochmal Standards Track [Page 53]
  2209. RFC 6762 Multicast DNS February 2013
  2210. IANA has implemented the following DNS records:
  2211. MDNS.MCAST.NET. IN A 224.0.0.251
  2212. 251.0.0.224.IN-ADDR.ARPA. IN PTR MDNS.MCAST.NET.
  2213. Entries for the AAAA and corresponding PTR records have not been made
  2214. as there is not yet an RFC providing direction for the management of
  2215. the IP6.ARPA domain relating to the IPv6 multicast address space.
  2216. The reuse of the top bit of the rrclass field in the Question and
  2217. Resource Record Sections means that Multicast DNS can only carry DNS
  2218. records with classes in the range 0-32767. Classes in the range
  2219. 32768 to 65535 are incompatible with Multicast DNS. IANA has noted
  2220. this fact, and if IANA receives a request to allocate a DNS class
  2221. value above 32767, IANA will make sure the requester is aware of this
  2222. implication before proceeding. This does not mean that allocations
  2223. of DNS class values above 32767 should be denied, only that they
  2224. should not be allowed until the requester has indicated that they are
  2225. aware of how this allocation will interact with Multicast DNS.
  2226. However, to date, only three DNS classes have been assigned by IANA
  2227. (1, 3, and 4), and only one (1, "Internet") is actually in widespread
  2228. use, so this issue is likely to remain a purely theoretical one.
  2229. IANA has recorded the list of domains below as being Special-Use
  2230. Domain Names [RFC6761]:
  2231. .local.
  2232. .254.169.in-addr.arpa.
  2233. .8.e.f.ip6.arpa.
  2234. .9.e.f.ip6.arpa.
  2235. .a.e.f.ip6.arpa.
  2236. .b.e.f.ip6.arpa.
  2237. 22.1. Domain Name Reservation Considerations
  2238. The six domains listed above, and any names falling within those
  2239. domains (e.g., "MyPrinter.local.", "34.12.254.169.in-addr.arpa.",
  2240. "Ink-Jet._pdl-datastream._tcp.local.") are special [RFC6761] in the
  2241. following ways:
  2242. 1. Users may use these names as they would other DNS names,
  2243. entering them anywhere that they would otherwise enter a
  2244. conventional DNS name, or a dotted decimal IPv4 address, or a
  2245. literal IPv6 address.
  2246. Since there is no central authority responsible for assigning
  2247. dot-local names, and all devices on the local network are
  2248. equally entitled to claim any dot-local name, users SHOULD be
  2249. Cheshire & Krochmal Standards Track [Page 54]
  2250. RFC 6762 Multicast DNS February 2013
  2251. aware of this and SHOULD exercise appropriate caution. In an
  2252. untrusted or unfamiliar network environment, users SHOULD be
  2253. aware that using a name like "www.local" may not actually
  2254. connect them to the web site they expected, and could easily
  2255. connect them to a different web page, or even a fake or spoof
  2256. of their intended web site, designed to trick them into
  2257. revealing confidential information. As always with networking,
  2258. end-to-end cryptographic security can be a useful tool. For
  2259. example, when connecting with ssh, the ssh host key
  2260. verification process will inform the user if it detects that
  2261. the identity of the entity they are communicating with has
  2262. changed since the last time they connected to that name.
  2263. 2. Application software may use these names as they would other
  2264. similar DNS names, and is not required to recognize the names
  2265. and treat them specially. Due to the relative ease of spoofing
  2266. dot-local names, end-to-end cryptographic security remains
  2267. important when communicating across a local network, just as it
  2268. is when communicating across the global Internet.
  2269. 3. Name resolution APIs and libraries SHOULD recognize these names
  2270. as special and SHOULD NOT send queries for these names to their
  2271. configured (unicast) caching DNS server(s). This is to avoid
  2272. unnecessary load on the root name servers and other name
  2273. servers, caused by queries for which those name servers do not
  2274. have useful non-negative answers to give, and will not ever
  2275. have useful non-negative answers to give.
  2276. 4. Caching DNS servers SHOULD recognize these names as special and
  2277. SHOULD NOT attempt to look up NS records for them, or otherwise
  2278. query authoritative DNS servers in an attempt to resolve these
  2279. names. Instead, caching DNS servers SHOULD generate immediate
  2280. NXDOMAIN responses for all such queries they may receive (from
  2281. misbehaving name resolver libraries). This is to avoid
  2282. unnecessary load on the root name servers and other name
  2283. servers.
  2284. 5. Authoritative DNS servers SHOULD NOT by default be configurable
  2285. to answer queries for these names, and, like caching DNS
  2286. servers, SHOULD generate immediate NXDOMAIN responses for all
  2287. such queries they may receive. DNS server software MAY provide
  2288. a configuration option to override this default, for testing
  2289. purposes or other specialized uses.
  2290. 6. DNS server operators SHOULD NOT attempt to configure
  2291. authoritative DNS servers to act as authoritative for any of
  2292. these names. Configuring an authoritative DNS server to act as
  2293. authoritative for any of these names may not, in many cases,
  2294. Cheshire & Krochmal Standards Track [Page 55]
  2295. RFC 6762 Multicast DNS February 2013
  2296. yield the expected result. Since name resolver libraries and
  2297. caching DNS servers SHOULD NOT send queries for those names
  2298. (see 3 and 4 above), such queries SHOULD be suppressed before
  2299. they even reach the authoritative DNS server in question, and
  2300. consequently it will not even get an opportunity to answer
  2301. them.
  2302. 7. DNS Registrars MUST NOT allow any of these names to be
  2303. registered in the normal way to any person or entity. These
  2304. names are reserved protocol identifiers with special meaning
  2305. and fall outside the set of names available for allocation by
  2306. registrars. Attempting to allocate one of these names as if it
  2307. were a normal domain name will probably not work as desired,
  2308. for reasons 3, 4, and 6 above.
  2309. 23. Acknowledgments
  2310. The concepts described in this document have been explored,
  2311. developed, and implemented with help from Ran Atkinson, Richard
  2312. Brown, Freek Dijkstra, Erik Guttman, Kyle McKay, Pasi Sarolahti,
  2313. Pekka Savola, Robby Simpson, Mark Townsley, Paul Vixie, Bill
  2314. Woodcock, and others. Special thanks go to Bob Bradley, Josh
  2315. Graessley, Scott Herscher, Rory McGuire, Roger Pantos, and Kiren
  2316. Sekar for their significant contributions. Special thanks also to
  2317. Kerry Lynn for converting the document to xml2rfc form in May 2010,
  2318. and to Area Director Ralph Droms for shepherding the document through
  2319. its final steps.
  2320. 24. References
  2321. 24.1. Normative References
  2322. [MC4] IANA, "IPv4 Multicast Address Space Registry",
  2323. <http://www.iana.org/assignments/multicast-addresses/>.
  2324. [MC6] IANA, "IPv6 Multicast Address Space Registry",
  2325. <http://www.iana.org/assignments/
  2326. ipv6-multicast-addresses/>.
  2327. [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
  2328. October 1969.
  2329. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
  2330. STD 13, RFC 1034, November 1987.
  2331. [RFC1035] Mockapetris, P., "Domain names - implementation and
  2332. specification", STD 13, RFC 1035, November 1987.
  2333. Cheshire & Krochmal Standards Track [Page 56]
  2334. RFC 6762 Multicast DNS February 2013
  2335. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
  2336. Requirement Levels", BCP 14, RFC 2119, March 1997.
  2337. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
  2338. 10646", STD 63, RFC 3629, November 2003.
  2339. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
  2340. Rose, "Resource Records for the DNS Security Extensions",
  2341. RFC 4034, March 2005.
  2342. [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
  2343. Interchange", RFC 5198, March 2008.
  2344. [RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA
  2345. Considerations", BCP 42, RFC 6195, March 2011.
  2346. [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
  2347. RFC 6761, February 2013.
  2348. [SN] IANA, "Service Name and Transport Protocol Port Number
  2349. Registry", <http://www.iana.org/assignments/
  2350. service-names-port-numbers/>.
  2351. 24.2. Informative References
  2352. [B4W] "Bonjour for Windows",
  2353. <http://en.wikipedia.org/wiki/Bonjour_(software)>.
  2354. [BJ] Apple Bonjour Open Source Software,
  2355. <http://developer.apple.com/bonjour/>.
  2356. [IEEE.802.3]
  2357. "Information technology - Telecommunications and
  2358. information exchange between systems - Local and
  2359. metropolitan area networks - Specific requirements - Part
  2360. 3: Carrier Sense Multiple Access with Collision Detection
  2361. (CMSA/CD) Access Method and Physical Layer
  2362. Specifications", IEEE Std 802.3-2008, December 2008,
  2363. <http://standards.ieee.org/getieee802/802.3.html>.
  2364. [IEEE.802.11]
  2365. "Information technology - Telecommunications and
  2366. information exchange between systems - Local and
  2367. metropolitan area networks - Specific requirements - Part
  2368. 11: Wireless LAN Medium Access Control (MAC) and Physical
  2369. Layer (PHY) Specifications", IEEE Std 802.11-2007, June
  2370. 2007, <http://standards.ieee.org/getieee802/802.11.html>.
  2371. Cheshire & Krochmal Standards Track [Page 57]
  2372. RFC 6762 Multicast DNS February 2013
  2373. [Jumbo] "Ethernet Jumbo Frames", November 2009,
  2374. <http://www.ethernetalliance.org/library/whitepaper/
  2375. ethernet-jumbo-frames/>.
  2376. [NIAS] Cheshire, S. "Discovering Named Instances of Abstract
  2377. Services using DNS", Work in Progress, July 2001.
  2378. [NSD] "NsdManager | Android Developer", June 2012,
  2379. <http://developer.android.com/reference/
  2380. android/net/nsd/NsdManager.html>.
  2381. [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
  2382. location of services (DNS SRV)", RFC 2052, October 1996.
  2383. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
  2384. Extensions", RFC 2132, March 1997.
  2385. [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
  2386. "Dynamic Updates in the Domain Name System (DNS UPDATE)",
  2387. RFC 2136, April 1997.
  2388. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
  2389. Specification", RFC 2181, July 1997.
  2390. [RFC2535] Eastlake 3rd, D., "Domain Name System Security
  2391. Extensions", RFC 2535, March 1999.
  2392. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
  2393. 2671, August 1999.
  2394. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
  2395. Wellington, "Secret Key Transaction Authentication for DNS
  2396. (TSIG)", RFC 2845, May 2000.
  2397. [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
  2398. RR)", RFC 2930, September 2000.
  2399. [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
  2400. ( SIG(0)s )", RFC 2931, September 2000.
  2401. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
  2402. Update", RFC 3007, November 2000.
  2403. [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
  2404. for Internationalized Domain Names in Applications
  2405. (IDNA)", RFC 3492, March 2003.
  2406. Cheshire & Krochmal Standards Track [Page 58]
  2407. RFC 6762 Multicast DNS February 2013
  2408. [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
  2409. Configuration of IPv4 Link-Local Addresses", RFC 3927, May
  2410. 2005.
  2411. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
  2412. Rose, "DNS Security Introduction and Requirements", RFC
  2413. 4033, March 2005.
  2414. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
  2415. Architecture", RFC 4291, February 2006.
  2416. [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
  2417. Multicast Name Resolution (LLMNR)", RFC 4795, January
  2418. 2007.
  2419. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
  2420. "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
  2421. September 2007.
  2422. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
  2423. Address Autoconfiguration", RFC 4862, September 2007.
  2424. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
  2425. IANA Considerations Section in RFCs", BCP 26, RFC 5226,
  2426. May 2008.
  2427. [RFC5890] Klensin, J., "Internationalized Domain Names for
  2428. Applications (IDNA): Definitions and Document Framework",
  2429. RFC 5890, August 2010.
  2430. [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
  2431. "Understanding Apple's Back to My Mac (BTMM) Service", RFC
  2432. 6281, June 2011.
  2433. [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol
  2434. to Replace the AppleTalk Name Binding Protocol (NBP)", RFC
  2435. 6760, February 2013.
  2436. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
  2437. Discovery", RFC 6763, February 2013.
  2438. [Zeroconf] Cheshire, S. and D. Steinberg, "Zero Configuration
  2439. Networking: The Definitive Guide", O'Reilly Media, Inc.,
  2440. ISBN 0-596-10100-7, December 2005.
  2441. Cheshire & Krochmal Standards Track [Page 59]
  2442. RFC 6762 Multicast DNS February 2013
  2443. Appendix A. Design Rationale for Choice of UDP Port Number
  2444. Arguments were made for and against using UDP port 53, the standard
  2445. Unicast DNS port. Some of the arguments are given below. The
  2446. arguments for using a different port were greater in number and more
  2447. compelling, so that option was ultimately selected. The UDP port
  2448. "5353" was selected for its mnemonic similarity to "53".
  2449. Arguments for using UDP port 53:
  2450. * This is "just DNS", so it should be the same port.
  2451. * There is less work to be done updating old resolver libraries to do
  2452. simple Multicast DNS queries. Only the destination address need be
  2453. changed. In some cases, this can be achieved without any code
  2454. changes, just by adding the address 224.0.0.251 to a configuration
  2455. file.
  2456. Arguments for using a different port (UDP port 5353):
  2457. * This is not "just DNS". This is a DNS-like protocol, but
  2458. different.
  2459. * Changing resolver library code to use a different port number is
  2460. not hard. In some cases, this can be achieved without any code
  2461. changes, just by adding the address 224.0.0.251:5353 to a
  2462. configuration file.
  2463. * Using the same port number makes it hard to run a Multicast DNS
  2464. responder and a conventional Unicast DNS server on the same
  2465. machine. If a conventional Unicast DNS server wishes to implement
  2466. Multicast DNS as well, it can still do that, by opening two
  2467. sockets. Having two different port numbers allows this
  2468. flexibility.
  2469. * Some VPN software hijacks all outgoing traffic to port 53 and
  2470. redirects it to a special DNS server set up to serve those VPN
  2471. clients while they are connected to the corporate network. It is
  2472. questionable whether this is the right thing to do, but it is
  2473. common, and redirecting link-local multicast DNS packets to a
  2474. remote server rarely produces any useful results. It does mean,
  2475. for example, that a user of such VPN software becomes unable to
  2476. access their local network printer sitting on their desk right next
  2477. to their computer. Using a different UDP port helps avoid this
  2478. particular problem.
  2479. Cheshire & Krochmal Standards Track [Page 60]
  2480. RFC 6762 Multicast DNS February 2013
  2481. * On many operating systems, unprivileged software may not send or
  2482. receive packets on low-numbered ports. This means that any
  2483. software sending or receiving Multicast DNS packets on port 53
  2484. would have to run as "root", which is an undesirable security risk.
  2485. Using a higher-numbered UDP port avoids this restriction.
  2486. Appendix B. Design Rationale for Not Using Hashed Multicast Addresses
  2487. Some discovery protocols use a range of multicast addresses, and
  2488. determine the address to be used by a hash function of the name being
  2489. sought. Queries are sent via multicast to the address as indicated
  2490. by the hash function, and responses are returned to the querier via
  2491. unicast. Particularly in IPv6, where multicast addresses are
  2492. extremely plentiful, this approach is frequently advocated. For
  2493. example, IPv6 Neighbor Discovery [RFC4861] sends Neighbor
  2494. Solicitation messages to the "solicited-node multicast address",
  2495. which is computed as a function of the solicited IPv6 address.
  2496. There are some disadvantages to using hashed multicast addresses like
  2497. this in a service discovery protocol:
  2498. * When a host has a large number of records with different names, the
  2499. host may have to join a large number of multicast groups. Each
  2500. time a host joins or leaves a multicast group, this results in
  2501. Internet Group Management Protocol (IGMP) or Multicast Listener
  2502. Discovery (MLD) traffic on the network announcing this fact.
  2503. Joining a large number of multicast groups can place undue burden
  2504. on the Ethernet hardware, which typically supports a limited number
  2505. of multicast addresses efficiently. When this number is exceeded,
  2506. the Ethernet hardware may have to resort to receiving all
  2507. multicasts and passing them up to the host networking code for
  2508. filtering in software, thereby defeating much of the point of using
  2509. a multicast address range in the first place. Finally, many IPv6
  2510. stacks have a fixed limit IPV6_MAX_MEMBERSHIPS, and the code simply
  2511. fails with an error if a client attempts to exceed this limit.
  2512. Common values for IPV6_MAX_MEMBERSHIPS are 20 or 31.
  2513. * Multiple questions cannot be placed in one packet if they don't all
  2514. hash to the same multicast address.
  2515. * Duplicate Question Suppression doesn't work if queriers are not
  2516. seeing each other's queries.
  2517. * Duplicate Answer Suppression doesn't work if responders are not
  2518. seeing each other's responses.
  2519. * Opportunistic Caching doesn't work.
  2520. Cheshire & Krochmal Standards Track [Page 61]
  2521. RFC 6762 Multicast DNS February 2013
  2522. * Ongoing Conflict Detection doesn't work.
  2523. Appendix C. Design Rationale for Maximum Multicast DNS Name Length
  2524. Multicast DNS names may be up to 255 bytes long (in the on-the-wire
  2525. message format), not counting the terminating zero byte at the end.
  2526. "Domain Names - Implementation and Specification" [RFC1035] says:
  2527. Various objects and parameters in the DNS have size limits. They
  2528. are listed below. Some could be easily changed, others are more
  2529. fundamental.
  2530. labels 63 octets or less
  2531. names 255 octets or less
  2532. ...
  2533. the total length of a domain name (i.e., label octets and label
  2534. length octets) is restricted to 255 octets or less.
  2535. This text does not state whether this 255-byte limit includes the
  2536. terminating zero at the end of every name.
  2537. Several factors lead us to conclude that the 255-byte limit does
  2538. *not* include the terminating zero:
  2539. o It is common in software engineering to have size limits that are a
  2540. power of two, or a multiple of a power of two, for efficiency. For
  2541. example, an integer on a modern processor is typically 2, 4, or 8
  2542. bytes, not 3 or 5 bytes. The number 255 is not a power of two, nor
  2543. is it to most people a particularly noteworthy number. It is
  2544. noteworthy to computer scientists for only one reason -- because it
  2545. is exactly one *less* than a power of two. When a size limit is
  2546. exactly one less than a power of two, that suggests strongly that
  2547. the one extra byte is being reserved for some specific reason -- in
  2548. this case reserved, perhaps, to leave room for a terminating zero
  2549. at the end.
  2550. o In the case of DNS label lengths, the stated limit is 63 bytes. As
  2551. with the total name length, this limit is exactly one less than a
  2552. power of two. This label length limit also excludes the label
  2553. length byte at the start of every label. Including that extra
  2554. byte, a 63-byte label takes 64 bytes of space in memory or in a DNS
  2555. message.
  2556. Cheshire & Krochmal Standards Track [Page 62]
  2557. RFC 6762 Multicast DNS February 2013
  2558. o It is common in software engineering for the semantic "length" of
  2559. an object to be one less than the number of bytes it takes to store
  2560. that object. For example, in C, strlen("foo") is 3, but
  2561. sizeof("foo") (which includes the terminating zero byte at the end)
  2562. is 4.
  2563. o The text describing the total length of a domain name mentions
  2564. explicitly that label length and data octets are included, but does
  2565. not mention the terminating zero at the end. The zero byte at the
  2566. end of a domain name is not a label length. Indeed, the value zero
  2567. is chosen as the terminating marker precisely because it is not a
  2568. legal length byte value -- DNS prohibits empty labels. For
  2569. example, a name like "bad..name." is not a valid domain name
  2570. because it contains a zero-length label in the middle, which cannot
  2571. be expressed in a DNS message, because software parsing the message
  2572. would misinterpret a zero label-length byte as being a zero "end of
  2573. name" marker instead.
  2574. Finally, "Clarifications to the DNS Specification" [RFC2181] offers
  2575. additional confirmation that, in the context of DNS specifications,
  2576. the stated "length" of a domain name does not include the terminating
  2577. zero byte at the end. That document refers to the root name, which
  2578. is typically written as "." and is represented in a DNS message by a
  2579. single lone zero byte (i.e., zero bytes of data plus a terminating
  2580. zero), as the "zero length full name":
  2581. The zero length full name is defined as representing the root of
  2582. the DNS tree, and is typically written and displayed as ".".
  2583. This wording supports the interpretation that, in a DNS context, when
  2584. talking about lengths of names, the terminating zero byte at the end
  2585. is not counted. If the root name (".") is considered to be zero
  2586. length, then to be consistent, the length (for example) of "org" has
  2587. to be 4 and the length of "ietf.org" has to be 9, as shown below:
  2588. ------
  2589. | 0x00 | length = 0
  2590. ------
  2591. ------------------ ------
  2592. | 0x03 | o | r | g | | 0x00 | length = 4
  2593. ------------------ ------
  2594. ----------------------------------------- ------
  2595. | 0x04 | i | e | t | f | 0x03 | o | r | g | | 0x00 | length = 9
  2596. ----------------------------------------- ------
  2597. Cheshire & Krochmal Standards Track [Page 63]
  2598. RFC 6762 Multicast DNS February 2013
  2599. This means that the maximum length of a domain name, as represented
  2600. in a Multicast DNS message, up to but not including the final
  2601. terminating zero, must not exceed 255 bytes.
  2602. However, many Unicast DNS implementers have read these RFCs
  2603. differently, and argue that the 255-byte limit does include the
  2604. terminating zero, and that the "Clarifications to the DNS
  2605. Specification" [RFC2181] statement that "." is the "zero length full
  2606. name" was simply a mistake.
  2607. Hence, implementers should be aware that other Unicast DNS
  2608. implementations may limit the maximum domain name to 254 bytes plus a
  2609. terminating zero, depending on how that implementer interpreted the
  2610. DNS specifications.
  2611. Compliant Multicast DNS implementations MUST support names up to 255
  2612. bytes plus a terminating zero, i.e., 256 bytes total.
  2613. Appendix D. Benefits of Multicast Responses
  2614. Some people have argued that sending responses via multicast is
  2615. inefficient on the network. In fact, using multicast responses can
  2616. result in a net lowering of overall multicast traffic for a variety
  2617. of reasons, and provides other benefits too:
  2618. * Opportunistic Caching. One multicast response can update the
  2619. caches on all machines on the network. If another machine later
  2620. wants to issue the same query, and it already has the answer in its
  2621. cache, it may not need to even transmit that multicast query on the
  2622. network at all.
  2623. * Duplicate Query Suppression. When more than one machine has the
  2624. same ongoing long-lived query running, every machine does not have
  2625. to transmit its own independent query. When one machine transmits
  2626. a query, all the other hosts see the answers, so they can suppress
  2627. their own queries.
  2628. * Passive Observation Of Failures (POOF). When a host sees a
  2629. multicast query, but does not see the corresponding multicast
  2630. response, it can use this information to promptly delete stale data
  2631. from its cache. To achieve the same level of user-interface
  2632. quality and responsiveness without multicast responses would
  2633. require lower cache lifetimes and more frequent network polling,
  2634. resulting in a higher packet rate.
  2635. * Passive Conflict Detection. Just because a name has been
  2636. previously verified to be unique does not guarantee it will
  2637. continue to be so indefinitely. By allowing all Multicast DNS
  2638. Cheshire & Krochmal Standards Track [Page 64]
  2639. RFC 6762 Multicast DNS February 2013
  2640. responders to constantly monitor their peers' responses, conflicts
  2641. arising out of network topology changes can be promptly detected
  2642. and resolved. If responses were not sent via multicast, some other
  2643. conflict detection mechanism would be needed, imposing its own
  2644. additional burden on the network.
  2645. * Use on devices with constrained memory resources: When using
  2646. delayed responses to reduce network collisions, responders need to
  2647. maintain a list recording to whom each answer should be sent. The
  2648. option of multicast responses allows responders with limited
  2649. storage, which cannot store an arbitrarily long list of response
  2650. addresses, to choose to fail-over to a single multicast response in
  2651. place of multiple unicast responses, when appropriate.
  2652. * Overlayed Subnets. In the case of overlayed subnets, multicast
  2653. responses allow a receiver to know with certainty that a response
  2654. originated on the local link, even when its source address may
  2655. apparently suggest otherwise.
  2656. * Robustness in the face of misconfiguration: Link-local multicast
  2657. transcends virtually every conceivable network misconfiguration.
  2658. Even if you have a collection of devices where every device's IP
  2659. address, subnet mask, default gateway, and DNS server address are
  2660. all wrong, packets sent by any of those devices addressed to a
  2661. link-local multicast destination address will still be delivered to
  2662. all peers on the local link. This can be extremely helpful when
  2663. diagnosing and rectifying network problems, since it facilitates a
  2664. direct communication channel between client and server that works
  2665. without reliance on ARP, IP routing tables, etc. Being able to
  2666. discover what IP address a device has (or thinks it has) is
  2667. frequently a very valuable first step in diagnosing why it is
  2668. unable to communicate on the local network.
  2669. Appendix E. Design Rationale for Encoding Negative Responses
  2670. Alternative methods of asserting nonexistence were considered, such
  2671. as using an NXDOMAIN response, or emitting a resource record with
  2672. zero-length rdata.
  2673. Using an NXDOMAIN response does not work well with Multicast DNS. A
  2674. Unicast DNS NXDOMAIN response applies to the entire message, but for
  2675. efficiency Multicast DNS allows (and encourages) multiple responses
  2676. in a single message. If the error code in the header were NXDOMAIN,
  2677. it would not be clear to which name(s) that error code applied.
  2678. Asserting nonexistence by emitting a resource record with zero-length
  2679. rdata would mean that there would be no way to differentiate between
  2680. a record that doesn't exist, and a record that does exist, with zero-
  2681. Cheshire & Krochmal Standards Track [Page 65]
  2682. RFC 6762 Multicast DNS February 2013
  2683. length rdata. By analogy, most file systems today allow empty files,
  2684. so a file that exists with zero bytes of data is not considered
  2685. equivalent to a filename that does not exist.
  2686. A benefit of asserting nonexistence through NSEC records instead of
  2687. through NXDOMAIN responses is that NSEC records can be added to the
  2688. Additional Section of a DNS response to offer additional information
  2689. beyond what the querier explicitly requested. For example, in
  2690. response to an SRV query, a responder should include A record(s)
  2691. giving its IPv4 addresses in the Additional Section, and an NSEC
  2692. record indicating which other types it does or does not have for this
  2693. name. If the responder is running on a host that does not support
  2694. IPv6 (or does support IPv6 but currently has no IPv6 address on that
  2695. interface) then this NSEC record in the Additional Section will
  2696. indicate this absence of AAAA records. In effect, the responder is
  2697. saying, "Here's my SRV record, and here are my IPv4 addresses, and
  2698. no, I don't have any IPv6 addresses, so don't waste your time
  2699. asking". Without this information in the Additional Section, it
  2700. would take the querier an additional round-trip to perform an
  2701. additional query to ascertain that the target host has no AAAA
  2702. records. (Arguably Unicast DNS could also benefit from this ability
  2703. to express nonexistence in the Additional Section, but that is
  2704. outside the scope of this document.)
  2705. Appendix F. Use of UTF-8
  2706. After many years of debate, as a result of the perceived need to
  2707. accommodate certain DNS implementations that apparently couldn't
  2708. handle any character that's not a letter, digit, or hyphen (and
  2709. apparently never would be updated to remedy this limitation), the
  2710. Unicast DNS community settled on an extremely baroque encoding called
  2711. "Punycode" [RFC3492]. Punycode is a remarkably ingenious encoding
  2712. solution, but it is complicated, hard to understand, and hard to
  2713. implement, using sophisticated techniques including insertion unsort
  2714. coding, generalized variable-length integers, and bias adaptation.
  2715. The resulting encoding is remarkably compact given the constraints,
  2716. but it's still not as good as simple straightforward UTF-8, and it's
  2717. hard even to predict whether a given input string will encode to a
  2718. Punycode string that fits within DNS's 63-byte limit, except by
  2719. simply trying the encoding and seeing whether it fits. Indeed, the
  2720. encoded size depends not only on the input characters, but on the
  2721. order they appear, so the same set of characters may or may not
  2722. encode to a legal Punycode string that fits within DNS's 63-byte
  2723. limit, depending on the order the characters appear. This is
  2724. extremely hard to present in a user interface that explains to users
  2725. why one name is allowed, but another name containing the exact same
  2726. characters is not. Neither Punycode nor any other of the "ASCII-
  2727. Compatible Encodings" [RFC5890] proposed for Unicast DNS may be used
  2728. Cheshire & Krochmal Standards Track [Page 66]
  2729. RFC 6762 Multicast DNS February 2013
  2730. in Multicast DNS messages. Any text being represented internally in
  2731. some other representation must be converted to canonical precomposed
  2732. UTF-8 before being placed in any Multicast DNS message.
  2733. Appendix G. Private DNS Namespaces
  2734. The special treatment of names ending in ".local." has been
  2735. implemented in Macintosh computers since the days of Mac OS 9, and
  2736. continues today in Mac OS X and iOS. There are also implementations
  2737. for Microsoft Windows [B4W], Linux, and other platforms.
  2738. Some network operators setting up private internal networks
  2739. ("intranets") have used unregistered top-level domains, and some may
  2740. have used the ".local" top-level domain. Using ".local" as a private
  2741. top-level domain conflicts with Multicast DNS and may cause problems
  2742. for users. Clients can be configured to send both Multicast and
  2743. Unicast DNS queries in parallel for these names, and this does allow
  2744. names to be looked up both ways, but this results in additional
  2745. network traffic and additional delays in name resolution, as well as
  2746. potentially creating user confusion when it is not clear whether any
  2747. given result was received via link-local multicast from a peer on the
  2748. same link, or from the configured unicast name server. Because of
  2749. this, we recommend against using ".local" as a private Unicast DNS
  2750. top-level domain. We do not recommend use of unregistered top-level
  2751. domains at all, but should network operators decide to do this, the
  2752. following top-level domains have been used on private internal
  2753. networks without the problems caused by trying to reuse ".local." for
  2754. this purpose:
  2755. .intranet.
  2756. .internal.
  2757. .private.
  2758. .corp.
  2759. .home.
  2760. .lan.
  2761. Appendix H. Deployment History
  2762. In July 1997, in an email to the net-thinkers@thumper.vmeng.com
  2763. mailing list, Stuart Cheshire first proposed the idea of running the
  2764. AppleTalk Name Binding Protocol [RFC6760] over IP. As a result of
  2765. this and related IETF discussions, the IETF Zeroconf working group
  2766. was chartered September 1999. After various working group
  2767. discussions and other informal IETF discussions, several Internet-
  2768. Drafts were written that were loosely related to the general themes
  2769. of DNS and multicast, but did not address the service discovery
  2770. aspect of NBP.
  2771. Cheshire & Krochmal Standards Track [Page 67]
  2772. RFC 6762 Multicast DNS February 2013
  2773. In April 2000, Stuart Cheshire registered IPv4 multicast address
  2774. 224.0.0.251 with IANA [MC4] and began writing code to test and
  2775. develop the idea of performing NBP-like service discovery using
  2776. Multicast DNS, which was documented in a group of three Internet-
  2777. Drafts:
  2778. o "Requirements for a Protocol to Replace the AppleTalk Name Binding
  2779. Protocol (NBP)" [RFC6760] is an overview explaining the AppleTalk
  2780. Name Binding Protocol, because many in the IETF community had
  2781. little first-hand experience using AppleTalk, and confusion in the
  2782. IETF community about what AppleTalk NBP did was causing confusion
  2783. about what would be required in an IP-based replacement.
  2784. o "Discovering Named Instances of Abstract Services using DNS" [NIAS]
  2785. proposed a way to perform NBP-like service discovery using DNS-
  2786. compatible names and record types.
  2787. o "Multicast DNS" (this document) specifies a way to transport those
  2788. DNS-compatible queries and responses using IP multicast, for zero-
  2789. configuration environments where no conventional Unicast DNS server
  2790. was available.
  2791. In 2001, an update to Mac OS 9 added resolver library support for
  2792. host name lookup using Multicast DNS. If the user typed a name such
  2793. as "MyPrinter.local." into any piece of networking software that used
  2794. the standard Mac OS 9 name lookup APIs, then those name lookup APIs
  2795. would recognize the name as a dot-local name and query for it by
  2796. sending simple one-shot Multicast DNS queries to 224.0.0.251:5353.
  2797. This enabled the user to, for example, enter the name
  2798. "MyPrinter.local." into their web browser in order to view a
  2799. printer's status and configuration web page, or enter the name
  2800. "MyPrinter.local." into the printer setup utility to create a print
  2801. queue for printing documents on that printer.
  2802. Multicast DNS responder software, with full service discovery, first
  2803. began shipping to end users in volume with the launch of Mac OS X
  2804. 10.2 "Jaguar" in August 2002, and network printer makers (who had
  2805. historically supported AppleTalk in their network printers and were
  2806. receptive to IP-based technologies that could offer them similar
  2807. ease-of-use) started adopting Multicast DNS shortly thereafter.
  2808. In September 2002, Apple released the source code for the
  2809. mDNSResponder daemon as Open Source under Apple's standard Apple
  2810. Public Source License (APSL).
  2811. Multicast DNS responder software became available for Microsoft
  2812. Windows users in June 2004 with the launch of Apple's "Rendezvous for
  2813. Windows" (now "Bonjour for Windows"), both in executable form (a
  2814. Cheshire & Krochmal Standards Track [Page 68]
  2815. RFC 6762 Multicast DNS February 2013
  2816. downloadable installer for end users) and as Open Source (one of the
  2817. supported platforms within Apple's body of cross-platform code in the
  2818. publicly accessible mDNSResponder CVS source code repository) [BJ].
  2819. In August 2006, Apple re-licensed the cross-platform mDNSResponder
  2820. source code under the Apache License, Version 2.0.
  2821. In addition to desktop and laptop computers running Mac OS X and
  2822. Microsoft Windows, Multicast DNS is now implemented in a wide range
  2823. of hardware devices, such as Apple's "AirPort" wireless base
  2824. stations, iPhone and iPad, and in home gateways from other vendors,
  2825. network printers, network cameras, TiVo DVRs, etc.
  2826. The Open Source community has produced many independent
  2827. implementations of Multicast DNS, some in C like Apple's
  2828. mDNSResponder daemon, and others in a variety of different languages
  2829. including Java, Python, Perl, and C#/Mono.
  2830. In January 2007, the IETF published the Informational RFC "Link-Local
  2831. Multicast Name Resolution (LLMNR)" [RFC4795], which is substantially
  2832. similar to Multicast DNS, but incompatible in some small but
  2833. important ways. In particular, the LLMNR design explicitly excluded
  2834. support for service discovery, which made it an unsuitable candidate
  2835. for a protocol to replace AppleTalk NBP [RFC6760].
  2836. While the original focus of Multicast DNS and DNS-Based Service
  2837. Discovery was for zero-configuration environments without a
  2838. conventional Unicast DNS server, DNS-Based Service Discovery also
  2839. works using Unicast DNS servers, using DNS Update [RFC2136] [RFC3007]
  2840. to create service discovery records and standard DNS queries to query
  2841. for them. Apple's Back to My Mac service, launched with Mac OS X
  2842. 10.5 "Leopard" in October 2007, uses DNS-Based Service Discovery over
  2843. Unicast DNS [RFC6281].
  2844. In June 2012, Google's Android operating system added native support
  2845. for DNS-SD and Multicast DNS with the android.net.nsd.NsdManager
  2846. class in Android 4.1 "Jelly Bean" (API Level 16) [NSD].
  2847. Cheshire & Krochmal Standards Track [Page 69]
  2848. RFC 6762 Multicast DNS February 2013
  2849. Authors' Addresses
  2850. Stuart Cheshire
  2851. Apple Inc.
  2852. 1 Infinite Loop
  2853. Cupertino, CA 95014
  2854. USA
  2855. Phone: +1 408 974 3207
  2856. EMail: cheshire@apple.com
  2857. Marc Krochmal
  2858. Apple Inc.
  2859. 1 Infinite Loop
  2860. Cupertino, CA 95014
  2861. USA
  2862. Phone: +1 408 974 4368
  2863. EMail: marc@apple.com
  2864. Cheshire & Krochmal Standards Track [Page 70]