====== 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 ======
From: http://itscribbles.blogspot.com/2013/05/bonjour-and-dns-sd.html
From: https://bugs.launchpad.net/opencontrail/+bug/1370997
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 1.1.1.1
(fully: server1.domain.com. A 1.1.1.1)
====== DNS-SD or DNS-based Service Discovery ======
== DNS-SD also wide area bonjour ==
From: http://en.wikipedia.org/wiki/Zero-configuration_networking
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
224.0.0.251 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.[15] 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 ==
From: http://tools.ietf.org/html/rfc6762#section-1
"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 ==
From: http://tools.ietf.org/html/rfc6281#ref-DNS-SD
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..
db._dns-sd._udp..
r._dns-sd._udp..
dr._dns-sd._udp..
lb._dns-sd._udp..
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.
From: https://tools.ietf.org/html/rfc6763
==== DNS-Based Service Discovery ====
From: http://tools.ietf.org/html/rfc6763#section-2
From: http://www.dns-sd.org/ServerSetup.html
From: http://www.dns-sd.org/ServerStaticSetup.html
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." yields a
set of PTR records, where the rdata of each PTR record is the two-
label name, plus the same domain, e.g.,
"_http._tcp.".
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..
db._dns-sd._udp..
r._dns-sd._udp..
dr._dns-sd._udp..
lb._dns-sd._udp..
b._dns-sd._udp IN PTR @ ; b = browse domain
lb._dns-sd._udp IN PTR @ ; lb = legacy browse domain
{{ :software:b-and-lb-and-service-types.png?890 |}}
{{ :software:dns-sd_records-pixelate.png?direct |}}
From: http://tools.ietf.org/html/rfc6763#section-2
Also: http://www.dns-sd.org/ServiceTypes.html
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 ".."
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 ".",
which returns a set of zero or more names, which are the names of the
aforementioned DNS SRV/TXT record pairs.
The 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
{{ :software:smb-services_list_here.png?890 |}}
{{ :software:smb_record-pixelate.png?direct |}}
And Of Course you need A (AAAA) and PTR records
{{ :software:a_record_for_server.png?890 |}}
{{ :software:pointer_for_a_record.png?890 |}}
{{ :software:a_record-pixelate.png?direct |}}
====== Configuring DNS to share Bonjour printers across subnets and VLANs (including AirPrint for iOS) ======
From: http://sybaspot.com/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 ======
From: http://en.wikipedia.org/wiki/Zero-configuration_networking
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[edit]
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.
From: https://simonwheatley.co.uk/2008/04/avahi-finder-icons/
After my alterations, the file read (I’ve emboldened the new portion):
%h
_afpovertcp._tcp
548
_device-info._tcp
0
model=RackMac
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.