Table of Contents
dns-sd nslookup queries OSX
macserver1:~ admin$ nslookup -type=any _smb._tcp.power.local 192.168.1.2 Server: 192.168.1.2 Address: 192.168.1.2#53 _smb._tcp.power.local name = server4._smb._tcp.power.local. _smb._tcp.power.local name = server3._smb._tcp.power.local. _smb._tcp.power.local name = server6._smb._tcp.power.local. _smb._tcp.power.local name = server1._smb._tcp.power.local. _smb._tcp.power.local name = server5._smb._tcp.power.local.
macserver:~ admin$ nslookup -type=any server4._smb._tcp.power.local 192.168.1.2 Server: 192.168.1.2 Address: 192.168.1.2#53 server4._smb._tcp.power.local text = "null" server4._smb._tcp.power.local service = 0 0 445 server4.power.local.
macserver:~ admin$ host -t PTR _smb._tcp.power.local _smb._tcp.power.local domain name pointer server4._smb._tcp.power.local. _smb._tcp.power.local domain name pointer server3._smb._tcp.power.local. _smb._tcp.power.local domain name pointer server6._smb._tcp.power.local. _smb._tcp.power.local domain name pointer server1._smb._tcp.power.local. _smb._tcp.power.local domain name pointer server5._smb._tcp.power.local.
Adding a cifs server or file service can be registered statically
servername._smb._tcp.zone TXT "model=RackMac" servername._smb._tcp.zone has SRV record 0 0 445 servername _smb._tcp.zone PTR servername._smb._tcp.zone More Specifically: server1._smb._tcp.domain.com TXT "model=RackMac" server1._smb._tcp.domain.com SRV record 0 0 445 server1.domain.com. _smb._tcp.domain.com PTR server1._smb._tcp.domain.com. Second Example: ; To direct clients to browse a different domain, substitute that domain in place of '@' lb._dns-sd._udp PTR @ (fully: lb.dns-sd.udp.domain.com. PTR @) ; In the list of services below, the SRV records will typically reference dot-local Multicast DNS names. ; When transferring this zone file data to your unicast DNS server, you'll need to replace those dot-local ; names with the correct fully-qualified (unicast) domain name of the target host offering the service. _smb._tcp PTR FILESERVER._smb._tcp (fully: _smb._tcp.domain.com. PTR server1._smb._tcp.domain.com.) FILESERVER._smb._tcp.domain.com. SRV 0 0 445 FILESERVER.localdomain. ; Replace with unicast FQDN of target host (fully: server1._smb._tcp.domain.com. SRV 0 0 445 server1.domain.com.) FILESERVER._smb._tcp TXT "netbios=" (fully: server1._smb._tcp.domain.com. TXT "netbios=") FILESERVER IN A 126.96.36.199 (fully: server1.domain.com. A 188.8.131.52)
DNS-SD or DNS-based Service Discovery
DNS-SD also wide area bonjour
Multicast DNS (mDNS) is a protocol that uses APIs similar to unicast Domain Name System but implemented over a multicast protocol. Each computer on the LAN stores its own list of DNS resource records (e.g., A, MX, SRV) and joins the mDNS multicast group. When an mDNS client wants to know the IP address of a computer given its name, mDNS client sends a request to a well-known multicast address; the computer with the corresponding A record replies with its IP address. The mDNS multicast address is 184.108.40.206 for IPv4 and ff02::fb for IPv6 link-local addressing.
DNS-based service discovery (DNS-SD) is the other half of Apple's solution, built on top of the Domain Name System; see RFC 6763. It is used in Apple products, many network printers and a number of third party products and applications on various operating systems. The Apple solution uses DNS messages, in contrast to Microsoft's competing technology, SSDP, which uses HTTP messages. It uses DNS SRV, TXT, and PTR records to advertise Service Instance Names.
"Multicast DNS", it should be taken to mean: "Clients performing DNS-like queries for DNS-like resource records by sending DNS-like UDP query and response messages over IP Multicast to UDP port 5353".
Understanding Apple's Back to My Mac (BTMM) Service
BTMM allows the user to connect to any Mac hosts with a click, after which the user can share files with remote computers or control the remote host through screen sharing. When a user changes locations and thus also changes the IP address of his computer (e.g., roaming around with a laptop and receiving dynamically allocated IP address), BTMM provides a means for the roaming host to update its reachability information to keep it reachable by the user's other Mac devices. BTMM achieves the above functions mainly by integrating a set of existing protocols and software tools. It uses DNS-based Service Discovery [DNS-SD] to announce host reachability information, dynamic DNS update [RFC2136] to refresh the DNS resource records (RRs) when a host detects network changes, and DNS Long-Lived Queries (LLQs) [DNS-LLQ] to notify hosts immediately when the answers to their earlier DNS queries have changed. BTMM uses the IPv6 Unique Local Address (ULA) [RFC4193] as the host identifier and employs the NAT Port Mapping Protocol (PMP) [NAT-PMP] to assist NAT traversal. It uses Kerberos [RFC4120] for end-to-end authentication and uses IPsec [RFC4301] to secure data communications between two end hosts.
DNS-Based Service Discovery
11. 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.
DNS-Based Service Discovery
However, for problem diagnosis and network management tools, it may be useful for network administrators to find the list of advertised service types on the network, even if those Service Names are just opaque identifiers and not particularly informative in isolation. For this purpose, a special meta-query is defined. A DNS query for PTR records with the name "_services._dns-sd._udp.<Domain>" yields a set of PTR records, where the rdata of each PTR record is the two- label <Service> name, plus the same domain, e.g., "_http._tcp.<Domain>". Discovery of Browsing and Registration Domains (Domain Enumeration) 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>. b._dns-sd._udp IN PTR @ ; b = browse domain lb._dns-sd._udp IN PTR @ ; lb = legacy browse domain
This document specifies that a particular service instance can be described using a DNS SRV [RFC2782] and DNS TXT [RFC1035] record. The SRV record has a name of the form "<Instance>.<Service>.<Domain>" and gives the target host and port where the service instance can be reached. The DNS TXT record of the same name gives additional information about this instance, in a structured form using key/value pairs, described in Section 6. A client discovers the list of available instances of a given service type using a query for a DNS PTR [RFC1035] record with a name of the form "<Service>.<Domain>", which returns a set of zero or more names, which are the names of the aforementioned DNS SRV/TXT record pairs. The <Service> portion of a Service Instance Name consists of a pair of DNS labels, The first label of the pair is an underscore character followed by the Service Name [RFC6335]. The Service Name identifies what the service does and what application protocol it uses to do it. For applications using TCP, the second label is "_tcp". For applications using any transport protocol other than TCP, the second label is "_udp". _smb._tcp.zone PTR servername._smb._tcp.zone servername._smb._tcp.zone TXT "model=RackMac" servername._smb._tcp.zone SRV 0 0 445 servername See: http://itscribbles.blogspot.com/2013/05/bonjour-and-dns-sd.html
And Of Course you need A (AAAA) and PTR records
Configuring DNS to share Bonjour printers across subnets and VLANs (including AirPrint for iOS)
First you need to setup the DNS server be “DNS Service Discovery” enabled – to accept DNS Service Records (in a database) and to enable clients to search your domain. This only needs to be performed once on the DNS server. This tutorial contains specific information for Microsoft DNS server, however if you want greater enhancement of this service look at BIND9.
Other Service Discovery Information
Following the failure of LLMNR to become an Internet standard, Apple was asked by the IETF to submit the mDNS/DNS-SD specs for publication as informational RFC as well, given that mDNS/DNS-SD is used much more widely than LLMNR. In February 2013 mDNS and DNS-SD were published as Standards Track Proposals RFC 6762 and RFC 6763.
Microsoft's UPnP SSDP Simple Service Discovery Protocol (SSDP) is a UPnP protocol, used in MS Windows XP and several brands of network equipment. SSDP uses HTTP notification announcements that give a service-type URI and a Unique Service Name (USN). Service types are regulated by the Universal Plug and Play Steering Committee. SSDP is supported in many SOHO firewall appliances, where host computers behind it may pierce holes for applications. It is also used in media center systems, where media exchange between host computers and the media center is facilitated using SSDP.
Major implementations Apple Bonjour Bonjour from Apple Inc., uses multicast DNS and DNS Service Discovery. Apple changed its preferred zeroconf technology from SLP to mDNS and DNS-SD between Mac OS X 10.1 and 10.2, though SLP continues to be supported by Mac OS X. Avahi Avahi is a Zeroconf implementation for Linux and BSDs. It implements IPv4LL (Link-local IPv4 addresses), mDNS and DNS-SD. If run in conjunction with nss-mdns it also offers host name resolution. 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.
After my alterations, the file read (I’ve emboldened the new portion):
<?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>
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.