Differences

This shows you the differences between two versions of the page.

--- software:dns-sd [2020/06/26 20:17] – [DNS-Based Service Discovery] superwizard
+++ software:dns-sd [2020/07/20 01:15] (current) – [Other Service Discovery Information] superwizard
@@ Line 129: / Line 129: @@
+====== DNS-Based Service Discovery ======
+<WRAP center round box >
+.  Discovery of Browsing and Registration Domains (Domain Enumeration)
+   One of the motivations for DNS-based Service Discovery is to enable a
+   visiting client (e.g., a Wi-Fi-equipped [IEEEW] laptop computer,
+   tablet, or mobile telephone) arriving on a new network to discover
+   what services are available on that network, without any manual
+   configuration.  The logic that discovering services without manual
+   configuration is a good idea also dictates that discovering
+   recommended registration and browsing domains without manual
+   configuration is a similarly good idea.
+   This discovery is performed using DNS queries, using Unicast or
+   Multicast DNS.  Five special RR names are reserved for this purpose:
+          b._dns-sd._udp.<domain>.
+         db._dns-sd._udp.<domain>.
+          r._dns-sd._udp.<domain>.
+         dr._dns-sd._udp.<domain>.
+         lb._dns-sd._udp.<domain>.
+   By performing PTR queries for these names, a client can learn,
+   respectively:
+   o  A list of domains recommended for browsing.
+   o  A single recommended default domain for browsing.
+   o  A list of domains recommended for registering services using
+      Dynamic Update.
+   o  A single recommended default domain for registering services.
+   o  The "legacy browsing" or "automatic browsing" domain(s).
+      Sophisticated client applications that care to present choices of
+      domain to the user use the answers learned from the previous four
+      queries to discover the domains to present.  In contrast, many
+      current applications browse without specifying an explicit domain,
+      allowing the operating system to automatically select an
+      appropriate domain on their behalf.  It is for this class of
+      application that the "automatic browsing" query is provided, to
+      allow the network administrator to communicate to the client
+      operating systems which domain(s) should be used automatically for
+      these applications.
+</WRAP>
+From: https://tools.ietf.org/html/rfc6763
 ==== DNS-Based Service Discovery ====
@@ Line 258: / Line 309: @@
 Avahi also implements binary compatibility libraries that emulate Bonjour and the historical mDNS implementation Howl, so software made to use those implementations can also utilize Avahi through the emulation interfaces.
 </code>
+<WRAP center round box >
+From: https://simonwheatley.co.uk/2008/04/avahi-finder-icons/
+After my alterations, the file read (I’ve emboldened the new portion):
+<code>
+<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
+<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
+<service-group>
+<name replace-wildcards="yes">%h</name>
+<service>
+<type>_afpovertcp._tcp</type>
+<port>548</port>
+</service>
+<service>
+<type>_device-info._tcp</type>
+<port>0</port>
+<txt-record>model=RackMac</txt-record>
+</service>
+</service-group>
+</code>
+The model information I’ve used, sets the icon to an XServe icon (see the screenshot above). You can determine the model text you need to broadcast for other icons by digging through the Plist at /System/Library/CoreServices/CoreTypes.bundle/Contents/Info.plist.
+</WRAP>