dnsextd(8) [osx man page]

dnsextd(8)						    BSD System Manager's Manual 						dnsextd(8)

NAME

     dnsextd -- BIND Extension Daemon

SYNOPSIS

     dnsextd

DESCRIPTION

     dnsextd is a daemon invoked at boot time, running alongside BIND 9, to implement two EDNS0 extensions to the standard DNS protocol.

     dnsextd allows clients to perform DNS Updates with an attached lease lifetime, so that if the client crashes or is disconnected from the net-
     work, its address records will be automatically deleted after the lease expires.

     dnsextd allows clients to perform long-lived queries. Instead of rapidly polling the server to discover when information changes, long-lived
     queries enable a client to indicate its interest in some set of data, and then be notified asynchronously by the server whenever any of that
     data changes.

     dnsextd has no user-specifiable command-line argument, and users should not run dnsextd manually.

SEE ALSO

     mDNS(1) mDNSResponder(8)

     For information on Dynamic DNS Update, see RFC 2136 "Dynamic Updates in the Domain Name System (DNS UPDATE)"

     For information on Dynamic DNS Update Leases, see http://files.dns-sd.org/draft-dns-update-leases.txt

     For information on Long-Lived Queries, see http://files.dns-sd.org/draft-dns-llq.txt

BUGS

     dnsextd bugs are tracked in Apple Radar component "mDNSResponder".

HISTORY

     The dnsextd daemon first appeared in Mac OS X 10.4 (Tiger).

Darwin								   June 2, 2019 							    Darwin

mDNS(1) 						    BSD General Commands Manual 						   mDNS(1)

NAME

     mDNS -- Multicast DNS (mDNS) & DNS Service Discovery (DNS-SD) Test Tool

SYNOPSIS

     mDNS -R name type domain port [key=value ...]

     mDNS -B type domain

     mDNS -L name type domain

DESCRIPTION

     The mDNS command is a network diagnostic tool, much like ping(8) or traceroute(8).  However, unlike those tools, most of its functionality is
     not implemented in the mDNS executable itself, but in library code that is available to any application.  The library API that mDNS uses is
     documented in /usr/include/DNSServiceDiscovery/DNSServiceDiscovery.h.  Note that this Mach-based API, first introduced in Mac OS X 10.2, is
     now deprecated in favour of the newer /usr/include/dns_sd.h API, which is built on Unix Domain Sockets and is supported on multiple plat-
     forms.  The command-line tool to exercise the cross-platform dns_sd.h API is dns-sd(1).

     The mDNS command is primarily intended for interactive use.  Because its command-line arguments and output format are subject to change,
     invoking it from a shell script will generally be fragile. Additionally, the asynchronous nature of DNS Service Discovery does not lend
     itself easily to script-oriented programming. For example, calls like "browse" never complete; the action of performing a "browse" sets in
     motion machinery to notify the client whenever instances of that service type appear or disappear from the network. These notifications con-
     tinue to be delivered indefinitely, for minutes, hours, or even days, as services come and go, until the client explicitly terminates the
     call. This style of asynchronous interaction works best with applications that are either multi-threaded, or use a main event-handling loop
     to receive keystrokes, network data, and other asynchronous event notifications as they happen.
     If you wish to perform DNS Service Discovery operations from a scripting language, then the best way to do this is not to execute the mDNS
     command and then attempt to decipher the textual output, but instead to directly call the DNS-SD APIs using a binding for your chosen lan-
     guage.
     For example, if you are programming in Ruby, then you can directly call DNS-SD APIs using the dnssd package documented at
     <http://rubyforge.org/projects/dnssd/>.
     Similar bindings for other languages are also in development.

     mDNS -R name type domain port [key=value ...]
	register (advertise) a service in the specified domain with the given name and type as listening (on the current machine) on port.

	name can be arbitrary unicode text, containing any legal unicode characters (including dots, spaces, slashes, colons, etc. without
	restriction), up to 63 UTF-8 bytes long.  type must be of the form "_app-proto._tcp" or "_app-proto._udp", where "app-proto" is an appli-
	cation protocol name registered at http://www.dns-sd.org/ServiceTypes.html.

	domain is the domain in which to register the service.	In current implementations, only the local multicast domain "local" is supported.
	In the future, registering will be supported in any arbitrary domain that has a working DNS Update server [RFC 2136]. The domain "." is a
	synonym for "pick a sensible default" which today means "local".

	port is a number from 0 to 65535, and is the TCP or UDP port number upon which the service is listening.

	Additional attributes of the service may optionally be described by key/value pairs, which are stored in the advertised service's DNS TXT
	record. Allowable keys and values are listed with the service registration at http://www.dns-sd.org/ServiceTypes.html.

     mDNS -B type domain
	browse for instances of service type in domain.

	For valid types see http://www.dns-sd.org/ServiceTypes.html as described above. Omitting the domain or using "." means "pick a sensible
	default."

     mDNS -L name type domain
	look up and display the information necessary to contact and use the named service: the hostname of the machine where that service is
	available, the port number on which the service is listening, and (if present) TXT record attributes describing properties of the service.

	Note that in a typical application, browsing happens rarely, while lookup (or "resolving") happens every time the service is used. For
	example, a user browses the network to pick a default printer fairly rarely, but once a default printer has been picked, that named ser-
	vice is resolved to its current IP address and port number every time the user presses Cmd-P to print.

EXAMPLES

     To advertise the existence of LPR printing service on port 515 on this machine, such that it will be discovered by the Mac OS X printing
     software and other DNS-SD compatible printing clients, use:

	   mDNS -R "My Test" _printer._tcp. . 515 pdl=application/postscript

     For this registration to be useful, you need to actually have LPR service available on port 515. Advertising a service that does not exist is
     not very useful, and will be confusing and annoying to other people on the network.

     Similarly, to advertise a web page being served by an HTTP server on port 80 on this machine, such that it will show up in the Bonjour list
     in Safari and other DNS-SD compatible Web clients, use:

	   mDNS -R "My Test" _http._tcp . 80 path=/path-to-page.html

     To find the advertised web pages on the local network (the same list that Safari shows), use:

	   mDNS -B _http._tcp

     While that command is running, in another window, try the mDNS -R example given above to advertise a web page, and you should see the "Add"
     event reported to the mDNS -B window. Now press Ctrl-C in the mDNS -R window and you should see the "Remove" event reported to the mDNS -B
     window.

FILES

     /usr/bin/mDNS

SEE ALSO

     dns-sd(1) mDNSResponder(8)

BUGS

     mDNS bugs are tracked in Apple Radar component "mDNSResponder".

HISTORY

     The mDNS command first appeared in Mac OS X 10.3 (Panther).

Darwin								   June 2, 2019 							    Darwin