DNS-SD Data Block Encoding for Non-DNS Transports

3.1. Applicability and Directionality

A DDB describes a service being offered by the sender; it is not a request or query for a service. Any seek/query semantics (e.g., a seek/query flag defined by the surrounding transport container's own framing) are properties of that container, not of the DDB payload itself. In particular, a DDB with an absent or empty Instance Name field (see Section 3.4.2) indicates only that no specific instance is being named, not that the sender is seeking rather than providing the service.¶

• OPEN ISSUE: This directionality constraint has not yet been discussed with the working group. If a future revision wants to support DDB content in a query/request role (e.g., a client advertising interest in a service type before association), this section will need to define how that role is distinguished from a service offer.¶

3.2. Block Header

A DDB begins with a single-octet Version field:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Version    |               TLV Fields ...                  |
+-+-+-+-+-+-+-+-+                                               +
|                             ...                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version (1 octet):

The version of this DDB encoding. This specification defines version 0x01. A decoder that encounters an unknown version value SHOULD treat the entire block as uninterpretable and MUST NOT attempt to parse the TLV fields.¶

Additive, backward-compatible extensions SHOULD be introduced by defining new TLV Type values or related registry entries without changing the Version value. The Version value is intended for wire-format or processing changes that are not backward compatible with earlier versions.¶

The remainder of the DDB is a sequence of zero or more TLV fields as defined in Section 3.3.¶

3.3. TLV Field Structure

Each TLV field in a DDB has the following structure:¶

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------//----------+
|     Type      |    Length     |         Value        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------//----------+

Type (1 octet):

Identifies the type of the field. Values are defined in Section 3.4. Value 0xFF is reserved. Values 0x09-0xEF are reserved for future assignment. Values 0xF0-0xFE are available for private/experimental use and MUST NOT be used in interoperability contexts.¶

The special value 0x00 is defined as a padding (NOP) octet. A 0x00 byte in the TLV stream is consumed as a single padding byte with no associated Length or Value fields. Encoders MUST NOT emit padding bytes except when byte-alignment is required by a specific transport framing. Decoders MUST skip 0x00 bytes and continue parsing the next TLV field.¶

Length (1 octet):

The length of the Value field in octets. A Length of 0x00 indicates an empty value (valid for some field types; see individual field definitions).¶

When a length of 255 octets is insufficient for a given field (notably TXT Data for rich service descriptions), the following extended-length encoding is used: if the Length octet is 0xFF, it is followed by two additional octets that carry the actual length as a 16-bit unsigned integer in network byte order, and the Value starts after those two octets. This extended form MUST NOT be used when the actual length is <= 254 octets.¶

Value (Length octets):

The field value. Encoding is field-type-specific; see Section 3.4.¶

TLV fields MUST be processed in the order they appear. Encoders MUST NOT include more than one TLV field with the same Type value. Decoders that encounter duplicate Type values MUST use the last instance and discard earlier ones, in order to remain robust against malformed input.¶

An implementation MUST ignore (skip past) any TLV field whose Type it does not recognize.¶

3.4. Field Type Registry

The following Type values are defined by this specification.¶

A DDB MUST include exactly one Service Name field (Type 0x01); all other field types defined in this registry are optional.¶

01 09                   ; Type=Service Name, Length=9
5F 69 70 70 2E 5F 74 63 ;
70                      ; "_ipp._tcp"

02 10                   ; Type=Instance Name, Length=16
4D 79 20 43 6F 6C 6F 72 ;
20 50 72 69 6E 74 65 72 ; "My Color Printer"

03 2C                   ; Type=TXT Data, Length=44
09                      ; string length 9
74 78 74 76 65 72 73 3D ;
31                      ; "txtvers=1"
14                      ; string length 20
70 64 6C 3D 69 6D 61 67 ;
65 2F 70 77 67 2D 72 61 ;
73 74 65 72             ; "pdl=image/pwg-raster"
0C                      ; string length 12
72 70 3D 69 70 70 2F 70 ;
72 69 6E 74             ; "rp=ipp/print"

04 10                   ; Type=UUID, Length=16
12 34 56 78 12 34 56 78 ;
12 34 56 78 12 34 56 78 ; UUID bytes

3.5. Encoding Rules

1. Begin the DDB with the Version octet (0x01 for this version).¶

2. Encode the Service Name field (Type 0x01) first. This is the primary identifier of what kind of service is being described.¶

3. Encode remaining fields in no required order, though the ordering Service Name -> Instance Name -> TXT -> UUID -> others is RECOMMENDED as it places the most informative fields first, which is useful when receivers truncate parsing on constrained implementations.¶

4. Omit any optional field that has no value to convey, to minimize encoded size.¶

5. All string values are UTF-8 encoded and MUST NOT be null-terminated, except the Hostname field (Section 3.4.8), which is restricted to ASCII as specified in its own field definition. String lengths in TLV Length fields count octets, not characters.¶

6. A single TLV field using extended-length encoding may carry a value of at most 65,535 octets, occupying 1 (Type) + 3 (0xFF escape + 2-octet extended length) + 65,535 (Value) = 65,539 octets. No absolute maximum is imposed on the total DDB length; practical transports impose far tighter limits, and implementations SHOULD reject DDBs that exceed the limit imposed by the transport in use.¶

3.6. Decoding Rules and Forward Compatibility

1. Read the Version octet. If not 0x01, treat the block as uninterpretable (do not attempt TLV parsing).¶

2. Process TLV fields in order. For each field:¶

   a. Read the Type octet. If Type is 0x00, this is a padding byte; consume it and continue to the next field.¶

   b. Read the Length octet. If Length is 0xFF, read the next two octets as a 16-bit big-endian extended length.¶

   c. Read Value octets (count given by the resolved length).¶

   d. If the Type is known, process according to Section 3.4.¶

   e. If the Type is unknown, skip the Value bytes.¶

3. Continue until all octets of the DDB have been consumed.¶

4. A DDB parses successfully as long as its octets form well-formed TLV fields (including a DDB consisting of nothing but padding octets after the Version octet). However, a decoded DDB that contains no Service Name field (Type 0x01) is not a conformant DDB per Section 3.4 and MUST be discarded by the receiver. Implementations MUST NOT generate a DDB lacking a Service Name field.¶

5. A DDB that is truncated (insufficient octets to complete the current TLV) MUST be treated as malformed; already-decoded fields MAY be used at the discretion of the application.¶

3.7. DDB Payload Identity and Media Types

The canonical DDB payload is the exact octet sequence defined by Section 3.7, Paragraph 2: one Version octet followed by zero or more TLV fields. A container that carries a DDB carries this payload without altering its internal format.¶

4.1. Deriving DNS-SD Records from a DDB

Given a DDB and an IP address for the device, a client can synthesize the corresponding PTR, SRV, and TXT records using the owner-name conventions of [RFC6763], Section 4.1, with the domain defaulting to "local" if the Domain field is absent:¶

PTR record:

RDATA is the Service Instance Name, built from the Instance Name, Service Name, and domain.¶

SRV record:

RDATA is <priority> <weight> <port> <hostname>, using the Port field and, if present, the Hostname field (Type 0x08) as the target. If Hostname is absent, the SRV target is not known until DNS-SD is queried after IP association.¶

TXT record:

RDATA is the TXT Data field verbatim.¶

If the UUID field is present but the TXT Data field does not already contain a "UUID=..." key=value pair, a client SHOULD synthesize the UUID TXT record key from the binary UUID (formatted as a lowercase hyphen-separated hex string) and add it to the reconstructed TXT record.¶

4.2. Constructing a DDB from DNS-SD Records

To serialize DNS-SD records into a DDB: set Version = 0x01; extract the Service Name and Instance Name from the PTR and Service Instance Name; copy the TXT record RDATA verbatim into TXT Data (extracting a "UUID" key into the UUID field, if present); copy Port from the SRV record; copy the SRV target hostname into Hostname (Type 0x08) if pre-connection hostname knowledge is needed; and omit Domain if it is "local".¶

4.3. Domain Handling

The Domain field SHOULD be omitted when the domain is "local", and MUST be included otherwise (e.g., for Wide-Area DNS-SD per [RFC6763], Section 11). A DDB decoder that finds no Domain field MUST assume "local".¶

5.1. Minimal Printer Service DDB

This DDB conveys only the Service Name, sufficient for a "this device provides IPP printing" beacon:¶

01                       ; Version = 1
01 09                    ; Type=Service Name, Length=9
5F 69 70 70 2E 5F 74 63 ;
70                       ; "_ipp._tcp"

Total: 12 octets.¶

5.2. Full Printer Service DDB with TXT and UUID

A more complete DDB for an IPP printer named "Conference Room Printer" (23 UTF-8 octets):¶

01                       ; Version = 1

01 09                    ; Type=Service Name, Length=9
5F 69 70 70 2E 5F 74 63 ;
70                       ; "_ipp._tcp"

02 17                    ; Type=Instance Name, Length=23
43 6F 6E 66 65 72 65 6E ;
63 65 20 52 6F 6F 6D 20 ;
50 72 69 6E 74 65 72     ; "Conference Room Printer"

03 2C                    ; Type=TXT Data, Length=44
09                       ; string length 9
74 78 74 76 65 72 73 3D ;
31                       ; "txtvers=1"
14                       ; string length 20
70 64 6C 3D 69 6D 61 67 ;
65 2F 70 77 67 2D 72 61 ;
73 74 65 72              ; "pdl=image/pwg-raster"
0C                       ; string length 12
72 70 3D 69 70 70 2F 70 ;
72 69 6E 74              ; "rp=ipp/print"

04 10                    ; Type=UUID, Length=16
A1 B2 C3 D4 E5 F6 07 08 ;
89 9A AB BC CD DE EF F0  ; UUID bytes

06 02                    ; Type=Port, Length=2
02 7F                    ; port 631 (0x027F)

Total: 1 + (2+9) + (2+23) + (2+44) + (2+16) + (2+2) = 105 octets.¶

6.1. Why TLV and Not CBOR or JSON

CBOR [RFC8949] and JSON [RFC8259] are both viable encoding options with good tooling. TLV was chosen for the following reasons:¶

• Minimal overhead per field: a simple string field costs 2 octets of overhead (Type + Length) versus CBOR's 1+ octets for a key plus 1+ octets for the string header -- comparable at small scale, but TLV's fixed 2-octet overhead per field is more predictable.¶

• Implementation simplicity: TLV parsing requires only arithmetic on byte arrays; no recursive descent or schema lookup is needed. This supports implementation on very constrained devices (e.g., embedded firmware).¶

• DNS-SD TXT data is already in a length-prefixed string encoding; embedding it verbatim in a TLV field avoids any re-encoding.¶

• CBOR is a strong alternative and SHOULD be explored in a future revision, particularly if the broader IETF context moves toward CBOR-based service advertisement encodings.¶

6.2. Why DNS-SD String Encoding and Not Numeric Types

An alternative design would replace the human-readable Service Name string with a compact numeric identifier (similar to how Bluetooth has 16-bit Service Class UUIDs). This was considered and rejected for the following reasons:¶

• DNS-SD's value proposition is that service names are declared using DNS labels, which are human-readable and do not require a centralized numeric registry for new service names.¶

• Introducing numeric type codes would require an IANA registry cross-referencing DNS-SD service names, tying the DDB format to an ongoing registration process.¶

• The string representation is compact enough for the vast majority of service names (e.g., "_ipp._tcp" is 9 octets).¶

The UUID field (Type 0x04) uses a binary encoding (16 octets) rather than the hyphenated ASCII form (36 octets) because the numeric form saves 20 octets and is unambiguously reversible.¶

6.3. Why TLV Type Values Are Not DNS RR TYPE Values

An alternative design would assign TLV Type values from the DNS RR TYPE registry itself (e.g., using 16 for a TXT Data field, mirroring the wire-format TYPE value assigned to TXT records), rather than defining a separate registry in Section 3.4. This was considered and rejected for the following reasons:¶

• Most DDB fields do not correspond to a whole DNS resource record. Instance Name, UUID, Port, and Domain are individual components extracted from SRV, TXT, and PTR RDATA, not complete records, so they have no DNS RR TYPE value to borrow. Only TXT Data has a clean one-to-one correspondence.¶

• The DNS RR TYPE namespace is a 16-bit space administered by IANA for an unrelated purpose (identifying resource record types generally), and is not guaranteed to stay within 1 octet: for example, CAA is assigned TYPE 257. Tying the DDB Type field to that registry would risk outgrowing the field's 1-octet width for reasons entirely outside this document's control.¶

• A DDB-specific registry (Section 7) keeps the Type namespace small, dense, and scoped to exactly the fields this format defines, which is more appropriate for a constrained, self-contained encoding.¶

6.4. TXT Record Encoding

Reusing the DNS TXT RDATA wire format for the TXT Data field means that existing DNS-SD TXT record parsers can process this field without modification. An alternative was to encode each key=value pair as a separate TLV sub-field; this was rejected as it would add complexity and would not reduce size for typical TXT records.¶

7.1. DNS-SD Data Block TLV Type Registry

IANA is requested to create a new registry "DNS-SD Data Block TLV Types" under a new "DNS-SD Data Block" registry group. The registry uses the following columns:¶

Value:

1-octet TLV Type value.¶

Name:

Short descriptive name of the field.¶

Reference:

RFC or other document defining the field.¶

Notes:

Additional information.¶

Registration Policy: Values 0x01-0xEF use "Specification Required" [RFC8126]. Values 0xF0-0xFE are "Private Use". Value 0xFF is "Reserved". Value 0x00 is defined as a Padding (NOP) octet (Section 3.3) and does not participate in the assignment pool.¶

Initial entries (defined by this specification):¶

7.2. MIME Type Registration

A request to register the MIME media type "application/vnd.dnssd.ddb", identifying the DDB payload defined in Section 3.7, should be submitted to IANA per [RFC6838]. This specification does not formally request that registration at this draft stage.¶

8.1. Spoofing and Impersonation

Any device within range of the carrying transport can transmit a DDB claiming any Service Name, Instance Name, or UUID. Receivers MUST NOT rely on DDB content alone to establish trust. A DDB is a discovery aid; any security-relevant properties (authentication, authorization) MUST be established over the application protocol after connectivity is established (e.g., TLS over IPP, 802.1X, device attestation).¶

8.2. Privacy: Persistent Identifiers

The UUID field, if reused across proximity events, constitutes a stable identifier that can be used to track a device's location or owner. Devices SHOULD use randomized UUIDs for DDBs carried in broadcast advertising if the service UUID is not already stable (e.g., print services that expose a stable mDNS UUID publicly may choose to accept this). This mirrors similar address- and identifier-randomization considerations found in other short-range broadcast technologies: a persistent service identifier in an advertisement creates the same tracking surface as a persistent link-layer address.¶

The Instance Name often contains human-readable device names (e.g., "Jane's MacBook Printer") which are personally identifying. Devices SHOULD allow users to customize or omit Instance Names in proximity advertisements.¶

8.3. Denial of Service

A malicious sender can flood receivers with large numbers of DDB-carrying advertisements or messages. Receivers SHOULD implement rate limiting and deduplication.¶

8.4. Data Integrity

DDB transport containers typically do not provide cryptographic integrity protection. An on-path attacker in close physical proximity could modify advertisement contents. Applications that require integrity SHOULD sign DDB content using an application-layer digital signature (e.g., a device certificate or vendor-defined signing mechanism) conveyed out-of-band or in a companion record, if the transport and deployment context support it.¶

8.5. Sensitive Data in TXT Records

The TXT Data field can carry arbitrary key=value pairs. Senders MUST NOT include long-lived secrets (Wi-Fi PSKs, passwords, private keys) in the TXT Data field of a DDB, as this data is transmitted in cleartext over short-range radio.¶

9.1. Normative References

[RFC1035]

Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC5891]

Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/rfc/rfc5891>.

[RFC6335]

Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/rfc/rfc6335>.

[RFC6763]

Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/rfc/rfc6763>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/rfc/rfc9562>.

9.2. Informative References

[BT-TDS]

Bluetooth SIG, "Transport Discovery Service 1.1", 2020, <https://www.bluetooth.com/specifications/specs/transport-discovery-service-1-1/>.

[IPPEVE]

ISTO Printer Working Group, "PWG 5100.14-2020: IPP Everywhere v1.1", Version 1.1, 2020, <https://ftp.pwg.org/pub/pwg/candidates/cs-ippeve11-20200515-5100.14.pdf>.

[NFC-VERB]

NFC Forum, "Verb RTD Technical Specification", Version 1.0, 2015, <https://nfc-forum.org/build/specifications/>.

[RFC4122]

Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/rfc/rfc4122>.

[RFC6762]

Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/rfc/rfc6762>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC7558]

Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, "Requirements for Scalable DNS-Based Service Discovery (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, DOI 10.17487/RFC7558, July 2015, <https://www.rfc-editor.org/rfc/rfc7558>.

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.