Marcus Hall

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== dns-sd nslookup queries OSX ======


<code>
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.
</code>


<code>
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.
</code>

<code>
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.
</code>

====== 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

<code>
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)

</code>

====== DNS-SD or DNS-based Service Discovery ======

== DNS-SD also wide area bonjour ==

From: http://en.wikipedia.org/wiki/Zero-configuration_networking

<code>
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.</code>

<code>
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. 
</code>
== Multicast DNS ==

From: http://tools.ietf.org/html/rfc6762#section-1

<code>
"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".
</code>

== Understanding Apple's Back to My Mac (BTMM) Service ==

From: http://tools.ietf.org/html/rfc6281#ref-DNS-SD

<code>
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.
</code>


====== DNS-Based Service Discovery ======


<WRAP center round box >
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.

</WRAP>

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

<code>
 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

</code>
   

{{ :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

<code>
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
</code>

{{ :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/

<code>
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.
</code>

====== Other Service Discovery Information ======

From: http://en.wikipedia.org/wiki/Zero-configuration_networking

<code>
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.
</code>

<code>
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.
</code>

<code>
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.
</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>