This part describes the configuration and administration of the BIND 9 DNS naming service in the Solaris OS.
The Solaris Operating System (Solaris OS) ships with the BIND 9.x DNS name server. This chapter provides configuration and administration information related to using BIND 9 on the Solaris operating system. General BIND and DNS information is available from many other sources, including those listed in Related Materials.
This chapter covers the following topics.
For information about DNS and BIND administration, see the following documentation.
BIND 9 Migration Notes documentation in /usr/share/doc/bind/migration.txt
BIND 9 Administrator's Manual on the Internet Systems Consortium (ISC) web site at http://www.isc.org
Listings of BIND features, known bugs and defects, and links to additional material on the ISC web site at http://www.isc.org
DNS and Bind, by Paul Albitz and Cricket Liu, (4th Edition, O'Reilly, 2001)
BIND 9 is upwards compatible with most BIND 8 features. However, there are still a number of caveats you should be aware of when upgrading an existing BIND 8 installation to use BIND 9. Be sure to read the entire Migration Notes document before installing and using BIND 9. The Migration Notes are available at /usr/share/doc/bind/migration.txt. Also, the BIND package names have changed to SUNWbind and SUNWbindr. The SUNWbindr package contains the DNS server manifest.
The following list presents a brief overview of the differences between BIND 8 and BIND 9. Details are available in the Migration Notes.
Configuration File Compatibility
Unimplemented options warning message
transfer-format option changes
Configuration file errors
Logging categories have changed
Notify message and refresh query changes
Multiple classes change
Zone File Compatibility
Stricter rules for TTLs in zone file
SOA serial number changes
Unbalanced quotes cause errors
Line breaks, syntax change
Use \$ instead of $$ in domain names
Interoperability Impact of New Protocol Features
EDNS0 new in BIND 9
Zone transfers default change
Unrestricted Character Set
No restrictions on character set
Security issue, improper naming
Server Administration Tools
The rndc program replaces ndc
nsupdate: changes in multiple updates
No Information Leakage Between Zones
Glue NS records handled differently
Umask Not Modified
Possible umask permissions issues
The DNS/BIND named service can be managed by using the Service Management Facility (SMF). For an overview of SMF, refer to Chapter 17, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M), svcs(1), and svccfg(1M) man pages for more details. Also review the DNS server manifest, server.xml, in /var/svc/manifest/network/dns.
Administrative actions on this service, such as enabling, disabling, or restarting, can be performed by using the svcadm command.
Temporarily disabling a service by using the -t option provides some protection for the service configuration. If the service is disabled with the -t option, the original settings would be restored for the service after a reboot. If the service is disabled without -t, the service will remain disabled after reboot.
The Fault Managed Resource Identifiers (FMRIs) for the DNS service are svc:/network/dns/server:<instance> and svc:/network/dns/client:<instance>.
You can query the status of the DNS server and client by using the svcs command.
Example of the svcs command and output.
# svcs \*dns\* STATE STIME FMRI online Nov_16 svc:/network/dns/server:default online Nov_16 svc:/network/dns/client:default |
Example of svcs -l command and output.
# svcs -l /network/dns/server fmri svc:/network/dns/server:default name Internet domain name server (DNS) enabled true state online next_state none restarter svc:/system/svc/restarter:default contract_id 25 dependency require_all/none svc:/system/filesystem/minimal (online) dependency require_all/none file://localhost/etc/named.conf (online) dependency require_any/error svc:/network/loopback (online) dependency optional_all/error svc:/network/physical (online) |
If you need to start the DNS service with different options (for example with a configuration file other than /etc/named.conf), change the start method property of the DNS server manifest by using the svccfg command.
Multiple SMF service instances are only needed if you want to run multiple copies of BIND 9 name service. Each additional instance can be specified in the DNS server manifest with a different start method.
While it is recommended that you use svcadm to administer the server, you can use rndc as well. SMF is aware of the state change of the BIND 9 named service, whether administered by using svcadm or rndc.
SMF will not be aware of the BIND 9 named service if the service is manually executed from the command line.
The BIND 8 ndc and BIND 9 rndc name server control tools are not backward compatible. rndc can not talk to the BIND 8 name server and ndc can not talk to the BIND 9 name server. Features, options, default modes of operation, and configuration file requirements have changed. Therefore, using ndc on a BIND 9 server could result in loss of functionality or insecure operation. See the rndc(1M) man page for more information.
The most significant difference between ndc in BIND 8 and rndc in BIND 9 is that rndc needs its own configuration file, rndc.conf. This file can be generated by rndc-confgen commands. The rndc.conf file specifies which server controls and what algorithm the server should use.
options { default-server localhost; default-key "rndc-key"; }; key "rndc-key" { algorithm hmac-md5; secret "qPWZ3Ndl81aBRY9AmJhVtU=="; }; |
controls { inet * allow { any; } keys { "rndc-key"; }; }; key "rndc-key" { algorithm hmac-md5; secret "qPWZ3Ndl81aBRY9AmJhVtU=="; }; |
Both the ndc and the rndc utilities use a control channel to send commands to and retrieve information from a name server. However, there are differences between the utilities.
In BIND 8, ndc can use AF_UNIX domain sockets (UNIX control channel) or TCP/IP sockets (inet control channel). By default, ndc does not need any support in /etc/named.conf, because BIND 8 servers use a UNIX domain socket with a path (/var/run/ndc.d/ndc) compiled into in.named.
For BIND 9, however, rndc only uses an authenticated TCP/IP inet control channel and so is not backward compatible with BIND 8. There is no UNIX domain socket support for control channels in BIND 9 servers.
When using rndc, you need to specify a 'key' clause to communicate with the name server. It is mandatory that the BIND 9 server and the rndc client share the same key (defined both in /etc/named.conf and /etc/rndc.conf). Using the BIND 8 controls entry in BIND 9 will result in an error message.
Some command options have changed from the ndc to the rndc implementation. This includes the -c option, which has a different syntax in BIND 9. Therefore, to specify the control channel in BIND 9, use rndc -s <server> -p <port>.
The following list describes the rndc commands.
Reload configuration file and zones
Reload a single zone
Schedule immediate maintenance for a zone
Reload configuration file and new zones only
Write server statistics to the statistics file
Toggle query logging
Dump cache(s) to the dump file (named_dump.db)
Save pending updates to master files and stop the server
Stop the server without saving pending updates
Increment debugging level by one
Change the debugging level
Set debugging level to 0
Flushes all of the server's caches
Flushes the server's cache for a view
Display status of the server
Restart the server (not yet implemented)
Some commands, files, tools, and options have remained the same in BIND 9 as they were in BIND 8. However, some have been modified and others have been added. This section describes many of the commands, files, tools, and options in BIND 9 and the new or modified behavior associated with each item.
The following BIND 9.x tools are available with the Solaris operating system.
named |
nsupdate |
rndc |
dnssec-keygen |
nslookup |
dig |
dnssec-makekeyset |
dnssec-signkey |
dnssec-signzone |
named-checkconf |
named-checkzone |
rndc-confgen |
host |
The following BIND 9.x configuration file is supported in Solaris 10 and Solaris Express Developer Edition releases.
/etc/rndc.conf |
The table below compares BIND 8 and BIND 9 commands and configuration files.
BIND 8 Command |
BIND 9.x Replacement |
---|---|
dnskeygen(1M) |
dnssec-keygen(1M) |
ndc(1M) |
rndc(1M) |
named-bootconf(1M) |
NONE NEEDED |
nsupdate(1M) |
nsupdate(1M) |
nslookup(1M) |
nslookup(1M) |
named-xfer(1M) |
NONE NEEDED |
in.named(1M) |
named(1M) |
named.conf(4) |
named.conf [A detailed named.conf man page is not included with BIND 9.2.4. The named.conf Options includes a summary of the named.conf options that are supported in BIND 9.2.4.] |
dig(1M) |
dig(1M) |
All incompatibles listed below are BIND 8 features and interfaces that are not supported in the equivalent BIND 9 binary. This is not intended to be an exhaustive list of the options, command line options, or features for any BIND 9.x binary.
Command |
Option Changes |
---|---|
in.named(1M) |
Some DNS name server in.named command line options are not supported. In the BIND 9.x name server, the -g group_name, -q, -r and -w directory options are not supported, and -c config_file replaces the BIND 8.x -b config_file. See the named man page for further details. |
dnssec-keygen(1M) |
dnskeygen in BIND 8.x, used to generate keys, and dnssec-keygen from BIND 9.x, have no common options. See the dnssec-keygen man page for further details. |
rndc(1M) |
ndc in BIND 8.x and rndc in BIND 9.x are significantly different. They share no common options and unlike ndc, rndc needs a configuration file in /etc/rndc.conf in order to run. See man pages for rndc, rndc.conf, and rndc-confgen for further details. |
In BIND 9.x, the syntax of the -k option changes in nsupdate. Instead of -k keydir::keyname, the syntax is now k keyfile. The only other difference is that whereas a blank line was used to signal sending the input to the server, an explicit send subcommand is now used to do the same. See the nsupdate man page for further details. |
|
The following options are unsupported in the 9.x version of BIND: help, host server, set ignoretc, set noignoretc, set srch[list]=N1[/N2/.../N6], set ro[ot]=host, root, finger [USER], ls [opt] DOMAIN [> FILE] |
|
named.conf(4) |
A detailed named.conf man page is not included with BIND 9.2.4. Several options are unsupported, not implemented, or have changed defaults. For a list of the option changes and a summary of all named.conf options that are supported in BIND 9.2.4, see The named.conf Options. |
The following list compares the named.conf options between BIND 8 and BIND 9. It also provides a brief description of the changes. An OK in the Changes column denotes the option works unchanged for the BIND 9 version of named.
This section describes any differences between BIND 8 and BIND 9 statements.
unix is the default for ndc and all of the arguments are compiled in. inet is the only option for rndc and nothing is compiled in.
Syntax controls { [ inet ip_addr port ip_port allow { address_match_list; }; ] OK [ unix path_name perm number owner number group number; ] Not Implemented }; |
Logging syntax has changed significantly. See The named.conf Options for a list of named.conf options.
The syntax for the zone statement in the BIND 8 named.conf man page is.mostly supported for BIND 9 except for the following:
[ pubkey number number number string; ] Obsolete [ check-names ( warn | fail | ignore ); ] Not Implemented |
Works unchanged in BIND 9.
Syntax acl name { address_match_list }; |
Works unchanged in BIND 9.
Syntax key key_id { algorithm algorithm_id; secret secret_string; }; |
Works unchanged, however the code to use this statement has been turned off in BIND 9.2.4.
Syntax trusted-keys { [ domain_name flags protocol algorithm key; ] }; |
support-ixfr is obsolete, however all of the following options work unchanged in BIND 9. Note the default for transfer-format has changed.
Syntax server ip_addr { [ bogus yes_or_no; ] [ transfers number; ] [ transfer-format ( one-answer | many-answers ); ] [ keys { key_id [ key_id ... ] }; ] [ edns yes_or_no; ] }; |
Works unchanged in BIND 9.
Syntax include path_name; |
A detailed named.conf man page is not included with BIND 9.2.4. Following is a summary of the named.conf options that are supported in BIND 9.2.4.
options { blackhole { <address_match_element>; ... }; coresize <size>; datasize <size>; deallocate-on-exit <boolean>; // obsolete directory <quoted_string>; dump-file <quoted_string>; fake-iquery <boolean>; // obsolete files <size>; has-old-clients <boolean>; // obsolete heartbeat-interval <integer>; host-statistics <boolean>; // not implemented host-statistics-max <integer>; // not implemented interface-interval <integer>; listen-on [ port <integer> ] { <address_match_element>; ... }; listen-on-v6 [ port <integer> ] { <address_match_element>; ... }; match-mapped-addresses <boolean>; memstatistics-file <quoted_string>; // not implemented multiple-cnames <boolean>; // obsolete named-xfer <quoted_string>; // obsolete pid-file <quoted_string>; port <integer>; random-device <quoted_string>; recursive-clients <integer>; rrset-order { [ class <string> ] [ type <string> ] [ name <quoted_string> ] <string> <string>; ... }; // not implemented serial-queries <integer>; // obsolete serial-query-rate <integer>; stacksize <size>; statistics-file <quoted_string>; statistics-interval <integer>; // not yet implemented tcp-clients <integer>; tkey-dhkey <quoted_string> <integer>; tkey-gssapi-credential <quoted_string>; tkey-domain <quoted_string>; transfers-per-ns <integer>; transfers-in <integer>; transfers-out <integer>; treat-cr-as-space <boolean>; // obsolete use-id-pool <boolean>; // obsolete use-ixfr <boolean>; version <quoted_string>; allow-recursion { <address_match_element>; ... }; allow-v6-synthesis { <address_match_element>; ... }; sortlist { <address_match_element>; ... }; topology { <address_match_element>; ... }; // not implemented auth-nxdomain <boolean>; // default changed minimal-responses <boolean>; recursion <boolean>; provide-ixfr <boolean>; request-ixfr <boolean>; fetch-glue <boolean>; // obsolete rfc2308-type1 <boolean>; // not yet implemented additional-from-auth <boolean>; additional-from-cache <boolean>; query-source <querysource4>; query-source-v6 <querysource6>; cleaning-interval <integer>; min-roots <integer>; // not implemented lame-ttl <integer>; max-ncache-ttl <integer>; max-cache-ttl <integer>; transfer-format ( many-answers | one-answer ); max-cache-size <size_no_default>; check-names <string> <string>; // not implemented cache-file <quoted_string>; allow-query { <address_match_element>; ... }; allow-transfer { <address_match_element>; ... }; allow-update-forwarding { <address_match_element>; ... }; allow-notify { <address_match_element>; ... }; notify <notifytype>; notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ]; notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ]; also-notify [ port <integer> ] { ( <ipv4_address> | <ipv6_address> ) [ port <integer> ]; ... }; dialup <dialuptype>; forward ( first | only ); forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> ) [ port <integer> ]; ... }; maintain-ixfr-base <boolean>; // obsolete max-ixfr-log-size <size>; // obsolete transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ]; transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ]; max-transfer-time-in <integer>; max-transfer-time-out <integer>; max-transfer-idle-in <integer>; max-transfer-idle-out <integer>; max-retry-time <integer>; min-retry-time <integer>; max-refresh-time <integer>; min-refresh-time <integer>; sig-validity-interval <integer>; zone-statistics <boolean>; }; controls { inet ( <ipv4_address> | <ipv6_address> | * ) [ port ( <integer> | * ) ] allow { <address_match_element>; ... } [ keys { <string>; ... } ]; unix <unsupported>; // not implemented }; acl <string> { <address_match_element>; ... }; logging { channel <string> { file <logfile>; syslog <optional_facility>; null; stderr; severity <logseverity>; print-time <boolean>; print-severity <boolean>; print-category <boolean>; }; category <string> { <string>; ... }; }; view <string> <optional_class> { match-clients { <address_match_element>; ... }; match-destinations { <address_match_element>; ... }; match-recursive-only <boolean>; key <string> { algorithm <string>; secret <string>; }; zone <string> <optional_class> { type ( master | slave | stub | hint | forward ); allow-update { <address_match_element>; ... }; file <quoted_string>; ixfr-base <quoted_string>; // obsolete ixfr-tmp-file <quoted_string>; // obsolete masters [ port <integer> ] { ( <ipv4_address> | <ipv6_address> ) [ port <integer> ] [ key <string> ]; ... }; pubkey <integer> <integer> <integer> <quoted_string>; // obsolete update-policy { ( grant | deny ) <string> ( name | subdomain | wildcard | self ) <string> <rrtypelist>; ... }; database <string>; check-names <string>; // not implemented allow-query { <address_match_element>; ... }; allow-transfer { <address_match_element>; ... }; allow-update-forwarding { <address_match_element>; ... }; allow-notify { <address_match_element>; ... }; notify <notifytype>; notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ]; notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ]; also-notify [ port <integer> ] { ( <ipv4_address> | <ipv6_address> ) [ port <integer> ]; ... }; dialup <dialuptype>; forward ( first | only ); forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> ) [ port <integer> ]; ... }; maintain-ixfr-base <boolean>; // obsolete max-ixfr-log-size <size>; // obsolete transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ]; transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ]; max-transfer-time-in <integer>; max-transfer-time-out <integer>; max-transfer-idle-in <integer>; max-transfer-idle-out <integer>; max-retry-time <integer>; min-retry-time <integer>; max-refresh-time <integer>; min-refresh-time <integer>; sig-validity-interval <integer>; zone-statistics <boolean>; }; server { bogus <boolean>; provide-ixfr <boolean>; request-ixfr <boolean>; support-ixfr <boolean>; // obsolete transfers <integer>; transfer-format ( many-answers | one-answer ); keys <server_key>; edns <boolean>; }; trusted-keys { <string> <integer> <integer> <integer> <quoted_string>; ... }; allow-recursion { <address_match_element>; ... }; allow-v6-synthesis { <address_match_element>; ... }; sortlist { <address_match_element>; ... }; topology { <address_match_element>; ... }; // not implemented auth-nxdomain <boolean>; // default changed minimal-responses <boolean>; recursion <boolean>; provide-ixfr <boolean>; request-ixfr <boolean>; fetch-glue <boolean>; // obsolete rfc2308-type1 <boolean>; // not yet implemented additional-from-auth <boolean>; additional-from-cache <boolean>; query-source <querysource4>; query-source-v6 <querysource6>; cleaning-interval <integer>; min-roots <integer>; // not implemented lame-ttl <integer>; max-ncache-ttl <integer>; max-cache-ttl <integer>; transfer-format ( many-answers | one-answer ); max-cache-size <size_no_default>; check-names <string> <string>; // not implemented cache-file <quoted_string>; allow-query { <address_match_element>; ... }; allow-transfer { <address_match_element>; ... }; allow-update-forwarding { <address_match_element>; ... }; allow-notify { <address_match_element>; ... }; notify <notifytype>; notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ]; notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ]; also-notify [ port <integer> ] { ( <ipv4_address> | <ipv6_address> ) [ port <integer> ]; ... }; dialup <dialuptype>; forward ( first | only ); forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> ) [ port <integer> ]; ... }; maintain-ixfr-base <boolean>; // obsolete max-ixfr-log-size <size>; // obsolete transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ]; transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ]; max-transfer-time-in <integer>; max-transfer-time-out <integer>; max-transfer-idle-in <integer>; max-transfer-idle-out <integer>; max-retry-time <integer>; min-retry-time <integer>; max-refresh-time <integer>; min-refresh-time <integer>; sig-validity-interval <integer>; zone-statistics <boolean>; }; lwres { listen-on [ port <integer> ] { ( <ipv4_address> | <ipv6_address> ) [ port <integer> ]; ... }; view <string> <optional_class>; search { <string>; ... }; ndots <integer>; }; key <string> { algorithm <string>; secret <string>; }; zone <string> <optional_class> { type ( master | slave | stub | hint | forward ); allow-update { <address_match_element>; ... }; file <quoted_string>; ixfr-base <quoted_string>; // obsolete ixfr-tmp-file <quoted_string>; // obsolete masters [ port <integer> ] { ( <ipv4_address> | <ipv6_address> ) [ port <integer> ] [ key <string> ]; ... }; pubkey <integer> <integer> <integer> <quoted_string>; // obsolete update-policy { ( grant | deny ) <string> ( name | subdomain | wildcard | self ) <string> <rrtypelist>; ... }; database <string>; check-names <string>; // not implemented allow-query { <address_match_element>; ... }; allow-transfer { <address_match_element>; ... }; allow-update-forwarding { <address_match_element>; ... }; allow-notify { <address_match_element>; ... }; notify <notifytype>; notify-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ]; notify-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ]; also-notify [ port <integer> ] { ( <ipv4_address> | <ipv6_address> ) [ port <integer> ]; ... }; dialup <dialuptype>; forward ( first | only ); forwarders [ port <integer> ] { ( <ipv4_address> | <ipv6_address> ) [ port <integer> ]; ... }; maintain-ixfr-base <boolean>; // obsolete max-ixfr-log-size <size>; // obsolete transfer-source ( <ipv4_address> | * ) [ port ( <integer> | * ) ]; transfer-source-v6 ( <ipv6_address> | * ) [ port ( <integer> | * ) ]; max-transfer-time-in <integer>; max-transfer-time-out <integer>; max-transfer-idle-in <integer>; max-transfer-idle-out <integer>; max-retry-time <integer>; min-retry-time <integer>; max-refresh-time <integer>; min-refresh-time <integer>; sig-validity-interval <integer>; zone-statistics <boolean>; }; server { bogus <boolean>; provide-ixfr <boolean>; request-ixfr <boolean>; support-ixfr <boolean>; // obsolete transfers <integer>; transfer-format ( many-answers | one-answer ); keys <server_key>; edns <boolean>; }; trusted-keys { <string> <integer> <integer> <integer> <quoted_string>; ... }; |
Two extensions to the DNS protocol are multicast DNS (mDNS) and DNS Service Discovery (DNS-SD). mDNS extends the Domain Name Service system to operate over link-local multicast. DNS-SD adds support needed to discover network services over DNS.
Multicast DNS (mDNS) provides a naming service system that is easy to set up and maintain, for computers on a local link. All participating network devices on the same local link perform standard DNS functions, using multicast DNS rather than unicast, and do not need a unicast DNS server. For administrators, the primary advantage of mDNS is that no unicast DNS server needs to be maintained on the local network. There is no need, for example, to update and maintain host names in files to resolve hostname to IP address for devices on the local link that are using mDNS.
Network services include printing, file transfer, music sharing, servers for photo, document and other file sharing, and services provided by other local devices. DNS service discovery support in the Solaris OS includes open source framework and tools from Apple to enable applications to advertise and discover network services, using DNS on the Solaris OS.
For users, network service discovery makes computing easier by enabling users to browse for services on the network, rather than needing to find the service manually. Existing standards, and work done by other companies and groups, assure that cross-platform support is available.
Use the Service Management Facility (SMF) to administer the mDNS daemon. You can use SMF to start and stop the mDNS service.
For an overview of SMF, refer to Chapter 17, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to the svcadm(1M) and svcs(1) man pages for more details.
For mDNS to function, it must be deployed on all peers that are to participate in mDNS. It is used to advertise the availability of services provided on the peer.
Multicast DNS and Service Discovery are both installed by default in the “all” cluster, when installing the Solaris OS. For other types of devices, for example, printers, music, video, and communication devices, many already have mDNS installed.
In addition to being installed, mDNS must be enabled, and must be included in the /etc/nsswitch.conf file. See nsswitch.conf(4)
For the Solaris OS, as root, or as a user with appropriate privileges, enable mDNS on each computer that will participate in mDNS.
# svcadm enable svc:/network/dns/multicast:default |
Enabling mDNS this way persists through upgrades and reboots. For more information, see svcadm(1M).
To be able to resolve local hosts, edit the nsswitch.conf file and add mdns to the list of name services. For example, the file might look like the following:
# /etc/nsswitch.conf hosts: files dns mdns ipnodes: files dns mdns |
For an example of the form such a file should take, see /etc/nswitch.conf.dns.
Check the multicast DNS service log for errors or messages.
/var/svc/log/network-dns-multicast:default.log
Use the dns-sd command as a network diagnosis tool, to browse and discover services, similar to how you would use ping (1M) or traceroute (1M).
The dns-sd command is intended primarily for interactive use, mainly because its command line arguments and its output format can change over time, which makes invoking it from a shell script unpredictable and risky. Additionally, the asynchronous nature of DNS Service Discovery does not easily lend itself to script-oriented programming.
For complete dns-sd information, see the man page for dns-sd (1M) and to incorporate DNS service in applications, see the libdns_sd (3DNS_SD) man page.
EXAMPLES of the dns-sd command
Advertising a printing service
The following command advertises the existence of LPR printing service on port 515 on “My Test” machine, so that it will be available to DNS-SD compatible printing clients:
dns-sd -R "My Test" _printer._tcp. . 515 pdl=application/postscript |
For this registration to be useful, the LPR service should be available on port 515.
Advertising a web page
The following command advertises a web page being served by an HTTP server on port 80 on My Test machine. The web page will appear on the Bonjour list in Safari and other DNS-SD compatible Web clients:
dns-sd -R "My Test" _http._tcp . 80 path=/path-to-page.html |