forked from avahi/avahi
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-cheshire-dnsext-dns-sd-02.txt
1798 lines (1179 loc) · 73 KB
/
draft-cheshire-dnsext-dns-sd-02.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Document: draft-cheshire-dnsext-dns-sd-02.txt Stuart Cheshire
Category: Standards Track Apple Computer, Inc.
Expires 14th August 2004 Marc Krochmal
Apple Computer, Inc.
14th February 2004
DNS-Based Service Discovery
<draft-cheshire-dnsext-dns-sd-02.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited.
Abstract
This document describes a convention for naming and structuring DNS
resource records. Given a type of service that a client is looking
for, and a domain in which the client is looking for that service,
this convention allows clients to discover a list of named instances
of that desired service, using only standard DNS queries. In short,
this is referred to as DNS-based Service Discovery, or DNS-SD.
Expires 14th August 2004 Cheshire & Krochmal [Page 1]
Internet Draft DNS-Based Service Discovery 14th February 2004
Table of Contents
1. Introduction....................................................3
2. Conventions and Terminology Used in this Document...............3
3. Design Goals....................................................4
4. Service Instance Enumeration....................................5
4.1 Structured Instance Names.......................................5
4.2 User Interface Presentation.....................................7
4.3 Internal Handling of Names......................................7
4.4 What You See Is What You Get....................................7
4.5 Ordering of Service Instance Name Components....................9
5. Service Name Resolution........................................11
6. Data Syntax for DNS-SD TXT Records.............................12
6.1 General Format Rules for DNS TXT Records.......................12
6.2 DNS TXT Record Format Rules for use in DNS-SD..................12
6.3 DNS-SD TXT Record Size.........................................14
6.4 Rules for Names in DNS-SD Name/Value Pairs.....................14
6.5 Rules for Values in DNS-SD Name/Value Pairs....................16
6.6 Example TXT Record.............................................16
6.7 Version Tag....................................................17
7. Application Protocol Names.....................................18
8. Selective Instance Enumeration.................................19
9. Flagship Naming................................................10
10. Service Type Enumeration.......................................21
11. Populating the DNS with Information............................22
12. Relationship to Multicast DNS..................................22
13. Discovery of Browsing and Registration Domains.................23
14. DNS Additional Record Generation...............................24
15. Comparison with Alternative Service Discovery Protocols........25
16. Real Example...................................................27
17. IPv6 Considerations............................................28
18. Security Considerations........................................28
19. IANA Considerations............................................28
20. Acknowledgements...............................................29
21. Copyright......................................................29
22. Normative References...........................................30
23. Informative References.........................................30
24. Author's Addresses.............................................31
Expires 14th August 2004 Cheshire & Krochmal [Page 2]
Internet Draft DNS-Based Service Discovery 14th February 2004
1. Introduction
This document describes a convention for naming and structuring DNS
resource records. Given a type of service that a client is looking
for, and a domain in which the client is looking for that service,
this convention allows clients to discover a list of named instances
of a that desired service, using only standard DNS queries. In short,
this is referred to as DNS-based Service Discovery, or DNS-SD.
This document proposes no change to the structure of DNS messages,
and no new operation codes, response codes, resource record types,
or any other new DNS protocol values. This document simply proposes
a convention for how existing resource record types can be named and
structured to facilitate service discovery.
This proposal is entirely compatible with today's existing unicast
DNS server and client software.
Note that the DNS-SD service does NOT have to be provided by the same
DNS server hardware that is currently providing an organization's
conventional host name lookup service (the service we traditionally
think of when we say "DNS"). By delegating the "_tcp" subdomain, all
the workload related to DNS-SD can be offloaded to a different
machine. This flexibility, to handle DNS-SD on the main DNS server,
or not, at the network administrator's discretion, is one of the
things that makes DNS-SD so compelling.
Even when the DNS-SD functions are delegated to a different machine,
the benefits of using DNS remain: It is mature technology, well
understood, with multiple independent implementations from different
vendors, a wide selection of books published on the subject, and an
established workforce experienced in its operation. In contrast,
adopting some other service discovery technology would require every
site in the world to install, learn, configure, operate and maintain
some entirely new and unfamiliar server software. Faced with these
obstacles, it seems unlikely that any other service discovery
technology could hope to compete with the ubiquitous deployment
that DNS already enjoys.
This proposal is also compatible with (but not dependent on) the
proposal outlined in "Multicast DNS" [mDNS].
2. Conventions and Terminology Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC 2119].
Expires 14th August 2004 Cheshire & Krochmal [Page 3]
Internet Draft DNS-Based Service Discovery 14th February 2004
3. Design Goals
A good service discovery protocol needs to have many properties,
three of which are mentioned below:
(i) The ability to query for services of a certain type in a certain
logical domain and receive in response a list of named instances
(network browsing, or "Service Instance Enumeration").
(ii) Given a particular named instance, the ability to efficiently
resolve that instance name to the required information a client needs
to actually use the service, i.e. IP address and port number, at the
very least (Service Name Resolution).
(iii) Instance names should be relatively persistent. If a user
selects their default printer from a list of available choices today,
then tomorrow they should still be able to print on that printer --
even if the IP address and/or port number where the service resides
have changed -- without the user (or their software) having to repeat
the network browsing step a second time.
In addition, if it is to become successful, a service discovery
protocol should be so simple to implement that virtually any
device capable of implementing IP should not have any trouble
implementing the service discovery software as well.
These goals are discussed in more detail in the remainder of this
document. A more thorough treatment of service discovery requirements
may be found in "Requirements for a Protocol to Replace AppleTalk
NBP" [NBP]. That document draws upon examples from two decades of
operational experience with AppleTalk Name Binding Protocol to
develop a list of universal requirements which are broadly applicable
to any potential service discovery protocol.
Expires 14th August 2004 Cheshire & Krochmal [Page 4]
Internet Draft DNS-Based Service Discovery 14th February 2004
4. Service Instance Enumeration
DNS SRV records [RFC 2782] are useful for locating instances of a
particular type of service when all the instances are effectively
indistinguishable and provide the same service to the client.
For example, SRV records with the (hypothetical) name
"_http._tcp.example.com." would allow a client to discover a list of
all servers implementing the "_http._tcp" service (i.e. Web servers)
for the "example.com." domain. The unstated assumption is that all
these servers offer an identical set of Web pages, and it doesn't
matter to the client which of the servers it uses, as long as it
selects one at random according to the weight and priority rules laid
out in RFC 2782.
Instances of other kinds of service are less easily interchangeable.
If a word processing application were to look up the (hypothetical)
SRV record "_ipp._tcp.example.com." to find the list of IPP printers
at Example Co., then picking one at random and printing on it would
probably not be what the user wanted.
The remainder of this section describes how SRV records may be used
in a slightly different way to allow a user to discover the names
of all available instances of a given type of service, in order to
select the particular instance the user desires.
4.1 Structured Instance Names
This document borrows the logical service naming syntax and semantics
from DNS SRV records, but adds one level of indirection. Instead of
requesting records of type "SRV" with name "_ipp._tcp.example.com.",
the client requests records of type "PTR" (pointer from one name to
another in the DNS namespace).
In effect, if one thinks of the domain name "_ipp._tcp.example.com."
as being analogous to an absolute path to a directory in a file
system then the PTR lookup is akin to performing a listing of that
directory to find all the files it contains. (Remember that domain
names are expressed in reverse order compared to path names: An
absolute path name is read from left to right, beginning with a
leading slash on the left, and then the top level directory, then the
next level directory, and so on. A fully-qualified domain name is
read from right to left, beginning with the dot on the right -- the
root label -- and then the top level domain to the left of that, and
the second level domain to the left of that, and so on. If the fully-
qualified domain name "_ipp._tcp.example.com." were expressed as a
file system path name, it would be "/com/example/_tcp/_ipp".)
Expires 14th August 2004 Cheshire & Krochmal [Page 5]
Internet Draft DNS-Based Service Discovery 14th February 2004
The result of this PTR lookup for the name "<Service>.<Domain>" is a
list of zero or more PTR records giving Service Instance Names of the
form:
Service Instance Name = <Instance> . <Service> . <Domain>
The <Instance> portion of the Service Instance Name is a single DNS
label, containing arbitrary UTF-8-encoded text [RFC 2279]. It is a
user-friendly name, meaning that it is allowed to contain any
characters, without restriction, including spaces, upper case, lower
case, punctuation -- including dots -- accented characters, non-roman
text, and anything else that may be represented using UTF-8.
DNS recommends guidelines for allowable characters for host names
[RFC 1033][RFC 1034][RFC 1035], but Service Instance Names are not
host names. Service Instance Names are not intended to ever be typed
in by a normal user; the user selects a Service Instance Name by
selecting it from a list of choices presented on the screen.
Note that just because this protocol supports arbitrary UTF-8-encoded
names doesn't mean that any particular user or administrator is
obliged to make use of that capability. Any user is free, if they
wish, to continue naming their services using only letters, digits
and hyphens, with no spaces, capital letters, or other punctuation.
DNS labels are currently limited to 63 octets in length. UTF-8
encoding can require up to four octets per Unicode character, which
means that in the worst case, the <Instance> portion of a name could
be limited to fifteen Unicode characters. However, the Unicode
characters with longer UTF-8 encodings tend to be the more obscure
ones, and tend to be the ones that convey greater meaning per
character.
Note that any character in the commonly-used 16-bit Unicode space can
be encoded with no more than three octets of UTF-8 encoding. This
means that an Instance name can contain up to 21 Kanji characters,
which is a sufficiently expressive name for most purposes.
The <Service> portion of the Service Instance Name consists of a pair
of DNS labels, following the established convention for SRV records
[RFC 2782], namely: the first label of the service pair is the
application protocol name, as recorded in the IANA list of assigned
application protocol names and port numbers [ports]. The second label
of the service pair is either "_tcp" or "_udp", depending on the
transport protocol used by the application.
The <Domain> portion of the Service Instance Name is a conventional
DNS domain name, consisting of as many labels as appropriate. For
example, "apple.com.", "cs.stanford.edu.", and "eng.us.ibm.com." are
all valid domain names for the <Domain> portion of the Service
Instance Name.
Expires 14th August 2004 Cheshire & Krochmal [Page 6]
Internet Draft DNS-Based Service Discovery 14th February 2004
4.2 User Interface Presentation
The names resulting from the PTR lookup are presented to the user in
a list for the user to select one (or more). Typically only the first
label is shown (the user-friendly <Instance> portion of the name). In
the common case, the <Service> and <Domain> are already known to the
user, these having been provided by the user in the first place, by
the act of indicating the service being sought, and the domain in
which to look for it. Note: The software handling the response
should be careful not to make invalid assumptions though, since it
*is* possible, though rare, for a service enumeration in one domain
to return the names of services in a different domain. Similarly,
when using subtypes (see "Selective Instance Enumeration") the
<Service> of the discovered instance my not be exactly the same as
the <Service> that was requested.
Having chosen the desired named instance, the Service Instance Name
may then be used immediately, or saved away in some persistent
user-preference data structure for future use, depending on what is
appropriate for the application in question.
4.3 Internal Handling of Names
If the <Instance>, <Service> and <Domain> portions are internally
concatenated together into a single string, then care must be taken
with the <Instance> portion, since it is allowed to contain any
characters, including dots.
Any dots in the <Instance> portion should be escaped by preceeding
them with a backslash ("." becomes "\."). Likewise, any backslashes
in the <Instance> portion should also be escaped by preceeding them
with a backslash ("\" becomes "\\"). Having done this, the three
components of the name may be safely concatenated. The
backslash-escaping allows literal dots in the name (escaped) to be
distinguished from label-separator dots (not escaped).
The resulting concatenated string may be safely passed to standard
DNS APIs like res_query(), which will interpret the string correctly
provided it has been escaped correctly, as described here.
4.4 What You See Is What You Get
Some service discovery protocols decouple the true service identifier
from the name presented to the user. The true service identifier used
by the protocol is an opaque unique id, often represented using a
long string of hexadecimal digits, and should never be seen by the
typical user. The name presented to the user is merely one of the
ephemeral attributes attached to this opaque identifier.
Expires 14th August 2004 Cheshire & Krochmal [Page 7]
Internet Draft DNS-Based Service Discovery 14th February 2004
The problem with this approach is that it decouples user perception
from reality:
* What happens if there are two service instances, with different
unique ids, but they have inadvertently been given the same
user-visible name? If two instances appear in an on-screen list
with the same name, how does the user know which is which?
* Suppose a printer breaks down, and the user replaces it with
another printer of the same make and model, and configures the new
printer with the exact same name as the one being replaced:
"Stuart's Printer". Now, when the user tries to print, the
on-screen print dialog tells them that their selected default
printer is "Stuart's Printer". When they browse the network to see
what is there, they see a printer called "Stuart's Printer", yet
when the user tries to print, they are told that the printer
"Stuart's Printer" can't be found. The hidden internal unique id
that the software is trying to find on the network doesn't match
the hidden internal unique id of the new printer, even though its
apparent "name" and its logical purpose for being there are the
same. To remedy this, the user typically has to delete the print
queue they have created, and then create a new (apparently
identical) queue for the new printer, so that the new queue will
contain the right hidden internal unique id. Having all this hidden
information that the user can't see makes for a confusing and
frustrating user experience, and exposing long ugly hexadecimal
strings to the user and forcing them to understand what they mean
is even worse.
* Suppose an existing printer is moved to a new department, and given
a new name and a new function. Changing the user-visible name of
that piece of hardware doesn't change its hidden internal unique
id. Users who had previously created print queues for that printer
will still be accessing the same hardware by its unique id, even
though the logical service that used to be offered by that hardware
has ceased to exist.
To solve these problems requires the user or administrator to be
aware of the supposedly hidden unique id, and to set its value
correctly as hardware is moved around, repurposed, or replaced,
thereby contradicting the notion that it is a hidden identifier that
human users never need to deal with. Requiring the user to unserstand
this expert behind-the-scenes knowledge of what is *really* going on
is just one more burden placed on the user when they are trying to
diagnose why their computers and network devices are not working as
expected.
These anomalies and counter-intuitive behaviours can be eliminated by
maintaining a tight bidirectional one-to-one mapping between what the
user sees on the screen and what is really happening "behind the
Expires 14th August 2004 Cheshire & Krochmal [Page 8]
Internet Draft DNS-Based Service Discovery 14th February 2004
curtain". If something is configured incorrectly, then that is
apparent in the familiar day-to-day user interface that everyone
understands, not in some little-known rarely-used "expert" interface.
In summary: The user-visible name is the primary identifier for a
service. If the user-visible name is changed, then conceptually the
service being offered is a different logical service -- even though
the hardware offering the service stayed the same. If the
user-visible name doesn't change, then conceptually the service being
offered is the same logical service -- even if the hardware offering
the service is new hardware brought in to replace some old equipment.
There are certainly arguments on both sides of this debate.
Nonetheless, the designers of any service discovery protocol have
to make a choice between between having the primary identifiers be
hidden, or having them be visible, and these are the reasons that we
chose to make them visible. We're not claiming that there are no
disadvantages of having primary identifiers be visible. We considered
both alternatives, and we believe that the few disadvantages
of visible identifiers are far outweighed by the many problems
caused by use of hidden identifiers.
4.5 Ordering of Service Instance Name Components
There have been questions about why services are named using DNS
Service Instance Names of the form:
Service Instance Name = <Instance> . <Service> . <Domain>
instead of:
Service Instance Name = <Service> . <Instance> . <Domain>
There are three reasons why it is beneficial to name service
instances with the parent domain as the most-significant (rightmost)
part of the name, then the abstract service type as the nextmost
significant, and then the specific instance name as the
least-significant (leftmost) part of the name:
4.5.1. Semantic Structure
The facility being provided by browsing ("Service Instance
Enumeration") is effectively enumerating the leaves of a tree
structure. A given domain offers zero or more services. For each of
those service types, there may be zero or more instances of that
service.
Expires 14th August 2004 Cheshire & Krochmal [Page 9]
Internet Draft DNS-Based Service Discovery 14th February 2004
The user knows what type of service they are seeking. (If they are
running an FTP client, they are looking for FTP servers. If they have
a document to print, they are looking for entities that speak some
known printing protocol.) The user knows in which organizational or
geographical domain they wish to search. (The user does not want a
single flat list of every single printer on the planet, even if such
a thing were possible.) What the user does not know in advance is
whether the service they seek is offered in the given domain, or if
so, how many instances are offered, and the names of those instances.
Hence having the instance names be the leaves of the tree is
consistent with this semantic model.
Having the service types be the terminal leaves of the tree would
imply that the user knows the domain name, and already knows the
name of the service instance, but doesn't have any idea what the
service does. We would argue that this is a less useful model.
4.5.2. Network Efficiency
When a DNS response contains multiple answers, name compression works
more effectively if all the names contain a common suffix. If many
answers in the packet have the same <Service> and <Domain>, then each
occurrence of a Service Instance Name can be expressed using only the
<Instance> part followed by a two-byte compression pointer
referencing a previous appearance of "<Service>.<Domain>". This
efficiency would not be possible if the <Service> component appeared
first in each name.
4.5.3. Operational Flexibility
This name structure allows subdomains to be delegated along logical
service boundaries. For example, the network administrator at Example
Co. could choose to delegate the "_tcp.example.com." subdomain to a
different machine, so that the machine handling service discovery
doesn't have to be the same as the machine handling other day-to-day
DNS operations. (It *can* be the same machine if the administrator so
chooses, but the point is that the administrator is free to make that
choice.) Furthermore, if the network administrator wishes to delegate
all information related to IPP printers to a machine dedicated to
that specific task, this is easily done by delegating the
"_ipp._tcp.example.com." subdomain to the desired machine. It is also
convenient to set security policies on a per-zone/per-subdomain
basis. For example, the administrator may choose to enable DNS
Dynamic Update [RFC 2136] [RFC 3007] for printers registering in the
"_ipp._tcp.example.com." subdomain, but not for other
zones/subdomains. This easy flexibility would not exist if the
<Service> component appeared first in each name.
Expires 14th August 2004 Cheshire & Krochmal [Page 10]
Internet Draft DNS-Based Service Discovery 14th February 2004
5. Service Name Resolution
Given a particular Service Instance Name, when a client needs to
contact that service, it sends a DNS query for the SRV record of
that name.
The result of the DNS query is a SRV record giving the port number
and target host where the service may be found.
The use of SRV records is very important. There are only 65535 TCP
port numbers available. These port numbers are being allocated
one-per-application-protocol at an alarming rate. Some protocols like
the X Window System have a block of 64 TCP ports allocated
(6000-6063). If we start allocating blocks of 64 TCP ports at a time,
we will run out even faster. Using a different TCP port for each
different instance of a given service on a given machine is entirely
sensible, but allocating large static ranges, as was done for X, is a
very inefficient way to manage a limited resource. On any given host,
most TCP ports are reserved for services that will never run on that
particular host. This is very poor utilization of the limited port
space. Using SRV records allows each host to allocate its available
port numbers dynamically to those services running on that host that
need them, and then advertise the allocated port numbers via SRV
records. Allocating the available listening port numbers locally
on a per-host basis as needed allows much better utilization of the
available port space than today's centralized global allocation.
In some environments there may be no compelling reason to assign
managed names to every host, since every available service is
accessible by name anyway, as a first-class entity in its own right.
However, the DNS packet format and record format still require a host
name to link the target host referenced in the SRV record to the
address records giving the IPv4 and/or IPv6 addresses for that
hardware. In the case where no natural host name is available, the
SRV record may give its own name as the name of the target host, and
then the requisite address records may be attached to that same name.
It is perfectly permissible for a single name in the DNS hierarchy to
have multiple records of different type attached. (The only
restriction being that a given name may not have both a CNAME record
and other records at the same time.)
In the event that more than one SRV is returned, clients MUST
correctly interpret the priority and weight fields -- i.e. Lower
numbered priority servers should be used in preference to higher
numbered priority servers, and servers with equal priority should be
selected randomly in proportion to their relative weights.
Expires 14th August 2004 Cheshire & Krochmal [Page 11]
Internet Draft DNS-Based Service Discovery 14th February 2004
6. Data Syntax for DNS-SD TXT Records
Some services discovered via Service Instance Enumeration may need
more than just an IP address and port number to properly identify the
service. For example, printing via the LPR protocol often specifies a
queue name. This queue name is typically short and cryptic, and need
not be shown to the user. It should be regarded the same way as the
IP address and port number -- it is one component of the addressing
information required to identify a specific instance of a service
being offered by some piece of hardware. Similarly, a file server may
have multiple volumes, each identified by its own volume name. A Web
server typically has multiple pages, each identified by its own URL.
In these cases, the necessary additional data is stored in a TXT
record with the same name as the SRV record. The specific nature of
that additional data, and how it is to be used, is service-dependent,
but the overall syntax of the data in the TXT record is standardized,
as described below.
6.1 General Format Rules for DNS TXT Records
A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total
length is indicated by the length given in the resource record header
in the DNS message. There is no way to tell directly from the data
alone how long it is (e.g. there is no length count at the start, or
terminating NULL byte at the end). (Note that when using Multicast
DNS [mDNS] the maximum packet size is 9000 bytes, which imposes an
upper limit on the size of TXT records of about 8800 bytes.)
The format of the data within a DNS TXT record is zero or more
strings, packed together in memory without any intervening gaps or
padding bytes for word alignment.
The format of each constituent string within the DNS TXT record is a
single length byte, followed by 0-255 bytes of text data.
These format rules are defined in Section 3.3.14 of RFC 1035, and are
not specific to DNS-SD. DNS-SD simply specifies a usage convention
for what data should be stored in those constituent strings.
6.2 DNS TXT Record Format Rules for use in DNS-SD
DNS-SD uses DNS TXT records to store arbitrary name/value pairs
conveying additional information about the named service. Each
name/value pair is encoded as its own constituent string within the
DNS TXT record, in the form "name=value". Everything up to the first
'=' character is the name. Everything after the first '=' character
to the end of the string (including subsequent '=' characters, if
any) is the value. Specific rules governing names and values are
given below. Each author defining a DNS-SD profile for discovering
Expires 14th August 2004 Cheshire & Krochmal [Page 12]
Internet Draft DNS-Based Service Discovery 14th February 2004
instances of a particular type of service should define the base set
of name/value attributes that are valid for that type of service.
Using this standardized name/value syntax within the TXT record makes
it easier for these base definitions to be expanded later by defining
additional named attributes. If an implementation sees unknown
attribute names in a service TXT record, it MUST silently ignore them.
The TCP (or UDP) port number of the service, and target host name,
are given in the SRV record. This information -- target host name and
port number -- MUST NOT be duplicated using name/value attributes in
the TXT record.
The intention of DNS-SD TXT records is to convey a small amount of
useful additional information about a service. Ideally it SHOULD NOT
be necessary for a client to retrieve this additional information
before it can usefully establish a connection to the service. For a
well-designed TCP-based application protocol, it should be possible,
knowing only the host name and port number, to open a connection to
that listening process, and then perform version- or feature-
negotiation to determine the capabilities of the service instance.
For example, when connecting to an AppleShare server over TCP, the
client enters into a protocol exchange with the server to determine
which version of the AppleShare protocol the server implements, and
which optional features or capabilities (if any) are available. For a
well-designed application protocol, clients should be able to connect
and use the service even if there is no information at all in the TXT
record. In this case, the information in the TXT record should be
viewed as a performance optimization -- when a client discovers many
instances of a service, the TXT record allows the client to know some
rudimentary information about each instance without having to open a
TCP connection to each one and interrogate every service instance
separately. Extreme care should be taken when doing this to ensure
that the information in the TXT record is in agreement with the
information retrieved by a client connecting over TCP.
There are legacy protocols which provide no feature negotiation
capability, and in these cases it may be useful to convey necessary
information in the TXT record. For example, when printing using the
old Unix LPR (port 515) protocol, the LPR service provides no way for
the client to determine whether a particular printer accepts
PostScript, or what version of PostScript, etc. In this case it is
appropriate to embed this information in the TXT record, because the
alternative is worse -- passing around written instructions to the
users, arcane manual configuration of "/etc/printcap" files, etc.
Expires 14th August 2004 Cheshire & Krochmal [Page 13]
Internet Draft DNS-Based Service Discovery 14th February 2004
6.3 DNS-SD TXT Record Size
The total size of a typical DNS-SD TXT record is intended to be small
-- 200 bytes or less.
In cases where more data is justified (e.g. LPR printing), keeping
the total size under 400 bytes should allow it to fit in a single
standard 512-byte DNS message. (This standard DNS message size is
defined in RFC 1035.)
In extreme cases where even this is not enough, keeping the size of
the TXT record under 1300 bytes should allow it to fit in a single
1500-byte Ethernet packet.
Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this
time.
6.4 Rules for Names in DNS-SD Name/Value Pairs
The "Name" MUST be at least one character. Strings beginning with an
'=' character (i.e. the name is missing) SHOULD be silently ignored.
The characters of "Name" MUST be printable US-ASCII values
(0x20-0x7E), excluding '=' (0x3D).
Spaces in the name are significant, whether leading, trailing, or in
the middle -- so don't include any spaces unless you really intend
that!
Case is ignored when interpreting a name, so "papersize=A4",
"PAPERSIZE=A4" and "Papersize=A4" are all identical.
If there is no '=', then it is a boolean attribute, and is simply
identified as being present, with no value.
Unless specified otherwise by a particular DNS-SD profile, a given
attribute name may appear at most once in a TXT record. If a client
receives a TXT record containing the same attribute name more than
once, then the client SHOULD silently ignore all but the first
occurrence of that attribute. For client implementations that process
a DNS-SD TXT record from start to end, placing name/value pairs into
a hash table, using the name as the hash table key, this means that
if the implementation attempts to add a new name/value pair into the
table and finds an entry with the same name already present, then the
new entry being added should be silently discarded instead. For
client implementations that retrieve name/value pairs by searching
the TXT record for the requested name, they should search the TXT
record from the start, and simply return the first matching name they
find.
Expires 14th August 2004 Cheshire & Krochmal [Page 14]
Internet Draft DNS-Based Service Discovery 14th February 2004
When examining a TXT record for a given named attribute, there are
therefore four broad categories of results which may be returned:
* Attribute not present (Absent)
* Attribute present, with no value
(e.g. "Anon Allowed" -- server allows anonymous connections)
* Attribute present, with empty value (e.g. "Installed PlugIns=" --
server supports plugins, but none are presently installed)
* Attribute present, with non-empty value
(e.g. "Installed PlugIns=JPEG,MPEG2,MPEG4")
Each author defining a DNS-SD profile for discovering instances of a
particular type of service should define the interpretation of these
different kinds of result. For example, for some keys, there may be
a natural true/false boolean interpretation:
* Present implies 'true'
* Absent implies 'false'
For other keys it may be sensible to define other semantics, such as
value/no-value/unknown:
* Present with value implies that value.
E.g. "Color=4" for a four-color ink-jet printer,
or "Color=6" for a six-color ink-jet printer.
* Present with empty value implies 'false'. E.g. Not a color printer.
* Absent implies 'Unknown'. E.g. A print server connected to some
unknown printer where the print server doesn't actually know if the
printer does color or not -- which gives a very bad user experience
and should be avoided wherever possible.
(Note that this is a hypothetical example, not an example of actual
name/value keys used by DNS-SD network printers.)
As a general rule, attribute names that contain no dots are defined
as part of the open-standard definition written by the person or
group defining the DNS-SD profile for discovering that particular
service type. Vendor-specific extensions should be given names of the
form "keyname.company.com=value", using a domain name legitimately
registered to the person or organization creating the vendor-specific
key. This reduces the risk of accidental conflict if different
organizations each define their own vendor-specific keys.
Expires 14th August 2004 Cheshire & Krochmal [Page 15]
Internet Draft DNS-Based Service Discovery 14th February 2004
6.5 Rules for Values in DNS-SD Name/Value Pairs
If there is an '=', then everything after the first '=' to the end of
the string is the value. The value can contain any eight-bit values
including '='. Leading or trailing spaces are part of the value, so
don't put them there unless you intend them to be there. Any
quotation marks around the value are part of the value, so don't put
them there unless you intend them to be part of the value.
The value is opaque binary data. Often the value for a particular
attribute will be US-ASCII (or UTF-8) text, but it is legal for a
value to be any binary data. For example, if the value of a key is an
IPv4 address, that address should simply be stored as four bytes of
binary data, not as a variable-length 7-15 byte ASCII string giving
the address represented in textual dotted decimal notation.
Generic debugging tools should generally display all attribute values
as a hex dump, with accompanying text alongside displaying the UTF-8
interpretation of those bytes, except for attributes where the
debugging tool has embedded knowledge that the value is some other
kind of data.
Authors defining DNS-SD profiles SHOULD NOT convert binary attribute
data types into printable text (e.g. using hexadecimal, Base64 or UU
encoding) merely for the sake of making the data be printable text
when seen in a generic debugging tool. Doing this simply bloats the
size of the TXT record, without atually making the data any more
understandable to someone looking at it in a generic debugging tool.
6.6 Example TXT Record
The TXT record below contains three syntactically valid name/value
pairs. (The meaning of these name/value pairs, if any, would depend
on the definitions pertaining to the service in question that is
using them.)
---------------------------------------------------------------
| 0x0A | name=value | 0x08 | paper=A4 | 0x0E | DNS-SD Is Cool |
---------------------------------------------------------------
Expires 14th August 2004 Cheshire & Krochmal [Page 16]
Internet Draft DNS-Based Service Discovery 14th February 2004
6.7 Version Tag
It is recommended that authors defining DNS-SD profiles include an
attribute of the form "txtvers=xxx" in their definition, and require
it to be the first name/value pair in the TXT record. This
information in the TXT record can be useful to help clients maintain
backwards compatibility with older implementations if it becomes
necessary to change or update the specification over time. Even if
the profile author doesn't anticipate the need for any future
incompatible changes, having a version number in the specification
provides useful insurance should incompatible changes become
unavoidable. Clients SHOULD ignore TXT records with a txtvers number
higher (or lower) than the version(s) they know how to interpret.
Note that the version number in the txtvers tag describes the version
of the TXT record specification being used to create this TXT record,
not the version of the application protocol that will be used if the
client subsequently decides to contact that service. Ideally, every
DNS-SD TXT record specification starts at txtvers=1 and stays that
way forever. Improvements can be made by defining new keys that older
clients silently ignore. The only reason to increment the version
number is if the old specification is subsequently found to be so
horribly broken that there's no way to do a compatible forward
revision, so the txtvers number has to be incremented to tell all the
old clients they should just not even try to understand this new TXT
record.
If there is a need to indicate which version number(s) of the
application protocol the service implements, the recommended key
name for this is "protovers".
Expires 14th August 2004 Cheshire & Krochmal [Page 17]
Internet Draft DNS-Based Service Discovery 14th February 2004
7. Application Protocol Names
The <Service> portion of a Service Instance Name consists of a pair
of DNS labels, following the established convention for SRV records
[RFC 2782], namely: the first label of the pair is the Application
Protocol Name, and the second label is either "_tcp" or "_udp".
Wise selection of the Application Protocol Name is very important,
and the choice is not always as obvious as it may appear.