return string_list_reverse(r);
}
+
+AvahiStringList *avahi_string_list_new_from_array(const gchar *array[], gint length) {
+ AvahiStringList *r = NULL;
+ gint index;
+
+ g_assert(array);
+
+ for (index = 0; length >= 0 ? index < length : !!array[index]; index++)
+ r = avahi_string_list_add(r, array[index]);
+
+ return r;
+}
/** Same as avahi_string_list_new() but pass a va_list structure */
AvahiStringList *avahi_string_list_new_va(va_list va);
+/** Create a new string list from a string array. The strings are
+ * copied using g_strdup(). length should contain the length of the
+ * array, or -1 if the array is NULL terminated*/
+AvahiStringList *avahi_string_list_new_from_array(const gchar **array, gint length);
+
/** Free a string list */
void avahi_string_list_free(AvahiStringList *l);
--- /dev/null
+$Id$
+
+org.freedesktop.Avahi.Server -- Accessible through /org/freedesktop/Avahi/Server
+ string GetHostName()
+ string GetHostNameFqdn()
+ string GetDomainName()
+ path EntryGroupNew() -- Creates a new org.freedesktop.Avahi.EntryGroup object
+
+ signal StateChanged(int32 state)
+
+org.freedesktop.Avahi.EntryGroup
+ void Free()
+ void Commit()
+ int32 GetState()
+ void AddService(int32 interface, int32 protocol, string type, string name, string domain, string host, uint16 port, string txt[])
+ void AddAddress(int32 interface, int32 protocol, string name, string address)
+
+ signal StateChanged(int32 state)
USA.
***/
-#include <glib.h>
-
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
+#include <glib.h>
+#include <string.h>
+
#define DBUS_API_SUBJECT_TO_CHANGE
#include <dbus/dbus.h>
#include <dbus/dbus-glib-lowlevel.h>
-
+
+#include <avahi-core/llist.h>
+#include <avahi-core/log.h>
+#include <avahi-core/core.h>
+
+
#include "dbus-protocol.h"
+#include "main.h"
+
+#define AVAHI_DBUS_NAME "org.freedesktop.Avahi"
+#define AVAHI_DBUS_INTERFACE_SERVER AVAHI_DBUS_NAME".Server"
+#define AVAHI_DBUS_PATH_SERVER "/org/freedesktop/Avahi/Server"
+#define AVAHI_DBUS_INTERFACE_ENTRY_GROUP AVAHI_DBUS_NAME".EntryGroup"
+
typedef struct Server Server;
typedef struct Client Client;
+typedef struct EntryGroupInfo EntryGroupInfo;
+
+struct EntryGroupInfo {
+ guint id;
+ Client *client;
+ AvahiEntryGroup *entry_group;
+ gchar *path;
+
+ AVAHI_LLIST_FIELDS(EntryGroupInfo, entry_groups);
+};
struct Client {
- int id;
+ guint id;
+ gchar *name;
+ guint current_id;
+
+ AVAHI_LLIST_FIELDS(Client, clients);
+ AVAHI_LLIST_HEAD(EntryGroupInfo, entry_groups);
};
struct Server {
- DBusConnection *bus;
- GSList *clients;
- int nextid;
+ DBusConnection *bus;
+
+ AVAHI_LLIST_HEAD(Client, clients);
+ guint current_id;
};
static Server *server = NULL;
-static DBusHandlerResult
-do_register (DBusConnection *conn, DBusMessage *message)
-{
- DBusError error;
- char *s;
+static void entry_group_free(EntryGroupInfo *i) {
+ g_assert(i);
+
+ avahi_entry_group_free(i->entry_group);
+ dbus_connection_unregister_object_path(server->bus, i->path);
+ g_free(i->path);
+ AVAHI_LLIST_REMOVE(EntryGroupInfo, entry_groups, i->client->entry_groups, i);
+ g_free(i);
+ }
+
+static void client_free(Client *c) {
+
+ g_assert(server);
+ g_assert(c);
+
+ while (c->entry_groups)
+ entry_group_free(c->entry_groups);
+
+ g_free(c->name);
+ AVAHI_LLIST_REMOVE(Client, clients, server->clients, c);
+ g_free(c);
+}
+
+static Client *client_get(const gchar *name, gboolean create) {
Client *client;
- DBusMessage *reply;
- DBusMessageIter iter;
-
- dbus_error_init (&error);
-
- dbus_message_get_args (message, &error,
- DBUS_TYPE_STRING, &s,
- DBUS_TYPE_INVALID);
-
- if (dbus_error_is_set (&error))
- {
- g_warning ("Error parsing register attempt");
- dbus_error_free (&error);
- } else {
- client = g_malloc (sizeof (Client));
- client->id = server->nextid;
- server->nextid++;
-
- server->clients = g_slist_append (server->clients, client);
-
- g_message ("Register received: idstring=(%s), dbus-id=(%s), client-id=(%d)", s, dbus_message_get_sender (message), client->id);
- }
- return DBUS_HANDLER_RESULT_HANDLED;
+ g_assert(server);
+ g_assert(name);
+
+ for (client = server->clients; client; client = client->clients_next)
+ if (!strcmp(name, client->name))
+ return client;
+
+ if (!create)
+ return NULL;
+
+ /* If not existant yet, create a new entry */
+ client = g_new(Client, 1);
+ client->id = server->current_id++;
+ client->name = g_strdup(name);
+ client->current_id = 0;
+ AVAHI_LLIST_HEAD_INIT(Client, client->entry_groups);
+
+ AVAHI_LLIST_PREPEND(Client, clients, server->clients, client);
+ return client;
}
-static DBusHandlerResult
-signal_filter (DBusConnection *conn, DBusMessage *message, void *user_data)
-{
- GMainLoop *loop = user_data;
+static DBusHandlerResult msg_signal_filter_impl(DBusConnection *c, DBusMessage *m, void *userdata) {
+ GMainLoop *loop = userdata;
DBusError error;
- dbus_error_init (&error);
+ dbus_error_init(&error);
- g_message ("dbus: interface=%s, path=%s, member=%s",
- dbus_message_get_interface (message),
- dbus_message_get_path (message),
- dbus_message_get_member (message));
+/* avahi_log_debug("dbus: interface=%s, path=%s, member=%s", */
+/* dbus_message_get_interface(m), */
+/* dbus_message_get_path(m), */
+/* dbus_message_get_member(m)); */
- if (dbus_message_is_signal (message,
- DBUS_INTERFACE_LOCAL,
- "Disconnected"))
- {
+ if (dbus_message_is_signal(m, DBUS_INTERFACE_LOCAL, "Disconnected")) {
/* No, we shouldn't quit, but until we get somewhere
* usefull such that we can restore our state, we will */
- g_warning ("Disconnnected from d-bus, terminating...");
-
+ avahi_log_warn("Disconnnected from d-bus, terminating...");
g_main_loop_quit (loop);
return DBUS_HANDLER_RESULT_HANDLED;
- } else if (dbus_message_is_method_call (message, DBUS_SERVICE_AVAHI,
- "Register"))
- {
- return do_register (conn, message);
- } else if (dbus_message_is_signal (message,
- DBUS_INTERFACE_DBUS,
- "NameAcquired"))
- {
- char *name;
-
- dbus_message_get_args (message, &error,
- DBUS_TYPE_STRING, &name,
- DBUS_TYPE_INVALID);
-
- if (dbus_error_is_set (&error))
- {
- g_warning ("Error parsing NameAcquired message");
- dbus_error_free (&error);
-
- return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+
+ } else if (dbus_message_is_signal(m, DBUS_INTERFACE_DBUS, "NameAcquired")) {
+ gchar *name;
+
+ if (!dbus_message_get_args(m, &error, DBUS_TYPE_STRING, &name, DBUS_TYPE_INVALID)) {
+ avahi_log_warn("Error parsing NameAcquired message");
+ goto fail;
+ }
+
+ avahi_log_info("dbus: name acquired (%s)", name);
+ return DBUS_HANDLER_RESULT_HANDLED;
+ } else if (dbus_message_is_signal(m, DBUS_INTERFACE_DBUS, "NameOwnerChanged")) {
+ gchar *name, *old, *new;
+
+ if (!dbus_message_get_args(m, &error, DBUS_TYPE_STRING, &name, DBUS_TYPE_STRING, &old, DBUS_TYPE_STRING, &new, DBUS_TYPE_INVALID)) {
+ avahi_log_warn("Error parsing NameOwnerChanged message");
+ goto fail;
+ }
+
+ if (!*new) {
+ Client *client;
+
+ if ((client = client_get(name, FALSE))) {
+ avahi_log_info("dbus: client %s vanished", name);
+ client_free(client);
+ }
+ }
+ }
+
+fail:
+ if (dbus_error_is_set(&error))
+ dbus_error_free(&error);
+
+ return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+}
+
+static DBusHandlerResult respond_error(DBusConnection *c, DBusMessage *m, const gchar *error, const gchar *text) {
+ DBusMessage *reply;
+
+ reply = dbus_message_new_error(m, error, text);
+ dbus_connection_send(c, reply, NULL);
+ dbus_message_unref(reply);
+
+ return DBUS_HANDLER_RESULT_HANDLED;
+}
+
+static void entry_group_callback(AvahiServer *s, AvahiEntryGroup *g, AvahiEntryGroupState state, gpointer userdata) {
+ EntryGroupInfo *i = userdata;
+ DBusMessage *m;
+ gint32 t;
+
+ g_assert(s);
+ g_assert(g);
+ g_assert(i);
+
+ m = dbus_message_new_signal(i->path, AVAHI_DBUS_INTERFACE_ENTRY_GROUP, "StateChanged");
+ t = (gint32) state;
+ dbus_message_append_args(m, DBUS_TYPE_INT32, &t, DBUS_TYPE_INVALID);
+ dbus_message_set_destination(m, i->client->name);
+ dbus_connection_send(server->bus, m, NULL);
+ dbus_message_unref(m);
+}
+
+static DBusHandlerResult respond_ok(DBusConnection *c, DBusMessage *m) {
+ DBusMessage *reply;
+
+ reply = dbus_message_new_method_return(m);
+ dbus_connection_send(c, reply, NULL);
+ dbus_message_unref(reply);
+
+ return DBUS_HANDLER_RESULT_HANDLED;
+}
+
+static DBusHandlerResult msg_entry_group_impl(DBusConnection *c, DBusMessage *m, void *userdata) {
+ DBusError error;
+ EntryGroupInfo *i = userdata;
+
+ g_assert(c);
+ g_assert(m);
+ g_assert(i);
+
+ dbus_error_init(&error);
+
+ avahi_log_debug("dbus: interface=%s, path=%s, member=%s",
+ dbus_message_get_interface(m),
+ dbus_message_get_path(m),
+ dbus_message_get_member(m));
+
+ /* Access control */
+ if (strcmp(dbus_message_get_sender(m), i->client->name))
+ return respond_error(c, m, DBUS_ERROR_ACCESS_DENIED, NULL);
+
+ if (dbus_message_is_method_call(m, AVAHI_DBUS_INTERFACE_ENTRY_GROUP, "Free")) {
+
+ if (!dbus_message_get_args(m, &error, DBUS_TYPE_INVALID)) {
+ avahi_log_warn("Error parsing EntryGroup::Free message");
+ goto fail;
+ }
+
+ entry_group_free(i);
+ return respond_ok(c, m);
+ } else if (dbus_message_is_method_call(m, AVAHI_DBUS_INTERFACE_ENTRY_GROUP, "Commit")) {
+
+ if (!dbus_message_get_args(m, &error, DBUS_TYPE_INVALID)) {
+ avahi_log_warn("Error parsing EntryGroup::Commit message");
+ goto fail;
}
- g_message ("dbus: ServiceAcquired (%s)", name);
+ avahi_entry_group_commit(i->entry_group);
+ return respond_ok(c, m);
+ } else if (dbus_message_is_method_call(m, AVAHI_DBUS_INTERFACE_ENTRY_GROUP, "GetState")) {
+ DBusMessage *reply;
+ gint32 t;
+ if (!dbus_message_get_args(m, &error, DBUS_TYPE_INVALID)) {
+ avahi_log_warn("Error parsing EntryGroup::GetState message");
+ goto fail;
+ }
+
+ t = (gint32) avahi_entry_group_get_state(i->entry_group);
+ reply = dbus_message_new_method_return(m);
+ dbus_message_append_args(reply, DBUS_TYPE_INT32, &t, DBUS_TYPE_INVALID);
+ dbus_connection_send(c, reply, NULL);
+ dbus_message_unref(reply);
+
return DBUS_HANDLER_RESULT_HANDLED;
+ } else if (dbus_message_is_method_call(m, AVAHI_DBUS_INTERFACE_ENTRY_GROUP, "AddService")) {
+ gint32 interface, protocol;
+ gchar *type, *name, *domain, *host;
+ guint16 port;
+ gchar **txt = NULL;
+ gint txt_len;
+ AvahiStringList *strlst;
+
+ if (!dbus_message_get_args(
+ m, &error,
+ DBUS_TYPE_INT32, &interface,
+ DBUS_TYPE_INT32, &protocol,
+ DBUS_TYPE_STRING, &type,
+ DBUS_TYPE_STRING, &name,
+ DBUS_TYPE_STRING, &domain,
+ DBUS_TYPE_STRING, &host,
+ DBUS_TYPE_UINT16, &port,
+ DBUS_TYPE_ARRAY, DBUS_TYPE_STRING, &txt, &txt_len,
+ DBUS_TYPE_INVALID) || !type || !*type || !name || !*name || !port) {
+ avahi_log_warn("Error parsing EntryGroup::AddService message");
+ goto fail;
+ }
+
+ strlst = avahi_string_list_new_from_array((const gchar**) txt, txt_len);
+ dbus_free_string_array(txt);
+
+ if (domain && !*domain)
+ domain = NULL;
+
+ if (host && !*host)
+ host = NULL;
+
+ if (avahi_server_add_service_strlst(avahi_server, i->entry_group, (AvahiIfIndex) interface, (AvahiProtocol) protocol, type, name, domain, host, port, strlst) < 0) {
+ avahi_log_warn("Failed to add service: %s", name);
+ return respond_error(c, m, "org.freedesktop.Avahi.InvalidServiceError", NULL);
+ } else
+ avahi_log_info("Successfully added service: %s", name);
+
+ return respond_ok(c, m);
+ } else if (dbus_message_is_method_call(m, AVAHI_DBUS_INTERFACE_ENTRY_GROUP, "AddAddress")) {
+ gint32 interface, protocol;
+ gchar *name, *address;
+ AvahiAddress a;
+
+ if (!dbus_message_get_args(
+ m, &error,
+ DBUS_TYPE_INT32, &interface,
+ DBUS_TYPE_INT32, &protocol,
+ DBUS_TYPE_STRING, &name,
+ DBUS_TYPE_STRING, &address,
+ DBUS_TYPE_INVALID) || !name || !*name || !address || !*address) {
+ avahi_log_warn("Error parsing EntryGroup::AddAddress message");
+ goto fail;
+ }
+
+ if (!(avahi_address_parse(address, AVAHI_PROTO_UNSPEC, &a))) {
+ avahi_log_warn("Error parsing address data");
+ return respond_error(c, m, "org.freedesktop.Avahi.InvalidAddressError", NULL);
+ }
+
+ if (avahi_server_add_address(avahi_server, i->entry_group, (AvahiIfIndex) interface, (AvahiProtocol) protocol, 0, name, &a) < 0) {
+ avahi_log_warn("Failed to add service: %s", name);
+ return respond_error(c, m, "org.freedesktop.Avahi.InvalidAddressError", NULL);
+ } else
+ avahi_log_info("Successfully added address: %s -> %s", name, address);
+
+ return respond_ok(c, m);
}
- g_message ("dbus: missed event");
+ avahi_log_warn("Missed message %s::%s()", dbus_message_get_interface(m), dbus_message_get_member(m));
+fail:
+ if (dbus_error_is_set(&error))
+ dbus_error_free(&error);
+
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
}
-int
-dbus_protocol_setup (GMainLoop *loop)
-{
+static DBusHandlerResult respond_string(DBusConnection *c, DBusMessage *m, const gchar *text) {
+ DBusMessage *reply;
+
+ reply = dbus_message_new_method_return(m);
+ dbus_message_append_args(reply, DBUS_TYPE_STRING, &text, DBUS_TYPE_INVALID);
+ dbus_connection_send(c, reply, NULL);
+ dbus_message_unref(reply);
+
+ return DBUS_HANDLER_RESULT_HANDLED;
+}
+
+static DBusHandlerResult msg_server_impl(DBusConnection *c, DBusMessage *m, void *userdata) {
DBusError error;
- dbus_error_init (&error);
+ dbus_error_init(&error);
- server = g_malloc (sizeof (server));
+ avahi_log_debug("dbus: interface=%s, path=%s, member=%s",
+ dbus_message_get_interface(m),
+ dbus_message_get_path(m),
+ dbus_message_get_member(m));
- server->clients = NULL;
- server->nextid = 1;
+ if (dbus_message_is_method_call(m, AVAHI_DBUS_INTERFACE_SERVER, "GetHostName")) {
- server->bus = dbus_bus_get (DBUS_BUS_SYSTEM, &error);
+ if (!dbus_message_get_args(m, &error, DBUS_TYPE_INVALID)) {
+ avahi_log_warn("Error parsing Server::GetHostName message");
+ goto fail;
+ }
- if (server->bus == NULL)
- {
- g_warning ("dbus_bus_get(): %s", error.message);
- dbus_error_free (&error);
+ return respond_string(c, m, avahi_server_get_host_name(avahi_server));
+
+ } if (dbus_message_is_method_call(m, AVAHI_DBUS_INTERFACE_SERVER, "GetDomainName")) {
- return 1;
- }
+ if (!dbus_message_get_args(m, &error, DBUS_TYPE_INVALID)) {
+ avahi_log_warn("Error parsing Server::GetDomainName message");
+ goto fail;
+ }
- dbus_connection_setup_with_g_main (server->bus, NULL);
- dbus_connection_set_exit_on_disconnect (server->bus, FALSE);
+ return respond_string(c, m, avahi_server_get_domain_name(avahi_server));
- dbus_bus_request_name (server->bus, DBUS_SERVICE_AVAHI, 0, &error);
+ } if (dbus_message_is_method_call(m, AVAHI_DBUS_INTERFACE_SERVER, "GetHostNameFqdn")) {
- if (dbus_error_is_set (&error))
- {
- g_warning ("dbus_error_is_set (): %s", error.message);
- dbus_error_free (&error);
+ if (!(dbus_message_get_args(m, &error, DBUS_TYPE_INVALID))) {
+ avahi_log_warn("Error parsing Server::GetHostNameFqdn message");
+ goto fail;
+ }
+
+ return respond_string(c, m, avahi_server_get_host_name_fqdn(avahi_server));
+
+ } else if (dbus_message_is_method_call(m, AVAHI_DBUS_INTERFACE_SERVER, "EntryGroupNew")) {
+ Client *client;
+ EntryGroupInfo *i;
+ static const DBusObjectPathVTable vtable = {
+ NULL,
+ msg_entry_group_impl,
+ NULL,
+ NULL,
+ NULL,
+ NULL
+ };
+ DBusMessage *reply;
+
+ if (!dbus_message_get_args(m, &error, DBUS_TYPE_INVALID)) {
+ avahi_log_warn("Error parsing Server::EntryGroupNew message");
+ goto fail;
+ }
- return 1;
- }
+ client = client_get(dbus_message_get_sender(m), TRUE);
- dbus_connection_add_filter (server->bus, signal_filter, loop, NULL);
- dbus_bus_add_match (server->bus,
- "type='method_call',interface='org.freedesktop.Avahi'",
- &error);
+ i = g_new(EntryGroupInfo, 1);
+ i->id = ++client->current_id;
+ i->client = client;
+ i->entry_group = avahi_entry_group_new(avahi_server, entry_group_callback, i);
+ i->path = g_strdup_printf("/org/freedesktop/Avahi/Client%u/EntryGroup%u", client->id, i->id);
- if (dbus_error_is_set (&error))
- {
- g_warning ("dbus_bus_add_match (): %s", error.message);
- dbus_error_free (&error);
+ AVAHI_LLIST_PREPEND(EntryGroupInfo, entry_groups, client->entry_groups, i);
- return 1;
+ dbus_connection_register_object_path(c, i->path, &vtable, i);
+ reply = dbus_message_new_method_return(m);
+ dbus_message_append_args(reply, DBUS_TYPE_OBJECT_PATH, &i->path, DBUS_TYPE_INVALID);
+ dbus_connection_send(c, reply, NULL);
+ dbus_message_unref(reply);
+
+ return DBUS_HANDLER_RESULT_HANDLED;
+ }
+
+ avahi_log_warn("Missed message %s::%s()", dbus_message_get_interface(m), dbus_message_get_member(m));
+
+
+fail:
+ if (dbus_error_is_set(&error))
+ dbus_error_free(&error);
+
+ return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+}
+
+void dbus_protocol_server_state_changed(AvahiServerState state) {
+ DBusMessage *m;
+ gint32 t;
+
+ if (!server)
+ return;
+
+ m = dbus_message_new_signal(AVAHI_DBUS_PATH_SERVER, AVAHI_DBUS_INTERFACE_SERVER, "StateChanged");
+ t = (gint32) state;
+ dbus_message_append_args(m, DBUS_TYPE_INT32, &t, DBUS_TYPE_INVALID);
+ dbus_connection_send(server->bus, m, NULL);
+ dbus_message_unref(m);
+}
+
+int dbus_protocol_setup(GMainLoop *loop) {
+ DBusError error;
+
+ static const DBusObjectPathVTable server_vtable = {
+ NULL,
+ msg_server_impl,
+ NULL,
+ NULL,
+ NULL,
+ NULL
+ };
+
+ dbus_error_init(&error);
+
+ server = g_malloc(sizeof(Server));
+ server->clients = NULL;
+ server->current_id = 0;
+
+ server->bus = dbus_bus_get(DBUS_BUS_SYSTEM, &error);
+ if (dbus_error_is_set(&error)) {
+ avahi_log_warn("dbus_bus_get(): %s", error.message);
+ goto fail;
}
+ dbus_connection_setup_with_g_main(server->bus, NULL);
+ dbus_connection_set_exit_on_disconnect(server->bus, FALSE);
+
+ dbus_bus_request_name(server->bus, AVAHI_DBUS_NAME, 0, &error);
+ if (dbus_error_is_set(&error)) {
+ avahi_log_warn("dbus_bus_request_name(): %s", error.message);
+ goto fail;
+ }
+
+ dbus_bus_add_match(server->bus, "type='signal',""interface='" DBUS_INTERFACE_DBUS "'", &error);
+
+ dbus_connection_add_filter(server->bus, msg_signal_filter_impl, loop, NULL);
+ dbus_connection_register_object_path(server->bus, AVAHI_DBUS_PATH_SERVER, &server_vtable, NULL);
+
return 0;
-}
-void
-dbus_protocol_shutdown ()
-{
+fail:
if (server->bus) {
dbus_connection_disconnect(server->bus);
dbus_connection_unref(server->bus);
}
+
+ dbus_error_free (&error);
+ g_free(server);
+ server = NULL;
+ return -1;
+}
+
+void dbus_protocol_shutdown(void) {
+
+ if (server) {
+
+ while (server->clients)
+ client_free(server->clients);
+
+ if (server->bus) {
+ dbus_connection_disconnect(server->bus);
+ dbus_connection_unref(server->bus);
+ }
+
+ g_free(server);
+ server = NULL;
+ }
}
USA.
***/
-#define DBUS_SERVICE_AVAHI "org.freedesktop.Avahi"
-
#include <glib.h>
-int dbus_protocol_setup (GMainLoop *loop);
-void dbus_protocol_shutdown ();
+int dbus_protocol_setup(GMainLoop *loop);
+void dbus_protocol_shutdown(void);
+void dbus_protocol_server_state_changed(AvahiServerState state);
#endif
--- /dev/null
+#!/usr/bin/python2.4
+
+import dbus
+import dbus.glib
+import gtk
+
+from time import sleep
+
+bus = dbus.SystemBus()
+
+server = dbus.Interface(bus.get_object("org.freedesktop.Avahi", '/org/freedesktop/Avahi/Server'), 'org.freedesktop.Avahi.Server')
+
+print "Host name: %s" % server.GetHostName()
+print "Domain name: %s" % server.GetDomainName()
+print "FQDN: %s" % server.GetHostNameFqdn()
+
+g = dbus.Interface(bus.get_object("org.freedesktop.Avahi", server.EntryGroupNew()), 'org.freedesktop.Avahi.EntryGroup')
+
+def state_changed_callback(t):
+ print "StateChanged: ", t
+
+g.connect_to_signal('StateChanged', state_changed_callback)
+g.AddService(0, 0, "_http._tcp", "foo", "", "", dbus.UInt16(4712), ["fuck=hallo", "gurke=mega"])
+g.AddAddress(0, 0, "foo.local", "47.11.8.15")
+g.Commit()
+
+try:
+ gtk.main()
+except KeyboardInterrupt, k:
+ pass
+
+g.Free()
+
+print "Quit"
g_assert(s);
g_assert(config);
+#ifdef ENABLE_DBUS
+ if (config->enable_dbus)
+ dbus_protocol_server_state_changed(state);
+#endif
+
if (state == AVAHI_SERVER_RUNNING) {
avahi_log_info("Server startup complete. Host name is <%s>", avahi_server_get_host_name_fqdn(s));
static_service_add_to_server();
avahi_server_set_host_name(s, n);
g_free(n);
}
+
+
}
static void help(FILE *f, const gchar *argv0) {
--- /dev/null
+Document: draft-cheshire-dnsext-dns-sd-02.txt Stuart Cheshire
+Category: Standards Track Apple Computer, Inc.
+Expires 14th August 2004 Marc Krochmal
+ Apple Computer, Inc.
+ 14th February 2004
+
+ DNS-Based Service Discovery
+
+ <draft-cheshire-dnsext-dns-sd-02.txt>
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF),
+ its areas, and its working groups. Note that other groups may
+ also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other documents
+ at any time. It is inappropriate to use Internet-Drafts as
+ reference material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ Distribution of this memo is unlimited.
+
+
+Abstract
+
+ This document describes a convention for naming and structuring DNS
+ resource records. Given a type of service that a client is looking
+ for, and a domain in which the client is looking for that service,
+ this convention allows clients to discover a list of named instances
+ of that desired service, using only standard DNS queries. In short,
+ this is referred to as DNS-based Service Discovery, or DNS-SD.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 1]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+Table of Contents
+
+ 1. Introduction....................................................3
+ 2. Conventions and Terminology Used in this Document...............3
+ 3. Design Goals....................................................4
+ 4. Service Instance Enumeration....................................5
+ 4.1 Structured Instance Names.......................................5
+ 4.2 User Interface Presentation.....................................7
+ 4.3 Internal Handling of Names......................................7
+ 4.4 What You See Is What You Get....................................7
+ 4.5 Ordering of Service Instance Name Components....................9
+ 5. Service Name Resolution........................................11
+ 6. Data Syntax for DNS-SD TXT Records.............................12
+ 6.1 General Format Rules for DNS TXT Records.......................12
+ 6.2 DNS TXT Record Format Rules for use in DNS-SD..................12
+ 6.3 DNS-SD TXT Record Size.........................................14
+ 6.4 Rules for Names in DNS-SD Name/Value Pairs.....................14
+ 6.5 Rules for Values in DNS-SD Name/Value Pairs....................16
+ 6.6 Example TXT Record.............................................16
+ 6.7 Version Tag....................................................17
+ 7. Application Protocol Names.....................................18
+ 8. Selective Instance Enumeration.................................19
+ 9. Flagship Naming................................................10
+ 10. Service Type Enumeration.......................................21
+ 11. Populating the DNS with Information............................22
+ 12. Relationship to Multicast DNS..................................22
+ 13. Discovery of Browsing and Registration Domains.................23
+ 14. DNS Additional Record Generation...............................24
+ 15. Comparison with Alternative Service Discovery Protocols........25
+ 16. Real Example...................................................27
+ 17. IPv6 Considerations............................................28
+ 18. Security Considerations........................................28
+ 19. IANA Considerations............................................28
+ 20. Acknowledgements...............................................29
+ 21. Copyright......................................................29
+ 22. Normative References...........................................30
+ 23. Informative References.........................................30
+ 24. Author's Addresses.............................................31
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 2]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+1. Introduction
+
+ This document describes a convention for naming and structuring DNS
+ resource records. Given a type of service that a client is looking
+ for, and a domain in which the client is looking for that service,
+ this convention allows clients to discover a list of named instances
+ of a that desired service, using only standard DNS queries. In short,
+ this is referred to as DNS-based Service Discovery, or DNS-SD.
+
+ This document proposes no change to the structure of DNS messages,
+ and no new operation codes, response codes, resource record types,
+ or any other new DNS protocol values. This document simply proposes
+ a convention for how existing resource record types can be named and
+ structured to facilitate service discovery.
+
+ This proposal is entirely compatible with today's existing unicast
+ DNS server and client software.
+
+ Note that the DNS-SD service does NOT have to be provided by the same
+ DNS server hardware that is currently providing an organization's
+ conventional host name lookup service (the service we traditionally
+ think of when we say "DNS"). By delegating the "_tcp" subdomain, all
+ the workload related to DNS-SD can be offloaded to a different
+ machine. This flexibility, to handle DNS-SD on the main DNS server,
+ or not, at the network administrator's discretion, is one of the
+ things that makes DNS-SD so compelling.
+
+ Even when the DNS-SD functions are delegated to a different machine,
+ the benefits of using DNS remain: It is mature technology, well
+ understood, with multiple independent implementations from different
+ vendors, a wide selection of books published on the subject, and an
+ established workforce experienced in its operation. In contrast,
+ adopting some other service discovery technology would require every
+ site in the world to install, learn, configure, operate and maintain
+ some entirely new and unfamiliar server software. Faced with these
+ obstacles, it seems unlikely that any other service discovery
+ technology could hope to compete with the ubiquitous deployment
+ that DNS already enjoys.
+
+ This proposal is also compatible with (but not dependent on) the
+ proposal outlined in "Multicast DNS" [mDNS].
+
+
+2. Conventions and Terminology Used in this Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in "Key words for use in
+ RFCs to Indicate Requirement Levels" [RFC 2119].
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 3]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+3. Design Goals
+
+ A good service discovery protocol needs to have many properties,
+ three of which are mentioned below:
+
+ (i) The ability to query for services of a certain type in a certain
+ logical domain and receive in response a list of named instances
+ (network browsing, or "Service Instance Enumeration").
+
+ (ii) Given a particular named instance, the ability to efficiently
+ resolve that instance name to the required information a client needs
+ to actually use the service, i.e. IP address and port number, at the
+ very least (Service Name Resolution).
+
+ (iii) Instance names should be relatively persistent. If a user
+ selects their default printer from a list of available choices today,
+ then tomorrow they should still be able to print on that printer --
+ even if the IP address and/or port number where the service resides
+ have changed -- without the user (or their software) having to repeat
+ the network browsing step a second time.
+
+ In addition, if it is to become successful, a service discovery
+ protocol should be so simple to implement that virtually any
+ device capable of implementing IP should not have any trouble
+ implementing the service discovery software as well.
+
+ These goals are discussed in more detail in the remainder of this
+ document. A more thorough treatment of service discovery requirements
+ may be found in "Requirements for a Protocol to Replace AppleTalk
+ NBP" [NBP]. That document draws upon examples from two decades of
+ operational experience with AppleTalk Name Binding Protocol to
+ develop a list of universal requirements which are broadly applicable
+ to any potential service discovery protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 4]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+4. Service Instance Enumeration
+
+ DNS SRV records [RFC 2782] are useful for locating instances of a
+ particular type of service when all the instances are effectively
+ indistinguishable and provide the same service to the client.
+
+ For example, SRV records with the (hypothetical) name
+ "_http._tcp.example.com." would allow a client to discover a list of
+ all servers implementing the "_http._tcp" service (i.e. Web servers)
+ for the "example.com." domain. The unstated assumption is that all
+ these servers offer an identical set of Web pages, and it doesn't
+ matter to the client which of the servers it uses, as long as it
+ selects one at random according to the weight and priority rules laid
+ out in RFC 2782.
+
+ Instances of other kinds of service are less easily interchangeable.
+ If a word processing application were to look up the (hypothetical)
+ SRV record "_ipp._tcp.example.com." to find the list of IPP printers
+ at Example Co., then picking one at random and printing on it would
+ probably not be what the user wanted.
+
+ The remainder of this section describes how SRV records may be used
+ in a slightly different way to allow a user to discover the names
+ of all available instances of a given type of service, in order to
+ select the particular instance the user desires.
+
+
+4.1 Structured Instance Names
+
+ This document borrows the logical service naming syntax and semantics
+ from DNS SRV records, but adds one level of indirection. Instead of
+ requesting records of type "SRV" with name "_ipp._tcp.example.com.",
+ the client requests records of type "PTR" (pointer from one name to
+ another in the DNS namespace).
+
+ In effect, if one thinks of the domain name "_ipp._tcp.example.com."
+ as being analogous to an absolute path to a directory in a file
+ system then the PTR lookup is akin to performing a listing of that
+ directory to find all the files it contains. (Remember that domain
+ names are expressed in reverse order compared to path names: An
+ absolute path name is read from left to right, beginning with a
+ leading slash on the left, and then the top level directory, then the
+ next level directory, and so on. A fully-qualified domain name is
+ read from right to left, beginning with the dot on the right -- the
+ root label -- and then the top level domain to the left of that, and
+ the second level domain to the left of that, and so on. If the fully-
+ qualified domain name "_ipp._tcp.example.com." were expressed as a
+ file system path name, it would be "/com/example/_tcp/_ipp".)
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 5]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+ The result of this PTR lookup for the name "<Service>.<Domain>" is a
+ list of zero or more PTR records giving Service Instance Names of the
+ form:
+
+ Service Instance Name = <Instance> . <Service> . <Domain>
+
+ The <Instance> portion of the Service Instance Name is a single DNS
+ label, containing arbitrary UTF-8-encoded text [RFC 2279]. It is a
+ user-friendly name, meaning that it is allowed to contain any
+ characters, without restriction, including spaces, upper case, lower
+ case, punctuation -- including dots -- accented characters, non-roman
+ text, and anything else that may be represented using UTF-8.
+ DNS recommends guidelines for allowable characters for host names
+ [RFC 1033][RFC 1034][RFC 1035], but Service Instance Names are not
+ host names. Service Instance Names are not intended to ever be typed
+ in by a normal user; the user selects a Service Instance Name by
+ selecting it from a list of choices presented on the screen.
+
+ Note that just because this protocol supports arbitrary UTF-8-encoded
+ names doesn't mean that any particular user or administrator is
+ obliged to make use of that capability. Any user is free, if they
+ wish, to continue naming their services using only letters, digits
+ and hyphens, with no spaces, capital letters, or other punctuation.
+
+ DNS labels are currently limited to 63 octets in length. UTF-8
+ encoding can require up to four octets per Unicode character, which
+ means that in the worst case, the <Instance> portion of a name could
+ be limited to fifteen Unicode characters. However, the Unicode
+ characters with longer UTF-8 encodings tend to be the more obscure
+ ones, and tend to be the ones that convey greater meaning per
+ character.
+
+ Note that any character in the commonly-used 16-bit Unicode space can
+ be encoded with no more than three octets of UTF-8 encoding. This
+ means that an Instance name can contain up to 21 Kanji characters,
+ which is a sufficiently expressive name for most purposes.
+
+ The <Service> portion of the Service Instance Name consists of a pair
+ of DNS labels, following the established convention for SRV records
+ [RFC 2782], namely: the first label of the service pair is the
+ application protocol name, as recorded in the IANA list of assigned
+ application protocol names and port numbers [ports]. The second label
+ of the service pair is either "_tcp" or "_udp", depending on the
+ transport protocol used by the application.
+
+ The <Domain> portion of the Service Instance Name is a conventional
+ DNS domain name, consisting of as many labels as appropriate. For
+ example, "apple.com.", "cs.stanford.edu.", and "eng.us.ibm.com." are
+ all valid domain names for the <Domain> portion of the Service
+ Instance Name.
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 6]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+4.2 User Interface Presentation
+
+ The names resulting from the PTR lookup are presented to the user in
+ a list for the user to select one (or more). Typically only the first
+ label is shown (the user-friendly <Instance> portion of the name). In
+ the common case, the <Service> and <Domain> are already known to the
+ user, these having been provided by the user in the first place, by
+ the act of indicating the service being sought, and the domain in
+ which to look for it. Note: The software handling the response
+ should be careful not to make invalid assumptions though, since it
+ *is* possible, though rare, for a service enumeration in one domain
+ to return the names of services in a different domain. Similarly,
+ when using subtypes (see "Selective Instance Enumeration") the
+ <Service> of the discovered instance my not be exactly the same as
+ the <Service> that was requested.
+
+ Having chosen the desired named instance, the Service Instance Name
+ may then be used immediately, or saved away in some persistent
+ user-preference data structure for future use, depending on what is
+ appropriate for the application in question.
+
+
+4.3 Internal Handling of Names
+
+ If the <Instance>, <Service> and <Domain> portions are internally
+ concatenated together into a single string, then care must be taken
+ with the <Instance> portion, since it is allowed to contain any
+ characters, including dots.
+
+ Any dots in the <Instance> portion should be escaped by preceeding
+ them with a backslash ("." becomes "\."). Likewise, any backslashes
+ in the <Instance> portion should also be escaped by preceeding them
+ with a backslash ("\" becomes "\\"). Having done this, the three
+ components of the name may be safely concatenated. The
+ backslash-escaping allows literal dots in the name (escaped) to be
+ distinguished from label-separator dots (not escaped).
+
+ The resulting concatenated string may be safely passed to standard
+ DNS APIs like res_query(), which will interpret the string correctly
+ provided it has been escaped correctly, as described here.
+
+
+4.4 What You See Is What You Get
+
+ Some service discovery protocols decouple the true service identifier
+ from the name presented to the user. The true service identifier used
+ by the protocol is an opaque unique id, often represented using a
+ long string of hexadecimal digits, and should never be seen by the
+ typical user. The name presented to the user is merely one of the
+ ephemeral attributes attached to this opaque identifier.
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 7]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+ The problem with this approach is that it decouples user perception
+ from reality:
+
+ * What happens if there are two service instances, with different
+ unique ids, but they have inadvertently been given the same
+ user-visible name? If two instances appear in an on-screen list
+ with the same name, how does the user know which is which?
+
+ * Suppose a printer breaks down, and the user replaces it with
+ another printer of the same make and model, and configures the new
+ printer with the exact same name as the one being replaced:
+ "Stuart's Printer". Now, when the user tries to print, the
+ on-screen print dialog tells them that their selected default
+ printer is "Stuart's Printer". When they browse the network to see
+ what is there, they see a printer called "Stuart's Printer", yet
+ when the user tries to print, they are told that the printer
+ "Stuart's Printer" can't be found. The hidden internal unique id
+ that the software is trying to find on the network doesn't match
+ the hidden internal unique id of the new printer, even though its
+ apparent "name" and its logical purpose for being there are the
+ same. To remedy this, the user typically has to delete the print
+ queue they have created, and then create a new (apparently
+ identical) queue for the new printer, so that the new queue will
+ contain the right hidden internal unique id. Having all this hidden
+ information that the user can't see makes for a confusing and
+ frustrating user experience, and exposing long ugly hexadecimal
+ strings to the user and forcing them to understand what they mean
+ is even worse.
+
+ * Suppose an existing printer is moved to a new department, and given
+ a new name and a new function. Changing the user-visible name of
+ that piece of hardware doesn't change its hidden internal unique
+ id. Users who had previously created print queues for that printer
+ will still be accessing the same hardware by its unique id, even
+ though the logical service that used to be offered by that hardware
+ has ceased to exist.
+
+ To solve these problems requires the user or administrator to be
+ aware of the supposedly hidden unique id, and to set its value
+ correctly as hardware is moved around, repurposed, or replaced,
+ thereby contradicting the notion that it is a hidden identifier that
+ human users never need to deal with. Requiring the user to unserstand
+ this expert behind-the-scenes knowledge of what is *really* going on
+ is just one more burden placed on the user when they are trying to
+ diagnose why their computers and network devices are not working as
+ expected.
+
+ These anomalies and counter-intuitive behaviours can be eliminated by
+ maintaining a tight bidirectional one-to-one mapping between what the
+ user sees on the screen and what is really happening "behind the
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 8]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+ curtain". If something is configured incorrectly, then that is
+ apparent in the familiar day-to-day user interface that everyone
+ understands, not in some little-known rarely-used "expert" interface.
+
+ In summary: The user-visible name is the primary identifier for a
+ service. If the user-visible name is changed, then conceptually the
+ service being offered is a different logical service -- even though
+ the hardware offering the service stayed the same. If the
+ user-visible name doesn't change, then conceptually the service being
+ offered is the same logical service -- even if the hardware offering
+ the service is new hardware brought in to replace some old equipment.
+
+ There are certainly arguments on both sides of this debate.
+ Nonetheless, the designers of any service discovery protocol have
+ to make a choice between between having the primary identifiers be
+ hidden, or having them be visible, and these are the reasons that we
+ chose to make them visible. We're not claiming that there are no
+ disadvantages of having primary identifiers be visible. We considered
+ both alternatives, and we believe that the few disadvantages
+ of visible identifiers are far outweighed by the many problems
+ caused by use of hidden identifiers.
+
+
+4.5 Ordering of Service Instance Name Components
+
+ There have been questions about why services are named using DNS
+ Service Instance Names of the form:
+
+ Service Instance Name = <Instance> . <Service> . <Domain>
+
+ instead of:
+
+ Service Instance Name = <Service> . <Instance> . <Domain>
+
+ There are three reasons why it is beneficial to name service
+ instances with the parent domain as the most-significant (rightmost)
+ part of the name, then the abstract service type as the nextmost
+ significant, and then the specific instance name as the
+ least-significant (leftmost) part of the name:
+
+
+4.5.1. Semantic Structure
+
+ The facility being provided by browsing ("Service Instance
+ Enumeration") is effectively enumerating the leaves of a tree
+ structure. A given domain offers zero or more services. For each of
+ those service types, there may be zero or more instances of that
+ service.
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 9]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+ The user knows what type of service they are seeking. (If they are
+ running an FTP client, they are looking for FTP servers. If they have
+ a document to print, they are looking for entities that speak some
+ known printing protocol.) The user knows in which organizational or
+ geographical domain they wish to search. (The user does not want a
+ single flat list of every single printer on the planet, even if such
+ a thing were possible.) What the user does not know in advance is
+ whether the service they seek is offered in the given domain, or if
+ so, how many instances are offered, and the names of those instances.
+ Hence having the instance names be the leaves of the tree is
+ consistent with this semantic model.
+
+ Having the service types be the terminal leaves of the tree would
+ imply that the user knows the domain name, and already knows the
+ name of the service instance, but doesn't have any idea what the
+ service does. We would argue that this is a less useful model.
+
+
+4.5.2. Network Efficiency
+
+ When a DNS response contains multiple answers, name compression works
+ more effectively if all the names contain a common suffix. If many
+ answers in the packet have the same <Service> and <Domain>, then each
+ occurrence of a Service Instance Name can be expressed using only the
+ <Instance> part followed by a two-byte compression pointer
+ referencing a previous appearance of "<Service>.<Domain>". This
+ efficiency would not be possible if the <Service> component appeared
+ first in each name.
+
+
+4.5.3. Operational Flexibility
+
+ This name structure allows subdomains to be delegated along logical
+ service boundaries. For example, the network administrator at Example
+ Co. could choose to delegate the "_tcp.example.com." subdomain to a
+ different machine, so that the machine handling service discovery
+ doesn't have to be the same as the machine handling other day-to-day
+ DNS operations. (It *can* be the same machine if the administrator so
+ chooses, but the point is that the administrator is free to make that
+ choice.) Furthermore, if the network administrator wishes to delegate
+ all information related to IPP printers to a machine dedicated to
+ that specific task, this is easily done by delegating the
+ "_ipp._tcp.example.com." subdomain to the desired machine. It is also
+ convenient to set security policies on a per-zone/per-subdomain
+ basis. For example, the administrator may choose to enable DNS
+ Dynamic Update [RFC 2136] [RFC 3007] for printers registering in the
+ "_ipp._tcp.example.com." subdomain, but not for other
+ zones/subdomains. This easy flexibility would not exist if the
+ <Service> component appeared first in each name.
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 10]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+5. Service Name Resolution
+
+ Given a particular Service Instance Name, when a client needs to
+ contact that service, it sends a DNS query for the SRV record of
+ that name.
+
+ The result of the DNS query is a SRV record giving the port number
+ and target host where the service may be found.
+
+ The use of SRV records is very important. There are only 65535 TCP
+ port numbers available. These port numbers are being allocated
+ one-per-application-protocol at an alarming rate. Some protocols like
+ the X Window System have a block of 64 TCP ports allocated
+ (6000-6063). If we start allocating blocks of 64 TCP ports at a time,
+ we will run out even faster. Using a different TCP port for each
+ different instance of a given service on a given machine is entirely
+ sensible, but allocating large static ranges, as was done for X, is a
+ very inefficient way to manage a limited resource. On any given host,
+ most TCP ports are reserved for services that will never run on that
+ particular host. This is very poor utilization of the limited port
+ space. Using SRV records allows each host to allocate its available
+ port numbers dynamically to those services running on that host that
+ need them, and then advertise the allocated port numbers via SRV
+ records. Allocating the available listening port numbers locally
+ on a per-host basis as needed allows much better utilization of the
+ available port space than today's centralized global allocation.
+
+ In some environments there may be no compelling reason to assign
+ managed names to every host, since every available service is
+ accessible by name anyway, as a first-class entity in its own right.
+ However, the DNS packet format and record format still require a host
+ name to link the target host referenced in the SRV record to the
+ address records giving the IPv4 and/or IPv6 addresses for that
+ hardware. In the case where no natural host name is available, the
+ SRV record may give its own name as the name of the target host, and
+ then the requisite address records may be attached to that same name.
+ It is perfectly permissible for a single name in the DNS hierarchy to
+ have multiple records of different type attached. (The only
+ restriction being that a given name may not have both a CNAME record
+ and other records at the same time.)
+
+ In the event that more than one SRV is returned, clients MUST
+ correctly interpret the priority and weight fields -- i.e. Lower
+ numbered priority servers should be used in preference to higher
+ numbered priority servers, and servers with equal priority should be
+ selected randomly in proportion to their relative weights.
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 11]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+6. Data Syntax for DNS-SD TXT Records
+
+ Some services discovered via Service Instance Enumeration may need
+ more than just an IP address and port number to properly identify the
+ service. For example, printing via the LPR protocol often specifies a
+ queue name. This queue name is typically short and cryptic, and need
+ not be shown to the user. It should be regarded the same way as the
+ IP address and port number -- it is one component of the addressing
+ information required to identify a specific instance of a service
+ being offered by some piece of hardware. Similarly, a file server may
+ have multiple volumes, each identified by its own volume name. A Web
+ server typically has multiple pages, each identified by its own URL.
+ In these cases, the necessary additional data is stored in a TXT
+ record with the same name as the SRV record. The specific nature of
+ that additional data, and how it is to be used, is service-dependent,
+ but the overall syntax of the data in the TXT record is standardized,
+ as described below.
+
+
+6.1 General Format Rules for DNS TXT Records
+
+ A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total
+ length is indicated by the length given in the resource record header
+ in the DNS message. There is no way to tell directly from the data
+ alone how long it is (e.g. there is no length count at the start, or
+ terminating NULL byte at the end). (Note that when using Multicast
+ DNS [mDNS] the maximum packet size is 9000 bytes, which imposes an
+ upper limit on the size of TXT records of about 8800 bytes.)
+
+ The format of the data within a DNS TXT record is zero or more
+ strings, packed together in memory without any intervening gaps or
+ padding bytes for word alignment.
+
+ The format of each constituent string within the DNS TXT record is a
+ single length byte, followed by 0-255 bytes of text data.
+
+ These format rules are defined in Section 3.3.14 of RFC 1035, and are
+ not specific to DNS-SD. DNS-SD simply specifies a usage convention
+ for what data should be stored in those constituent strings.
+
+
+6.2 DNS TXT Record Format Rules for use in DNS-SD
+
+ DNS-SD uses DNS TXT records to store arbitrary name/value pairs
+ conveying additional information about the named service. Each
+ name/value pair is encoded as its own constituent string within the
+ DNS TXT record, in the form "name=value". Everything up to the first
+ '=' character is the name. Everything after the first '=' character
+ to the end of the string (including subsequent '=' characters, if
+ any) is the value. Specific rules governing names and values are
+ given below. Each author defining a DNS-SD profile for discovering
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 12]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+ instances of a particular type of service should define the base set
+ of name/value attributes that are valid for that type of service.
+
+ Using this standardized name/value syntax within the TXT record makes
+ it easier for these base definitions to be expanded later by defining
+ additional named attributes. If an implementation sees unknown
+ attribute names in a service TXT record, it MUST silently ignore them.
+
+ The TCP (or UDP) port number of the service, and target host name,
+ are given in the SRV record. This information -- target host name and
+ port number -- MUST NOT be duplicated using name/value attributes in
+ the TXT record.
+
+ The intention of DNS-SD TXT records is to convey a small amount of
+ useful additional information about a service. Ideally it SHOULD NOT
+ be necessary for a client to retrieve this additional information
+ before it can usefully establish a connection to the service. For a
+ well-designed TCP-based application protocol, it should be possible,
+ knowing only the host name and port number, to open a connection to
+ that listening process, and then perform version- or feature-
+ negotiation to determine the capabilities of the service instance.
+ For example, when connecting to an AppleShare server over TCP, the
+ client enters into a protocol exchange with the server to determine
+ which version of the AppleShare protocol the server implements, and
+ which optional features or capabilities (if any) are available. For a
+ well-designed application protocol, clients should be able to connect
+ and use the service even if there is no information at all in the TXT
+ record. In this case, the information in the TXT record should be
+ viewed as a performance optimization -- when a client discovers many
+ instances of a service, the TXT record allows the client to know some
+ rudimentary information about each instance without having to open a
+ TCP connection to each one and interrogate every service instance
+ separately. Extreme care should be taken when doing this to ensure
+ that the information in the TXT record is in agreement with the
+ information retrieved by a client connecting over TCP.
+
+ There are legacy protocols which provide no feature negotiation
+ capability, and in these cases it may be useful to convey necessary
+ information in the TXT record. For example, when printing using the
+ old Unix LPR (port 515) protocol, the LPR service provides no way for
+ the client to determine whether a particular printer accepts
+ PostScript, or what version of PostScript, etc. In this case it is
+ appropriate to embed this information in the TXT record, because the
+ alternative is worse -- passing around written instructions to the
+ users, arcane manual configuration of "/etc/printcap" files, etc.
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 13]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+6.3 DNS-SD TXT Record Size
+
+ The total size of a typical DNS-SD TXT record is intended to be small
+ -- 200 bytes or less.
+
+ In cases where more data is justified (e.g. LPR printing), keeping
+ the total size under 400 bytes should allow it to fit in a single
+ standard 512-byte DNS message. (This standard DNS message size is
+ defined in RFC 1035.)
+
+ In extreme cases where even this is not enough, keeping the size of
+ the TXT record under 1300 bytes should allow it to fit in a single
+ 1500-byte Ethernet packet.
+
+ Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this
+ time.
+
+
+6.4 Rules for Names in DNS-SD Name/Value Pairs
+
+ The "Name" MUST be at least one character. Strings beginning with an
+ '=' character (i.e. the name is missing) SHOULD be silently ignored.
+
+ The characters of "Name" MUST be printable US-ASCII values
+ (0x20-0x7E), excluding '=' (0x3D).
+
+ Spaces in the name are significant, whether leading, trailing, or in
+ the middle -- so don't include any spaces unless you really intend
+ that!
+
+ Case is ignored when interpreting a name, so "papersize=A4",
+ "PAPERSIZE=A4" and "Papersize=A4" are all identical.
+
+ If there is no '=', then it is a boolean attribute, and is simply
+ identified as being present, with no value.
+
+ Unless specified otherwise by a particular DNS-SD profile, a given
+ attribute name may appear at most once in a TXT record. If a client
+ receives a TXT record containing the same attribute name more than
+ once, then the client SHOULD silently ignore all but the first
+ occurrence of that attribute. For client implementations that process
+ a DNS-SD TXT record from start to end, placing name/value pairs into
+ a hash table, using the name as the hash table key, this means that
+ if the implementation attempts to add a new name/value pair into the
+ table and finds an entry with the same name already present, then the
+ new entry being added should be silently discarded instead. For
+ client implementations that retrieve name/value pairs by searching
+ the TXT record for the requested name, they should search the TXT
+ record from the start, and simply return the first matching name they
+ find.
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 14]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+ When examining a TXT record for a given named attribute, there are
+ therefore four broad categories of results which may be returned:
+
+ * Attribute not present (Absent)
+
+ * Attribute present, with no value
+ (e.g. "Anon Allowed" -- server allows anonymous connections)
+
+ * Attribute present, with empty value (e.g. "Installed PlugIns=" --
+ server supports plugins, but none are presently installed)
+
+ * Attribute present, with non-empty value
+ (e.g. "Installed PlugIns=JPEG,MPEG2,MPEG4")
+
+ Each author defining a DNS-SD profile for discovering instances of a
+ particular type of service should define the interpretation of these
+ different kinds of result. For example, for some keys, there may be
+ a natural true/false boolean interpretation:
+
+ * Present implies 'true'
+ * Absent implies 'false'
+
+ For other keys it may be sensible to define other semantics, such as
+ value/no-value/unknown:
+
+ * Present with value implies that value.
+ E.g. "Color=4" for a four-color ink-jet printer,
+ or "Color=6" for a six-color ink-jet printer.
+
+ * Present with empty value implies 'false'. E.g. Not a color printer.
+
+ * Absent implies 'Unknown'. E.g. A print server connected to some
+ unknown printer where the print server doesn't actually know if the
+ printer does color or not -- which gives a very bad user experience
+ and should be avoided wherever possible.
+
+ (Note that this is a hypothetical example, not an example of actual
+ name/value keys used by DNS-SD network printers.)
+
+ As a general rule, attribute names that contain no dots are defined
+ as part of the open-standard definition written by the person or
+ group defining the DNS-SD profile for discovering that particular
+ service type. Vendor-specific extensions should be given names of the
+ form "keyname.company.com=value", using a domain name legitimately
+ registered to the person or organization creating the vendor-specific
+ key. This reduces the risk of accidental conflict if different
+ organizations each define their own vendor-specific keys.
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 15]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+6.5 Rules for Values in DNS-SD Name/Value Pairs
+
+ If there is an '=', then everything after the first '=' to the end of
+ the string is the value. The value can contain any eight-bit values
+ including '='. Leading or trailing spaces are part of the value, so
+ don't put them there unless you intend them to be there. Any
+ quotation marks around the value are part of the value, so don't put
+ them there unless you intend them to be part of the value.
+
+ The value is opaque binary data. Often the value for a particular
+ attribute will be US-ASCII (or UTF-8) text, but it is legal for a
+ value to be any binary data. For example, if the value of a key is an
+ IPv4 address, that address should simply be stored as four bytes of
+ binary data, not as a variable-length 7-15 byte ASCII string giving
+ the address represented in textual dotted decimal notation.
+
+ Generic debugging tools should generally display all attribute values
+ as a hex dump, with accompanying text alongside displaying the UTF-8
+ interpretation of those bytes, except for attributes where the
+ debugging tool has embedded knowledge that the value is some other
+ kind of data.
+
+ Authors defining DNS-SD profiles SHOULD NOT convert binary attribute
+ data types into printable text (e.g. using hexadecimal, Base64 or UU
+ encoding) merely for the sake of making the data be printable text
+ when seen in a generic debugging tool. Doing this simply bloats the
+ size of the TXT record, without atually making the data any more
+ understandable to someone looking at it in a generic debugging tool.
+
+
+6.6 Example TXT Record
+
+ The TXT record below contains three syntactically valid name/value
+ pairs. (The meaning of these name/value pairs, if any, would depend
+ on the definitions pertaining to the service in question that is
+ using them.)
+
+ ---------------------------------------------------------------
+ | 0x0A | name=value | 0x08 | paper=A4 | 0x0E | DNS-SD Is Cool |
+ ---------------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 16]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+6.7 Version Tag
+
+ It is recommended that authors defining DNS-SD profiles include an
+ attribute of the form "txtvers=xxx" in their definition, and require
+ it to be the first name/value pair in the TXT record. This
+ information in the TXT record can be useful to help clients maintain
+ backwards compatibility with older implementations if it becomes
+ necessary to change or update the specification over time. Even if
+ the profile author doesn't anticipate the need for any future
+ incompatible changes, having a version number in the specification
+ provides useful insurance should incompatible changes become
+ unavoidable. Clients SHOULD ignore TXT records with a txtvers number
+ higher (or lower) than the version(s) they know how to interpret.
+
+ Note that the version number in the txtvers tag describes the version
+ of the TXT record specification being used to create this TXT record,
+ not the version of the application protocol that will be used if the
+ client subsequently decides to contact that service. Ideally, every
+ DNS-SD TXT record specification starts at txtvers=1 and stays that
+ way forever. Improvements can be made by defining new keys that older
+ clients silently ignore. The only reason to increment the version
+ number is if the old specification is subsequently found to be so
+ horribly broken that there's no way to do a compatible forward
+ revision, so the txtvers number has to be incremented to tell all the
+ old clients they should just not even try to understand this new TXT
+ record.
+
+ If there is a need to indicate which version number(s) of the
+ application protocol the service implements, the recommended key
+ name for this is "protovers".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 17]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+7. Application Protocol Names
+
+ The <Service> portion of a Service Instance Name consists of a pair
+ of DNS labels, following the established convention for SRV records
+ [RFC 2782], namely: the first label of the pair is the Application
+ Protocol Name, and the second label is either "_tcp" or "_udp".
+
+ Wise selection of the Application Protocol Name is very important,
+ and the choice is not always as obvious as it may appear.
+
+ In some cases, the Application Protocol Name merely names and refers
+ to the on-the-wire message format and semantics being used. FTP is
+ "ftp", IPP printing is "ipp", and so on.
+
+ However, it is common to "borrow" an existing protocol and repurpose
+ it for a new task. This is entirely sensible and sound engineering
+ practice, but that doesn't mean that the new protocol is providing
+ the same semantic service as the old one, even if it borrows the same
+ message formats. For example, the local network music playing
+ protocol implemented by iTunes on Macintosh and Windows is little
+ more than "HTTP GET" commands. However, that does *not* mean that it
+ is sensible or useful to try to access one of these music servers by
+ connecting to it with a standard web browser. Consequently, the
+ DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp"
+ (Digital Audio Access Procol), not "_http._tcp". Advertising
+ "_http._tcp" service would cause iTunes servers to show up in
+ conventional Web browsers (Safari, Camino, OmniWeb, Opera, Netscape,
+ Internet Explorer, etc.) which is little use since it offers no pages
+ containing human-readable content. Similarly, browsing for
+ "_http._tcp" service would cause iTunes to find generic web servers,
+ such as the embedded web servers in devices like printers, which is
+ little use since printers generally don't have much music to offer.
+
+ Similarly, NFS is built on top of SUN RPC, but that doesn't mean it
+ makes sense for an NFS server to advertise that it provides "SUN RPC"
+ service. Likewise, Microsoft SMB file service is built on top of
+ Netbios running over IP, but that doesn't mean it makes sense for an
+ SMB file server to advertise that it provides "Netbios-over-IP"
+ service. The DNS-SD name of a service needs to encapsulate both the
+ "what" (semantics) and the "how" (protocol implementation) of the
+ service, since knowledge of both is necessary for a client to
+ usefully use the service. Merely advertising that a service was built
+ on top of SUN RPC is no use if the client has no idea what the
+ service actually does.
+
+ Another common mistake is to assume that the service type advertised
+ by iTunes should be "_daap._http._tcp." This is also incorrect. Part
+ of the confusion here is that the presence of "_tcp" or "_udp" in the
+ <Service> portion of a Service Instance Name has led people to assume
+ that the structure of a service name has to reflect the internal
+ structure of how the protocol was implemented. This is not correct.
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 18]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+ The "_tcp" or "_udp" should be regarded as little more than
+ boilerplate text, and care should be taken not to attach too much
+ importance to it. Some might argue that the "_tcp" or "_udp" should
+ not be there at all, but this format is defined by RFC 2782, and
+ that's not going to change. In addition, the presence of "_tcp" has
+ the useful side-effect that it provides a convenient delegation point
+ to hand off control to a different DNS server, if so desired.
+
+
+8. Selective Instance Enumeration
+
+ This document does not attempt to define an arbitrary query language
+ for service discovery, nor do we believe one is necessary.
+
+ However, there are some circumstances where narrowing the list of
+ results may be useful. A Web browser client that is able to retrieve
+ HTML documents via HTTP and display them may also be able to retrieve
+ HTML documents via FTP and display them, but only in the case of FTP
+ servers that allow anonymous login. For that Web browser, discovering
+ all FTP servers on the network is not useful. The Web browser only
+ wants to discover FTP servers that it is able to talk to. In this
+ case, a subtype of "_ftp._tcp" could be defined. Instead of issuing a
+ query for "_ftp._tcp.<Domain>", the Web browser issues a query for
+ "_anon._ftp._tcp.<Domain>", where "_anon" is a defined subtype of
+ "_ftp._tcp". The response to this query only includes the names of
+ SRV records for FTP servers that are willing to allow anonymous
+ login.
+
+ Note that the FTP server's Service Instance Name is unchanged -- it
+ is still something of the form "The Server._ftp._tcp.example.com."
+ The subdomain in which FTP server SRV records are registered defines
+ the namespace within which FTP server names are unique. Additional
+ subtypes (e.g. "_anon") of the basic service type (e.g. "_ftp._tcp")
+ serve to narrow the list of results, not to create more namespace.
+
+ As with the TXT record name/value pairs, the list of possible
+ subtypes, if any, are defined and specified separately for each basic
+ service type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 19]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+9. Flagship Naming
+
+ In some cases, there may be several network protocols available which
+ all perform roughly the same logical function. For example, the
+ printing world has the LPR protocol, and the Internet Printing
+ Protocol (IPP), both of which cause printed sheets to be emitted from
+ printers in much the same way. In addition, many printer vendors send
+ their own proprietary page description language (PDL) data over a TCP
+ connection to TCP port 9100, herein referred to as the
+ "pdl-datastream" protocol. In an ideal world we would have only one
+ network printing protocol, and it would be sufficiently good that no
+ one felt a compelling need to invent a different one. However, in
+ practice, multiple legacy protocols do exist, and a service discovery
+ protocol has to accommodate that.
+
+ Many printers implement all three printing protocols: LPR, IPP, and
+ pdl-datastream. For the benefit of clients that may speak only one of
+ those protocols, all three are advertised.
+
+ However, some clients may implement two, or all three of those
+ printing protocols. When a client looks for all three service types
+ on the network, it will find three distinct services -- an LPR
+ service, an IPP service, and a pdl-datastream service -- all of which
+ cause printed sheets to be emitted from the same physical printer.
+
+ In the case of multiple protocols like this that all perform
+ effectively the same function, the client should suppress duplicate
+ names and display each name only once. When the user prints to a
+ given named printer, the printing client is responsible for choosing
+ the protocol which will best achieve the desired effect, without, for
+ example, requiring the user to make a manual choice between LPR and
+ IPP.
+
+ As described so far, this all works very well. However, consider some
+ future printer that only supports IPP printing, and some other future
+ printer that only supports pdl-datastream printing. The name spaces
+ for different service types are intentionally disjoint -- it is
+ acceptable and desirable to be able to have both a file server called
+ "Sales Department" and a printer called "Sales Department". However,
+ it is not desirable, in the common case, to have two different
+ printers both called "Sales Department", just because those printers
+ are implementing different protocols.
+
+ To help guard against this, when there are two or more network
+ protocols which perform roughly the same logical function, one of the
+ protocols is declared the "flagship" of the fleet of related
+ protocols. Typically the flagship protocol is the oldest and/or
+ best-known protocol of the set.
+
+ If a device does not implement the flagship protocol, then it instead
+ creates a placeholder SRV record (priority=0, weight=0, port=0,
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 20]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+ target host = hostname of device) with that name. If, when it
+ attempts to create this SRV record, it finds that a record with the
+ same name already exists, then it knows that this name is already
+ taken by some entity implementing at least one of the protocols from
+ the class, and it must choose another. If no SRV record already
+ exists, then the act of creating it stakes a claim to that name so
+ that future devices in the same class will detect a conflict when
+ they try to use it. The SRV record needs to contain the target host
+ name in order for the conflict detection rules to operate. If two
+ different devices were to create placeholder SRV records both using a
+ null target host name (just the root label), then the two SRV records
+ would be seen to be in agreement so no conflict would be registered.
+
+ By defining a common well-known flagship protocol for the class,
+ future devices that may not even know about each other's protocols
+ establish a common ground where they can coordinate to verify
+ uniqueness of names.
+
+ No PTR record is created advertising the presence of empty flagship
+ SRV records, since they do not represent a real service being
+ advertised.
+
+
+10. Service Type Enumeration
+
+ In general, clients are not interested in finding *every* service on
+ the network, just the services that the client knows how to talk to.
+ (Software designers may *think* there's some value to finding *every*
+ service on the network, but that's just wooly thinking.)
+
+ 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 reason, a special meta-query is defined. A DNS query for
+ PTR records with the name "_services._dns-sd._udp.<Domain>" yields
+ a list of PTR records, where the rdata of each PTR record is the
+ name of a service type. A subsequent query for PTR records with
+ one of those names yields a list of instances of that service type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 21]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+11. Populating the DNS with Information
+
+ How the SRV and PTR records that describe services and allow them to
+ be enumerated make their way into the DNS is outside the scope of
+ this document. However, it can happen easily in any of a number of
+ ways, for example:
+
+ On some networks, the administrator might manually enter the records
+ into the name server's configuration file.
+
+ A network monitoring tool could output a standard zone file to be
+ read into a conventional DNS server. For example, a tool that can
+ find Apple LaserWriters using AppleTalk NBP could find the list of
+ printers, communicate with each one to find its IP address,
+ PostScript version, installed options, etc., and then write out a DNS
+ zone file describing those printers and their capabilities using DNS
+ resource records. That information would then be available to DNS-SD
+ clients that don't implement AppleTalk NBP, and don't want to.
+
+ Future IP printers could use Dynamic DNS Update [RFC 2136] to
+ automatically register their own SRV and PTR records with the DNS
+ server.
+
+ A printer manager device which has knowledge of printers on the
+ network through some other management protocol could also use Dynamic
+ DNS Update [RFC 2136].
+
+ Alternatively, a printer manager device could implement enough of the
+ DNS protocol that it is able to answer DNS queries directly, and
+ Example Co.'s main DNS server could delegate the
+ _ipp._tcp.example.com subdomain to the printer manager device.
+
+ Zeroconf printers answer Multicast DNS queries on the local link
+ for appropriate PTR and SRV names ending with ".local." [mDNS]
+
+
+12. Relationship to Multicast DNS
+
+ DNS-Based Service Discovery is only peripherally related to Multicast
+ DNS, in that the standard unicast DNS queries used by DNS-SD may also
+ be performed using multicast when appropriate, which is particularly
+ beneficial in Zeroconf environments [ZC].
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 22]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+13. Discovery of Browsing and Registration Domains (Domain Enumeration)
+
+ One of the main reasons for DNS-Based Service Discovery is so that
+ when a visiting client (e.g. a laptop computer) arrives at a new
+ network, it can discover what services are available on that network
+ without manual configuration. This logic that applies to discovering
+ services without manual configuration also applies to discovering the
+ domains in which services are registered without requiring manual
+ configuration.
+
+ This discovery is performed recursively, using Unicast or Multicast
+ DNS. Four special RR names are reserved for this purpose:
+
+ _browse._dns-sd._udp.<domain>
+ _default._browse._dns-sd._udp.<domain>
+ _register._dns-sd._udp.<domain>
+ _default._register._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.
+
+ These domains are purely advisory. The client or user is free to
+ browse and/or register services in any domains. The purpose of these
+ special queries is to allow software to create a user-interface that
+ displays a useful list of suggested choices to the user, from which
+ they may make a suitable selection, or ignore the offered suggestions
+ and manually enter their own choice.
+
+ The <domain> part of the name may be ".local." (meaning "perform the
+ query using link-local multicast) or it may be learned through some
+ other mechanism, such as the DHCP "Domain" option (option code 15)
+ [RFC 2132] or the DHCP "Domain Search" option (option code 119)
+ [RFC 3397]. Sophisticated clients may perform these queries both in
+ ".local." and in one or more unicast domains, and then present the
+ user with an aggregate result, combining the information received
+ from all sources.
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 23]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+14. DNS Additional Record Generation
+
+ DNS has an efficiency feature whereby a DNS server may place
+ additional records in the Additional Section of the DNS Message.
+ These additional records are typically records that the client did
+ not explicitly request, but the server has reasonable grounds to
+ expect that the client might request them shortly.
+
+ This section recommends which additional records should be generated
+ to improve network efficiency for both unicast and multicast DNS-SD
+ responses.
+
+
+14.1 PTR Records
+
+ When including a PTR record in a response packet, the
+ server/responder SHOULD include the following additional records:
+
+ o The SRV record(s) named in the PTR rdata.
+ o The TXT record(s) named in the PTR rdata.
+ o All address records (type "A" and "AAAA") named in the SRV rdata.
+
+
+14.2 SRV Records
+
+ When including an SVR record in a response packet, the
+ server/responder SHOULD include the following additional records:
+
+ o All address records (type "A" and "AAAA") named in the SRV rdata.
+
+
+14.3 TXT Records
+
+ When including a TXT record in a response packet, no additional
+ records are required.
+
+
+14.4 Other Record Types
+
+ In response to address queries, or other record types, no additional
+ records are required by this document.
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 24]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+15. Comparison with Alternative Service Discovery Protocols
+
+ Over the years there have been many proposed ways to do network
+ service discovery with IP, but none achieved ubiquity in the
+ marketplace. Certainly none has achieved anything close to the
+ ubiquity of today's deployment of DNS servers, clients, and other
+ infrastructure.
+
+ The advantage of using DNS as the basis for service discovery is that
+ it makes use of those existing servers, clients, protocols,
+ infrastructure, and expertise. Existing network analyser tools
+ already know how to decode and display DNS packets for network
+ debugging.
+
+ For ad-hoc networks such as Zeroconf environments, peer-to-peer
+ multicast protocols are appropriate. The Zeroconf host profile [ZCHP]
+ requires the use of a DNS-like protocol over IP Multicast for host
+ name resolution in the absence of DNS servers. Given that Zeroconf
+ hosts will have to implement this Multicast-based DNS-like protocol
+ anyway, it makes sense for them to also perform service discovery
+ using that same Multicast-based DNS-like software, instead of also
+ having to implement an entirely different service discovery protocol.
+
+ In larger networks, a high volume of enterprise-wide IP multicast
+ traffic may not be desirable, so any credible service discovery
+ protocol intended for larger networks has to provide some facility to
+ aggregate registrations and lookups at a central server (or servers)
+ instead of working exclusively using multicast. This requires some
+ service discovery aggregation server software to be written,
+ debugged, deployed, and maintained. This also requires some service
+ discovery registration protocol to be implemented and deployed for
+ clients to register with the central aggregation server. Virtually
+ every company with an IP network already runs a DNS server, and DNS
+ already has a dynamic registration protocol [RFC 2136]. Given that
+ virtually every company already has to operate and maintain a DNS
+ server anyway, it makes sense to take advantage of this instead of
+ also having to learn, operate and maintain a different service
+ registration server. It should be stressed again that using the same
+ software and protocols doesn't necessarily mean using the same
+ physical piece of hardware. The DNS-SD service discovery functions
+ do not have to be provided by the same piece of hardware that
+ is currently providing the company's DNS name service. The
+ "_tcp.<Domain>" subdomain may be delegated to a different piece of
+ hardware. However, even when the DNS-SD service is being provided by
+ a different piece of hardware, it is still the same familiar DNS
+ server software that is running, with the same configuration file
+ syntax, the same log file format, and so forth.
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 25]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+ Service discovery needs to be able to provide appropriate security.
+ DNS already has existing mechanisms for security [RFC 2535].
+
+ In summary:
+
+ Service discovery requires a central aggregation server.
+ DNS already has one: It's called a DNS server.
+
+ Service discovery requires a service registration protocol.
+ DNS already has one: It's called DNS Dynamic Update.
+
+ Service discovery requires a query protocol
+ DNS already has one: It's called DNS.
+
+ Service discovery requires security mechanisms.
+ DNS already has security mechanisms: DNSSEC.
+
+ Service discovery requires a multicast mode for ad-hoc networks.
+ Zeroconf environments already require a multicast-based DNS-like
+ name lookup protocol for mapping host names to addresses, so it
+ makes sense to let one multicast-based protocol do both jobs.
+
+ It makes more sense to use the existing software that every network
+ needs already, instead of deploying an entire parallel system just
+ for service discovery.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 26]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+16. Real Example
+
+ The following examples were prepared using standard unmodified
+ nslookup and standard unmodified BIND running on GNU/Linux.
+
+ Note: In real products, this information is obtained and presented to
+ the user using graphical network browser software, not command-line
+ tools, but if you wish you can try these examples for yourself as you
+ read along, using the command-line tools already available on your
+ own Unix machine.
+
+
+16.1 Question: What FTP servers are being advertised from dns-sd.org?
+
+ nslookup -q=ptr _ftp._tcp.dns-sd.org.
+ _ftp._tcp.dns-sd.org name=Apple\032QuickTime\032Files.dns-sd.org
+ _ftp._tcp.dns-sd.org name=Microsoft\032Developer\032Files.dns-sd.org
+ _ftp._tcp.dns-sd.org name=Registered\032Users'\032Only.dns-sd.org
+
+ Answer: There are three, called "Apple QuickTime Files",
+ "Microsoft Developer Files" and "Registered Users' Only".
+
+ Note that nslookup escapes spaces as "\032" for display purposes,
+ but a graphical DNS-SD browser does not.
+
+
+16.2 Question: What FTP servers allow anonymous access?
+
+ nslookup -q=ptr _anon._ftp._tcp.dns-sd.org
+ _anon._ftp._tcp.dns-sd.org
+ name=Apple\032QuickTime\032Files.dns-sd.org
+ _anon._ftp._tcp.dns-sd.org
+ name=Microsoft\032Developer\032Files.dns-sd.org
+
+ Answer: Only "Apple QuickTime Files" and "Microsoft Developer Files"
+ allow anonymous access.
+
+
+16.3 Question: How do I access "Apple QuickTime Files"?
+
+ nslookup -q=any "Apple\032QuickTime\032Files.dns-sd.org."
+ Apple\032QuickTime\032Files.dns-sd.org text = "path=/quicktime"
+ Apple\032QuickTime\032Files.dns-sd.org
+ priority = 0, weight = 0, port= 21 host = ftp.apple.com
+ ftp.apple.com internet address = 17.254.0.27
+ ftp.apple.com internet address = 17.254.0.31
+ ftp.apple.com internet address = 17.254.0.26
+
+ Answer: You need to connect to ftp.apple.com, port 21, path
+ "/quicktime". The addresses for ftp.apple.com are also given.
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 27]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+17. IPv6 Considerations
+
+ IPv6 has no significant differences, except that the address of the
+ SRV record's target host is given by the appropriate IPv6 address
+ records instead of the IPv4 "A" record.
+
+
+18. Security Considerations
+
+ DNSSEC [RFC 2535] should be used where the authenticity of
+ information is important. Since DNS-SD is just a naming and usage
+ convention for records in the existing DNS system, it has no specific
+ additional security requirements over and above those that already
+ apply to DNS queries and DNS updates.
+
+
+19. IANA Considerations
+
+ This protocol builds on DNS SRV records [RFC 2782], and similarly
+ requires IANA to assign unique application protocol names.
+ Unfortunately, the "IANA Considerations" section of RFC 2782 says
+ simply, "The IANA has assigned RR type value 33 to the SRV RR.
+ No other IANA services are required by this document."
+ Due to this oversight, IANA is currently prevented from carrying
+ out the necessary function of assigning these unique identifiers.
+
+ This document proposes the following IANA allocation policy for
+ unique application protocol names:
+
+ Allowable names:
+ * Must be no more than fourteen characters long
+ * Must consist only of:
+ - lower-case letters 'a' - 'z'
+ - digits '0' - '9'
+ - the hyphen character '-'
+ * Must begin and end with a lower-case letter or digit.
+ * Must not already be assigned to some other protocol in the
+ existing IANA "list of assigned application protocol names
+ and port numbers" [ports].
+
+ These identifiers are allocated on a First Come First Served basis.
+ In the event of abuse (e.g. automatated mass registrations, etc.),
+ the policy may be changed without notice to Expert Review [RFC 2434].
+
+ The textual nature of service/protocol names means that there are
+ almost infinitely many more of them available than the finite set of
+ 65535 possible port numbers. This means that developers can produce
+ experimental implementations using unregistered service names with
+ little chance of accidental collision, providing service names are
+ chosen with appropriate care. However, this document strongly
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 28]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+ advocates that on or before the date a product ships, developers
+ should properly register their service names.
+
+ Some developers have expressed concern that publicly registering
+ their service names (and port numbers today) with IANA before a
+ product ships may give away clues about that product to competitors.
+ For this reason, IANA should consider allowing service name
+ applications to remain secret for some period of time, much as US
+ patent applications remain secret for two years after the date of
+ filing.
+
+ This proposed IANA allocation policy is not in force until this
+ document is published as an RFC. In the meantime, unique application
+ protocol names may be registered according to the instructions at
+ <http://www.dns-sd.org/ServiceNames.html>. As of January 2004, there
+ are roughly 100 application protocols in currently shipping products
+ that have been so registered as using DNS-SD for service discovery.
+
+
+20. Acknowledgements
+
+ We would like to thank (in alphabetical order) Richard Brown, Josh
+ Graessley, Erik Guttman, Paul Vixie, and Bill Woodcock, for their
+ contributions.
+
+
+21. Copyright
+
+ Copyright (C) The Internet Society 2004.
+ All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 29]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+22. Normative References
+
+ [ports] IANA list of assigned application protocol names and port
+ numbers <http://www.iana.org/assignments/port-numbers>
+
+ [RFC 1033] Lottor, M., "Domain Administrators Operations Guide",
+ RFC 1033, November 1987.
+
+ [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
+ Facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+ Specifications", STD 13, RFC 1035, November 1987.
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+ [RFC 2782] Gulbrandsen, A., et al., "A DNS RR for specifying the
+ location of services (DNS SRV)", RFC 2782, February 2000.
+
+
+23. Informative References
+
+ [mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS",
+ Internet-Draft (work in progress),
+ draft-cheshire-dnsext-multicastdns-04.txt, February 2004.
+
+ [NBP] Cheshire, S., and M. Krochmal,
+ "Requirements for a Protocol to Replace AppleTalk NBP",
+ Internet-Draft (work in progress),
+ draft-cheshire-dnsext-nbp-03.txt, February 2004.
+
+ [RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP
+ Vendor Extensions", RFC 2132, March 1997.
+
+ [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
+ System (DNS UPDATE)", RFC 2136, April 1997.
+
+ [RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing
+ an IANA Considerations Section in RFCs", RFC 2434,
+ October 1998.
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 30]
+\f
+Internet Draft DNS-Based Service Discovery 14th February 2004
+
+
+ [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [RFC 3007] Wellington, B., et al., "Secure Domain Name System (DNS)
+ Dynamic Update", RFC 3007, November 2000.
+
+ [RFC 3397] Aboba, B., and Cheshire, S., "Dynamic Host Configuration
+ Protocol (DHCP) Domain Search Option", RFC 3397, November
+ 2002.
+
+ [ZC] Williams, A., "Requirements for Automatic Configuration
+ of IP Hosts", Internet-Draft (work in progress),
+ draft-ietf-zeroconf-reqts-12.txt, September 2002.
+
+ [ZCHP] Guttman, E., "Zeroconf Host Profile Applicability
+ Statement", Internet-Draft (work in progress),
+ draft-ietf-zeroconf-host-prof-01.txt, July 2001.
+
+
+24. Author's Addresses
+
+ Stuart Cheshire
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino
+ California 95014
+ USA
+
+ Phone: +1 408 974 3207
+ EMail: rfc@stuartcheshire.org
+
+
+ Marc Krochmal
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino
+ California 95014
+ USA
+
+ Phone: +1 408 974 4368
+ EMail: marc@apple.com
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 31]
--- /dev/null
+Document: draft-cheshire-dnsext-dns-sd-03.txt Stuart Cheshire
+Category: Standards Track Apple Computer, Inc.
+Expires 7th December 2005 Marc Krochmal
+ Apple Computer, Inc.
+ 7th June 2005
+
+ DNS-Based Service Discovery
+
+ <draft-cheshire-dnsext-dns-sd-03.txt>
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF),
+ its areas, and its working groups. Note that other groups may
+ also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other documents
+ at any time. It is inappropriate to use Internet-Drafts as
+ reference material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ Distribution of this memo is unlimited.
+
+
+Abstract
+
+ This document describes a convention for naming and structuring DNS
+ resource records. Given a type of service that a client is looking
+ for, and a domain in which the client is looking for that service,
+ this convention allows clients to discover a list of named instances
+ of that desired service, using only standard DNS queries. In short,
+ this is referred to as DNS-based Service Discovery, or DNS-SD.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 1]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+Table of Contents
+
+ 1. Introduction....................................................3
+ 2. Conventions and Terminology Used in this Document...............3
+ 3. Design Goals....................................................4
+ 4. Service Instance Enumeration....................................5
+ 4.1 Structured Instance Names.......................................5
+ 4.2 User Interface Presentation.....................................7
+ 4.3 Internal Handling of Names......................................7
+ 4.4 What You See Is What You Get....................................7
+ 4.5 Ordering of Service Instance Name Components....................9
+ 5. Service Name Resolution........................................11
+ 6. Data Syntax for DNS-SD TXT Records.............................12
+ 6.1 General Format Rules for DNS TXT Records.......................12
+ 6.2 DNS TXT Record Format Rules for use in DNS-SD..................13
+ 6.3 DNS-SD TXT Record Size.........................................14
+ 6.4 Rules for Names in DNS-SD Name/Value Pairs.....................14
+ 6.5 Rules for Values in DNS-SD Name/Value Pairs....................16
+ 6.6 Example TXT Record.............................................16
+ 6.7 Version Tag....................................................17
+ 7. Application Protocol Names.....................................17
+ 7.1 Service Name Length Limits.....................................19
+ 8. Selective Instance Enumeration.................................20
+ 9. Flagship Naming................................................20
+ 10. Service Type Enumeration.......................................22
+ 11. Populating the DNS with Information............................23
+ 12. Relationship to Multicast DNS..................................23
+ 13. Discovery of Browsing and Registration Domains.................24
+ 14. DNS Additional Record Generation...............................25
+ 15. Comparison with Alternative Service Discovery Protocols........26
+ 16. Real Example...................................................28
+ 17. IPv6 Considerations............................................29
+ 18. Security Considerations........................................29
+ 19. IANA Considerations............................................29
+ 20. Acknowledgments................................................30
+ 21. Copyright......................................................30
+ 22. Normative References...........................................31
+ 23. Informative References.........................................31
+ 24. Authors' Addresses.............................................32
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 2]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+1. Introduction
+
+ This document describes a convention for naming and structuring DNS
+ resource records. Given a type of service that a client is looking
+ for, and a domain in which the client is looking for that service,
+ this convention allows clients to discover a list of named instances
+ of a that desired service, using only standard DNS queries. In short,
+ this is referred to as DNS-based Service Discovery, or DNS-SD.
+
+ This document proposes no change to the structure of DNS messages,
+ and no new operation codes, response codes, resource record types,
+ or any other new DNS protocol values. This document simply proposes
+ a convention for how existing resource record types can be named and
+ structured to facilitate service discovery.
+
+ This proposal is entirely compatible with today's existing unicast
+ DNS server and client software.
+
+ Note that the DNS-SD service does NOT have to be provided by the same
+ DNS server hardware that is currently providing an organization's
+ conventional host name lookup service (the service we traditionally
+ think of when we say "DNS"). By delegating the "_tcp" subdomain, all
+ the workload related to DNS-SD can be offloaded to a different
+ machine. This flexibility, to handle DNS-SD on the main DNS server,
+ or not, at the network administrator's discretion, is one of the
+ things that makes DNS-SD so compelling.
+
+ Even when the DNS-SD functions are delegated to a different machine,
+ the benefits of using DNS remain: It is mature technology, well
+ understood, with multiple independent implementations from different
+ vendors, a wide selection of books published on the subject, and an
+ established workforce experienced in its operation. In contrast,
+ adopting some other service discovery technology would require every
+ site in the world to install, learn, configure, operate and maintain
+ some entirely new and unfamiliar server software. Faced with these
+ obstacles, it seems unlikely that any other service discovery
+ technology could hope to compete with the ubiquitous deployment
+ that DNS already enjoys.
+
+ This proposal is also compatible with (but not dependent on) the
+ proposal outlined in "Multicast DNS" [mDNS].
+
+
+2. Conventions and Terminology Used in this Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in "Key words for use in
+ RFCs to Indicate Requirement Levels" [RFC 2119].
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 3]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+3. Design Goals
+
+ A good service discovery protocol needs to have many properties,
+ three of which are mentioned below:
+
+ (i) The ability to query for services of a certain type in a certain
+ logical domain and receive in response a list of named instances
+ (network browsing, or "Service Instance Enumeration").
+
+ (ii) Given a particular named instance, the ability to efficiently
+ resolve that instance name to the required information a client needs
+ to actually use the service, i.e. IP address and port number, at the
+ very least (Service Name Resolution).
+
+ (iii) Instance names should be relatively persistent. If a user
+ selects their default printer from a list of available choices today,
+ then tomorrow they should still be able to print on that printer --
+ even if the IP address and/or port number where the service resides
+ have changed -- without the user (or their software) having to repeat
+ the network browsing step a second time.
+
+ In addition, if it is to become successful, a service discovery
+ protocol should be so simple to implement that virtually any
+ device capable of implementing IP should not have any trouble
+ implementing the service discovery software as well.
+
+ These goals are discussed in more detail in the remainder of this
+ document. A more thorough treatment of service discovery requirements
+ may be found in "Requirements for a Protocol to Replace AppleTalk
+ NBP" [NBP]. That document draws upon examples from two decades of
+ operational experience with AppleTalk Name Binding Protocol to
+ develop a list of universal requirements which are broadly applicable
+ to any potential service discovery protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 4]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+4. Service Instance Enumeration
+
+ DNS SRV records [RFC 2782] are useful for locating instances of a
+ particular type of service when all the instances are effectively
+ indistinguishable and provide the same service to the client.
+
+ For example, SRV records with the (hypothetical) name
+ "_http._tcp.example.com." would allow a client to discover a list of
+ all servers implementing the "_http._tcp" service (i.e. Web servers)
+ for the "example.com." domain. The unstated assumption is that all
+ these servers offer an identical set of Web pages, and it doesn't
+ matter to the client which of the servers it uses, as long as it
+ selects one at random according to the weight and priority rules laid
+ out in RFC 2782.
+
+ Instances of other kinds of service are less easily interchangeable.
+ If a word processing application were to look up the (hypothetical)
+ SRV record "_ipp._tcp.example.com." to find the list of IPP printers
+ at Example Co., then picking one at random and printing on it would
+ probably not be what the user wanted.
+
+ The remainder of this section describes how SRV records may be used
+ in a slightly different way to allow a user to discover the names
+ of all available instances of a given type of service, in order to
+ select the particular instance the user desires.
+
+
+4.1 Structured Instance Names
+
+ This document borrows the logical service naming syntax and semantics
+ from DNS SRV records, but adds one level of indirection. Instead of
+ requesting records of type "SRV" with name "_ipp._tcp.example.com.",
+ the client requests records of type "PTR" (pointer from one name to
+ another in the DNS namespace).
+
+ In effect, if one thinks of the domain name "_ipp._tcp.example.com."
+ as being analogous to an absolute path to a directory in a file
+ system then the PTR lookup is akin to performing a listing of that
+ directory to find all the files it contains. (Remember that domain
+ names are expressed in reverse order compared to path names: An
+ absolute path name is read from left to right, beginning with a
+ leading slash on the left, and then the top level directory, then the
+ next level directory, and so on. A fully-qualified domain name is
+ read from right to left, beginning with the dot on the right -- the
+ root label -- and then the top level domain to the left of that, and
+ the second level domain to the left of that, and so on. If the fully-
+ qualified domain name "_ipp._tcp.example.com." were expressed as a
+ file system path name, it would be "/com/example/_tcp/_ipp".)
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 5]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ The result of this PTR lookup for the name "<Service>.<Domain>" is a
+ list of zero or more PTR records giving Service Instance Names of the
+ form:
+
+ Service Instance Name = <Instance> . <Service> . <Domain>
+
+ The <Instance> portion of the Service Instance Name is a single DNS
+ label, containing arbitrary precomposed UTF-8-encoded text [RFC
+ 2279]. It is a user-friendly name, meaning that it is allowed to
+ contain any characters, without restriction, including spaces, upper
+ case, lower case, punctuation -- including dots -- accented
+ characters, non-roman text, and anything else that may be represented
+ using UTF-8. DNS recommends guidelines for allowable characters for
+ host names [RFC 1033][RFC 1034][RFC 1035], but Service Instance Names
+ are not host names. Service Instance Names are not intended to ever
+ be typed in by a normal user; the user selects a Service Instance
+ Name by selecting it from a list of choices presented on the screen.
+
+ Note that just because this protocol supports arbitrary UTF-8-encoded
+ names doesn't mean that any particular user or administrator is
+ obliged to make use of that capability. Any user is free, if they
+ wish, to continue naming their services using only letters, digits
+ and hyphens, with no spaces, capital letters, or other punctuation.
+
+ DNS labels are currently limited to 63 octets in length. UTF-8
+ encoding can require up to four octets per Unicode character, which
+ means that in the worst case, the <Instance> portion of a name could
+ be limited to fifteen Unicode characters. However, the Unicode
+ characters with longer UTF-8 encodings tend to be the more obscure
+ ones, and tend to be the ones that convey greater meaning per
+ character.
+
+ Note that any character in the commonly-used 16-bit Unicode space can
+ be encoded with no more than three octets of UTF-8 encoding. This
+ means that an Instance name can contain up to 21 Kanji characters,
+ which is a sufficiently expressive name for most purposes.
+
+ The <Service> portion of the Service Instance Name consists of a pair
+ of DNS labels, following the established convention for SRV records
+ [RFC 2782], namely: the first label of the pair is the Application
+ Protocol Name, and the second label is either "_tcp" or "_udp",
+ depending on the transport protocol used by the application.
+ More details are given in Section 7, "Application Protocol Names".
+
+ The <Domain> portion of the Service Instance Name is a conventional
+ DNS domain name, consisting of as many labels as appropriate. For
+ example, "apple.com.", "cs.stanford.edu.", and "eng.us.ibm.com." are
+ all valid domain names for the <Domain> portion of the Service
+ Instance Name.
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 6]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+4.2 User Interface Presentation
+
+ The names resulting from the PTR lookup are presented to the user in
+ a list for the user to select one (or more). Typically only the first
+ label is shown (the user-friendly <Instance> portion of the name). In
+ the common case, the <Service> and <Domain> are already known to the
+ user, these having been provided by the user in the first place, by
+ the act of indicating the service being sought, and the domain in
+ which to look for it. Note: The software handling the response
+ should be careful not to make invalid assumptions though, since it
+ *is* possible, though rare, for a service enumeration in one domain
+ to return the names of services in a different domain. Similarly,
+ when using subtypes (see "Selective Instance Enumeration") the
+ <Service> of the discovered instance my not be exactly the same as
+ the <Service> that was requested.
+
+ Having chosen the desired named instance, the Service Instance Name
+ may then be used immediately, or saved away in some persistent
+ user-preference data structure for future use, depending on what is
+ appropriate for the application in question.
+
+
+4.3 Internal Handling of Names
+
+ If the <Instance>, <Service> and <Domain> portions are internally
+ concatenated together into a single string, then care must be taken
+ with the <Instance> portion, since it is allowed to contain any
+ characters, including dots.
+
+ Any dots in the <Instance> portion should be escaped by preceding
+ them with a backslash ("." becomes "\."). Likewise, any backslashes
+ in the <Instance> portion should also be escaped by preceding them
+ with a backslash ("\" becomes "\\"). Having done this, the three
+ components of the name may be safely concatenated. The
+ backslash-escaping allows literal dots in the name (escaped) to be
+ distinguished from label-separator dots (not escaped).
+
+ The resulting concatenated string may be safely passed to standard
+ DNS APIs like res_query(), which will interpret the string correctly
+ provided it has been escaped correctly, as described here.
+
+
+4.4 What You See Is What You Get
+
+ Some service discovery protocols decouple the true service identifier
+ from the name presented to the user. The true service identifier used
+ by the protocol is an opaque unique id, often represented using a
+ long string of hexadecimal digits, and should never be seen by the
+ typical user. The name presented to the user is merely one of the
+ ephemeral attributes attached to this opaque identifier.
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 7]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ The problem with this approach is that it decouples user perception
+ from reality:
+
+ * What happens if there are two service instances, with different
+ unique ids, but they have inadvertently been given the same
+ user-visible name? If two instances appear in an on-screen list
+ with the same name, how does the user know which is which?
+
+ * Suppose a printer breaks down, and the user replaces it with
+ another printer of the same make and model, and configures the new
+ printer with the exact same name as the one being replaced:
+ "Stuart's Printer". Now, when the user tries to print, the
+ on-screen print dialog tells them that their selected default
+ printer is "Stuart's Printer". When they browse the network to see
+ what is there, they see a printer called "Stuart's Printer", yet
+ when the user tries to print, they are told that the printer
+ "Stuart's Printer" can't be found. The hidden internal unique id
+ that the software is trying to find on the network doesn't match
+ the hidden internal unique id of the new printer, even though its
+ apparent "name" and its logical purpose for being there are the
+ same. To remedy this, the user typically has to delete the print
+ queue they have created, and then create a new (apparently
+ identical) queue for the new printer, so that the new queue will
+ contain the right hidden internal unique id. Having all this hidden
+ information that the user can't see makes for a confusing and
+ frustrating user experience, and exposing long ugly hexadecimal
+ strings to the user and forcing them to understand what they mean
+ is even worse.
+
+ * Suppose an existing printer is moved to a new department, and given
+ a new name and a new function. Changing the user-visible name of
+ that piece of hardware doesn't change its hidden internal unique
+ id. Users who had previously created print queues for that printer
+ will still be accessing the same hardware by its unique id, even
+ though the logical service that used to be offered by that hardware
+ has ceased to exist.
+
+ To solve these problems requires the user or administrator to be
+ aware of the supposedly hidden unique id, and to set its value
+ correctly as hardware is moved around, repurposed, or replaced,
+ thereby contradicting the notion that it is a hidden identifier that
+ human users never need to deal with. Requiring the user to understand
+ this expert behind-the-scenes knowledge of what is *really* going on
+ is just one more burden placed on the user when they are trying to
+ diagnose why their computers and network devices are not working as
+ expected.
+
+ These anomalies and counter-intuitive behaviors can be eliminated by
+ maintaining a tight bidirectional one-to-one mapping between what the
+ user sees on the screen and what is really happening "behind the
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 8]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ curtain". If something is configured incorrectly, then that is
+ apparent in the familiar day-to-day user interface that everyone
+ understands, not in some little-known rarely-used "expert" interface.
+
+ In summary: The user-visible name is the primary identifier for a
+ service. If the user-visible name is changed, then conceptually the
+ service being offered is a different logical service -- even though
+ the hardware offering the service stayed the same. If the
+ user-visible name doesn't change, then conceptually the service being
+ offered is the same logical service -- even if the hardware offering
+ the service is new hardware brought in to replace some old equipment.
+
+ There are certainly arguments on both sides of this debate.
+ Nonetheless, the designers of any service discovery protocol have
+ to make a choice between between having the primary identifiers be
+ hidden, or having them be visible, and these are the reasons that we
+ chose to make them visible. We're not claiming that there are no
+ disadvantages of having primary identifiers be visible. We considered
+ both alternatives, and we believe that the few disadvantages
+ of visible identifiers are far outweighed by the many problems
+ caused by use of hidden identifiers.
+
+
+4.5 Ordering of Service Instance Name Components
+
+ There have been questions about why services are named using DNS
+ Service Instance Names of the form:
+
+ Service Instance Name = <Instance> . <Service> . <Domain>
+
+ instead of:
+
+ Service Instance Name = <Service> . <Instance> . <Domain>
+
+ There are three reasons why it is beneficial to name service
+ instances with the parent domain as the most-significant (rightmost)
+ part of the name, then the abstract service type as the next-most
+ significant, and then the specific instance name as the
+ least-significant (leftmost) part of the name:
+
+
+4.5.1. Semantic Structure
+
+ The facility being provided by browsing ("Service Instance
+ Enumeration") is effectively enumerating the leaves of a tree
+ structure. A given domain offers zero or more services. For each of
+ those service types, there may be zero or more instances of that
+ service.
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 9]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ The user knows what type of service they are seeking. (If they are
+ running an FTP client, they are looking for FTP servers. If they have
+ a document to print, they are looking for entities that speak some
+ known printing protocol.) The user knows in which organizational or
+ geographical domain they wish to search. (The user does not want a
+ single flat list of every single printer on the planet, even if such
+ a thing were possible.) What the user does not know in advance is
+ whether the service they seek is offered in the given domain, or if
+ so, how many instances are offered, and the names of those instances.
+ Hence having the instance names be the leaves of the tree is
+ consistent with this semantic model.
+
+ Having the service types be the terminal leaves of the tree would
+ imply that the user knows the domain name, and already knows the
+ name of the service instance, but doesn't have any idea what the
+ service does. We would argue that this is a less useful model.
+
+
+4.5.2. Network Efficiency
+
+ When a DNS response contains multiple answers, name compression works
+ more effectively if all the names contain a common suffix. If many
+ answers in the packet have the same <Service> and <Domain>, then each
+ occurrence of a Service Instance Name can be expressed using only the
+ <Instance> part followed by a two-byte compression pointer
+ referencing a previous appearance of "<Service>.<Domain>". This
+ efficiency would not be possible if the <Service> component appeared
+ first in each name.
+
+
+4.5.3. Operational Flexibility
+
+ This name structure allows subdomains to be delegated along logical
+ service boundaries. For example, the network administrator at Example
+ Co. could choose to delegate the "_tcp.example.com." subdomain to a
+ different machine, so that the machine handling service discovery
+ doesn't have to be the same as the machine handling other day-to-day
+ DNS operations. (It *can* be the same machine if the administrator so
+ chooses, but the point is that the administrator is free to make that
+ choice.) Furthermore, if the network administrator wishes to delegate
+ all information related to IPP printers to a machine dedicated to
+ that specific task, this is easily done by delegating the
+ "_ipp._tcp.example.com." subdomain to the desired machine. It is also
+ convenient to set security policies on a per-zone/per-subdomain
+ basis. For example, the administrator may choose to enable DNS
+ Dynamic Update [RFC 2136] [RFC 3007] for printers registering in the
+ "_ipp._tcp.example.com." subdomain, but not for other
+ zones/subdomains. This easy flexibility would not exist if the
+ <Service> component appeared first in each name.
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 10]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+5. Service Name Resolution
+
+ Given a particular Service Instance Name, when a client needs to
+ contact that service, it sends a DNS query for the SRV record of
+ that name.
+
+ The result of the DNS query is a SRV record giving the port number
+ and target host where the service may be found.
+
+ The use of SRV records is very important. There are only 65535 TCP
+ port numbers available. These port numbers are being allocated
+ one-per-application-protocol at an alarming rate. Some protocols like
+ the X Window System have a block of 64 TCP ports allocated
+ (6000-6063). If we start allocating blocks of 64 TCP ports at a time,
+ we will run out even faster. Using a different TCP port for each
+ different instance of a given service on a given machine is entirely
+ sensible, but allocating large static ranges, as was done for X, is a
+ very inefficient way to manage a limited resource. On any given host,
+ most TCP ports are reserved for services that will never run on that
+ particular host. This is very poor utilization of the limited port
+ space. Using SRV records allows each host to allocate its available
+ port numbers dynamically to those services running on that host that
+ need them, and then advertise the allocated port numbers via SRV
+ records. Allocating the available listening port numbers locally
+ on a per-host basis as needed allows much better utilization of the
+ available port space than today's centralized global allocation.
+
+ In some environments there may be no compelling reason to assign
+ managed names to every host, since every available service is
+ accessible by name anyway, as a first-class entity in its own right.
+ However, the DNS packet format and record format still require a host
+ name to link the target host referenced in the SRV record to the
+ address records giving the IPv4 and/or IPv6 addresses for that
+ hardware. In the case where no natural host name is available, the
+ SRV record may give its own name as the name of the target host, and
+ then the requisite address records may be attached to that same name.
+ It is perfectly permissible for a single name in the DNS hierarchy to
+ have multiple records of different type attached. (The only
+ restriction being that a given name may not have both a CNAME record
+ and other records at the same time.)
+
+ In the event that more than one SRV is returned, clients MUST
+ correctly interpret the priority and weight fields -- i.e. Lower
+ numbered priority servers should be used in preference to higher
+ numbered priority servers, and servers with equal priority should be
+ selected randomly in proportion to their relative weights. However,
+ in the overwhelmingly common case, a single advertised DNS-SD service
+ instance is described by exactly one SRV record, and in this common
+ case the priority and weight fields of the SRV record SHOULD both be
+ set to zero.
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 11]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+6. Data Syntax for DNS-SD TXT Records
+
+ Some services discovered via Service Instance Enumeration may need
+ more than just an IP address and port number to properly identify the
+ service. For example, printing via the LPR protocol often specifies a
+ queue name. This queue name is typically short and cryptic, and need
+ not be shown to the user. It should be regarded the same way as the
+ IP address and port number -- it is one component of the addressing
+ information required to identify a specific instance of a service
+ being offered by some piece of hardware. Similarly, a file server may
+ have multiple volumes, each identified by its own volume name. A Web
+ server typically has multiple pages, each identified by its own URL.
+ In these cases, the necessary additional data is stored in a TXT
+ record with the same name as the SRV record. The specific nature of
+ that additional data, and how it is to be used, is service-dependent,
+ but the overall syntax of the data in the TXT record is standardized,
+ as described below. Every DNS-SD service MUST have a TXT record in
+ addition to its SRV record, with same name, even if the service has
+ no additional data to store and the TXT record contains no more than
+ a single zero byte.
+
+
+6.1 General Format Rules for DNS TXT Records
+
+ A DNS TXT record can be up to 65535 (0xFFFF) bytes long. The total
+ length is indicated by the length given in the resource record header
+ in the DNS message. There is no way to tell directly from the data
+ alone how long it is (e.g. there is no length count at the start, or
+ terminating NULL byte at the end). (Note that when using Multicast
+ DNS [mDNS] the maximum packet size is 9000 bytes, which imposes an
+ upper limit on the size of TXT records of about 8800 bytes.)
+
+ The format of the data within a DNS TXT record is one or more
+ strings, packed together in memory without any intervening gaps or
+ padding bytes for word alignment.
+
+ The format of each constituent string within the DNS TXT record is a
+ single length byte, followed by 0-255 bytes of text data.
+
+ These format rules are defined in Section 3.3.14 of RFC 1035, and are
+ not specific to DNS-SD. DNS-SD simply specifies a usage convention
+ for what data should be stored in those constituent strings.
+
+ An empty TXT record containing zero strings is disallowed by RFC
+ 1035. DNS-SD implementations MUST NOT emit empty TXT records. DNS-SD
+ implementations receiving empty TXT records MUST treat them as
+ equivalent to a one-byte TXT record containing a single zero byte
+ (i.e. a single empty string).
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 12]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+6.2 DNS TXT Record Format Rules for use in DNS-SD
+
+ DNS-SD uses DNS TXT records to store arbitrary name/value pairs
+ conveying additional information about the named service. Each
+ name/value pair is encoded as its own constituent string within the
+ DNS TXT record, in the form "name=value". Everything up to the first
+ '=' character is the name. Everything after the first '=' character
+ to the end of the string (including subsequent '=' characters, if
+ any) is the value. Specific rules governing names and values are
+ given below. Each author defining a DNS-SD profile for discovering
+ instances of a particular type of service should define the base set
+ of name/value attributes that are valid for that type of service.
+
+ Using this standardized name/value syntax within the TXT record makes
+ it easier for these base definitions to be expanded later by defining
+ additional named attributes. If an implementation sees unknown
+ attribute names in a service TXT record, it MUST silently ignore
+ them.
+
+ The TCP (or UDP) port number of the service, and target host name,
+ are given in the SRV record. This information -- target host name and
+ port number -- MUST NOT be duplicated using name/value attributes in
+ the TXT record.
+
+ The intention of DNS-SD TXT records is to convey a small amount of
+ useful additional information about a service. Ideally it SHOULD NOT
+ be necessary for a client to retrieve this additional information
+ before it can usefully establish a connection to the service. For a
+ well-designed TCP-based application protocol, it should be possible,
+ knowing only the host name and port number, to open a connection to
+ that listening process, and then perform version- or feature-
+ negotiation to determine the capabilities of the service instance.
+ For example, when connecting to an AppleShare server over TCP, the
+ client enters into a protocol exchange with the server to determine
+ which version of the AppleShare protocol the server implements, and
+ which optional features or capabilities (if any) are available. For a
+ well-designed application protocol, clients should be able to connect
+ and use the service even if there is no information at all in the TXT
+ record. In this case, the information in the TXT record should be
+ viewed as a performance optimization -- when a client discovers many
+ instances of a service, the TXT record allows the client to know some
+ rudimentary information about each instance without having to open a
+ TCP connection to each one and interrogate every service instance
+ separately. Extreme care should be taken when doing this to ensure
+ that the information in the TXT record is in agreement with the
+ information retrieved by a client connecting over TCP.
+
+ There are legacy protocols which provide no feature negotiation
+ capability, and in these cases it may be useful to convey necessary
+ information in the TXT record. For example, when printing using the
+ old Unix LPR (port 515) protocol, the LPR service provides no way for
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 13]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ the client to determine whether a particular printer accepts
+ PostScript, or what version of PostScript, etc. In this case it is
+ appropriate to embed this information in the TXT record, because the
+ alternative is worse -- passing around written instructions to the
+ users, arcane manual configuration of "/etc/printcap" files, etc.
+
+
+6.3 DNS-SD TXT Record Size
+
+ The total size of a typical DNS-SD TXT record is intended to be small
+ -- 200 bytes or less.
+
+ In cases where more data is justified (e.g. LPR printing), keeping
+ the total size under 400 bytes should allow it to fit in a single
+ standard 512-byte DNS message. (This standard DNS message size is
+ defined in RFC 1035.)
+
+ In extreme cases where even this is not enough, keeping the size of
+ the TXT record under 1300 bytes should allow it to fit in a single
+ 1500-byte Ethernet packet.
+
+ Using TXT records larger than 1300 bytes is NOT RECOMMENDED at this
+ time.
+
+
+6.4 Rules for Names in DNS-SD Name/Value Pairs
+
+ The "Name" MUST be at least one character. Strings beginning with an
+ '=' character (i.e. the name is missing) SHOULD be silently ignored.
+
+ The characters of "Name" MUST be printable US-ASCII values
+ (0x20-0x7E), excluding '=' (0x3D).
+
+ Spaces in the name are significant, whether leading, trailing, or in
+ the middle -- so don't include any spaces unless you really intend
+ that!
+
+ Case is ignored when interpreting a name, so "papersize=A4",
+ "PAPERSIZE=A4" and "Papersize=A4" are all identical.
+
+ If there is no '=', then it is a boolean attribute, and is simply
+ identified as being present, with no value.
+
+ A given attribute name may appear at most once in a TXT record. If a
+ client receives a TXT record containing the same attribute name more
+ than once, then the client MUST silently ignore all but the first
+ occurrence of that attribute. For client implementations that process
+ a DNS-SD TXT record from start to end, placing name/value pairs into
+ a hash table, using the name as the hash table key, this means that
+ if the implementation attempts to add a new name/value pair into the
+ table and finds an entry with the same name already present, then the
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 14]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ new entry being added should be silently discarded instead. For
+ client implementations that retrieve name/value pairs by searching
+ the TXT record for the requested name, they should search the TXT
+ record from the start, and simply return the first matching name they
+ find. The reason for this simplifying rule is to facilitate the
+ creation of client libraries that parse the TXT record into an
+ internal data structure, such as a hash table or dictionary object
+ that maps from names to values, and then make that abstraction
+ available to client code.
+
+ When examining a TXT record for a given named attribute, there are
+ therefore four broad categories of results which may be returned:
+
+ * Attribute not present (Absent)
+
+ * Attribute present, with no value
+ (e.g. "Anon Allowed" -- server allows anonymous connections)
+
+ * Attribute present, with empty value (e.g. "Installed PlugIns=" --
+ server supports plugins, but none are presently installed)
+
+ * Attribute present, with non-empty value
+ (e.g. "Installed PlugIns=JPEG,MPEG2,MPEG4")
+
+ Each author defining a DNS-SD profile for discovering instances of a
+ particular type of service should define the interpretation of these
+ different kinds of result. For example, for some keys, there may be
+ a natural true/false boolean interpretation:
+
+ * Present implies 'true'
+ * Absent implies 'false'
+
+ For other keys it may be sensible to define other semantics, such as
+ value/no-value/unknown:
+
+ * Present with value implies that value.
+ E.g. "Color=4" for a four-color ink-jet printer,
+ or "Color=6" for a six-color ink-jet printer.
+
+ * Present with empty value implies 'false'. E.g. Not a color printer.
+
+ * Absent implies 'Unknown'. E.g. A print server connected to some
+ unknown printer where the print server doesn't actually know if the
+ printer does color or not -- which gives a very bad user experience
+ and should be avoided wherever possible.
+
+ (Note that this is a hypothetical example, not an example of actual
+ name/value keys used by DNS-SD network printers.)
+
+ As a general rule, attribute names that contain no dots are defined
+ as part of the open-standard definition written by the person or
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 15]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ group defining the DNS-SD profile for discovering that particular
+ service type. Vendor-specific extensions should be given names of the
+ form "keyname.company.com=value", using a domain name legitimately
+ registered to the person or organization creating the vendor-specific
+ key. This reduces the risk of accidental conflict if different
+ organizations each define their own vendor-specific keys.
+
+
+6.5 Rules for Values in DNS-SD Name/Value Pairs
+
+ If there is an '=', then everything after the first '=' to the end of
+ the string is the value. The value can contain any eight-bit values
+ including '='. Leading or trailing spaces are part of the value, so
+ don't put them there unless you intend them to be there. Any
+ quotation marks around the value are part of the value, so don't put
+ them there unless you intend them to be part of the value.
+
+ The value is opaque binary data. Often the value for a particular
+ attribute will be US-ASCII (or UTF-8) text, but it is legal for a
+ value to be any binary data. For example, if the value of a key is an
+ IPv4 address, that address should simply be stored as four bytes of
+ binary data, not as a variable-length 7-15 byte ASCII string giving
+ the address represented in textual dotted decimal notation.
+
+ Generic debugging tools should generally display all attribute values
+ as a hex dump, with accompanying text alongside displaying the UTF-8
+ interpretation of those bytes, except for attributes where the
+ debugging tool has embedded knowledge that the value is some other
+ kind of data.
+
+ Authors defining DNS-SD profiles SHOULD NOT convert binary attribute
+ data types into printable text (e.g. using hexadecimal, Base-64 or UU
+ encoding) merely for the sake of making the data be printable text
+ when seen in a generic debugging tool. Doing this simply bloats the
+ size of the TXT record, without actually making the data any more
+ understandable to someone looking at it in a generic debugging tool.
+
+
+6.6 Example TXT Record
+
+ The TXT record below contains three syntactically valid name/value
+ pairs. (The meaning of these name/value pairs, if any, would depend
+ on the definitions pertaining to the service in question that is
+ using them.)
+
+ ---------------------------------------------------------------
+ | 0x0A | name=value | 0x08 | paper=A4 | 0x0E | DNS-SD Is Cool |
+ ---------------------------------------------------------------
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 16]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+6.7 Version Tag
+
+ It is recommended that authors defining DNS-SD profiles include an
+ attribute of the form "txtvers=xxx" in their definition, and require
+ it to be the first name/value pair in the TXT record. This
+ information in the TXT record can be useful to help clients maintain
+ backwards compatibility with older implementations if it becomes
+ necessary to change or update the specification over time. Even if
+ the profile author doesn't anticipate the need for any future
+ incompatible changes, having a version number in the specification
+ provides useful insurance should incompatible changes become
+ unavoidable. Clients SHOULD ignore TXT records with a txtvers number
+ higher (or lower) than the version(s) they know how to interpret.
+
+ Note that the version number in the txtvers tag describes the version
+ of the TXT record specification being used to create this TXT record,
+ not the version of the application protocol that will be used if the
+ client subsequently decides to contact that service. Ideally, every
+ DNS-SD TXT record specification starts at txtvers=1 and stays that
+ way forever. Improvements can be made by defining new keys that older
+ clients silently ignore. The only reason to increment the version
+ number is if the old specification is subsequently found to be so
+ horribly broken that there's no way to do a compatible forward
+ revision, so the txtvers number has to be incremented to tell all the
+ old clients they should just not even try to understand this new TXT
+ record.
+
+ If there is a need to indicate which version number(s) of the
+ application protocol the service implements, the recommended key
+ name for this is "protovers".
+
+
+7. Application Protocol Names
+
+ The <Service> portion of a Service Instance Name consists of a pair
+ of DNS labels, following the established convention for SRV records
+ [RFC 2782], namely: the first label of the pair is the Application
+ Protocol Name, and the second label is either "_tcp" or "_udp".
+
+ Wise selection of the Application Protocol Name is very important,
+ and the choice is not always as obvious as it may appear.
+
+ Application Protocol Names may be no more than fourteen characters,
+ conforming to normal DNS host name rules: Only lower-case letters,
+ digits, and hyphens; must begin and end with lower-case letter or
+ digit.
+
+ In some cases, the Application Protocol Name merely names and refers
+ to the on-the-wire message format and semantics being used. FTP is
+ "ftp", IPP printing is "ipp", and so on.
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 17]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ However, it is common to "borrow" an existing protocol and repurpose
+ it for a new task. This is entirely sensible and sound engineering
+ practice, but that doesn't mean that the new protocol is providing
+ the same semantic service as the old one, even if it borrows the same
+ message formats. For example, the local network music playing
+ protocol implemented by iTunes on Macintosh and Windows is little
+ more than "HTTP GET" commands. However, that does *not* mean that it
+ is sensible or useful to try to access one of these music servers by
+ connecting to it with a standard web browser. Consequently, the
+ DNS-SD service advertised (and browsed for) by iTunes is "_daap._tcp"
+ (Digital Audio Access Protocol), not "_http._tcp". Advertising
+ "_http._tcp" service would cause iTunes servers to show up in
+ conventional Web browsers (Safari, Camino, OmniWeb, Opera, Netscape,
+ Internet Explorer, etc.) which is little use since it offers no pages
+ containing human-readable content. Similarly, browsing for
+ "_http._tcp" service would cause iTunes to find generic web servers,
+ such as the embedded web servers in devices like printers, which is
+ little use since printers generally don't have much music to offer.
+
+ Similarly, NFS is built on top of SUN RPC, but that doesn't mean it
+ makes sense for an NFS server to advertise that it provides "SUN RPC"
+ service. Likewise, Microsoft SMB file service is built on top of
+ Netbios running over IP, but that doesn't mean it makes sense for an
+ SMB file server to advertise that it provides "Netbios-over-IP"
+ service. The DNS-SD name of a service needs to encapsulate both the
+ "what" (semantics) and the "how" (protocol implementation) of the
+ service, since knowledge of both is necessary for a client to
+ usefully use the service. Merely advertising that a service was built
+ on top of SUN RPC is no use if the client has no idea what the
+ service actually does.
+
+ Another common mistake is to assume that the service type advertised
+ by iTunes should be "_daap._http._tcp." This is also incorrect. Part
+ of the confusion here is that the presence of "_tcp" or "_udp" in the
+ <Service> portion of a Service Instance Name has led people to assume
+ that the structure of a service name has to reflect the internal
+ structure of how the protocol was implemented. This is not correct.
+
+ The "_tcp" or "_udp" should be regarded as little more than
+ boilerplate text, and care should be taken not to attach too much
+ importance to it. Some might argue that the "_tcp" or "_udp" should
+ not be there at all, but this format is defined by RFC 2782, and
+ that's not going to change. In addition, the presence of "_tcp" has
+ the useful side-effect that it provides a convenient delegation point
+ to hand off control to a different DNS server, if so desired.
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 18]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+7.1 Service Name Length Limits
+
+ As described above, application protocol names are allowed to be up
+ to fourteen characters long. The reason for this limit is to leave
+ as many bytes of the domain name as possible available for use
+ by both the network administrator (choosing service domain names)
+ and the end user (choosing instance names).
+
+ A domain name may be up to 255 bytes long, including the final
+ terminating root label at the end. Domain names used by DNS-SD
+ take the following forms:
+
+ <Instance>.<app>._tcp.<servicedomain>.<parentdomain>.
+ <sub>._sub.<app>._tcp.<servicedomain>.<parentdomain>.
+
+ The first example shows a service instance name, i.e. the name of the
+ service's SRV and TXT records. The second shows a subtype browsing
+ name, i.e. the name of a PTR record pointing to service instance
+ names.
+
+ The instance name <Instance> may be up to 63 bytes. Including the
+ length byte used by the DNS format when the name is stored in a
+ packet, that makes 64 bytes.
+
+ When using subtypes, the subtype identifier is allowed to be up to
+ 63 bytes, plus the length byte, making 64. Including the "_sub"
+ and its length byte, this makes 69 bytes.
+
+ The application protocol name <app> may be up to 14 bytes, plus the
+ underscore and length byte, making 16. Including the "_udp" or "_tcp"
+ and its length byte, this makes 21 bytes.
+
+ Typically, DNS-SD service records are placed into subdomains of their
+ own beneath a company's existing domain name. Since these subdomains
+ are intended to be accessed through graphical user interfaces, not
+ typed on a command-line they are frequently long and descriptive.
+ Including the length byte, the user-visible service domain may be up
+ to 64 bytes.
+
+ The terminating root label at the end counts as one byte.
+
+ Of our available 255 bytes, we have now accounted for 69+21+64+1 =
+ 155 bytes. This leaves 100 bytes to accommodate the organization's
+ existing domain name <parentdomain>. When used with Multicast DNS,
+ <parentdomain> is "local", which easily fits. When used with parent
+ domains of 100 bytes or less, the full functionality of DNS-SD is
+ available without restriction. When used with parent domains longer
+ than 100 bytes, the protocol risks exceeding the maximum possible
+ length of domain names, causing failures. In this case, careful
+ choice of short <servicedomain> names can help avoid overflows. If
+ the <servicedomain> and <parentdomain> are too long, then service
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 19]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ instances with long instance names will not be discoverable or
+ resolvable, and applications making use of long subtype names may
+ fail.
+
+ Because of this constraint, we choose to limit Application Protocol
+ Names to 14 characters or less. Allowing more characters would not
+ add to the expressive power of the protocol, and would needlessly
+ lower the limit on the maximum <parentdomain> length that may be
+ safely used.
+
+
+8. Selective Instance Enumeration
+
+ This document does not attempt to define an arbitrary query language
+ for service discovery, nor do we believe one is necessary.
+
+ However, there are some circumstances where narrowing the list of
+ results may be useful. A Web browser client that is able to retrieve
+ HTML documents via HTTP and display them may also be able to retrieve
+ HTML documents via FTP and display them, but only in the case of FTP
+ servers that allow anonymous login. For that Web browser, discovering
+ all FTP servers on the network is not useful. The Web browser only
+ wants to discover FTP servers that it is able to talk to. In this
+ case, a subtype of "_ftp._tcp" could be defined. Instead of issuing a
+ query for "_ftp._tcp.<Domain>", the Web browser issues a query for
+ "_anon._sub._ftp._tcp.<Domain>", where "_anon" is a defined subtype
+ of "_ftp._tcp". The response to this query only includes the names of
+ SRV records for FTP servers that are willing to allow anonymous
+ login.
+
+ Note that the FTP server's Service Instance Name is unchanged -- it
+ is still something of the form "The Server._ftp._tcp.example.com."
+ The subdomain in which FTP server SRV records are registered defines
+ the namespace within which FTP server names are unique. Additional
+ subtypes (e.g. "_anon") of the basic service type (e.g. "_ftp._tcp")
+ serve to narrow the list of results, not to create more namespace.
+
+ As with the TXT record name/value pairs, the list of possible
+ subtypes, if any, are defined and specified separately for each basic
+ service type.
+
+
+9. Flagship Naming
+
+ In some cases, there may be several network protocols available which
+ all perform roughly the same logical function. For example, the
+ printing world has the LPR protocol, and the Internet Printing
+ Protocol (IPP), both of which cause printed sheets to be emitted from
+ printers in much the same way. In addition, many printer vendors send
+ their own proprietary page description language (PDL) data over a TCP
+ connection to TCP port 9100, herein referred to as the
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 20]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ "pdl-datastream" protocol. In an ideal world we would have only one
+ network printing protocol, and it would be sufficiently good that no
+ one felt a compelling need to invent a different one. However, in
+ practice, multiple legacy protocols do exist, and a service discovery
+ protocol has to accommodate that.
+
+ Many printers implement all three printing protocols: LPR, IPP, and
+ pdl-datastream. For the benefit of clients that may speak only one of
+ those protocols, all three are advertised.
+
+ However, some clients may implement two, or all three of those
+ printing protocols. When a client looks for all three service types
+ on the network, it will find three distinct services -- an LPR
+ service, an IPP service, and a pdl-datastream service -- all of which
+ cause printed sheets to be emitted from the same physical printer.
+
+ In the case of multiple protocols like this that all perform
+ effectively the same function, the client should suppress duplicate
+ names and display each name only once. When the user prints to a
+ given named printer, the printing client is responsible for choosing
+ the protocol which will best achieve the desired effect, without, for
+ example, requiring the user to make a manual choice between LPR and
+ IPP.
+
+ As described so far, this all works very well. However, consider some
+ future printer that only supports IPP printing, and some other future
+ printer that only supports pdl-datastream printing. The name spaces
+ for different service types are intentionally disjoint -- it is
+ acceptable and desirable to be able to have both a file server called
+ "Sales Department" and a printer called "Sales Department". However,
+ it is not desirable, in the common case, to have two different
+ printers both called "Sales Department", just because those printers
+ are implementing different protocols.
+
+ To help guard against this, when there are two or more network
+ protocols which perform roughly the same logical function, one of the
+ protocols is declared the "flagship" of the fleet of related
+ protocols. Typically the flagship protocol is the oldest and/or
+ best-known protocol of the set.
+
+ If a device does not implement the flagship protocol, then it instead
+ creates a placeholder SRV record (priority=0, weight=0, port=0,
+ target host = hostname of device) with that name. If, when it
+ attempts to create this SRV record, it finds that a record with the
+ same name already exists, then it knows that this name is already
+ taken by some entity implementing at least one of the protocols from
+ the class, and it must choose another. If no SRV record already
+ exists, then the act of creating it stakes a claim to that name so
+ that future devices in the same class will detect a conflict when
+ they try to use it. The SRV record needs to contain the target host
+ name in order for the conflict detection rules to operate. If two
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 21]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ different devices were to create placeholder SRV records both using a
+ null target host name (just the root label), then the two SRV records
+ would be seen to be in agreement so no conflict would be registered.
+
+ By defining a common well-known flagship protocol for the class,
+ future devices that may not even know about each other's protocols
+ establish a common ground where they can coordinate to verify
+ uniqueness of names.
+
+ No PTR record is created advertising the presence of empty flagship
+ SRV records, since they do not represent a real service being
+ advertised.
+
+
+10. Service Type Enumeration
+
+ In general, clients are not interested in finding *every* service on
+ the network, just the services that the client knows how to talk to.
+ (Software designers may *think* there's some value to finding *every*
+ service on the network, but that's just wooly thinking.)
+
+ 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 reason, a special meta-query is defined. A DNS query for
+ PTR records with the name "_services._dns-sd._udp.<Domain>" yields
+ a list of PTR records, where the rdata of each PTR record is the
+ name of a service type. A subsequent query for PTR records with
+ one of those names yields a list of instances of that service type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 22]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+11. Populating the DNS with Information
+
+ How the SRV and PTR records that describe services and allow them to
+ be enumerated make their way into the DNS is outside the scope of
+ this document. However, it can happen easily in any of a number of
+ ways, for example:
+
+ On some networks, the administrator might manually enter the records
+ into the name server's configuration file.
+
+ A network monitoring tool could output a standard zone file to be
+ read into a conventional DNS server. For example, a tool that can
+ find Apple LaserWriters using AppleTalk NBP could find the list of
+ printers, communicate with each one to find its IP address,
+ PostScript version, installed options, etc., and then write out a DNS
+ zone file describing those printers and their capabilities using DNS
+ resource records. That information would then be available to DNS-SD
+ clients that don't implement AppleTalk NBP, and don't want to.
+
+ Future IP printers could use Dynamic DNS Update [RFC 2136] to
+ automatically register their own SRV and PTR records with the DNS
+ server.
+
+ A printer manager device which has knowledge of printers on the
+ network through some other management protocol could also use Dynamic
+ DNS Update [RFC 2136].
+
+ Alternatively, a printer manager device could implement enough of the
+ DNS protocol that it is able to answer DNS queries directly, and
+ Example Co.'s main DNS server could delegate the
+ _ipp._tcp.example.com subdomain to the printer manager device.
+
+ Zeroconf printers answer Multicast DNS queries on the local link
+ for appropriate PTR and SRV names ending with ".local." [mDNS]
+
+
+12. Relationship to Multicast DNS
+
+ DNS-Based Service Discovery is only peripherally related to Multicast
+ DNS, in that the standard unicast DNS queries used by DNS-SD may also
+ be performed using multicast when appropriate, which is particularly
+ beneficial in Zeroconf environments [ZC].
+
+
+
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 23]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+13. Discovery of Browsing and Registration Domains (Domain Enumeration)
+
+ One of the main reasons for DNS-Based Service Discovery is so that
+ when a visiting client (e.g. a laptop computer) arrives at a new
+ network, it can discover what services are available on that network
+ without manual configuration. This logic that applies to discovering
+ services without manual configuration also applies to discovering the
+ domains in which services are registered without requiring manual
+ configuration.
+
+ This discovery is performed recursively, 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 final query shown yields the "legacy browsing" domain.
+ Sophisticated client applications that care to present choices of
+ domain to the user, use the answers learned from the previous four
+ queries to discover those 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 "legacy browsing" query is provided, to allow
+ the network administrator to communicate to the client operating
+ systems which domain should be used for these applications.
+
+ These domains are purely advisory. The client or user is free to
+ browse and/or register services in any domains. The purpose of these
+ special queries is to allow software to create a user-interface that
+ displays a useful list of suggested choices to the user, from which
+ they may make a suitable selection, or ignore the offered suggestions
+ and manually enter their own choice.
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 24]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ The <domain> part of the name may be "local" (meaning "perform the
+ query using link-local multicast) or it may be learned through some
+ other mechanism, such as the DHCP "Domain" option (option code 15)
+ [RFC 2132] or the DHCP "Domain Search" option (option code 119)
+ [RFC 3397].
+
+ The <domain> part of the name may also be derived from the host's IP
+ address. The host takes its IP address, and calculates the logical
+ AND of that address and its subnet mask, to derive the 'base' address
+ of the subnet. It then constructs the conventional DNS "reverse
+ mapping" name corresponding to that base address, and uses that as
+ the <domain> part of the name for the queries described above.
+ For example, if a host has address 192.168.12.34, with subnet mask
+ 255.255.0.0, then the 'base' address of the subnet is 192.168.0.0,
+ and to discover the recommended legacy browsing domain for devices
+ on this subnet, the host issues a DNS PTR query for the name
+ "lb._dns-sd._udp.0.0.168.192.in-addr.arpa."
+
+ Sophisticated clients may perform domain enumeration queries both in
+ "local" and in one or more unicast domains, and then present the user
+ with an aggregate result, combining the information received from all
+ sources.
+
+
+14. DNS Additional Record Generation
+
+ DNS has an efficiency feature whereby a DNS server may place
+ additional records in the Additional Section of the DNS Message.
+ These additional records are typically records that the client did
+ not explicitly request, but the server has reasonable grounds to
+ expect that the client might request them shortly.
+
+ This section recommends which additional records should be generated
+ to improve network efficiency for both unicast and multicast DNS-SD
+ responses.
+
+
+14.1 PTR Records
+
+ When including a PTR record in a response packet, the
+ server/responder SHOULD include the following additional records:
+
+ o The SRV record(s) named in the PTR rdata.
+ o The TXT record(s) named in the PTR rdata.
+ o All address records (type "A" and "AAAA") named in the SRV rdata.
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 25]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+14.2 SRV Records
+
+ When including an SVR record in a response packet, the
+ server/responder SHOULD include the following additional records:
+
+ o All address records (type "A" and "AAAA") named in the SRV rdata.
+
+
+14.3 TXT Records
+
+ When including a TXT record in a response packet, no additional
+ records are required.
+
+
+14.4 Other Record Types
+
+ In response to address queries, or other record types, no additional
+ records are required by this document.
+
+
+15. Comparison with Alternative Service Discovery Protocols
+
+ Over the years there have been many proposed ways to do network
+ service discovery with IP, but none achieved ubiquity in the
+ marketplace. Certainly none has achieved anything close to the
+ ubiquity of today's deployment of DNS servers, clients, and other
+ infrastructure.
+
+ The advantage of using DNS as the basis for service discovery is that
+ it makes use of those existing servers, clients, protocols,
+ infrastructure, and expertise. Existing network analyzer tools
+ already know how to decode and display DNS packets for network
+ debugging.
+
+ For ad-hoc networks such as Zeroconf environments, peer-to-peer
+ multicast protocols are appropriate. The Zeroconf host profile [ZCHP]
+ requires the use of a DNS-like protocol over IP Multicast for host
+ name resolution in the absence of DNS servers. Given that Zeroconf
+ hosts will have to implement this Multicast-based DNS-like protocol
+ anyway, it makes sense for them to also perform service discovery
+ using that same Multicast-based DNS-like software, instead of also
+ having to implement an entirely different service discovery protocol.
+
+ In larger networks, a high volume of enterprise-wide IP multicast
+ traffic may not be desirable, so any credible service discovery
+ protocol intended for larger networks has to provide some facility to
+ aggregate registrations and lookups at a central server (or servers)
+ instead of working exclusively using multicast. This requires some
+ service discovery aggregation server software to be written,
+ debugged, deployed, and maintained. This also requires some service
+ discovery registration protocol to be implemented and deployed for
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 26]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ clients to register with the central aggregation server. Virtually
+ every company with an IP network already runs a DNS server, and DNS
+ already has a dynamic registration protocol [RFC 2136]. Given that
+ virtually every company already has to operate and maintain a DNS
+ server anyway, it makes sense to take advantage of this instead of
+ also having to learn, operate and maintain a different service
+ registration server. It should be stressed again that using the same
+ software and protocols doesn't necessarily mean using the same
+ physical piece of hardware. The DNS-SD service discovery functions
+ do not have to be provided by the same piece of hardware that
+ is currently providing the company's DNS name service. The
+ "_tcp.<Domain>" subdomain may be delegated to a different piece of
+ hardware. However, even when the DNS-SD service is being provided by
+ a different piece of hardware, it is still the same familiar DNS
+ server software that is running, with the same configuration file
+ syntax, the same log file format, and so forth.
+
+ Service discovery needs to be able to provide appropriate security.
+ DNS already has existing mechanisms for security [RFC 2535].
+
+ In summary:
+
+ Service discovery requires a central aggregation server.
+ DNS already has one: It's called a DNS server.
+
+ Service discovery requires a service registration protocol.
+ DNS already has one: It's called DNS Dynamic Update.
+
+ Service discovery requires a query protocol
+ DNS already has one: It's called DNS.
+
+ Service discovery requires security mechanisms.
+ DNS already has security mechanisms: DNSSEC.
+
+ Service discovery requires a multicast mode for ad-hoc networks.
+ Zeroconf environments already require a multicast-based DNS-like
+ name lookup protocol for mapping host names to addresses, so it
+ makes sense to let one multicast-based protocol do both jobs.
+
+ It makes more sense to use the existing software that every network
+ needs already, instead of deploying an entire parallel system just
+ for service discovery.
+
+
+
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 27]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+16. Real Example
+
+ The following examples were prepared using standard unmodified
+ nslookup and standard unmodified BIND running on GNU/Linux.
+
+ Note: In real products, this information is obtained and presented to
+ the user using graphical network browser software, not command-line
+ tools, but if you wish you can try these examples for yourself as you
+ read along, using the command-line tools already available on your
+ own Unix machine.
+
+16.1 Question: What FTP servers are being advertised from dns-sd.org?
+
+ nslookup -q=ptr _ftp._tcp.dns-sd.org.
+ _ftp._tcp.dns-sd.org
+ name = Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org
+ _ftp._tcp.dns-sd.org
+ name = Microsoft\032Developer\032Files._ftp._tcp.dns-sd.org
+ _ftp._tcp.dns-sd.org
+ name = Registered\032Users'\032Only._ftp._tcp.dns-sd.org
+
+ Answer: There are three, called "Apple QuickTime Files",
+ "Microsoft Developer Files" and "Registered Users' Only".
+
+ Note that nslookup escapes spaces as "\032" for display purposes,
+ but a graphical DNS-SD browser does not.
+
+16.2 Question: What FTP servers allow anonymous access?
+
+ nslookup -q=ptr _anon._sub._ftp._tcp.dns-sd.org
+ _anon._sub._ftp._tcp.dns-sd.org
+ name = Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org
+ _anon._sub._ftp._tcp.dns-sd.org
+ name = Microsoft\032Developer\032Files._ftp._tcp.dns-sd.org
+
+ Answer: Only "Apple QuickTime Files" and "Microsoft Developer Files"
+ allow anonymous access.
+
+16.3 Question: How do I access "Apple QuickTime Files"?
+
+ nslookup -q=any "Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org."
+ Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org
+ text = "path=/quicktime"
+ Apple\032QuickTime\032Files._ftp._tcp.dns-sd.org
+ priority = 0, weight = 0, port= 21 host = ftp.apple.com
+ ftp.apple.com internet address = 17.254.0.27
+ ftp.apple.com internet address = 17.254.0.31
+ ftp.apple.com internet address = 17.254.0.26
+
+ Answer: You need to connect to ftp.apple.com, port 21, path
+ "/quicktime". The addresses for ftp.apple.com are also given.
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 28]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+17. IPv6 Considerations
+
+ IPv6 has no significant differences, except that the address of the
+ SRV record's target host is given by the appropriate IPv6 address
+ records instead of the IPv4 "A" record.
+
+
+18. Security Considerations
+
+ DNSSEC [RFC 2535] should be used where the authenticity of
+ information is important. Since DNS-SD is just a naming and usage
+ convention for records in the existing DNS system, it has no specific
+ additional security requirements over and above those that already
+ apply to DNS queries and DNS updates.
+
+
+19. IANA Considerations
+
+ This protocol builds on DNS SRV records [RFC 2782], and similarly
+ requires IANA to assign unique application protocol names.
+ Unfortunately, the "IANA Considerations" section of RFC 2782 says
+ simply, "The IANA has assigned RR type value 33 to the SRV RR.
+ No other IANA services are required by this document."
+ Due to this oversight, IANA is currently prevented from carrying
+ out the necessary function of assigning these unique identifiers.
+
+ This document proposes the following IANA allocation policy for
+ unique application protocol names:
+
+ Allowable names:
+ * Must be no more than fourteen characters long
+ * Must consist only of:
+ - lower-case letters 'a' - 'z'
+ - digits '0' - '9'
+ - the hyphen character '-'
+ * Must begin and end with a lower-case letter or digit.
+ * Must not already be assigned to some other protocol in the
+ existing IANA "list of assigned application protocol names
+ and port numbers" [ports].
+
+ These identifiers are allocated on a First Come First Served basis.
+ In the event of abuse (e.g. automated mass registrations, etc.),
+ the policy may be changed without notice to Expert Review [RFC 2434].
+
+ The textual nature of service/protocol names means that there are
+ almost infinitely many more of them available than the finite set of
+ 65535 possible port numbers. This means that developers can produce
+ experimental implementations using unregistered service names with
+ little chance of accidental collision, providing service names are
+ chosen with appropriate care. However, this document strongly
+ advocates that on or before the date a product ships, developers
+ should properly register their service names.
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 29]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ Some developers have expressed concern that publicly registering
+ their service names (and port numbers today) with IANA before a
+ product ships may give away clues about that product to competitors.
+ For this reason, IANA should consider allowing service name
+ applications to remain secret for some period of time, much as US
+ patent applications remain secret for two years after the date of
+ filing.
+
+ This proposed IANA allocation policy is not in force until this
+ document is published as an RFC. In the meantime, unique application
+ protocol names may be registered according to the instructions at
+ <http://www.dns-sd.org/ServiceTypes.html>. As of January 2004, there
+ are roughly 100 application protocols in currently shipping products
+ that have been so registered as using DNS-SD for service discovery.
+
+
+20. Acknowledgments
+
+ The concepts described in this document have been explored, developed
+ and implemented with help from Richard Brown, Erik Guttman, Paul
+ Vixie, and Bill Woodcock.
+
+ Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher,
+ Roger Pantos and Kiren Sekar for their significant contributions.
+
+
+21. Copyright
+
+ Copyright (C) The Internet Society 2005.
+ All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 30]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+22. Normative References
+
+ [ports] IANA list of assigned application protocol names and port
+ numbers <http://www.iana.org/assignments/port-numbers>
+
+ [RFC 1033] Lottor, M., "Domain Administrators Operations Guide",
+ RFC 1033, November 1987.
+
+ [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
+ Facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+ Specifications", STD 13, RFC 1035, November 1987.
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+ [RFC 2782] Gulbrandsen, A., et al., "A DNS RR for specifying the
+ location of services (DNS SRV)", RFC 2782, February 2000.
+
+
+23. Informative References
+
+ [mDNS] Cheshire, S., and M. Krochmal, "Multicast DNS",
+ Internet-Draft (work in progress),
+ draft-cheshire-dnsext-multicastdns-05.txt, June 2005.
+
+ [NBP] Cheshire, S., and M. Krochmal,
+ "Requirements for a Protocol to Replace AppleTalk NBP",
+ Internet-Draft (work in progress),
+ draft-cheshire-dnsext-nbp-04.txt, June 2005.
+
+ [RFC 2132] Alexander, S., and Droms, R., "DHCP Options and BOOTP
+ Vendor Extensions", RFC 2132, March 1997.
+
+ [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
+ System (DNS UPDATE)", RFC 2136, April 1997.
+
+ [RFC 2434] Narten, T., and H. Alvestrand, "Guidelines for Writing
+ an IANA Considerations Section in RFCs", RFC 2434,
+ October 1998.
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 31]
+\f
+Internet Draft DNS-Based Service Discovery 7th June 2005
+
+
+ [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [RFC 3007] Wellington, B., et al., "Secure Domain Name System (DNS)
+ Dynamic Update", RFC 3007, November 2000.
+
+ [RFC 3397] Aboba, B., and Cheshire, S., "Dynamic Host Configuration
+ Protocol (DHCP) Domain Search Option", RFC 3397, November
+ 2002.
+
+ [ZC] Williams, A., "Requirements for Automatic Configuration
+ of IP Hosts", Internet-Draft (work in progress),
+ draft-ietf-zeroconf-reqts-12.txt, September 2002.
+
+ [ZCHP] Guttman, E., "Zeroconf Host Profile Applicability
+ Statement", Internet-Draft (work in progress),
+ draft-ietf-zeroconf-host-prof-01.txt, July 2001.
+
+
+24. Authors' Addresses
+
+ Stuart Cheshire
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino
+ California 95014
+ USA
+
+ Phone: +1 408 974 3207
+ EMail: rfc@stuartcheshire.org
+
+
+ Marc Krochmal
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino
+ California 95014
+ USA
+
+ Phone: +1 408 974 4368
+ EMail: marc@apple.com
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 32]
--- /dev/null
+Document: draft-cheshire-dnsext-multicastdns-03.txt Stuart Cheshire
+Category: Standards Track Apple Computer, Inc.
+Expires 29th July 2004 Marc Krochmal
+ Apple Computer, Inc.
+ 29th January 2003
+
+ Multicast DNS
+
+ <draft-cheshire-dnsext-multicastdns-03.txt>
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF),
+ its areas, and its working groups. Note that other groups may
+ also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other documents
+ at any time. It is inappropriate to use Internet-Drafts as
+ reference material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ Distribution of this memo is unlimited.
+
+
+Abstract
+
+ As networked devices become smaller, more portable, and more
+ ubiquitous, the ability to operate with less configured
+ infrastructure is increasingly important. In particular, the ability
+ to look up DNS resource record data types (including, but not limited
+ to, host names) in the absence of a conventional managed DNS server,
+ is becoming essential.
+
+ Multicast DNS (mDNS) provides the ability to do DNS-like operations
+ on the local link in the absense of any conventional unicast DNS
+ server. In addition, mDNS designates a portion of the DNS namespace
+ to be free for local use, without the need to pay any annual fee, and
+ without the need to set up delegations or otherwise configure a
+ conventional DNS server to answer for those names.
+
+ The primary benefits of mDNS names are that (i) they require little
+ or no administration or configuration to set them up, (ii) they work
+ when no infrastructure is present, and (iii) they work during
+ infrastructure failures.
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 1]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+Table of Contents
+
+ 1. Introduction...................................................3
+ 2. Conventions and Terminology Used in this Document..............4
+ 3. Multicast DNS Names............................................4
+ 4. IP TTL Checks..................................................8
+ 5. Reverse Address Mapping........................................8
+ 6. Querying.......................................................9
+ 7. Duplicate Suppression.........................................13
+ 8. Responding....................................................15
+ 9. Probing and Announcing on Startup.............................17
+ 10. Conflict Resolution...........................................21
+ 11. Special Characteristics of Multicast DNS Domains..............23
+ 12. Multicast DNS for Service Discovery...........................24
+ 13. Resource Record TTL Values and Cache Coherency................25
+ 14. Enabling and Disabling Multicast DNS..........................30
+ 15. Considerations for Multiple Interfaces........................30
+ 16. Multicast DNS and Power Management............................31
+ 17. Multicast DNS Character Set...................................32
+ 18. Multicast DNS Message Size....................................33
+ 19. Multicast DNS Message Format..................................33
+ 20. Choice of UDP Port Number.....................................36
+ 21. Summary of Differences Between Multicast DNS and Unicast DNS..37
+ 22. Benefits of Multicast Responses...............................38
+ 23. IPv6 Considerations...........................................39
+ 24. Security Considerations.......................................40
+ 25. IANA Considerations...........................................41
+ 26. Acknowledgements..............................................41
+ 27. Copyright.....................................................41
+ 28. Normative References..........................................42
+ 29. Informative References........................................42
+ 30. Author's Addresses............................................43
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 2]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+1. Introduction
+
+ When reading this document, familiarity with the concepts of Zero
+ Configuration Networking [ZC] and automatic link-local addressing
+ [v4LL] [RFC 2462] is helpful.
+
+ This document proposes no change to the structure of DNS messages,
+ and no new operation codes, response codes, or resource record types.
+ This document simply discusses what needs to happen if DNS clients
+ start sending DNS queries to a multicast address, and how a
+ collection of hosts can cooperate to collectively answer those
+ queries in a useful manner.
+
+ There has been discussion of how much burden Multicast DNS might
+ impose on a network. It should be remembered that whenever IPv4 hosts
+ communicate, they broadcast ARP packets on the network on a regular
+ basis, and this is not disastrous. The approximate amount of
+ multicast traffic generated by hosts making conventional use of
+ Multicast DNS is anticipated to be roughly the same order of
+ magnitude as the amount of broadcast ARP traffic those hosts already
+ generate.
+
+ New applications making new use of Multicast DNS capabilities for
+ unconventional purposes may generate more traffic. If some of those
+ new applications are "chatty", then work will be needed to help them
+ become less chatty. When performing any analysis, it is important to
+ make a distinction between the application behavior and the
+ underlying protocol behavior. If a chatty application uses UDP, that
+ doesn't mean that UDP is chatty, or that IP is chatty, or that
+ Ethernet is chatty. What it means is that the application is chatty.
+ The same applies to any future applications that may decide to layer
+ increasing portions of their functionality over Multicast DNS.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 3]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+2. Conventions and Terminology Used in this Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in "Key words for use in
+ RFCs to Indicate Requirement Levels" [RFC 2119].
+
+ This document uses the term "host name" in the strict sense to mean a
+ fully qualified domain name that has an address record. It does not
+ use the term "host name" in the commonly used but incorrect sense to
+ mean just the first DNS label of a host's fully qualified domain
+ name.
+
+ A DNS (or mDNS) packet contains an IP TTL in the IP header, which
+ is effectively a hop-count limit for the packet, to guard against
+ routing loops. Each Resource Record also contains a TTL, which is
+ the number of seconds for which the Resource Record may be cached.
+
+ In any place where there may be potential confusion between these two
+ types of TTL, the term "IP TTL" is used to refer to the IP header TTL
+ (hop limit), and the term "RR TTL" is used to refer to the Resource
+ Record TTL (cache lifetime).
+
+ When this document uses the term "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 packets over IP
+ Multicast to UDP port 5353."
+
+
+3. Multicast DNS Names
+
+ This document proposes that the DNS top-level domain ".local." be
+ designated a special domain with special semantics, namely that any
+ fully-qualified name ending in ".local." is link-local, and names
+ within this domain are meaningful only on the link where they
+ originate. This is analogous to IPv4 addresses in the 169.254/16
+ prefix, which are link-local and meaningful only on the link where
+ they originate.
+
+ Any DNS query for a name ending with ".local." MUST be sent
+ to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent
+ FF02::FB).
+
+ It is unimportant whether a name ending with ".local." occurred
+ because the user explicitly typed in a fully qualified domain name
+ ending in ".local.", or because the user entered an unqualified
+ domain name and the host software appended the suffix ".local."
+ because that suffix appears in the user's search list. The ".local."
+ suffix could appear in the search list because the user manually
+ configured it, or because it was received in a DHCP option, or via
+ any other valid mechanism for configuring the DNS search list. In
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 4]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ this respect the ".local." suffix is treated no differently to any
+ other search domain that might appear in the DNS search list.
+
+ DNS queries for names that do not end with ".local." MAY be sent to
+ the mDNS multicast address, if no other conventional DNS server is
+ available. This can allow hosts on the same link to continue
+ communicating using each other's globally unique DNS names during
+ network outages which disrupt communication with the greater
+ Internet. When resolving global names via local multicast, it is even
+ more important to use DNSSEC or other security mechanisms to ensure
+ that the response is trustworthy. Resolving global names via local
+ multicast is a contentious issue, and this document does not discuss
+ it in detail, instead concentrating on the issue of resolving local
+ names using DNS packets sent to a multicast address.
+
+ A host which belongs to an organization or individual who has control
+ over some portion of the DNS namespace can be assigned a globally
+ unique name within that portion of the DNS namespace, for example,
+ "cheshire.apple.com." For those of us who have this luxury, this
+ works very well. However, the majority of home customers do not have
+ easy access to any portion of the global DNS namespace within which
+ they have the authority to create names as they wish. This leaves the
+ majority of home computers effectively anonymous for practical
+ purposes.
+
+ To remedy this problem, this document allows any computer user to
+ elect to give their computers link-local Multicast DNS host names of
+ the form: "single-dns-label.local." For example, my Titanium
+ PowerBook laptop computer answers to the name "sctibook.local." Any
+ computer user is granted the authority to name their computer this
+ way, providing that the chosen host name is not already in use on
+ that link. Having named their computer this way, the user has the
+ authority to continue using that name until such time as a name
+ conflict occurs on the link which is not resolved in the user's
+ favour. If this happens, the computer (or its human user) SHOULD
+ cease using the name, and may choose to attempt to allocate a new
+ unique name for use on that link. Like law suits over global DNS
+ names, these conflicts are expected to be relatively rare for people
+ who choose reasonably imaginative names, but it is still important
+ to have a mechanism in place to handle them when they happen.
+
+ The point made in the previous paragraph is very important and bears
+ repeating. It is easy for those of us in the IETF community who run
+ our own name servers at home to forget that the majority of computer
+ users do not run their own name server and have no easy way to create
+ their own host names. When these users wish to transfer files between
+ two laptop computers, they are frequently reduced to typing in
+ dotted-decimal IP addresses because they simply have no other way for
+ one host to refer to the other by name. This is a sorry state of
+ affairs. What is worse, most users don't even bother trying to use
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 5]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ dotted-decimal IP addresses. Most users still move data between
+ machines by copying it onto a floppy disk or similar removable media.
+
+ In a world of gigabit Ethernet and ubiquitous wireless networking it
+ is a sad indictment of the networking community that the preferred
+ communication medium for most computer users is still the floppy
+ disk.
+
+ Allowing ad-hoc allocation of single-label names in a single flat
+ ".local." namespace may seem to invite chaos. However, operational
+ experience with AppleTalk NBP names, which on any given link are also
+ effectively single-label names in a flat namespace, shows that in
+ practice name collisions happen extremely rarely and are not a
+ problem. Groups of computer users from disparate organizations bring
+ Macintosh laptop computers to events such as IETF Meetings, the Mac
+ Hack conference, the Apple World Wide Developer Conference, etc., and
+ complaints at these events about users suffering conflicts and being
+ forced to rename their machines have never been an issue.
+
+ Enforcing uniqueness of host names (i.e. the names of DNS address
+ records mapping names to IP addresses) is probably desirable in the
+ common case, but this document does not mandate that. It is
+ permissible for a collection of coordinated hosts to agree to
+ maintain multiple DNS address records with the same name, possibly
+ for load balancing or fault-tolerance reasons. This document does not
+ take a position on whether that is sensible. It is important that
+ both modes of operation are supported. The Multicast DNS protocol
+ allows hosts to verify and maintain unique names for resource records
+ where that behaviour is desired, and it also allows hosts to maintain
+ multiple resource records with a single shared name where that
+ behaviour is desired. This consideration applies to all resource
+ records, not just address records (host names). In summary: It is
+ required that the protocol have the ability to detect and handle name
+ conflicts, but it is not required that this ability be used for every
+ record.
+
+
+3.1 Governing Standards Body
+
+ Note that this use of the ".local." suffix falls under IETF
+ jurisdiction, not ICANN jurisdiction. DNS is an IETF network
+ protocol, governed by protocol rules defined by the IETF. These IETF
+ protocol rules dictate character set, maximum name length, packet
+ format, etc. ICANN determines additional rules that apply when the
+ IETF's DNS protocol is used on the public Internet. In contrast,
+ private uses of the DNS protocol on isolated private networks are not
+ governed by ICANN. Since this proposed change is a change to the core
+ DNS protocol rules, it affects everyone, not just those machines
+ using the ICANN-governed Internet. Hence this change falls into the
+ category of an IETF protocol rule, not an ICANN usage rule.
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 6]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+3.2 Private DNS Namespaces
+
+ Note also that the special treatment of names ending in ".local." has
+ been implemented in Macintosh computers since the days of Mac OS 9,
+ and continues today in Mac OS X. There are also implementations for
+ Linux and other platforms [dotlocal]. Operators setting up private
+ internal networks ("intranets") are advised that their lives may be
+ easier if they avoid using the suffix ".local." in names in their
+ private internal DNS server. Alternative possibilities include:
+
+ .intranet
+ .internal
+ .private
+ .corp
+ .home
+
+ Another alternative naming scheme, advocated by Professor D. J.
+ Bernstein, is to use a numerical suffix, such as ".6." [djbdl].
+
+
+3.3 Maximum Multicast DNS Name Length
+
+ RFC 1034 says:
+
+ "the total number of octets that represent a domain name (i.e.,
+ the sum of all label octets and label lengths) is limited to 255."
+
+ This text implies that the final root label at the end of every name
+ is included in this count (a name can't be represented without it),
+ but the text does not explicitly state that. Implementations of
+ Multicast DNS MUST include the label length byte of the final root
+ label at the end of every name when enforcing the rule that no name
+ may be longer than 255 bytes. For example, the length of the name
+ "apple.com." is considered to be 11, which is the number of bytes it
+ takes to represent that name in a packet without using name
+ compression:
+
+ ------------------------------------------------------
+ | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 |
+ ------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 7]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+4. IP TTL Checks
+
+ All Multicast DNS responses (including responses sent via unicast)
+ MUST be sent with IP TTL set to 255.
+
+ A host sending Multicast DNS queries to a link-local destination
+ address (including the 224.0.0.251 link-local multicast address) MUST
+ verify that the IP TTL in response packets is 255, and silently
+ discard any response packets where the IP TTL is not 255. Without
+ this check, it could be possible for remote rogue hosts to send
+ spoof answer packets (perhaps unicast to the victim host) which the
+ receiving machine could misinterpret as having originated on the
+ local link.
+
+ The authors have heard complaints that some older network stack
+ implementations do not implement the IP_RECVTTL socket option
+ (or equivalent API) for obtaining the IP TTL of received packets.
+ This is unfortunate, and these old network stacks would benefit
+ from adding this API support so that they may benefit from this
+ enhanced protection against spoof packets arriving from off-link.
+
+ Note that Multicast DNS Responders SHOULD NOT discard queries with
+ TTLs other than 255. There may be valid future applications of
+ Multicast DNS where hosts issue unicast queries directed at Multicast
+ DNS Responders more than one hop away, if Multicast DNS Responders
+ were to discard queries where the TTL is not 255, they would not
+ answer these queries.
+
+
+5. Reverse Address Mapping
+
+ Like ".local.", the IPv4 and IPv6 reverse-mapping domains are also
+ defined to be link-local.
+
+ Any DNS query for a name ending with "254.169.in-addr.arpa." MUST
+ be sent to the mDNS multicast address 224.0.0.251. Since names under
+ this domain correspond to IPv4 link-local addresses, it is logical
+ that the local link is the best place to find information pertaining
+ to those names. As an optimization, these queries MAY be first
+ unicast directly to the address in question, but if this query is not
+ answered, the query MUST also be sent via multicast, to accommodate
+ the case where the machine in question is not answering for itself
+ (for example, because it is currently sleeping).
+
+ Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa."
+ MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB,
+ with or without an optional initial query unicast directly to the
+ address in question.
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 8]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+6. Querying
+
+ There are three kinds of Multicast DNS Queries, one-shot queries of
+ the kind made by today's conventional DNS clients, one-shot queries
+ accumulating multiple responses made by multicast-aware DNS clients,
+ and continuous ongoing Multicast DNS Queries used by IP network
+ browser software.
+
+ A Multicast DNS Responder that is offering records that are intended
+ to be unique on the local link MUST also implement a Multicast DNS
+ Querier so that it can first verify the uniqueness of those records
+ before it begins answering queries for them.
+
+
+6.1 One-Shot Queries
+
+ An unsophisticated DNS client may simply send its DNS queries
+ blindly to the 224.0.0.251 multicast address, without necessarily
+ even being aware what a multicast address is.
+
+ Such an unsophisticated DNS client may not get ideal behaviour. Such
+ a client may simply take the first response it receives and fail to
+ wait to see if there are more, but in many instances this may not be
+ a serious problem. If a user types "http://stu.local." into their Web
+ browser and gets to see the page they were hoping for, then the
+ protocol has met the user's needs in this case.
+
+
+6.2 One-Shot Queries, Accumulating Multiple Responses
+
+ A more sophisticated DNS client should understand that Multicast DNS
+ is not exactly the same as unicast DNS, and should modify its
+ behaviour in some simple ways.
+
+ As described above, there are some cases, such as looking up the
+ address associated with a unique host name, where a single response
+ is sufficient, and moreover may be all that is expected. However,
+ there are other DNS queries where more than one response is
+ possible, and for these queries a more sophisticated Multicast DNS
+ client should include the ability to wait for an appropriate period
+ of time to collect multiple responses.
+
+ A naive DNS client retransmits its query only so long as it has
+ received no response. A more sophisticated Multicast DNS client is
+ aware that having received one response is not necessarily an
+ indication that it might not receive others, and has the ability to
+ retransmit its query an appropriate number of times at appropriate
+ intervals until it is satisfied with the collection of responses it
+ has gathered.
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 9]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ A more sophisticated Multicast DNS client that is retransmitting
+ a query for which it has already received some responses, MUST
+ implement Known Answer Suppression, as described below in Section
+ 7.1. This indicates to responders who have already replied that their
+ responses have been received, and they don't need to send them again
+ in response to this repeated query. In addition, the interval between
+ the first two queries MUST be at least one second, and the
+ intervals between subsequent queries MUST double.
+
+
+6.3 Continuous Querying
+
+ In One-Shot Queries, with either a single or multiple responses,
+ the underlying assumption is that the transaction begins when the
+ application issues a query, and ends when all the desired responses
+ have been received. There is another type of operation which is more
+ akin to continuous monitoring.
+
+ Macintosh users are accustomed to opening the "Chooser" window,
+ selecting a desired printer, and then closing the Chooser window.
+ However, when the desired printer does not appear in the list, the
+ user will typically leave the "Chooser" window open while they go and
+ check to verify that the printer is plugged in, powered on, connected
+ to the Ethernet, etc. While the user jiggles the wires, hits the
+ Ethernet hub, and so forth, they keep an eye on the Chooser window,
+ and when the printer name appears, they know they have fixed whatever
+ the problem was. This can be a useful and intuitive troubleshooting
+ technique, but a user who goes home for the weekend leaving the
+ Chooser window open places a non-trivial burden on the network.
+
+ With continuous querying, multiple queries are sent over a long
+ period of time, until the user terminates the operation. It is
+ important that an IP network browser window displaying live
+ information from the network using Multicast DNS, if left running for
+ an extended period of time, should generate significantly less
+ multicast traffic on the network than the old AppleTalk Chooser.
+ Therefore, the interval between the first two queries MUST be at
+ least one second, the intervals between subsequent queries MUST
+ double, and the querier MUST implement Known Answer Suppression, as
+ described below in Section 7.1.
+
+ When a Multicast DNS Querier receives an answer, the answer contains
+ a TTL value that indicates for how many seconds this answer is valid.
+ After this interval has passed, the answer will no longer be valid
+ and should be deleted from the cache. Before this time is reached, a
+ Multicast DNS Querier with an ongoing interest in that record SHOULD
+ re-issue its query to determine whether the record is still valid,
+ and if so update its expiry time.
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 10]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ To perform this cache maintenance, a Multicast DNS Querier should
+ plan to issue a query at 80% of the record lifetime, and then if no
+ answer is received, at 85%, 90% and 95%. If an answer is received,
+ then the remaining TTL is reset to the value given in the answer, and
+ this process repeats for as long as the Multicast DNS Querier has an
+ ongoing interest in the record. If after four queries no answer is
+ received, the record is deleted when it reaches 100% of its lifetime.
+
+ To avoid the case where multiple Multicast DNS Queriers on a network
+ all issue their queries simultaneously, a random variation of 2% of
+ the record TTL should be added, so that queries are scheduled to be
+ performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL.
+
+
+6.4 Multiple Questions per Query
+
+ Multicast DNS allows a querier to place multiple questions in the
+ question section of a single Multicast DNS query packet.
+
+ The semantics of a Multicast DNS query packet containing multiple
+ questions is identical to a series of individual DNS query packets
+ containing one question each. Combining multiple questions into a
+ single packet is purely an efficiency optimization, and has no other
+ semantic significance.
+
+ A useful technique for adaptively combining multiple questions into a
+ single query is to use a Nagle-style algorithm: When a client issues
+ its first question, a Query packet is immediately built and sent,
+ without delay. If the client then continues issuing a rapid series of
+ questions they are held until either the first query receives at
+ least one answer, or 100ms has passed, or there are enough questions
+ to fill the question section of a Multicast DNS query packet. At this
+ time, all the held questions are placed into a Multicast DNS query
+ packet and sent.
+
+
+6.5 Questions Requesting Unicast Responses
+
+ Sending Multicast DNS responses via multicast has the benefit that
+ all the other hosts on the network get to see those responses, and
+ can keep their caches up to date, and detect conflicting responses.
+
+ However, there are situations where all the other hosts on the
+ network don't need to see every response. One example is a laptop
+ computer waking from sleep. At that instant it is a brand new
+ participant on a new network. Its Multicast DNS cache is empty, and
+ it has no knowledge of its surroundings. It may have a significant
+ number of queries that it wants answered right away to discover
+ information about its new surroundings and present that information
+ to the user. As a new participant on the network, it has no idea
+ whether the exact same questions may have been asked and answered
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 11]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ just seconds ago. In this case, trigging a large sudden flood of
+ multicast responses may impose an unreasonable burden on the network.
+ To avoid this, the Multicast DNS Querier SHOULD set the top bit in
+ the class field of its DNS question(s), to indicate that it is
+ willing to accept unicast responses instead of the usual multicast
+ responses. These questions requesting unicast responses are referred
+ to as "QU" questions, to distinguish them from the more usual
+ questions requesting multicast responses ("QM" questions).
+
+ When retransmitting a question more than once, the 'unicast response'
+ bit SHOULD be set only for the first question of the series. After
+ the first question has received its responses, the querier should
+ have a large known-answer list (see "Known Answer Suppression" below)
+ so that subsequent queries should elicit few, if any, further
+ responses. Reverting to multicast responses as soon as possible is
+ important because of the benefits that multicast responses provide
+ (see "Benefits of Multicast Responses" below).
+
+ When receiving a question with the 'unicast response' bit set, a
+ responder SHOULD usually respond with a unicast packet directed back
+ to the querier. If the responder has not multicast that record
+ recently (within one quarter of its TTL), then the responder SHOULD
+ instead multicast the response so as to keep all the peer caches up
+ to date, and to permit passive conflict detection.
+
+
+6.6 Suppressing Initial Query
+
+ If a query is issued for which there already exist one or more
+ records in the local cache, and those record(s) were received with
+ the cache flush bit set, indicating that they form a unique RRSet,
+ then the host SHOULD suppress its initial "QU" query, and proceed to
+ issue a "QM" query. To avoid the situation where a group of hosts
+ are synchronized by some external event and all perform the same
+ query simultaneously, a host suppressing its initial "QU" query
+ SHOULD impose a random delay from 500-1000ms before transmitting its
+ first "QM" query for this question. This means that when the first
+ host (selected randomly by this algorithm) transmits its "QM" query,
+ all the other hosts that were about to transmit the same query can
+ suppress their superfluous query, as described in "Duplicate
+ Question Suppression" below.
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 12]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+7. Duplicate Suppression
+
+ A variety of techniques are used to reduce the amount of redundant
+ traffic on the network.
+
+
+7.1 Known Answer Suppression
+
+ When a Multicast DNS Querier sends a query to which it already knows
+ some answers, it populates the Answer Section of the DNS message with
+ those answers.
+
+ A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if
+ the answer it would give is already included in the Answer Section
+ with an RR TTL at least half the correct value. If the RR TTL of the
+ answer as given in the Answer Section is less than half of the true
+ RR TTL as known by the Multicast DNS Responder, the responder MUST
+ send an answer so as to update the Querier's cache before the record
+ becomes in danger of expiration.
+
+ Because a Multicast DNS Responder will respond if the remaining TTL
+ given in the known answer list is less than half the true TTL, it is
+ superfluous for the Querier to include such records in the known
+ answer list. Therefore a Multicast DNS Querier SHOULD NOT include
+ records in the known answer list whose remaining TTL is less than
+ half their original TTL. Doing so would simply consume space in the
+ packet without achieving the goal of suppressing responses, and would
+ therefore be a pointless waste of network bandwidth.
+
+ A Multicast DNS Querier MUST NOT cache resource records observed in
+ the Known Answer Section of other Multicast DNS Queries. The Answer
+ Section of Multicast DNS Queries is not authoritative. By placing
+ information in the Answer Section of a Multicast DNS Query the
+ querier is stating that it *believes* the information to be true.
+ It is not asserting that the information *is* true. Some of those
+ records may have come from other hosts that are no longer on the
+ network. Propagating that stale information to other Multicast DNS
+ Queriers on the network would not be helpful.
+
+
+7.2 Multi-Packet Known Answer Suppression
+
+ Sometimes a Multicast DNS Querier will already have too many answers
+ to fit in the Known Answer section of its query packets. In this
+ case, it should issue a Multicast DNS Query containing a question and
+ as many Known Answer records as will fit. It should then set the TC
+ (Truncated) bit in the header before sending the Query. It should
+ then immediately follow the packet with another query containing no
+ questions, and as many more Known Answer records as will fit. If
+ there are still too many records remaining to fit in the packet, it
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 13]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ again sets the TC bit and continues until all the Known Answer
+ records have been sent.
+
+ A Multicast DNS Responder seeing a Multicast DNS Query with the TC
+ bit set defers its response for a time period randomly selected in
+ the interval 20-120ms. This gives the Multicast DNS Querier time to
+ send additional Known Answer packets before the Responder responds.
+ If the Responder sees any of its answers listed in the Known Answer
+ lists of subsequent packets from the querying host, it should delete
+ that answer from the list of answers it is planning to give, provided
+ that no other host on the network is also waiting to receive the same
+ answer record.
+
+
+7.3 Duplicate Question Suppression
+
+ If a host is planning to send a query, and it sees another host on
+ the network send a query containing the same question, and the Known
+ Answer section of that query does not contain any records which this
+ host would not also put in its own Known Answer section, then this
+ host should treat its own query as having been sent. When multiple
+ clients on the network are querying for the same resource records,
+ there is no need for them to all be repeatedly asking the same
+ question.
+
+
+7.4 Duplicate Answer Suppression
+
+ If a host is planning to send an answer, and it sees another host on
+ the network send a response packet containing the same answer record,
+ and the TTL in that record is not less than the TTL this host would
+ have given, then this host should treat its own answer as having been
+ sent. When multiple responders on the network have the same data,
+ there is no need for all of them to respond.
+
+ This feature is particularly useful when multiple Sleep Proxy Servers
+ are deployed (see Section 16. "Multicast DNS and Power Management").
+ In the future it is possible that every general-purpose OS (Mac,
+ Windows, Linux, etc.) will implement Sleep Proxy Service as a matter
+ of course. In this case there could be a large number of Sleep Proxy
+ Servers on any given network, which is good for reliability and
+ fault-tolerance, but would be bad for the network if every Sleep
+ Proxy Server were to answer every query.
+
+
+
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 14]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+8. Responding
+
+ A Multicast DNS Responder MUST only respond when it has a positive
+ non-null response to send. Error responses must never be sent. The
+ non-existence of any name in a Multicast DNS Domain is ascertained by
+ the failure of any machine to respond to the Multicast DNS query, not
+ by NXDOMAIN errors.
+
+ Multicast DNS Responses MUST NOT contain any questions in the
+ Question Section. Any questions in the Question Section of a received
+ Multicast DNS Response MUST be silently ignored. Multicast DNS
+ Queriers receiving Multicast DNS Responses do not care what question
+ elicited the response; they care only that the information in the
+ response is true and accurate.
+
+ A Multicast DNS Responder on Ethernet [IEEE802] and similar shared
+ multiple access networks SHOULD delay its responses by a random
+ amount of time selected with uniform random distribution in the range
+ 20-120ms. If multiple Multicast DNS Responders were all to respond
+ immediately to a particular query, a collision would be virtually
+ guaranteed. By imposing a small random delay, the number of
+ collisions is dramatically reduced. 120ms is a short enough time that
+ it is almost imperceptible to a human user, but long enough to
+ significantly reduce the risk of Ethernet collisions. On a full-sized
+ Ethernet using the maximum cable lengths allowed and the maximum
+ number of repeaters allowed, an Ethernet frame is vulnerable to
+ collisions during the transmission of its first 256 bits. On 10Mb/s
+ Ethernet, this equates to a vulnerable time window of 25.6us.
+
+ In the case where a Multicast DNS Responder has good reason to
+ believe that it will be the only responder on the link with a
+ positive non-null response, it SHOULD NOT impose the random delay
+ before responding, and SHOULD normally generate its response within
+ 10ms. To do this safely, it MUST have previously verified that the
+ requested name, type and class in the DNS query are unique on this
+ link. Responding immediately without delay is appropriate for things
+ like looking up the address record for a particular host name, when
+ the host name has been previously verified unique. Responding
+ immediately without delay is *not* appropriate for things like
+ looking up PTR records used for DNS Service Discovery [DNS-SD], where
+ a large number of responses may be anticipated.
+
+ Except when a unicast reply has been explicitly requested via the
+ "unicast reply" bit, Multicast DNS Responses MUST be sent to UDP port
+ 5353 (the well-known port assigned to mDNS) on the 224.0.0.251
+ multicast address (or its IPv6 equivalent FF02::FB). Operating in a
+ Zeroconf environment requires constant vigilance. Just because a name
+ has been previously verified unique does not mean it will continue to
+ be so indefinitely. By allowing all Multicast DNS Responders to
+ constantly monitor their peers' responses, conflicts arising out of
+ network topology changes can be promptly detected and resolved.
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 15]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ Sending all responses by multicast also facilitates opportunistic
+ caching by other hosts on the network.
+
+ To protect the network against excessive packet flooding due to
+ software bugs or malicious attack, a Multicast DNS Responder MUST NOT
+ multicast a given record on a given interface if it has previously
+ multicast that record on that interface within the last second. A
+ legitimate client on the network should have seen the previous
+ transmission and cached it. A client that did not receive and cache
+ the previous transmission will retry its request and receive a
+ subsequent response. Under no circumstances is there any legitimate
+ reason for a Multicast DNS Responder to multicast a given record more
+ than once per second on any given interface.
+
+
+8.1 Legacy Unicast Responses
+
+ If the source UDP port in a received Multicast DNS Query is not port
+ 5353, this indicates that the client originating the query is a
+ simple client that does not fully implement all of Multicast DNS. In
+ this case, the Multicast DNS Responder MUST send a UDP response
+ directly back to the client, via unicast, to the query packet's
+ source IP address and port. This unicast response MUST be a
+ conventional unicast response as would be generated by a conventional
+ unicast DNS server; for example, it must repeat the query ID and the
+ question given in the query packet.
+
+ The resource record TTL given in a unicast response SHOULD NOT be
+ greater than ten seconds, even if the true TTL of the Multicast DNS
+ resource record is higher. This is because Multicast DNS Responders
+ that fully participate in the protocol use the cache coherency
+ mechanisms described in Section 13 to update and invalidate stale
+ data. Were unicast responses sent to legacy clients to use the same
+ high TTLs, these legacy clients, which do not implement these cache
+ coherency mechanisms, could retain stale cached resource record data
+ long after it is no longer valid.
+
+ Having sent this unicast response, if the Responder has not sent this
+ record in any multicast response recently, it SHOULD schedule the
+ record to be sent via multicast as well, to facilitate passive
+ conflict detection. "Recently" in this context means "if the time
+ since the record was last sent via multicast is less than one quarter
+ of the record's TTL".
+
+
+
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 16]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+8.2 Multi-Question Queries
+
+ Multicast DNS Responders MUST correctly handle DNS query packets
+ containing more than one question, by answering any or all of the
+ questions to which they have answers. Any answers generated
+ in response to query packets containing more than one question
+ MUST be randomly delayed in the range 20-120ms, as described above.
+
+
+8.3 Response Aggregation
+
+ Having delayed one or more multicast responses by 20-120ms as
+ described above in Section 8 "Responding", a Multicast DNS Responder
+ SHOULD, for the sake of network efficiency, aggregate as many of its
+ pending responses as possible into a single Multicast DNS response
+ packet.
+
+
+9. Probing and Announcing on Startup
+
+ Typically a Multicast DNS Responder should have, at the very least,
+ address records for all of its active interfaces. Creating and
+ advertising an HINFO record on each interface as well can be useful
+ to network administrators.
+
+ Whenever a Multicast DNS Responder starts up, wakes up from sleep,
+ receives an indication of an Ethernet "Link Change" event, or has any
+ other reason to believe that its network connectivity may have
+ changed in some relevant way, it MUST perform the two startup steps
+ below.
+
+
+9.1 Probing
+
+ The first startup step is that for all those resource records that a
+ Multicast DNS Responder desires to be unique on the local link, it
+ MUST send a Multicast DNS Query asking for those resource records, to
+ see if any of them are already in use. The primary example of this is
+ its address record which maps its unique host name to its unique IP
+ address. All Probe Queries SHOULD be done using the desired resource
+ record name and query type T_ANY (255), to elicit answers for all
+ types of records with that name. This allows a single question to be
+ used in place of several questions, which is more efficient on the
+ network. It also allows a host to verify exclusive ownership of a
+ name, which is desirable in most cases. It would be confusing, for
+ example, if one host owned the "A" record for "myhost.local.", but a
+ different host owned the HINFO record for that name.
+
+ The ability to place more than one question in a Multicast DNS Query
+ is useful here, because it can allow a host to use a single packet
+ for all of its resource records instead of needing a separate packet
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 17]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ for each. For example, a host can simultaneously probe for uniqueness
+ of its "A" record and all its SRV records [DNS-SD] in the same query
+ packet.
+
+ When ready to send its mDNS probe packet(s) the host should first
+ wait for a short random delay time, uniformly distributed in the
+ range 0-250ms. This random delay is to guard against the case where a
+ group of devices are powered on simultaneously, or a group of devices
+ are connected to an Ethernet hub which is then powered on, or some
+ other external event happens that might cause a group of hosts to all
+ send synchronized probes.
+
+ 250ms after the first query the host should send a second, then
+ 250ms after that a third. If, by 250ms after the third probe, no
+ conflicting Multicast DNS responses have been received, the host may
+ move to the next step, announcing.
+
+ If any conflicting Multicast DNS responses are received, then the
+ probing host MUST defer to the existing host, and must choose new
+ names for some or all of its resource records as appropriate, to
+ avoid conflict with pre-existing hosts on the network. In the case
+ of a host probing using query type T_ANY as recommended above, any
+ answer containing a record with that name, of any type, MUST be
+ considered a conflicting response and handled accordingly.
+
+ If ten failures occur within any ten-second period, then the host
+ MUST wait at least five seconds before each successive additional
+ probe attempt. This is to help ensure that in the event of software
+ bugs or other unanticipated problems, errant hosts do not flood the
+ network with a continuous stream of multicast traffic. For very
+ simple devices, a valid way to comply with this requirement is to
+ always wait five seconds after any failed probe attempt.
+
+
+9.2 Simultaneous Probe Tie-Breaking
+
+ The astute reader will observe that there is a race condition
+ inherent in the previous description. If two hosts are probing for
+ the same name simultaneously, neither will receive any response to
+ the probe, and the hosts could incorrectly conclude that they may
+ both proceed to use the name. To break this symmetry, each host
+ populates the Authority Section of its queries with records giving
+ the rdata that it would be proposing to use, should its probing be
+ successful. The Authority Section is being used here in a way
+ analogous to the Update section of a DNS Update packet [RFC 2136].
+
+ When a host that is probing for a record sees another host issue a
+ query for the same record, it consults the Authority Section of that
+ query. If it finds any resource record there which answers the query,
+ then it compares the data of that resource record with its own
+ tentative data. The lexicographically later data wins. This means
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 18]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ that if the host finds that its own data is lexicographically later,
+ it simply ignores the other host's probe. If the host finds that its
+ own data is lexicographically earlier, then it treats this exactly
+ as if it had received a positive answer to its query, and concludes
+ that it may not use the desired name.
+
+ The determination of 'lexicographically later' is performed by first
+ comparing the record class, then the record type, then raw comparison
+ of the binary content of the rdata without regard for meaning or
+ structure. If the record classes differ, then the numerically greater
+ class is considered 'lexicographically later'. Otherwise, if the
+ record types differ, then the numerically greater type is considered
+ 'lexicographically later'. If the type and class both match then the
+ rdata is compared.
+
+ In the case of resource records containing rdata that is subject to
+ name compression, the names must be uncompressed before comparison.
+ (The details of how a particular name is compressed is an artifact of
+ how and where the record is written into the DNS message; it is not
+ an intrinsic property of the resource record itself.)
+
+ The bytes of the raw uncompressed rdata are compared in turn,
+ interpreting the bytes as eight-bit UNSIGNED values, until a byte
+ is found whose value is greater than that of its counterpart (in
+ which case the rdata whose byte has the greater value is deemed
+ lexicographically later) or one of the resource records runs out
+ of rdata (in which case the resource record which still has
+ remaining data first is deemed lexicographically later).
+
+ The following is an example of a conflict:
+
+ sctibook.local. A 196.254.100.200
+ sctibook.local. A 196.254.200.100
+
+ In this case 196.254.200.100 is lexicographically later, so it is
+ deemed the winner.
+
+ Note that it is vital that the bytes are interpreted as UNSIGNED
+ values, or the wrong outcome may result. In the example above, if
+ the byte with value 200 had been incorrectly interpreted as a
+ signed value then it would be interpreted as value -56, and the
+ wrong address record would be deemed the winner.
+
+
+9.3 Announcing
+
+ The second startup step is that the Multicast DNS Responder MUST send
+ a gratuitous Multicast DNS Response containing, in the Answer
+ Section, all of its resource records. If there are too many resource
+ records to fit in a single packet, multiple packets should be used.
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 19]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ In the case of shared records (e.g. the PTR records used by DNS
+ Service Discovery [DNS-SD]), the records are simply placed as-is
+ into the answer section of the DNS Response.
+
+ In the case of records that have been verified to be unique in the
+ previous step, they are placed into the answer section of the DNS
+ Response with the most significant bit of the rrclass set to one. The
+ most significant bit of the rrclass is the mDNS "cache flush" bit and
+ is discussed in more detail below in Section 13.3 "Announcements to
+ Flush Outdated Cache Entries".
+
+ The Multicast DNS Responder MUST send at least two gratuitous
+ responses, one second apart. A Responder MAY send up to ten
+ gratuitous Responses, providing that the interval between gratuitous
+ responses doubles with every response sent.
+
+ A Multicast DNS Responder SHOULD NOT continue sending gratuitous
+ Responses for longer than the TTL of the record. The purpose of
+ announcing new records via gratuitous Responses is to ensure that
+ peer caches are up to date. After a time interval equal to the TTL of
+ the record has passed, it is very likely that old stale copies of
+ that record in peer caches will have expired naturally, so subsequent
+ announcements serve little purpose.
+
+ Whenever a Multicast DNS Responder receives any Multicast DNS
+ response (gratuitous or otherwise) containing a conflicting resource
+ record, the conflict MUST be resolved as described below in "Conflict
+ Resolution".
+
+ A Multicast DNS Responder MUST NOT send announcements in the absence
+ of information that its network connectivity may have changed in some
+ relevant way. In particular, a Multicast DNS Responder MUST NOT send
+ regular periodic announcements as a matter of course.
+
+
+9.4 Updating
+
+ At any time, if the rdata of any of a host's Multicast DNS records
+ changes, the host MUST repeat the Announcing step described above to
+ update neighbouring caches. For example, if any of a host's IP
+ addresses change, it must re-announce those address records.
+
+ A host may update the contents of any of its records at any time,
+ though a host SHOULD NOT update records more frequently than ten
+ times per minute. Frequent rapid updates impose a burden on the
+ network. If a host has information to disseminate which changes more
+ frequently than ten times per minute, then Multicast DNS may not be
+ the appropriate protocol to disseminate that information.
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 20]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+10. Conflict Resolution
+
+ A conflict occurs when two resource records with the same name, type
+ and class have inconsistent rdata. What may be considered
+ inconsistent is context sensitive, except that resource records with
+ identical rdata are never considered inconsistent, even if they
+ originate from different hosts. A common example of a resource record
+ type that is intended to be unique, not shared between hosts, is the
+ address record that maps a host's name to its IP address. Should a
+ host witness another host announce an address record with the same
+ name but a different IP address, then that is considered
+ inconsistent, and that address record is considered to be in
+ conflict.
+
+ Whenever a Multicast DNS Responder receives any Multicast DNS
+ response (gratuitous or otherwise) containing a conflicting resource
+ record, the Multicast DNS Responder MUST immediately reset that
+ record to probing state, and go through the startup steps described
+ above in Section 9. "Probing and Announcing on Startup". The
+ protocol used in the Probing phase will determine a winner and a
+ loser, and the loser must cease using the name, and reconfigure.
+
+ It is very important that any host that observes an apparent conflict
+ MUST take action. In the case of two hosts using the same host name,
+ where one has been configured to require a unique host name and the
+ other has not, the one that has not been configured to require a
+ unique host name will not perceive any conflict, and will not take
+ any action. By reverting to Probing state, the host that desires a
+ unique host name will go through the necessary steps to ensure that a
+ unique host is obtained.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 21]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ The recommended course of action after probing and failing is as
+ follows:
+
+ o Programmatically change the resource record name in an attempt to
+ find a new name that is unique. This could be done by adding some
+ further identifying information (e.g. the model name of the
+ hardware) if it is not already present in the name, appending the
+ digit "2" to the name, or incrementing a number at the end of the
+ name if one is already present.
+
+ o Probe again, and repeat until a unique name is found.
+
+ o Record this newly chosen name in persistent storage so that the
+ device will use the same name the next time it is power-cycled.
+
+ o Display a message to the user or operator informing them of the
+ name change. For example:
+
+ The name "Bob's Music" is in use by another iTunes music
+ server on the network. Your music has been renamed to
+ "Bob's Music (G4 Cube)". If you want to change this name,
+ use [describe appropriate menu item or preference dialog].
+
+ How the user or operator is informed depends on context. A desktop
+ computer with a screen might put up a dialog box. A headless server
+ in the closet may write a message to a log file, or use whatever
+ mechanism (email, SNMP trap, etc.) it uses to inform the
+ administrator of other error conditions. On the other hand a headless
+ server in the closet may not inform the user at all -- if the user
+ cares, they will notice the name has changed, and connect to the
+ server in the usual way (e.g. via Web Browser) to configure a new
+ name.
+
+ The examples in this section focus on address records (i.e. host
+ names), but the same considerations apply to all resource records
+ where uniqueness (or maintenance of some other defined constraint) is
+ desired.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 22]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+11. Special Characteristics of Multicast DNS Domains
+
+ Unlike conventional DNS names, names that end in ".local.",
+ "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local
+ significance. Conventional DNS seeks to provide a single unified
+ namespace, where a given DNS query yields the same answer no matter
+ where on the planet it is performed or to which recursive DNS server
+ the query is sent. (However, split views, firewalls, intranets and
+ the like have somewhat interfered with this goal of DNS representing
+ a single universal truth.) In contrast, each IP link has its own
+ private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa."
+ namespaces, and the answer to any query for a name within those
+ domains depends on where that query is asked.
+
+ Multicast DNS Domains are not delegated from their parent domain via
+ use of NS records. There are no NS records anywhere in Multicast DNS
+ Domains. Instead, all Multicast DNS Domains are delegated to the IP
+ addresses 224.0.0.251 and FF02::FB by virtue of the individual
+ organizations producing DNS client software deciding how to handle
+ those names. It would be extremely valuable for the industry if this
+ special handling were ratified and recorded by IANA, since otherwise
+ the special handling provided by each vendor is likely to be
+ inconsistent.
+
+ The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The
+ IPv6 name server for a Multicast DNS Domain is FF02::FB. These are
+ multicast addresses; therefore they identify not a single host but a
+ collection of hosts, working in cooperation to maintain some
+ reasonable facsimile of a competently managed DNS zone. Conceptually
+ a Multicast DNS Domain is a single DNS zone, however its server is
+ implemented as a distributed process running on a cluster of loosely
+ cooperating CPUs rather than as a single process running on a single
+ CPU.
+
+ No delegation is performed within Multicast DNS Domains. Because the
+ cluster of loosely coordinated CPUs is cooperating to administer a
+ single zone, delegation is neither necessary nor desirable. Just
+ because a particular host on the network may answer queries for a
+ particular record type with the name "example.local." does not imply
+ anything about whether that host will answer for the name
+ "child.example.local.", or indeed for other record types with the
+ name "example.local."
+
+ Multicast DNS Zones have no SOA record. A conventional DNS zone's
+ SOA record contains information such as the email address of the zone
+ administrator and the monotonically increasing serial number of the
+ last zone modification. There is no single human administrator for
+ any given Multicast DNS Zone, so there is no email address. Because
+ the hosts managing any given Multicast DNS Zone are only loosely
+ coordinated, there is no readily available monotonically increasing
+ serial number to determine whether or not the zone contents have
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 23]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ changed. A host holding part of the shared zone could crash or be
+ disconnected from the network at any time without informing the other
+ hosts. There is no reliable way to provide a zone serial number that
+ would, whenever such a crash or disconnection occurred, immediately
+ change to indicate that the contents of the shared zone had changed.
+
+ Zone transfers are not possible for any Multicast DNS Zone.
+
+
+12. Multicast DNS for Service Discovery
+
+ This document does not describe using Multicast DNS for network
+ browsing or service discovery. However, the mechanisms this document
+ describes are compatible with (and support) the browsing and service
+ discovery mechanisms proposed in "DNS-Based Service Discovery"
+ [DNS-SD].
+
+ This document places few limitations on what DNS record types may be
+ looked up using local multicast. One particular kind of Multicast DNS
+ query that might be useful is a query for the SRV record named
+ "_domain._udp.local.", yielding the port number and IP address of a
+ conventional DNS server willing to perform general recursive DNS
+ lookups. This could solve a particular problem facing the IPv6
+ community, which is that IPv6 is able to self-configure almost all of
+ the information it needs to operate [RFC 2462], except for the
+ address of the DNS server. Bringing in all of the mechanisms of DHCP
+ just for that one little additional piece of information is not an
+ attractive solution. Using DNS-format messages and DNS-format
+ resource records to find the address of the DNS server has an elegant
+ self-sufficiency about it. Any host that needs to know the address of
+ the DNS server must already have code to generate and parse DNS
+ packets, so using that same code and those same packets to find the
+ DNS server in the first place is a simple self-reliant solution that
+ avoids taking external dependencies on other protocols.
+
+
+13. Resource Record TTL Values and Cache Coherency
+
+ The recommended TTL value for Multicast DNS resource records is
+ 120 minutes.
+
+ A client with an active outstanding query will issue a query packet
+ when one or more of the resource record(s) in its cache is (are) 80%
+ of the way to expiry. If the TTL on those records is 120 minutes,
+ this ongoing cache maintenance process yields a steady-state query
+ rate of one query every 96 minutes.
+
+ Any distributed cache needs a cache coherency protocol. If Multicast
+ DNS resource records follow the recommendation and have a TTL of 120
+ minutes, that means that stale data could persist in the system for
+ up to two hours. Making the default TTL significantly lower would
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 24]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ reduce the lifetime of stale data, but would produce too much extra
+ traffic on the network. Various techniques are available to minimize
+ the impact of such stale data.
+
+
+13.1 Cooperating Multicast DNS Responders
+
+ If a Multicast DNS Responder ("A") observes some other Multicast DNS
+ Responder ("B") send a Multicast DNS Response packet containing a
+ resource record with the same name type and class as one of A's
+ resource records, but different rdata, then:
+
+ o If A's resource record is intended to be a shared resource record,
+ then this is no conflict, and no action is required.
+
+ o If A's resource record is intended to be a unique resource record
+ then this is a conflict and MUST be handled as described in Section
+ 10 "Conflict Resolution".
+
+ If a Multicast DNS Responder ("A") observes some other Multicast DNS
+ Responder ("B") send a Multicast DNS Response packet containing a
+ resource record with the same name type and class as one of A's
+ resource records, and identical rdata, then:
+
+ o If the TTL of B's resource record given in the packet is at least
+ half the true TTL from A's point of view, then no action is
+ required.
+
+ o If the TTL of B's resource record given in the packet is less than
+ half the true TTL from A's point of view, then A MUST mark its
+ record to be announced via multicast. Clients receiving the record
+ from B would use the TTL given by B, and hence may delete the
+ record sooner than A expects. By sending its own multicast response
+ correcting the TTL, A ensures that the record will be retained for
+ the desired time.
+
+ These rules allow multiple Multicast DNS Responders to offer the same
+ data on the network (perhaps for fault tolerance reasons) without
+ conflicting with each other.
+
+
+13.2 Goodbye Packets
+
+ In the case where a host knows that certain resource record data is
+ about to become invalid (for example when the host is undergoing a
+ clean shutdown) the host SHOULD send a gratuitous announcement mDNS
+ response packet, giving the same resource record name, type, class
+ and rdata, but an RR TTL of zero. This has the effect of updating the
+ TTL stored in neighbouring hosts' cache entries to zero, causing that
+ cache entry to be promptly deleted.
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 25]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ Clients receiving a Multicast DNS Response with a TTL of zero SHOULD
+ NOT immediately delete the record from the cache, but instead record
+ a TTL of 1 and then delete the record one second later. In the case
+ of multiple Multicast DNS Responders on the network described in
+ Section 13.1 above, if one of the Responders shuts down and
+ incorrectly sends goodbye packets for its records, it gives the other
+ cooperating Responders one second to send out their own response to
+ "rescue" the records before they expire and are deleted.
+
+ Generally speaking, it is more important to send goodbye packets for
+ shared records than unique records. A given shared record name (such
+ as a PTR record used for DNS Service Discovery [DNS-SD]) by its
+ nature often has many representatives from many different hosts, and
+ tends to be the subject of long-lived ongoing queries. Those
+ long-lived queries are often concerned not just about being informed
+ when records appear, but also about being informed if those records
+ vanish again. In contrast, a unique record set (such as an SRV
+ record, or a host address record), by its nature, often has far fewer
+ members than a shared record set, and is usually the subject of
+ one-shot queries which simply retrieve the data and then cease
+ querying once they have the answer they are seeking. Therefore,
+ sending a goodbye packet for a unique record set is likely to offer
+ less benefit, because it is likely at any given moment that no one
+ has an active query running for that record set. One example where
+ goodbye packets for SRV and address records are useful is when
+ transferring control to a Sleep Proxy Server (see Section 16.
+ "Multicast DNS and Power Management").
+
+
+13.3 Announcements to Flush Outdated Cache Entries
+
+ Whenever a host has a resource record with potentially new data (e.g.
+ after rebooting, waking from sleep, connecting to a new network link,
+ changing IP address, etc.), the host MUST send a series of gratuitous
+ announcements to update cache entries in its neighbour hosts. In
+ these gratuitous announcements, if the record is one that is intended
+ to be unique, the host sets the most significant bit of the rrclass
+ field of the resource record. This bit, the "cache flush" bit, tells
+ neighbouring hosts that this is not a shared record type. Instead of
+ merging this new record additively into the cache in addition to any
+ previous records with the same name, type and class, all old records
+ with that name, type and class that were received more than one
+ second ago are declared invalid, and marked to expire from the cache
+ in one second.
+
+ The semantics of the cache flush bit are as follows: Normally when a
+ resource record appears in the answer section of the DNS Response, it
+ means, "This is an assertion that this information is true." When a
+ resource record appears in the answer section of the DNS Response
+ with the "cache flush" bit set, it means, "This is an assertion that
+ this information is the truth and the whole truth, and anything you
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 26]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ may have heard more than a second ago regarding records of this
+ name/type/class is no longer valid".
+
+ To accommodate the case where the set of records from one host
+ constituting a single unique RRSet is too large to fit in a single
+ packet, only cache records that are more than one second old are
+ flushed. This allows the announcing host to generate a quick burst of
+ packets back-to-back on the wire containing all the members
+ of the RRSet. When receiving records with the "cache flush" bit set,
+ all records older than one second are marked to be deleted one second
+ in the future. One second after the end of the little packet burst,
+ any records not represented within that packet burst will then be
+ expired from all peer caches.
+
+ Any time a host sends a response packet containing some members of a
+ unique RRSet, it SHOULD send the entire RRSet, preferably in a single
+ packet, or if the entire RRSet will not fit in a single packet, in a
+ quick burst of packets sent as close together as possible. The host
+ SHOULD set the cache flush bit on all members of the unique RRSet.
+ In the event that for some reason the host chooses not to send the
+ entire unique RRSet in a single packet or a rapid packet burst,
+ it MUST NOT set the cache flush bit on any of those records.
+
+ The reason for waiting one second before deleting stale records from
+ the cache is to accommodate bridged networks. For example, a host's
+ address record announcement on a wireless interface may be bridged
+ onto a wired Ethernet, and cause that same host's Ethernet address
+ records to be flushed from peer caches. The one-second delay gives
+ the host the chance to see its own announcement arrive on the wired
+ Ethernet, and immediately re-announce its Ethernet address records
+ so that both sets remain valid and live in peer caches.
+
+ These rules apply regardless of *why* the response packet is being
+ generated. They apply to startup announcements as described in
+ Section 9.3, and to responses generated as a result of receiving
+ query packets.
+
+ The "cache flush" bit is only set in Multicast DNS responses sent to
+ UDP port 5353. The "cache flush" bit MUST NOT be set in any resource
+ records in a response packet sent in legacy unicast responses to UDP
+ ports other than 5353.
+
+ The "cache flush" bit MUST NOT be set in any resource records in the
+ known-answer list of any query packet.
+
+ The "cache flush" bit MUST NOT ever be set in any shared resource
+ record. To do so would cause all the other shared versions of this
+ resource record with different rdata from different Responders to be
+ immediately deleted from all the caches on the network.
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 27]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ Note that the "cache flush" bit is NOT part of the resource record
+ class. The "cache flush" bit is the most significant bit of the
+ second 16-bit word of a resource record in an mDNS packet (the field
+ conventionally referred to as the rrclass field), and the actual
+ resource record class is the least-significant fifteen bits of this
+ field. There is no mDNS resource record class 0x8001. The value
+ 0x8001 in the rrclass field of a resource record in an mDNS response
+ packet indicates a resource record with class 1, with the "cache
+ flush" bit set. When receiving a resource record with the "cache
+ flush" bit set, implementations should take care to mask off that bit
+ before storing the resource record in memory.
+
+
+13.4 Cache Flush on Topology change
+
+ If the hardware on a given host is able to indicate physical changes
+ of connectivity, then when the hardware indicates such a change, the
+ host should take this information into account in its mDNS cache
+ management strategy. For example, a host may choose to immediately
+ flush all cache records received on a particular interface when that
+ cable is disconnected. Alternatively, a host may choose to adjust the
+ remaining TTL on all those records to a few seconds so that if the
+ cable is not reconnected quickly, those records will expire from the
+ cache.
+
+ Likewise, when a host reboots, or wakes from sleep, or undergoes some
+ other similar discontinuous state change, the cache management
+ strategy should take that information into account.
+
+
+13.5 Cache Flush on Failure Indication
+
+ Sometimes a cache record can be determined to be stale when a client
+ attempts to use the rdata it contains, and finds that rdata to be
+ incorrect.
+
+ For example, the rdata in an address record can be determined to be
+ incorrect if attempts to contact that host fail, either because
+ ARP/ND requests for that address go unanswered (for an address on a
+ local subnet) or because a router returns an ICMP "Host Unreachable"
+ error (for an address on a remote subnet).
+
+ The rdata in an SRV record can be determined to be incorrect if
+ attempts to communicate with the indicated service at the host and
+ port number indicated are not successful.
+
+ The rdata in a DNS-SD PTR record can be determined to be incorrect if
+ attempts to look up the SRV record it references are not successful.
+
+ In any such case, the software implementing the mDNS resource record
+ cache should provide a mechanism so that clients detecting stale
+ rdata can inform the cache.
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 28]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ When the cache receives this hint that it should reconfirm some
+ record, it MUST issue two or more queries for the resource record in
+ question. If no response is received in a reasonable amount of time,
+ then, even though its TTL may indicate that it is not yet due to
+ expire, that record SHOULD be promptly flushed from the cache.
+
+ The end result of this is that if a printer suffers a sudden power
+ failure or other abrupt disconnection from the network, its name may
+ continue to appear in DNS-SD browser lists displayed on users'
+ screens. Eventually that entry will expire from the cache naturally,
+ but if a user tries to access the printer before that happens, the
+ failure to successfully contact the printer will trigger the more
+ hasty demise of its cache entries. This is a sensible trade-off
+ between good user-experience and good network efficiency. If we were
+ to insist that printers should disappear from the printer list within
+ 30 seconds of becoming unavailable, for all failure modes, the only
+ way to achieve this would be for the client to poll the printer at
+ least every 30 seconds, or for the printer to announce its presence
+ at least every 30 seconds, both of which would be an unreasonable
+ burden on most networks.
+
+
+13.6 Passive Observation of Failures
+
+ A host observes the multicast queries issued by the other hosts on
+ the network. One of the major benefits of also sending responses
+ using multicast is that it allows all hosts to see the responses (or
+ lack thereof) to those queries.
+
+ If a host sees queries, for which a record in its cache would be
+ expected to be given as an answer in a multicast response, but no
+ such answer is seen, then the host may take this as an indication
+ that the record may no longer be valid.
+
+ After seeing two or more of these queries, and seeing no multicast
+ response containing the expected answer within a reasonable amount of
+ time, then even though its TTL may indicate that it is not yet due to
+ expire, that record MAY be flushed from the cache. The host SHOULD
+ NOT perform its own queries to re-confirm that the record is truly
+ gone. If every host on a large network were to do this, it would
+ cause a lot of unnecessary multicast traffic. If host A sends
+ multicast queries that remain unanswered, then there is no reason to
+ suppose that host B or any other host is likely to be any more
+ successful.
+
+ The previous section, "Cache Flush on Failure Indication", describes
+ a situation where a user trying to print discovers that the printer
+ is no longer available. By implementing the passive observation
+ described here, when one user fails to contact the printer, all hosts
+ on the network observe that failure and update their caches
+ accordingly.
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 29]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+14. Enabling and Disabling Multicast DNS
+
+ The option to fail-over to Multicast DNS for names not ending in
+ ".local." SHOULD be a user-configured option, and SHOULD
+ be disabled by default because of the possible security issues
+ related to unintended local resolution of apparently global names.
+
+ The option to lookup unqualified (relative) names by appending
+ ".local." (or not) is controlled by whether ".local." appears
+ (or not) in the client's DNS search list.
+
+ No special control is needed for enabling and disabling Multicast DNS
+ for names explicitly ending with ".local." as entered by the user.
+ The user doesn't need a way to disable Multicast DNS for names ending
+ with ".local.", because if the user doesn't want to use Multicast
+ DNS, they can achieve this by simply not using those names. If a user
+ *does* enter a name ending in ".local.", then we can safely assume
+ the user's intention was probably that it should work. Having user
+ configuration options that can be (intentionally or unintentionally)
+ set so that local names don't work is just one more way of
+ frustrating the user's ability to perform the tasks they want,
+ perpetuating the view that, "IP networking is too complicated to
+ configure and too hard to use." This in turn perpetuates the
+ continued use of protocols like AppleTalk. If we want to retire
+ AppleTalk, NetBIOS, etc., we need to offer users equivalent IP
+ functionality that they can rely on to, "always work, like
+ AppleTalk." A little Multicast DNS traffic may be a burden on the
+ network, but it is an insignificant burden compared to continued
+ widespread use of AppleTalk.
+
+
+15. Considerations for Multiple Interfaces
+
+ A host should defend its host name (FQDN) on all active interfaces on
+ which it is answering Multicast DNS queries.
+
+ In the event of a name conflict on *any* interface, a host should
+ configure a new host name, if it wishes to maintain uniqueness of its
+ host name.
+
+ When answering a Multicast DNS query, a multi-homed host with a
+ link-local address (or addresses) should take care to ensure that
+ any address going out in a Multicast DNS response is valid for use
+ on the interface on which the response is going out.
+
+ Just as the same link-local IP address may validly be in use
+ simultaneously on different links by different hosts, the same
+ link-local host name may validly be in use simultaneously on
+ different links, and this is not an error. A multi-homed host with
+ connections to two different links may be able to communicate with
+ two different hosts that are validly using the same name. While this
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 30]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ kind of name duplication should be rare, it means that a host that
+ wants to fully support this case needs network programming APIs that
+ allow applications to specify on what interface to perform a
+ link-local Multicast DNS query, and to discover on what interface a
+ Multicast DNS response was received.
+
+
+16. Multicast DNS and Power Management
+
+ Many modern network devices have the ability to go into a low-power
+ mode where only a small part of the Ethernet hardware remains
+ powered, and the device can be woken up by sending a specially
+ formatted Ethernet frame which the device's power-management hardware
+ recognizes.
+
+ To make use of this in conjunction with Multicast DNS, the device
+ first uses DNS-SD to determine if Sleep Proxy Service is available on
+ the local network. In some networks there may be more than one piece
+ of hardware implementing Sleep Proxy Service, for fault-tolerance
+ reasons.
+
+ If the device finds the network has Sleep Proxy Service, the device
+ transmits two or more gratuitous mDNS announcements setting the TTL
+ of its relevant resource records to zero, to delete them from
+ neighbouring caches. The relevant resource records include address
+ records and SRV records, and other resource records as may apply to a
+ particular device. The device then communicates all of its remaining
+ active records, plus the names, types and classes of the deleted
+ records, to the Sleep Proxy Service(s), along with a copy of the
+ specific "magic packet" required to wake the device up.
+
+ When a Sleep Proxy Service sees an mDNS query for one of the
+ device's active records (e.g. a DNS-SD PTR record), it answers on
+ behalf of the device without waking it up. When a Sleep Proxy Service
+ sees an mDNS query for one of the device's deleted resource
+ records, it deduces that some client on the network needs to make an
+ active connection to the device, and sends the specified "magic
+ packet" to wake the device up. The device then wakes up, reactivates
+ its deleted resource records, and re-announces them to the network.
+ The client waiting to connect sees the announcements, learns the
+ current IP address and port number of the desired service on the
+ device, and proceeds to connect to it.
+
+ The connecting client does not need to be aware of how Sleep Proxy
+ Service works. Only devices that implement low power mode and wish to
+ make use of Sleep Proxy Service need to be aware of how that protocol
+ works.
+
+ The reason that a device using a Sleep Proxy Service should send more
+ than one goodbye packet is that the wakeup message is caused by the
+ Sleep Proxy Service seeing queries for the device's SRV and/or
+ address records, and those queries are in turn caused by the records
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 31]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ being absent from peer caches. If the records are not deleted from
+ peer caches, then those peers may use the cached value directly
+ without querying, and no wakeup message would be generated.
+
+ The full specification of mDNS / DNS-SD Sleep Proxy Service
+ is described in another document [not yet published].
+
+
+17. Multicast DNS Character Set
+
+ Unicast DNS has been plagued by the lack of any support for non-US
+ characters. Indeed, conventional DNS is usually limited to just
+ letters, digits and hyphens, with no spaces or other punctuation.
+ Attempts to remedy this have made slow progress because of the need
+ to accommodate old buggy legacy implementations.
+
+ Multicast DNS is a new protocol and doesn't (yet) have old buggy
+ legacy implementations to constrain the design choices. Accordingly,
+ it adopts the obvious simple solution: all names in Multicast DNS are
+ encoded using UTF-8 [RFC 2279]. For names that are restricted to
+ letters, digits and hyphens, the UTF-8 encoding is identical to the
+ US-ASCII encoding, so this is entirely compatible with existing host
+ names. For characters outside the US-ASCII range, UTF-8 encoding is
+ used.
+
+ Multicast DNS implementations MUST NOT use any other encodings apart
+ from UTF-8 (US-ASCII being considered a compatible subset of UTF-8).
+
+ This point bears repeating: There are various baroque representations
+ of international text being proposed for Unicast DNS. None of these
+ representations may be used in Multicast DNS packets. Any text being
+ represented internally in some other representation MUST be converted
+ to canonical UTF-8 before being placed in any Multicast DNS packet.
+
+ The simple rules for case-insensitivity in Unicast DNS also apply in
+ Multicast DNS; that is to say, in name comparisons, the lower-case
+ letters "a" to "z" match their upper-case equivalents "A" to "Z".
+ Hence, if a client issues a query for an address record with the name
+ "stuartcheshire.local", then a responder having an address record
+ with the name "StuartCheshire.local" should issue a response.
+
+ No other automatic character equivalence is defined in Multicast DNS.
+ For example, accented characters are not defined to be automatically
+ equivalent to their unaccented counterparts. Where automatic
+ equivalences are desired, this may be achieved through the use of
+ programmatically-generated CNAME records. For example, if a responder
+ has an address record for an accented name Y, and a client issues a
+ query for a name X, where X is the same as Y with all the accents
+ removed, then the responder may issue a response containing two
+ resource records: A CNAME record "X CNAME Y", asserting that the
+ requested name X (unaccented) is an alias for the true (accented)
+ name Y, followed by the address record for Y.
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 32]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+18. Multicast DNS Message Size
+
+ RFC 1035 restricts DNS Messages carried by UDP to no more than 512
+ bytes (not counting the IP or UDP headers). For UDP packets carried
+ over the wide-area Internet in 1987, this was appropriate. For
+ link-local multicast packets on today's networks, there is no reason
+ to retain this restriction. Given that the packets are by definition
+ link-local, there are no Path MTU issues to consider.
+
+ Multicast DNS Messages carried by UDP may be up to the IP MTU of the
+ physical interface, less the space required for the IP header (20
+ bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).
+
+ In the case of a single mDNS Resource Record which is too large to
+ fit in a single MTU-sized multicast response packet, a Multicast DNS
+ Responder SHOULD send the Resource Record alone, in a single IP
+ datagram, sent using multiple IP fragments. Resource Records this
+ large SHOULD be avoided, except in the very rare cases where they
+ really are the appropriate solution to the problem at hand.
+ Implementers should be aware that many simple devices do not
+ re-assemble fragmented IP datagrams, so large Resource Records SHOULD
+ only be used in specialized cases where the implementer knows that
+ all receivers implement reassembly.
+
+ A Multicast DNS packet larger than the interface MTU, which is sent
+ using fragments, MUST NOT contain more than one Resource Record.
+
+ Even when fragmentation is used, a Multicast DNS packet, including IP
+ and UDP headers, MUST NOT exceed 9000 bytes.
+
+
+19. Multicast DNS Message Format
+
+ This section describes specific restrictions on the allowable
+ values for the header fields of a Multicast DNS message.
+
+19.1. ID (Query Identifier)
+
+ Multicast DNS clients SHOULD listen for gratuitous responses
+ issued by hosts booting up (or waking up from sleep or otherwise
+ joining the network). Since these gratuitous responses may contain a
+ useful answer to a question for which the client is currently
+ awaiting an answer, Multicast DNS clients SHOULD examine all received
+ Multicast DNS response messages for useful answers, without regard to
+ the contents of the ID field or the question section. In Multicast
+ DNS, knowing which particular query message (if any) is responsible
+ for eliciting a particular response message is less interesting than
+ knowing whether the response message contains useful information.
+
+ Multicast DNS clients MAY cache any or all Multicast DNS response
+ messages they receive, for possible future use, providing of course
+ that normal TTL aging is performed on these cashed resource records.
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 33]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+ In multicast query messages, the Query ID SHOULD be set to zero on
+ transmission.
+
+ In multicast responses, including gratuitous multicast responses, the
+ Query ID MUST be set to zero on transmission, and MUST be ignored on
+ reception.
+
+ In unicast response messages generated specifically in response to a
+ particular (unicast or multicast) query, the Query ID MUST match the
+ ID from the query message.
+
+
+19.2. QR (Query/Response) Bit
+
+ In query messages, MUST be zero.
+
+ In response messages, MUST be one.
+
+
+19.3. OPCODE
+
+ In both multicast query and multicast response messages, MUST be zero
+ (only standard queries are currently supported over multicast, unless
+ other queries are allowed by future IETF Standards Action).
+
+
+19.4. AA (Authoritative Answer) Bit
+
+ In query messages, the Authoritative Answer bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+ In response messages for Multicast Domains, the Authoritative Answer
+ bit MUST be set to one (not setting this bit implies there's some
+ other place where "better" information may be found) and MUST be
+ ignored on reception.
+
+
+19.5. TC (Truncated) Bit
+
+ In query messages, if the TC bit is set, it means that additional
+ Known Answer records may be following shortly. A responder MAY choose
+ to record this fact, and wait for those additional Known Answer
+ records, before deciding whether to respond. If the TC bit is clear,
+ it means that the querying host has no additional Known Answers.
+
+ In multicast response messages, the TC bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+ In legacy unicast response messages, the TC bit has the same meaning
+ as in conventional unicast DNS: it means that the response was too
+ large to fit in a single packet, so the client SHOULD re-issue its
+ query using TCP in order to receive the larger response.
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 34]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+19.6. RD (Recursion Desired) Bit
+
+ In both multicast query and multicast response messages, the
+ Recursion Desired bit SHOULD be zero on transmission, and MUST be
+ ignored on reception.
+
+
+19.7. RA (Recursion Available) Bit
+
+ In both multicast query and multicast response messages, the
+ Recursion Available bit MUST be zero on transmission, and MUST be
+ ignored on reception.
+
+
+19.8. Z (Zero) Bit
+
+ In both query and response messages, the Zero bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+
+19.9. AD (Authentic Data) Bit [RFC 2535]
+
+ In query messages the Authentic Data bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+ In response messages, the Authentic Data bit MAY be set. Resolvers
+ receiving response messages with the AD bit set MUST NOT trust the AD
+ bit unless they trust the source of the message and either have a
+ secure path to it or use DNS transaction security.
+
+
+19.10. CD (Checking Disabled) Bit [RFC 2535]
+
+ In query messages, a resolver willing to do cryptography SHOULD set
+ the Checking Disabled bit to permit it to impose its own policies.
+
+ In response messages, the Checking Disabled bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+
+19.11. RCODE (Response Code)
+
+ In both multicast query and multicast response messages, the Response
+ Code MUST be zero on transmission. Multicast DNS messages received
+ with non-zero Response Codes MUST be silently ignored.
+
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 35]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+20. Choice of UDP Port Number
+
+ Arguments were made for and against using Multicast on UDP port 53.
+ The final decision was to use UDP port 5353. Some of the arguments
+ for and against are given below.
+
+
+20.1 Arguments for using UDP port 53:
+
+ * This is "just DNS", so it should be the same port.
+
+ * There is less work to be done updating old clients to do simple
+ mDNS queries. Only the destination address need be changed.
+ In some cases, this can be achieved without any code changes,
+ just by adding the address 224.0.0.251 to a configuration file.
+
+
+20.2 Arguments for using a different port (UDP port 5353):
+
+ * This is not "just DNS". This is a DNS-like protocol, but different.
+
+ * Changing client code to use a different port number is not hard.
+
+ * Using the same port number makes it hard to run an mDNS Responder
+ and a conventional unicast DNS server on the same machine. If a
+ conventional unicast DNS server wishes to implement mDNS as well,
+ it can still do that, by opening two sockets. Having two different
+ port numbers is important to allow this flexibility.
+
+ * Some VPN software hijacks all outgoing traffic to port 53 and
+ redirects it to a special DNS server set up to serve those VPN
+ clients while they are connected to the corporate network. It is
+ questionable whether this is the right thing to do, but it is
+ common, and redirecting link-local multicast DNS packets to a
+ remote server rarely produces any useful results. It does mean, for
+ example, that the user becomes unable to access their local network
+ printer sitting on their desk right next to their computer. Using
+ a different UDP port eliminates this particular problem.
+
+ * On many operating systems, unprivileged clients may not send or
+ receive packets on low-numbered ports. This means that any client
+ sending or receiving mDNS packets on port 53 would have to run as
+ "root", which is an undesirable security risk. Using a higher-
+ numbered UDP port eliminates this particular problem.
+
+
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 36]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+21. Summary of Differences Between Multicast DNS and Unicast DNS
+
+ The value of Multicast DNS is that it shares, as much as possible,
+ the familiar APIs, naming syntax, resource record types, etc., of
+ Unicast DNS. There are of course necessary differences by virtue of
+ it using Multicast, and by virtue of it operating in a community of
+ cooperating peers, rather than a precisely defined authoritarian
+ hierarchy controlled by a strict chain of formal delegations from the
+ top. These differences are listed below:
+
+ Multicast DNS...
+ * uses multicast
+ * uses UDP port 5353 instead of port 53
+ * operates in well-defined parts of the DNS namespace
+ * uses UTF-8, and only UTF-8, to encode resource record names
+ * defines a clear limit on the maximum legal domain name (255 bytes)
+ * allows larger UDP packets
+ * allows more than one question in a query packet
+ * uses the Answer Section of a query to list Known Answers
+ * uses the TC bit in a query to indicate additional Known Answers
+ * uses the Authority Section of a query for probe tie-breaking
+ * ignores the Query ID field (except for generating legacy responses)
+ * doesn't require the question to be repeated in the response packet
+ * uses gratuitous responses to announce new records to the peer group
+ * defines a "unicast response" bit in the rrclass of query questions
+ * defines a "cache flush" bit in the rrclass of responses
+ * uses DNS TTL 0 to indicate that a record has been deleted
+ * uses IP TTL 255 to verify that answers originated on the local link
+ * monitors queries to perform Duplicate Question Suppression
+ * monitors responses to perform Duplicate Answer Suppression...
+ * ... and Ongoing Conflict Detection
+ * ... and Opportunistic Caching
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 37]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+22. Benefits of Multicast Responses
+
+ Some people have argued that sending responses via multicast is
+ inefficient on the network. In fact the benefits of using multicast
+ responses result in a net lowering of overall multicast traffic, for
+ a variety of reasons.
+
+ * One multicast response can update the cache on all machines on the
+ network. If another machine later wants to issue the same query, it
+ already has the answer in its cache, so it may not need to even
+ transmit that multicast query on the network at all.
+
+ * When more than one machine has the same ongoing long-lived query
+ running, every machine does not have to transmit its own
+ independent query. When one machine transmits a query, all the
+ other hosts see the answers, so they can suppress their own
+ queries.
+
+ * When a host sees a multicast query, but does not see the
+ corresponding multicast response, it can use this information to
+ promptly delete stale data from its cache. To achieve the same
+ level of user-interface quality and responsiveness without
+ multicast responses would require lower cache lifetimes and more
+ frequent network polling, resulting in a significantly higher
+ packet rate.
+
+ * Multicast responses allow passive conflict detection. Without this
+ ability, some other conflict detection mechanism would be needed,
+ imposing its own additional burden on the network.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 38]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+23. IPv6 Considerations
+
+ An IPv4-only host and an IPv6-only host behave as "ships that pass in
+ the night". Even if they are on the same Ethernet, neither is aware
+ of the other's traffic. For this reason, each physical link may have
+ *two* unrelated ".local." zones, one for IPv4 and one for IPv6.
+ Since for practical purposes, a group of IPv4-only hosts and a group
+ of IPv6-only hosts on the same Ethernet act as if they were on two
+ entirely separate Ethernet segments, it is unsurprising that their
+ use of the ".local." zone should occur exactly as it would if
+ they really were on two entirely separate Ethernet segments.
+
+ A dual-stack (v4/v6) host can participate in both ".local."
+ zones, and should register its name(s) and perform its lookups both
+ using IPv4 and IPv6. This enables it to reach, and be reached by,
+ both IPv4-only and IPv6-only hosts. In effect this acts like a
+ multi-homed host, with one connection to the logical "IPv4 Ethernet
+ segment", and a connection to the logical "IPv6 Ethernet segment".
+
+23.1 IPv6 Multicast Addresses by Hashing
+
+ Some discovery protocols use a range of multicast addresses, and
+ determine the address to be used by a hash function of the name being
+ sought. Queries are sent via multicast to the address as indicated by
+ the hash function, and responses are returned to the querier via
+ unicast. Particularly in IPv6, where multicast addresses are
+ extremely plentiful, this approach is frequently advocated.
+
+ There are some problems with this:
+
+ * When a host has a large number of records with different names, the
+ host may have to join a large number of multicast groups. This can
+ place undue burden on the Ethernet hardware, which typically
+ supports a limited number of multicast addresses efficiently. When
+ this number is exceeded, the Ethernet hardware may have to resort
+ to receiving all multicasts and passing them up to the host
+ software for filtering, thereby defeating the point of using a
+ multicast address range in the first place.
+
+ * Multiple questions cannot be placed in one packet if they don't all
+ hash to the same multicast address.
+
+ * Duplicate Question Suppression doesn't work if queriers are not
+ seeing each other's queries.
+
+ * Duplicate Answer Suppression doesn't work if responders are not
+ seeing each other's responses.
+
+ * Opportunistic Caching doesn't work.
+
+ * Ongoing Conflict Detection doesn't work.
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 39]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+24. Security Considerations
+
+ The algorithm for detecting and resolving name conflicts is, by its
+ very nature, an algorithm that assumes cooperating participants. Its
+ purpose is to allow a group of hosts to arrive at a mutually disjoint
+ set of host names and other DNS resource record names, in the absence
+ of any central authority to coordinate this or mediate disputes. In
+ the absence of any higher authority to resolve disputes, the only
+ alternative is that the participants must work together cooperatively
+ to arrive at a resolution.
+
+ In an environment where the participants are mutually antagonistic
+ and unwilling to cooperate, other mechanisms are appropriate, like
+ manually administered DNS.
+
+ In an environment where there is a group of cooperating participants,
+ but there may be other antagonistic participants on the same physical
+ link, the cooperating participants need to use IPSEC signatures
+ and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS
+ messages from trusted participants (which they process as usual) from
+ mDNS messages from untrusted participants (which they silently
+ discard).
+
+ When DNS queries for *global* DNS names are sent to the mDNS
+ multicast address (during network outages which disrupt communication
+ with the greater Internet) it is *especially* important to use
+ DNSSEC, because the user may have the impression that he or she is
+ communicating with some authentic host, when in fact he or she is
+ really communicating with some local host that is merely masquerading
+ as that name. This is less critical for names ending with ".local.",
+ because the user should be aware that those names have only local
+ significance and no global authority is implied.
+
+ Most computer users neglect to type the trailing dot at the end of a
+ fully qualified domain name, making it a relative domain name (e.g.
+ "www.example.com"). In the event of network outage, attempts to
+ positively resolve the name as entered will fail, resulting in
+ application of the search list, including ".local.", if present.
+ A malicious host could masquerade as "www.example.com" by answering
+ the resulting Multicast DNS query for "www.example.com.local."
+ To avoid this, a host MUST NOT append the search suffix
+ ".local.", if present, to any relative (partially qualified)
+ domain name containing two or more labels. Appending ".local." to
+ single-label relative domain names is acceptable, since the user
+ should have no expectation that a single-label domain name will
+ resolve as-is.
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 40]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+25. IANA Considerations
+
+ The IANA has allocated the IPv4 link-local multicast address
+ 224.0.0.251 for the use described in this document.
+
+ The IANA has allocated the IPv6 multicast address set FF0X::FB
+ for the use described in this document.
+
+ When this document is published, IANA should designate a list
+ of domains which are deemed to have only link-local significance,
+ as described in this document.
+
+ No other IANA services are required by this document.
+
+
+26. Acknowledgements
+
+ The concepts described in this document have been explored and
+ developed with help from Erik Guttman, Paul Vixie, Bill Woodcock,
+ and others.
+
+
+27. Copyright
+
+ Copyright (C) The Internet Society January 2004.
+ All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 41]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+28. Normative References
+
+ [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
+ Facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+ Specifications", STD 13, RFC 1035, November 1987.
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+29. Informative References
+
+ [dotlocal] <http://www.dotlocal.org/>
+
+ [djbdl] <http://cr.yp.to/djbdns/dot-local.html>
+
+ [IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
+ Overview and Architecture.
+ Institute of Electrical and Electronic Engineers,
+ IEEE Standard 802, 1990.
+
+ [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service
+ Discovery", Internet-Draft (work in progress),
+ draft-cheshire-dnsext-dns-sd-03.txt, January 2004.
+
+ [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
+ System (DNS UPDATE)", RFC 2136, April 1997.
+
+ [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+ [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [v4LL] Cheshire, S., B. Aboba, and E. Guttman, "Dynamic
+ Configuration of IPv4 Link-Local Addresses",
+ Internet-Draft (work in progress),
+ draft-ietf-zeroconf-ipv4-linklocal-11.txt, January 2004.
+
+ [ZC] Williams, A., "Requirements for Automatic Configuration
+ of IP Hosts", Internet-Draft (work in progress),
+ draft-ietf-zeroconf-reqts-12.txt, September 2002.
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 42]
+\f
+Internet Draft Multicast DNS 29th January 2003
+
+
+30. Author's Addresses
+
+ Stuart Cheshire
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino
+ California 95014
+ USA
+
+ Phone: +1 408 974 3207
+ EMail: rfc@stuartcheshire.org
+
+
+ Marc Krochmal
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino
+ California 95014
+ USA
+
+ Phone: +1 408 974 4368
+ EMail: marc@apple.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 29th July 2004 Cheshire & Krochmal [Page 43]
--- /dev/null
+Document: draft-cheshire-dnsext-multicastdns-04.txt Stuart Cheshire
+Category: Standards Track Apple Computer, Inc.
+Expires 14th August 2004 Marc Krochmal
+ Apple Computer, Inc.
+ 14th February 2004
+
+ Multicast DNS
+
+ <draft-cheshire-dnsext-multicastdns-04.txt>
+
+
+Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with
+ all provisions of Section 10 of RFC2026. Internet-Drafts are
+ working documents of the Internet Engineering Task Force (IETF),
+ its areas, and its working groups. Note that other groups may
+ also distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other documents
+ at any time. It is inappropriate to use Internet-Drafts as
+ reference material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html
+
+ Distribution of this memo is unlimited.
+
+
+Abstract
+
+ As networked devices become smaller, more portable, and more
+ ubiquitous, the ability to operate with less configured
+ infrastructure is increasingly important. In particular, the ability
+ to look up DNS resource record data types (including, but not limited
+ to, host names) in the absence of a conventional managed DNS server,
+ is becoming essential.
+
+ Multicast DNS (mDNS) provides the ability to do DNS-like operations
+ on the local link in the absense of any conventional unicast DNS
+ server. In addition, mDNS designates a portion of the DNS namespace
+ to be free for local use, without the need to pay any annual fee, and
+ without the need to set up delegations or otherwise configure a
+ conventional DNS server to answer for those names.
+
+ The primary benefits of mDNS names are that (i) they require little
+ or no administration or configuration to set them up, (ii) they work
+ when no infrastructure is present, and (iii) they work during
+ infrastructure failures.
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 1]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+Table of Contents
+
+ 1. Introduction...................................................3
+ 2. Conventions and Terminology Used in this Document..............4
+ 3. Multicast DNS Names............................................4
+ 4. IP TTL Checks..................................................8
+ 5. Reverse Address Mapping........................................8
+ 6. Querying.......................................................9
+ 7. Duplicate Suppression.........................................13
+ 8. Responding....................................................15
+ 9. Probing and Announcing on Startup.............................17
+ 10. Conflict Resolution...........................................21
+ 11. Special Characteristics of Multicast DNS Domains..............23
+ 12. Multicast DNS for Service Discovery...........................24
+ 13. Resource Record TTL Values and Cache Coherency................25
+ 14. Enabling and Disabling Multicast DNS..........................30
+ 15. Considerations for Multiple Interfaces........................30
+ 16. Multicast DNS and Power Management............................31
+ 17. Multicast DNS Character Set...................................32
+ 18. Multicast DNS Message Size....................................33
+ 19. Multicast DNS Message Format..................................33
+ 20. Choice of UDP Port Number.....................................36
+ 21. Summary of Differences Between Multicast DNS and Unicast DNS..37
+ 22. Benefits of Multicast Responses...............................38
+ 23. IPv6 Considerations...........................................39
+ 24. Security Considerations.......................................40
+ 25. IANA Considerations...........................................41
+ 26. Acknowledgements..............................................41
+ 27. Copyright.....................................................41
+ 28. Normative References..........................................42
+ 29. Informative References........................................42
+ 30. Author's Addresses............................................43
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 2]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+1. Introduction
+
+ When reading this document, familiarity with the concepts of Zero
+ Configuration Networking [ZC] and automatic link-local addressing
+ [v4LL] [RFC 2462] is helpful.
+
+ This document proposes no change to the structure of DNS messages,
+ and no new operation codes, response codes, or resource record types.
+ This document simply discusses what needs to happen if DNS clients
+ start sending DNS queries to a multicast address, and how a
+ collection of hosts can cooperate to collectively answer those
+ queries in a useful manner.
+
+ There has been discussion of how much burden Multicast DNS might
+ impose on a network. It should be remembered that whenever IPv4 hosts
+ communicate, they broadcast ARP packets on the network on a regular
+ basis, and this is not disastrous. The approximate amount of
+ multicast traffic generated by hosts making conventional use of
+ Multicast DNS is anticipated to be roughly the same order of
+ magnitude as the amount of broadcast ARP traffic those hosts already
+ generate.
+
+ New applications making new use of Multicast DNS capabilities for
+ unconventional purposes may generate more traffic. If some of those
+ new applications are "chatty", then work will be needed to help them
+ become less chatty. When performing any analysis, it is important to
+ make a distinction between the application behavior and the
+ underlying protocol behavior. If a chatty application uses UDP, that
+ doesn't mean that UDP is chatty, or that IP is chatty, or that
+ Ethernet is chatty. What it means is that the application is chatty.
+ The same applies to any future applications that may decide to layer
+ increasing portions of their functionality over Multicast DNS.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 3]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+2. Conventions and Terminology Used in this Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in "Key words for use in
+ RFCs to Indicate Requirement Levels" [RFC 2119].
+
+ This document uses the term "host name" in the strict sense to mean a
+ fully qualified domain name that has an address record. It does not
+ use the term "host name" in the commonly used but incorrect sense to
+ mean just the first DNS label of a host's fully qualified domain
+ name.
+
+ A DNS (or mDNS) packet contains an IP TTL in the IP header, which
+ is effectively a hop-count limit for the packet, to guard against
+ routing loops. Each Resource Record also contains a TTL, which is
+ the number of seconds for which the Resource Record may be cached.
+
+ In any place where there may be potential confusion between these two
+ types of TTL, the term "IP TTL" is used to refer to the IP header TTL
+ (hop limit), and the term "RR TTL" is used to refer to the Resource
+ Record TTL (cache lifetime).
+
+ When this document uses the term "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 packets over IP
+ Multicast to UDP port 5353."
+
+
+3. Multicast DNS Names
+
+ This document proposes that the DNS top-level domain ".local." be
+ designated a special domain with special semantics, namely that any
+ fully-qualified name ending in ".local." is link-local, and names
+ within this domain are meaningful only on the link where they
+ originate. This is analogous to IPv4 addresses in the 169.254/16
+ prefix, which are link-local and meaningful only on the link where
+ they originate.
+
+ Any DNS query for a name ending with ".local." MUST be sent
+ to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent
+ FF02::FB).
+
+ It is unimportant whether a name ending with ".local." occurred
+ because the user explicitly typed in a fully qualified domain name
+ ending in ".local.", or because the user entered an unqualified
+ domain name and the host software appended the suffix ".local."
+ because that suffix appears in the user's search list. The ".local."
+ suffix could appear in the search list because the user manually
+ configured it, or because it was received in a DHCP option, or via
+ any other valid mechanism for configuring the DNS search list. In
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 4]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ this respect the ".local." suffix is treated no differently to any
+ other search domain that might appear in the DNS search list.
+
+ DNS queries for names that do not end with ".local." MAY be sent to
+ the mDNS multicast address, if no other conventional DNS server is
+ available. This can allow hosts on the same link to continue
+ communicating using each other's globally unique DNS names during
+ network outages which disrupt communication with the greater
+ Internet. When resolving global names via local multicast, it is even
+ more important to use DNSSEC or other security mechanisms to ensure
+ that the response is trustworthy. Resolving global names via local
+ multicast is a contentious issue, and this document does not discuss
+ it in detail, instead concentrating on the issue of resolving local
+ names using DNS packets sent to a multicast address.
+
+ A host which belongs to an organization or individual who has control
+ over some portion of the DNS namespace can be assigned a globally
+ unique name within that portion of the DNS namespace, for example,
+ "cheshire.apple.com." For those of us who have this luxury, this
+ works very well. However, the majority of home customers do not have
+ easy access to any portion of the global DNS namespace within which
+ they have the authority to create names as they wish. This leaves the
+ majority of home computers effectively anonymous for practical
+ purposes.
+
+ To remedy this problem, this document allows any computer user to
+ elect to give their computers link-local Multicast DNS host names of
+ the form: "single-dns-label.local." For example, my Titanium
+ PowerBook laptop computer answers to the name "sctibook.local." Any
+ computer user is granted the authority to name their computer this
+ way, providing that the chosen host name is not already in use on
+ that link. Having named their computer this way, the user has the
+ authority to continue using that name until such time as a name
+ conflict occurs on the link which is not resolved in the user's
+ favour. If this happens, the computer (or its human user) SHOULD
+ cease using the name, and may choose to attempt to allocate a new
+ unique name for use on that link. Like law suits over global DNS
+ names, these conflicts are expected to be relatively rare for people
+ who choose reasonably imaginative names, but it is still important
+ to have a mechanism in place to handle them when they happen.
+
+ The point made in the previous paragraph is very important and bears
+ repeating. It is easy for those of us in the IETF community who run
+ our own name servers at home to forget that the majority of computer
+ users do not run their own name server and have no easy way to create
+ their own host names. When these users wish to transfer files between
+ two laptop computers, they are frequently reduced to typing in
+ dotted-decimal IP addresses because they simply have no other way for
+ one host to refer to the other by name. This is a sorry state of
+ affairs. What is worse, most users don't even bother trying to use
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 5]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ dotted-decimal IP addresses. Most users still move data between
+ machines by copying it onto a floppy disk or similar removable media.
+
+ In a world of gigabit Ethernet and ubiquitous wireless networking it
+ is a sad indictment of the networking community that the preferred
+ communication medium for most computer users is still the floppy
+ disk.
+
+ Allowing ad-hoc allocation of single-label names in a single flat
+ ".local." namespace may seem to invite chaos. However, operational
+ experience with AppleTalk NBP names [NBP], which on any given link
+ are also effectively single-label names in a flat namespace, shows
+ that in practice name collisions happen extremely rarely and are not
+ a problem. Groups of computer users from disparate organizations
+ bring Macintosh laptop computers to events such as IETF Meetings, the
+ Mac Hack conference, the Apple World Wide Developer Conference, etc.,
+ and complaints at these events about users suffering conflicts and
+ being forced to rename their machines have never been an issue.
+
+ Enforcing uniqueness of host names (i.e. the names of DNS address
+ records mapping names to IP addresses) is probably desirable in the
+ common case, but this document does not mandate that. It is
+ permissible for a collection of coordinated hosts to agree to
+ maintain multiple DNS address records with the same name, possibly
+ for load balancing or fault-tolerance reasons. This document does not
+ take a position on whether that is sensible. It is important that
+ both modes of operation are supported. The Multicast DNS protocol
+ allows hosts to verify and maintain unique names for resource records
+ where that behaviour is desired, and it also allows hosts to maintain
+ multiple resource records with a single shared name where that
+ behaviour is desired. This consideration applies to all resource
+ records, not just address records (host names). In summary: It is
+ required that the protocol have the ability to detect and handle name
+ conflicts, but it is not required that this ability be used for every
+ record.
+
+
+3.1 Governing Standards Body
+
+ Note that this use of the ".local." suffix falls under IETF
+ jurisdiction, not ICANN jurisdiction. DNS is an IETF network
+ protocol, governed by protocol rules defined by the IETF. These IETF
+ protocol rules dictate character set, maximum name length, packet
+ format, etc. ICANN determines additional rules that apply when the
+ IETF's DNS protocol is used on the public Internet. In contrast,
+ private uses of the DNS protocol on isolated private networks are not
+ governed by ICANN. Since this proposed change is a change to the core
+ DNS protocol rules, it affects everyone, not just those machines
+ using the ICANN-governed Internet. Hence this change falls into the
+ category of an IETF protocol rule, not an ICANN usage rule.
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 6]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+3.2 Private DNS Namespaces
+
+ Note also that the special treatment of names ending in ".local." has
+ been implemented in Macintosh computers since the days of Mac OS 9,
+ and continues today in Mac OS X. There are also implementations for
+ Linux and other platforms [dotlocal]. Operators setting up private
+ internal networks ("intranets") are advised that their lives may be
+ easier if they avoid using the suffix ".local." in names in their
+ private internal DNS server. Alternative possibilities include:
+
+ .intranet
+ .internal
+ .private
+ .corp
+ .home
+
+ Another alternative naming scheme, advocated by Professor D. J.
+ Bernstein, is to use a numerical suffix, such as ".6." [djbdl].
+
+
+3.3 Maximum Multicast DNS Name Length
+
+ RFC 1034 says:
+
+ "the total number of octets that represent a domain name (i.e.,
+ the sum of all label octets and label lengths) is limited to 255."
+
+ This text implies that the final root label at the end of every name
+ is included in this count (a name can't be represented without it),
+ but the text does not explicitly state that. Implementations of
+ Multicast DNS MUST include the label length byte of the final root
+ label at the end of every name when enforcing the rule that no name
+ may be longer than 255 bytes. For example, the length of the name
+ "apple.com." is considered to be 11, which is the number of bytes it
+ takes to represent that name in a packet without using name
+ compression:
+
+ ------------------------------------------------------
+ | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 |
+ ------------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 7]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+4. IP TTL Checks
+
+ All Multicast DNS responses (including responses sent via unicast)
+ MUST be sent with IP TTL set to 255.
+
+ A host sending Multicast DNS queries to a link-local destination
+ address (including the 224.0.0.251 link-local multicast address) MUST
+ verify that the IP TTL in response packets is 255, and silently
+ discard any response packets where the IP TTL is not 255. Without
+ this check, it could be possible for remote rogue hosts to send
+ spoof answer packets (perhaps unicast to the victim host) which the
+ receiving machine could misinterpret as having originated on the
+ local link.
+
+ The authors have heard complaints that some older network stack
+ implementations do not implement the IP_RECVTTL socket option
+ (or equivalent API) for obtaining the IP TTL of received packets.
+ This is unfortunate, and these old network stacks would benefit
+ from adding this API support so that they may benefit from this
+ enhanced protection against spoof packets arriving from off-link.
+
+ Note that Multicast DNS Responders SHOULD NOT discard queries with
+ TTLs other than 255. There may be valid future applications of
+ Multicast DNS where hosts issue unicast queries directed at Multicast
+ DNS Responders more than one hop away, if Multicast DNS Responders
+ were to discard queries where the TTL is not 255, they would not
+ answer these queries.
+
+
+5. Reverse Address Mapping
+
+ Like ".local.", the IPv4 and IPv6 reverse-mapping domains are also
+ defined to be link-local.
+
+ Any DNS query for a name ending with "254.169.in-addr.arpa." MUST
+ be sent to the mDNS multicast address 224.0.0.251. Since names under
+ this domain correspond to IPv4 link-local addresses, it is logical
+ that the local link is the best place to find information pertaining
+ to those names. As an optimization, these queries MAY be first
+ unicast directly to the address in question, but if this query is not
+ answered, the query MUST also be sent via multicast, to accommodate
+ the case where the machine in question is not answering for itself
+ (for example, because it is currently sleeping).
+
+ Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa."
+ MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB,
+ with or without an optional initial query unicast directly to the
+ address in question.
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 8]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+6. Querying
+
+ There are three kinds of Multicast DNS Queries, one-shot queries of
+ the kind made by today's conventional DNS clients, one-shot queries
+ accumulating multiple responses made by multicast-aware DNS clients,
+ and continuous ongoing Multicast DNS Queries used by IP network
+ browser software.
+
+ A Multicast DNS Responder that is offering records that are intended
+ to be unique on the local link MUST also implement a Multicast DNS
+ Querier so that it can first verify the uniqueness of those records
+ before it begins answering queries for them.
+
+
+6.1 One-Shot Queries
+
+ An unsophisticated DNS client may simply send its DNS queries
+ blindly to the 224.0.0.251 multicast address, without necessarily
+ even being aware what a multicast address is.
+
+ Such an unsophisticated DNS client may not get ideal behaviour. Such
+ a client may simply take the first response it receives and fail to
+ wait to see if there are more, but in many instances this may not be
+ a serious problem. If a user types "http://stu.local." into their Web
+ browser and gets to see the page they were hoping for, then the
+ protocol has met the user's needs in this case.
+
+
+6.2 One-Shot Queries, Accumulating Multiple Responses
+
+ A more sophisticated DNS client should understand that Multicast DNS
+ is not exactly the same as unicast DNS, and should modify its
+ behaviour in some simple ways.
+
+ As described above, there are some cases, such as looking up the
+ address associated with a unique host name, where a single response
+ is sufficient, and moreover may be all that is expected. However,
+ there are other DNS queries where more than one response is
+ possible, and for these queries a more sophisticated Multicast DNS
+ client should include the ability to wait for an appropriate period
+ of time to collect multiple responses.
+
+ A naive DNS client retransmits its query only so long as it has
+ received no response. A more sophisticated Multicast DNS client is
+ aware that having received one response is not necessarily an
+ indication that it might not receive others, and has the ability to
+ retransmit its query an appropriate number of times at appropriate
+ intervals until it is satisfied with the collection of responses it
+ has gathered.
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 9]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ A more sophisticated Multicast DNS client that is retransmitting
+ a query for which it has already received some responses, MUST
+ implement Known Answer Suppression, as described below in Section
+ 7.1. This indicates to responders who have already replied that their
+ responses have been received, and they don't need to send them again
+ in response to this repeated query. In addition, the interval between
+ the first two queries MUST be at least one second, and the
+ intervals between subsequent queries MUST double.
+
+
+6.3 Continuous Querying
+
+ In One-Shot Queries, with either a single or multiple responses,
+ the underlying assumption is that the transaction begins when the
+ application issues a query, and ends when all the desired responses
+ have been received. There is another type of operation which is more
+ akin to continuous monitoring.
+
+ Macintosh users are accustomed to opening the "Chooser" window,
+ selecting a desired printer, and then closing the Chooser window.
+ However, when the desired printer does not appear in the list, the
+ user will typically leave the "Chooser" window open while they go and
+ check to verify that the printer is plugged in, powered on, connected
+ to the Ethernet, etc. While the user jiggles the wires, hits the
+ Ethernet hub, and so forth, they keep an eye on the Chooser window,
+ and when the printer name appears, they know they have fixed whatever
+ the problem was. This can be a useful and intuitive troubleshooting
+ technique, but a user who goes home for the weekend leaving the
+ Chooser window open places a non-trivial burden on the network.
+
+ With continuous querying, multiple queries are sent over a long
+ period of time, until the user terminates the operation. It is
+ important that an IP network browser window displaying live
+ information from the network using Multicast DNS, if left running for
+ an extended period of time, should generate significantly less
+ multicast traffic on the network than the old AppleTalk Chooser.
+ Therefore, the interval between the first two queries MUST be at
+ least one second, the intervals between subsequent queries MUST
+ double, and the querier MUST implement Known Answer Suppression, as
+ described below in Section 7.1.
+
+ When a Multicast DNS Querier receives an answer, the answer contains
+ a TTL value that indicates for how many seconds this answer is valid.
+ After this interval has passed, the answer will no longer be valid
+ and should be deleted from the cache. Before this time is reached, a
+ Multicast DNS Querier with an ongoing interest in that record SHOULD
+ re-issue its query to determine whether the record is still valid,
+ and if so update its expiry time.
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 10]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ To perform this cache maintenance, a Multicast DNS Querier should
+ plan to issue a query at 80% of the record lifetime, and then if no
+ answer is received, at 85%, 90% and 95%. If an answer is received,
+ then the remaining TTL is reset to the value given in the answer, and
+ this process repeats for as long as the Multicast DNS Querier has an
+ ongoing interest in the record. If after four queries no answer is
+ received, the record is deleted when it reaches 100% of its lifetime.
+
+ To avoid the case where multiple Multicast DNS Queriers on a network
+ all issue their queries simultaneously, a random variation of 2% of
+ the record TTL should be added, so that queries are scheduled to be
+ performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL.
+
+
+6.4 Multiple Questions per Query
+
+ Multicast DNS allows a querier to place multiple questions in the
+ question section of a single Multicast DNS query packet.
+
+ The semantics of a Multicast DNS query packet containing multiple
+ questions is identical to a series of individual DNS query packets
+ containing one question each. Combining multiple questions into a
+ single packet is purely an efficiency optimization, and has no other
+ semantic significance.
+
+ A useful technique for adaptively combining multiple questions into a
+ single query is to use a Nagle-style algorithm: When a client issues
+ its first question, a Query packet is immediately built and sent,
+ without delay. If the client then continues issuing a rapid series of
+ questions they are held until either the first query receives at
+ least one answer, or 100ms has passed, or there are enough questions
+ to fill the question section of a Multicast DNS query packet. At this
+ time, all the held questions are placed into a Multicast DNS query
+ packet and sent.
+
+
+6.5 Questions Requesting Unicast Responses
+
+ Sending Multicast DNS responses via multicast has the benefit that
+ all the other hosts on the network get to see those responses, and
+ can keep their caches up to date, and detect conflicting responses.
+
+ However, there are situations where all the other hosts on the
+ network don't need to see every response. One example is a laptop
+ computer waking from sleep. At that instant it is a brand new
+ participant on a new network. Its Multicast DNS cache is empty, and
+ it has no knowledge of its surroundings. It may have a significant
+ number of queries that it wants answered right away to discover
+ information about its new surroundings and present that information
+ to the user. As a new participant on the network, it has no idea
+ whether the exact same questions may have been asked and answered
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 11]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ just seconds ago. In this case, trigging a large sudden flood of
+ multicast responses may impose an unreasonable burden on the network.
+ To avoid this, the Multicast DNS Querier SHOULD set the top bit in
+ the class field of its DNS question(s), to indicate that it is
+ willing to accept unicast responses instead of the usual multicast
+ responses. These questions requesting unicast responses are referred
+ to as "QU" questions, to distinguish them from the more usual
+ questions requesting multicast responses ("QM" questions).
+
+ When retransmitting a question more than once, the 'unicast response'
+ bit SHOULD be set only for the first question of the series. After
+ the first question has received its responses, the querier should
+ have a large known-answer list (see "Known Answer Suppression" below)
+ so that subsequent queries should elicit few, if any, further
+ responses. Reverting to multicast responses as soon as possible is
+ important because of the benefits that multicast responses provide
+ (see "Benefits of Multicast Responses" below).
+
+ When receiving a question with the 'unicast response' bit set, a
+ responder SHOULD usually respond with a unicast packet directed back
+ to the querier. If the responder has not multicast that record
+ recently (within one quarter of its TTL), then the responder SHOULD
+ instead multicast the response so as to keep all the peer caches up
+ to date, and to permit passive conflict detection.
+
+
+6.6 Suppressing Initial Query
+
+ If a query is issued for which there already exist one or more
+ records in the local cache, and those record(s) were received with
+ the cache flush bit set, indicating that they form a unique RRSet,
+ then the host SHOULD suppress its initial "QU" query, and proceed to
+ issue a "QM" query. To avoid the situation where a group of hosts
+ are synchronized by some external event and all perform the same
+ query simultaneously, a host suppressing its initial "QU" query
+ SHOULD impose a random delay from 500-1000ms before transmitting its
+ first "QM" query for this question. This means that when the first
+ host (selected randomly by this algorithm) transmits its "QM" query,
+ all the other hosts that were about to transmit the same query can
+ suppress their superfluous query, as described in "Duplicate
+ Question Suppression" below.
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 12]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+7. Duplicate Suppression
+
+ A variety of techniques are used to reduce the amount of redundant
+ traffic on the network.
+
+
+7.1 Known Answer Suppression
+
+ When a Multicast DNS Querier sends a query to which it already knows
+ some answers, it populates the Answer Section of the DNS message with
+ those answers.
+
+ A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if
+ the answer it would give is already included in the Answer Section
+ with an RR TTL at least half the correct value. If the RR TTL of the
+ answer as given in the Answer Section is less than half of the true
+ RR TTL as known by the Multicast DNS Responder, the responder MUST
+ send an answer so as to update the Querier's cache before the record
+ becomes in danger of expiration.
+
+ Because a Multicast DNS Responder will respond if the remaining TTL
+ given in the known answer list is less than half the true TTL, it is
+ superfluous for the Querier to include such records in the known
+ answer list. Therefore a Multicast DNS Querier SHOULD NOT include
+ records in the known answer list whose remaining TTL is less than
+ half their original TTL. Doing so would simply consume space in the
+ packet without achieving the goal of suppressing responses, and would
+ therefore be a pointless waste of network bandwidth.
+
+ A Multicast DNS Querier MUST NOT cache resource records observed in
+ the Known Answer Section of other Multicast DNS Queries. The Answer
+ Section of Multicast DNS Queries is not authoritative. By placing
+ information in the Answer Section of a Multicast DNS Query the
+ querier is stating that it *believes* the information to be true.
+ It is not asserting that the information *is* true. Some of those
+ records may have come from other hosts that are no longer on the
+ network. Propagating that stale information to other Multicast DNS
+ Queriers on the network would not be helpful.
+
+
+7.2 Multi-Packet Known Answer Suppression
+
+ Sometimes a Multicast DNS Querier will already have too many answers
+ to fit in the Known Answer section of its query packets. In this
+ case, it should issue a Multicast DNS Query containing a question and
+ as many Known Answer records as will fit. It should then set the TC
+ (Truncated) bit in the header before sending the Query. It should
+ then immediately follow the packet with another query containing no
+ questions, and as many more Known Answer records as will fit. If
+ there are still too many records remaining to fit in the packet, it
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 13]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ again sets the TC bit and continues until all the Known Answer
+ records have been sent.
+
+ A Multicast DNS Responder seeing a Multicast DNS Query with the TC
+ bit set defers its response for a time period randomly selected in
+ the interval 20-120ms. This gives the Multicast DNS Querier time to
+ send additional Known Answer packets before the Responder responds.
+ If the Responder sees any of its answers listed in the Known Answer
+ lists of subsequent packets from the querying host, it should delete
+ that answer from the list of answers it is planning to give, provided
+ that no other host on the network is also waiting to receive the same
+ answer record.
+
+
+7.3 Duplicate Question Suppression
+
+ If a host is planning to send a query, and it sees another host on
+ the network send a query containing the same question, and the Known
+ Answer section of that query does not contain any records which this
+ host would not also put in its own Known Answer section, then this
+ host should treat its own query as having been sent. When multiple
+ clients on the network are querying for the same resource records,
+ there is no need for them to all be repeatedly asking the same
+ question.
+
+
+7.4 Duplicate Answer Suppression
+
+ If a host is planning to send an answer, and it sees another host on
+ the network send a response packet containing the same answer record,
+ and the TTL in that record is not less than the TTL this host would
+ have given, then this host should treat its own answer as having been
+ sent. When multiple responders on the network have the same data,
+ there is no need for all of them to respond.
+
+ This feature is particularly useful when multiple Sleep Proxy Servers
+ are deployed (see Section 16. "Multicast DNS and Power Management").
+ In the future it is possible that every general-purpose OS (Mac,
+ Windows, Linux, etc.) will implement Sleep Proxy Service as a matter
+ of course. In this case there could be a large number of Sleep Proxy
+ Servers on any given network, which is good for reliability and
+ fault-tolerance, but would be bad for the network if every Sleep
+ Proxy Server were to answer every query.
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 14]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+8. Responding
+
+ A Multicast DNS Responder MUST only respond when it has a positive
+ non-null response to send. Error responses must never be sent. The
+ non-existence of any name in a Multicast DNS Domain is ascertained by
+ the failure of any machine to respond to the Multicast DNS query, not
+ by NXDOMAIN errors.
+
+ Multicast DNS Responses MUST NOT contain any questions in the
+ Question Section. Any questions in the Question Section of a received
+ Multicast DNS Response MUST be silently ignored. Multicast DNS
+ Queriers receiving Multicast DNS Responses do not care what question
+ elicited the response; they care only that the information in the
+ response is true and accurate.
+
+ A Multicast DNS Responder on Ethernet [IEEE802] and similar shared
+ multiple access networks SHOULD delay its responses by a random
+ amount of time selected with uniform random distribution in the range
+ 20-120ms. If multiple Multicast DNS Responders were all to respond
+ immediately to a particular query, a collision would be virtually
+ guaranteed. By imposing a small random delay, the number of
+ collisions is dramatically reduced. 120ms is a short enough time that
+ it is almost imperceptible to a human user, but long enough to
+ significantly reduce the risk of Ethernet collisions. On a full-sized
+ Ethernet using the maximum cable lengths allowed and the maximum
+ number of repeaters allowed, an Ethernet frame is vulnerable to
+ collisions during the transmission of its first 256 bits. On 10Mb/s
+ Ethernet, this equates to a vulnerable time window of 25.6us.
+
+ In the case where a Multicast DNS Responder has good reason to
+ believe that it will be the only responder on the link with a
+ positive non-null response, it SHOULD NOT impose the random delay
+ before responding, and SHOULD normally generate its response within
+ 10ms. To do this safely, it MUST have previously verified that the
+ requested name, type and class in the DNS query are unique on this
+ link. Responding immediately without delay is appropriate for things
+ like looking up the address record for a particular host name, when
+ the host name has been previously verified unique. Responding
+ immediately without delay is *not* appropriate for things like
+ looking up PTR records used for DNS Service Discovery [DNS-SD], where
+ a large number of responses may be anticipated.
+
+ Except when a unicast reply has been explicitly requested via the
+ "unicast reply" bit, Multicast DNS Responses MUST be sent to UDP port
+ 5353 (the well-known port assigned to mDNS) on the 224.0.0.251
+ multicast address (or its IPv6 equivalent FF02::FB). Operating in a
+ Zeroconf environment requires constant vigilance. Just because a name
+ has been previously verified unique does not mean it will continue to
+ be so indefinitely. By allowing all Multicast DNS Responders to
+ constantly monitor their peers' responses, conflicts arising out of
+ network topology changes can be promptly detected and resolved.
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 15]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ Sending all responses by multicast also facilitates opportunistic
+ caching by other hosts on the network.
+
+ To protect the network against excessive packet flooding due to
+ software bugs or malicious attack, a Multicast DNS Responder MUST NOT
+ multicast a given record on a given interface if it has previously
+ multicast that record on that interface within the last second. A
+ legitimate client on the network should have seen the previous
+ transmission and cached it. A client that did not receive and cache
+ the previous transmission will retry its request and receive a
+ subsequent response. Under no circumstances is there any legitimate
+ reason for a Multicast DNS Responder to multicast a given record more
+ than once per second on any given interface.
+
+
+8.1 Legacy Unicast Responses
+
+ If the source UDP port in a received Multicast DNS Query is not port
+ 5353, this indicates that the client originating the query is a
+ simple client that does not fully implement all of Multicast DNS. In
+ this case, the Multicast DNS Responder MUST send a UDP response
+ directly back to the client, via unicast, to the query packet's
+ source IP address and port. This unicast response MUST be a
+ conventional unicast response as would be generated by a conventional
+ unicast DNS server; for example, it must repeat the query ID and the
+ question given in the query packet.
+
+ The resource record TTL given in a unicast response SHOULD NOT be
+ greater than ten seconds, even if the true TTL of the Multicast DNS
+ resource record is higher. This is because Multicast DNS Responders
+ that fully participate in the protocol use the cache coherency
+ mechanisms described in Section 13 to update and invalidate stale
+ data. Were unicast responses sent to legacy clients to use the same
+ high TTLs, these legacy clients, which do not implement these cache
+ coherency mechanisms, could retain stale cached resource record data
+ long after it is no longer valid.
+
+ Having sent this unicast response, if the Responder has not sent this
+ record in any multicast response recently, it SHOULD schedule the
+ record to be sent via multicast as well, to facilitate passive
+ conflict detection. "Recently" in this context means "if the time
+ since the record was last sent via multicast is less than one quarter
+ of the record's TTL".
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 16]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+8.2 Multi-Question Queries
+
+ Multicast DNS Responders MUST correctly handle DNS query packets
+ containing more than one question, by answering any or all of the
+ questions to which they have answers. Any answers generated
+ in response to query packets containing more than one question
+ MUST be randomly delayed in the range 20-120ms, as described above.
+
+
+8.3 Response Aggregation
+
+ Having delayed one or more multicast responses by 20-120ms as
+ described above in Section 8 "Responding", a Multicast DNS Responder
+ SHOULD, for the sake of network efficiency, aggregate as many of its
+ pending responses as possible into a single Multicast DNS response
+ packet.
+
+
+9. Probing and Announcing on Startup
+
+ Typically a Multicast DNS Responder should have, at the very least,
+ address records for all of its active interfaces. Creating and
+ advertising an HINFO record on each interface as well can be useful
+ to network administrators.
+
+ Whenever a Multicast DNS Responder starts up, wakes up from sleep,
+ receives an indication of an Ethernet "Link Change" event, or has any
+ other reason to believe that its network connectivity may have
+ changed in some relevant way, it MUST perform the two startup steps
+ below.
+
+
+9.1 Probing
+
+ The first startup step is that for all those resource records that a
+ Multicast DNS Responder desires to be unique on the local link, it
+ MUST send a Multicast DNS Query asking for those resource records, to
+ see if any of them are already in use. The primary example of this is
+ its address record which maps its unique host name to its unique IP
+ address. All Probe Queries SHOULD be done using the desired resource
+ record name and query type T_ANY (255), to elicit answers for all
+ types of records with that name. This allows a single question to be
+ used in place of several questions, which is more efficient on the
+ network. It also allows a host to verify exclusive ownership of a
+ name, which is desirable in most cases. It would be confusing, for
+ example, if one host owned the "A" record for "myhost.local.", but a
+ different host owned the HINFO record for that name.
+
+ The ability to place more than one question in a Multicast DNS Query
+ is useful here, because it can allow a host to use a single packet
+ for all of its resource records instead of needing a separate packet
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 17]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ for each. For example, a host can simultaneously probe for uniqueness
+ of its "A" record and all its SRV records [DNS-SD] in the same query
+ packet.
+
+ When ready to send its mDNS probe packet(s) the host should first
+ wait for a short random delay time, uniformly distributed in the
+ range 0-250ms. This random delay is to guard against the case where a
+ group of devices are powered on simultaneously, or a group of devices
+ are connected to an Ethernet hub which is then powered on, or some
+ other external event happens that might cause a group of hosts to all
+ send synchronized probes.
+
+ 250ms after the first query the host should send a second, then
+ 250ms after that a third. If, by 250ms after the third probe, no
+ conflicting Multicast DNS responses have been received, the host may
+ move to the next step, announcing.
+
+ If any conflicting Multicast DNS responses are received, then the
+ probing host MUST defer to the existing host, and must choose new
+ names for some or all of its resource records as appropriate, to
+ avoid conflict with pre-existing hosts on the network. In the case
+ of a host probing using query type T_ANY as recommended above, any
+ answer containing a record with that name, of any type, MUST be
+ considered a conflicting response and handled accordingly.
+
+ If ten failures occur within any ten-second period, then the host
+ MUST wait at least five seconds before each successive additional
+ probe attempt. This is to help ensure that in the event of software
+ bugs or other unanticipated problems, errant hosts do not flood the
+ network with a continuous stream of multicast traffic. For very
+ simple devices, a valid way to comply with this requirement is to
+ always wait five seconds after any failed probe attempt.
+
+
+9.2 Simultaneous Probe Tie-Breaking
+
+ The astute reader will observe that there is a race condition
+ inherent in the previous description. If two hosts are probing for
+ the same name simultaneously, neither will receive any response to
+ the probe, and the hosts could incorrectly conclude that they may
+ both proceed to use the name. To break this symmetry, each host
+ populates the Authority Section of its queries with records giving
+ the rdata that it would be proposing to use, should its probing be
+ successful. The Authority Section is being used here in a way
+ analogous to the Update section of a DNS Update packet [RFC 2136].
+
+ When a host that is probing for a record sees another host issue a
+ query for the same record, it consults the Authority Section of that
+ query. If it finds any resource record there which answers the query,
+ then it compares the data of that resource record with its own
+ tentative data. The lexicographically later data wins. This means
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 18]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ that if the host finds that its own data is lexicographically later,
+ it simply ignores the other host's probe. If the host finds that its
+ own data is lexicographically earlier, then it treats this exactly
+ as if it had received a positive answer to its query, and concludes
+ that it may not use the desired name.
+
+ The determination of 'lexicographically later' is performed by first
+ comparing the record class, then the record type, then raw comparison
+ of the binary content of the rdata without regard for meaning or
+ structure. If the record classes differ, then the numerically greater
+ class is considered 'lexicographically later'. Otherwise, if the
+ record types differ, then the numerically greater type is considered
+ 'lexicographically later'. If the type and class both match then the
+ rdata is compared.
+
+ In the case of resource records containing rdata that is subject to
+ name compression, the names must be uncompressed before comparison.
+ (The details of how a particular name is compressed is an artifact of
+ how and where the record is written into the DNS message; it is not
+ an intrinsic property of the resource record itself.)
+
+ The bytes of the raw uncompressed rdata are compared in turn,
+ interpreting the bytes as eight-bit UNSIGNED values, until a byte
+ is found whose value is greater than that of its counterpart (in
+ which case the rdata whose byte has the greater value is deemed
+ lexicographically later) or one of the resource records runs out
+ of rdata (in which case the resource record which still has
+ remaining data first is deemed lexicographically later).
+
+ The following is an example of a conflict:
+
+ sctibook.local. A 196.254.100.200
+ sctibook.local. A 196.254.200.100
+
+ In this case 196.254.200.100 is lexicographically later, so it is
+ deemed the winner.
+
+ Note that it is vital that the bytes are interpreted as UNSIGNED
+ values, or the wrong outcome may result. In the example above, if
+ the byte with value 200 had been incorrectly interpreted as a
+ signed value then it would be interpreted as value -56, and the
+ wrong address record would be deemed the winner.
+
+
+9.3 Announcing
+
+ The second startup step is that the Multicast DNS Responder MUST send
+ a gratuitous Multicast DNS Response containing, in the Answer
+ Section, all of its resource records. If there are too many resource
+ records to fit in a single packet, multiple packets should be used.
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 19]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ In the case of shared records (e.g. the PTR records used by DNS
+ Service Discovery [DNS-SD]), the records are simply placed as-is
+ into the answer section of the DNS Response.
+
+ In the case of records that have been verified to be unique in the
+ previous step, they are placed into the answer section of the DNS
+ Response with the most significant bit of the rrclass set to one. The
+ most significant bit of the rrclass is the mDNS "cache flush" bit and
+ is discussed in more detail below in Section 13.3 "Announcements to
+ Flush Outdated Cache Entries".
+
+ The Multicast DNS Responder MUST send at least two gratuitous
+ responses, one second apart. A Responder MAY send up to ten
+ gratuitous Responses, providing that the interval between gratuitous
+ responses doubles with every response sent.
+
+ A Multicast DNS Responder SHOULD NOT continue sending gratuitous
+ Responses for longer than the TTL of the record. The purpose of
+ announcing new records via gratuitous Responses is to ensure that
+ peer caches are up to date. After a time interval equal to the TTL of
+ the record has passed, it is very likely that old stale copies of
+ that record in peer caches will have expired naturally, so subsequent
+ announcements serve little purpose.
+
+ Whenever a Multicast DNS Responder receives any Multicast DNS
+ response (gratuitous or otherwise) containing a conflicting resource
+ record, the conflict MUST be resolved as described below in "Conflict
+ Resolution".
+
+ A Multicast DNS Responder MUST NOT send announcements in the absence
+ of information that its network connectivity may have changed in some
+ relevant way. In particular, a Multicast DNS Responder MUST NOT send
+ regular periodic announcements as a matter of course.
+
+
+9.4 Updating
+
+ At any time, if the rdata of any of a host's Multicast DNS records
+ changes, the host MUST repeat the Announcing step described above to
+ update neighbouring caches. For example, if any of a host's IP
+ addresses change, it must re-announce those address records.
+
+ A host may update the contents of any of its records at any time,
+ though a host SHOULD NOT update records more frequently than ten
+ times per minute. Frequent rapid updates impose a burden on the
+ network. If a host has information to disseminate which changes more
+ frequently than ten times per minute, then Multicast DNS may not be
+ the appropriate protocol to disseminate that information.
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 20]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+10. Conflict Resolution
+
+ A conflict occurs when two resource records with the same name, type
+ and class have inconsistent rdata. What may be considered
+ inconsistent is context sensitive, except that resource records with
+ identical rdata are never considered inconsistent, even if they
+ originate from different hosts. A common example of a resource record
+ type that is intended to be unique, not shared between hosts, is the
+ address record that maps a host's name to its IP address. Should a
+ host witness another host announce an address record with the same
+ name but a different IP address, then that is considered
+ inconsistent, and that address record is considered to be in
+ conflict.
+
+ Whenever a Multicast DNS Responder receives any Multicast DNS
+ response (gratuitous or otherwise) containing a conflicting resource
+ record, the Multicast DNS Responder MUST immediately reset that
+ record to probing state, and go through the startup steps described
+ above in Section 9. "Probing and Announcing on Startup". The
+ protocol used in the Probing phase will determine a winner and a
+ loser, and the loser must cease using the name, and reconfigure.
+
+ It is very important that any host that observes an apparent conflict
+ MUST take action. In the case of two hosts using the same host name,
+ where one has been configured to require a unique host name and the
+ other has not, the one that has not been configured to require a
+ unique host name will not perceive any conflict, and will not take
+ any action. By reverting to Probing state, the host that desires a
+ unique host name will go through the necessary steps to ensure that a
+ unique host is obtained.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 21]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ The recommended course of action after probing and failing is as
+ follows:
+
+ o Programmatically change the resource record name in an attempt to
+ find a new name that is unique. This could be done by adding some
+ further identifying information (e.g. the model name of the
+ hardware) if it is not already present in the name, appending the
+ digit "2" to the name, or incrementing a number at the end of the
+ name if one is already present.
+
+ o Probe again, and repeat until a unique name is found.
+
+ o Record this newly chosen name in persistent storage so that the
+ device will use the same name the next time it is power-cycled.
+
+ o Display a message to the user or operator informing them of the
+ name change. For example:
+
+ The name "Bob's Music" is in use by another iTunes music
+ server on the network. Your music has been renamed to
+ "Bob's Music (G4 Cube)". If you want to change this name,
+ use [describe appropriate menu item or preference dialog].
+
+ How the user or operator is informed depends on context. A desktop
+ computer with a screen might put up a dialog box. A headless server
+ in the closet may write a message to a log file, or use whatever
+ mechanism (email, SNMP trap, etc.) it uses to inform the
+ administrator of other error conditions. On the other hand a headless
+ server in the closet may not inform the user at all -- if the user
+ cares, they will notice the name has changed, and connect to the
+ server in the usual way (e.g. via Web Browser) to configure a new
+ name.
+
+ The examples in this section focus on address records (i.e. host
+ names), but the same considerations apply to all resource records
+ where uniqueness (or maintenance of some other defined constraint) is
+ desired.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 22]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+11. Special Characteristics of Multicast DNS Domains
+
+ Unlike conventional DNS names, names that end in ".local.",
+ "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local
+ significance. Conventional DNS seeks to provide a single unified
+ namespace, where a given DNS query yields the same answer no matter
+ where on the planet it is performed or to which recursive DNS server
+ the query is sent. (However, split views, firewalls, intranets and
+ the like have somewhat interfered with this goal of DNS representing
+ a single universal truth.) In contrast, each IP link has its own
+ private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa."
+ namespaces, and the answer to any query for a name within those
+ domains depends on where that query is asked.
+
+ Multicast DNS Domains are not delegated from their parent domain via
+ use of NS records. There are no NS records anywhere in Multicast DNS
+ Domains. Instead, all Multicast DNS Domains are delegated to the IP
+ addresses 224.0.0.251 and FF02::FB by virtue of the individual
+ organizations producing DNS client software deciding how to handle
+ those names. It would be extremely valuable for the industry if this
+ special handling were ratified and recorded by IANA, since otherwise
+ the special handling provided by each vendor is likely to be
+ inconsistent.
+
+ The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The
+ IPv6 name server for a Multicast DNS Domain is FF02::FB. These are
+ multicast addresses; therefore they identify not a single host but a
+ collection of hosts, working in cooperation to maintain some
+ reasonable facsimile of a competently managed DNS zone. Conceptually
+ a Multicast DNS Domain is a single DNS zone, however its server is
+ implemented as a distributed process running on a cluster of loosely
+ cooperating CPUs rather than as a single process running on a single
+ CPU.
+
+ No delegation is performed within Multicast DNS Domains. Because the
+ cluster of loosely coordinated CPUs is cooperating to administer a
+ single zone, delegation is neither necessary nor desirable. Just
+ because a particular host on the network may answer queries for a
+ particular record type with the name "example.local." does not imply
+ anything about whether that host will answer for the name
+ "child.example.local.", or indeed for other record types with the
+ name "example.local."
+
+ Multicast DNS Zones have no SOA record. A conventional DNS zone's
+ SOA record contains information such as the email address of the zone
+ administrator and the monotonically increasing serial number of the
+ last zone modification. There is no single human administrator for
+ any given Multicast DNS Zone, so there is no email address. Because
+ the hosts managing any given Multicast DNS Zone are only loosely
+ coordinated, there is no readily available monotonically increasing
+ serial number to determine whether or not the zone contents have
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 23]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ changed. A host holding part of the shared zone could crash or be
+ disconnected from the network at any time without informing the other
+ hosts. There is no reliable way to provide a zone serial number that
+ would, whenever such a crash or disconnection occurred, immediately
+ change to indicate that the contents of the shared zone had changed.
+
+ Zone transfers are not possible for any Multicast DNS Zone.
+
+
+12. Multicast DNS for Service Discovery
+
+ This document does not describe using Multicast DNS for network
+ browsing or service discovery. However, the mechanisms this document
+ describes are compatible with (and support) the browsing and service
+ discovery mechanisms proposed in "DNS-Based Service Discovery"
+ [DNS-SD].
+
+ This document places few limitations on what DNS record types may be
+ looked up using local multicast. One particular kind of Multicast DNS
+ query that might be useful is a query for the SRV record named
+ "_domain._udp.local.", yielding the port number and IP address of a
+ conventional DNS server willing to perform general recursive DNS
+ lookups. This could solve a particular problem facing the IPv6
+ community, which is that IPv6 is able to self-configure almost all of
+ the information it needs to operate [RFC 2462], except for the
+ address of the DNS server. Bringing in all of the mechanisms of DHCP
+ just for that one little additional piece of information is not an
+ attractive solution. Using DNS-format messages and DNS-format
+ resource records to find the address of the DNS server has an elegant
+ self-sufficiency about it. Any host that needs to know the address of
+ the DNS server must already have code to generate and parse DNS
+ packets, so using that same code and those same packets to find the
+ DNS server in the first place is a simple self-reliant solution that
+ avoids taking external dependencies on other protocols.
+
+
+13. Resource Record TTL Values and Cache Coherency
+
+ The recommended TTL value for Multicast DNS resource records is
+ 120 minutes.
+
+ A client with an active outstanding query will issue a query packet
+ when one or more of the resource record(s) in its cache is (are) 80%
+ of the way to expiry. If the TTL on those records is 120 minutes,
+ this ongoing cache maintenance process yields a steady-state query
+ rate of one query every 96 minutes.
+
+ Any distributed cache needs a cache coherency protocol. If Multicast
+ DNS resource records follow the recommendation and have a TTL of 120
+ minutes, that means that stale data could persist in the system for
+ up to two hours. Making the default TTL significantly lower would
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 24]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ reduce the lifetime of stale data, but would produce too much extra
+ traffic on the network. Various techniques are available to minimize
+ the impact of such stale data.
+
+
+13.1 Cooperating Multicast DNS Responders
+
+ If a Multicast DNS Responder ("A") observes some other Multicast DNS
+ Responder ("B") send a Multicast DNS Response packet containing a
+ resource record with the same name type and class as one of A's
+ resource records, but different rdata, then:
+
+ o If A's resource record is intended to be a shared resource record,
+ then this is no conflict, and no action is required.
+
+ o If A's resource record is intended to be a unique resource record
+ then this is a conflict and MUST be handled as described in Section
+ 10 "Conflict Resolution".
+
+ If a Multicast DNS Responder ("A") observes some other Multicast DNS
+ Responder ("B") send a Multicast DNS Response packet containing a
+ resource record with the same name type and class as one of A's
+ resource records, and identical rdata, then:
+
+ o If the TTL of B's resource record given in the packet is at least
+ half the true TTL from A's point of view, then no action is
+ required.
+
+ o If the TTL of B's resource record given in the packet is less than
+ half the true TTL from A's point of view, then A MUST mark its
+ record to be announced via multicast. Clients receiving the record
+ from B would use the TTL given by B, and hence may delete the
+ record sooner than A expects. By sending its own multicast response
+ correcting the TTL, A ensures that the record will be retained for
+ the desired time.
+
+ These rules allow multiple Multicast DNS Responders to offer the same
+ data on the network (perhaps for fault tolerance reasons) without
+ conflicting with each other.
+
+
+13.2 Goodbye Packets
+
+ In the case where a host knows that certain resource record data is
+ about to become invalid (for example when the host is undergoing a
+ clean shutdown) the host SHOULD send a gratuitous announcement mDNS
+ response packet, giving the same resource record name, type, class
+ and rdata, but an RR TTL of zero. This has the effect of updating the
+ TTL stored in neighbouring hosts' cache entries to zero, causing that
+ cache entry to be promptly deleted.
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 25]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ Clients receiving a Multicast DNS Response with a TTL of zero SHOULD
+ NOT immediately delete the record from the cache, but instead record
+ a TTL of 1 and then delete the record one second later. In the case
+ of multiple Multicast DNS Responders on the network described in
+ Section 13.1 above, if one of the Responders shuts down and
+ incorrectly sends goodbye packets for its records, it gives the other
+ cooperating Responders one second to send out their own response to
+ "rescue" the records before they expire and are deleted.
+
+ Generally speaking, it is more important to send goodbye packets for
+ shared records than unique records. A given shared record name (such
+ as a PTR record used for DNS Service Discovery [DNS-SD]) by its
+ nature often has many representatives from many different hosts, and
+ tends to be the subject of long-lived ongoing queries. Those
+ long-lived queries are often concerned not just about being informed
+ when records appear, but also about being informed if those records
+ vanish again. In contrast, a unique record set (such as an SRV
+ record, or a host address record), by its nature, often has far fewer
+ members than a shared record set, and is usually the subject of
+ one-shot queries which simply retrieve the data and then cease
+ querying once they have the answer they are seeking. Therefore,
+ sending a goodbye packet for a unique record set is likely to offer
+ less benefit, because it is likely at any given moment that no one
+ has an active query running for that record set. One example where
+ goodbye packets for SRV and address records are useful is when
+ transferring control to a Sleep Proxy Server (see Section 16.
+ "Multicast DNS and Power Management").
+
+
+13.3 Announcements to Flush Outdated Cache Entries
+
+ Whenever a host has a resource record with potentially new data (e.g.
+ after rebooting, waking from sleep, connecting to a new network link,
+ changing IP address, etc.), the host MUST send a series of gratuitous
+ announcements to update cache entries in its neighbour hosts. In
+ these gratuitous announcements, if the record is one that is intended
+ to be unique, the host sets the most significant bit of the rrclass
+ field of the resource record. This bit, the "cache flush" bit, tells
+ neighbouring hosts that this is not a shared record type. Instead of
+ merging this new record additively into the cache in addition to any
+ previous records with the same name, type and class, all old records
+ with that name, type and class that were received more than one
+ second ago are declared invalid, and marked to expire from the cache
+ in one second.
+
+ The semantics of the cache flush bit are as follows: Normally when a
+ resource record appears in the answer section of the DNS Response, it
+ means, "This is an assertion that this information is true." When a
+ resource record appears in the answer section of the DNS Response
+ with the "cache flush" bit set, it means, "This is an assertion that
+ this information is the truth and the whole truth, and anything you
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 26]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ may have heard more than a second ago regarding records of this
+ name/type/class is no longer valid".
+
+ To accommodate the case where the set of records from one host
+ constituting a single unique RRSet is too large to fit in a single
+ packet, only cache records that are more than one second old are
+ flushed. This allows the announcing host to generate a quick burst of
+ packets back-to-back on the wire containing all the members
+ of the RRSet. When receiving records with the "cache flush" bit set,
+ all records older than one second are marked to be deleted one second
+ in the future. One second after the end of the little packet burst,
+ any records not represented within that packet burst will then be
+ expired from all peer caches.
+
+ Any time a host sends a response packet containing some members of a
+ unique RRSet, it SHOULD send the entire RRSet, preferably in a single
+ packet, or if the entire RRSet will not fit in a single packet, in a
+ quick burst of packets sent as close together as possible. The host
+ SHOULD set the cache flush bit on all members of the unique RRSet.
+ In the event that for some reason the host chooses not to send the
+ entire unique RRSet in a single packet or a rapid packet burst,
+ it MUST NOT set the cache flush bit on any of those records.
+
+ The reason for waiting one second before deleting stale records from
+ the cache is to accommodate bridged networks. For example, a host's
+ address record announcement on a wireless interface may be bridged
+ onto a wired Ethernet, and cause that same host's Ethernet address
+ records to be flushed from peer caches. The one-second delay gives
+ the host the chance to see its own announcement arrive on the wired
+ Ethernet, and immediately re-announce its Ethernet address records
+ so that both sets remain valid and live in peer caches.
+
+ These rules apply regardless of *why* the response packet is being
+ generated. They apply to startup announcements as described in
+ Section 9.3, and to responses generated as a result of receiving
+ query packets.
+
+ The "cache flush" bit is only set in Multicast DNS responses sent to
+ UDP port 5353. The "cache flush" bit MUST NOT be set in any resource
+ records in a response packet sent in legacy unicast responses to UDP
+ ports other than 5353.
+
+ The "cache flush" bit MUST NOT be set in any resource records in the
+ known-answer list of any query packet.
+
+ The "cache flush" bit MUST NOT ever be set in any shared resource
+ record. To do so would cause all the other shared versions of this
+ resource record with different rdata from different Responders to be
+ immediately deleted from all the caches on the network.
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 27]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ Note that the "cache flush" bit is NOT part of the resource record
+ class. The "cache flush" bit is the most significant bit of the
+ second 16-bit word of a resource record in an mDNS packet (the field
+ conventionally referred to as the rrclass field), and the actual
+ resource record class is the least-significant fifteen bits of this
+ field. There is no mDNS resource record class 0x8001. The value
+ 0x8001 in the rrclass field of a resource record in an mDNS response
+ packet indicates a resource record with class 1, with the "cache
+ flush" bit set. When receiving a resource record with the "cache
+ flush" bit set, implementations should take care to mask off that bit
+ before storing the resource record in memory.
+
+
+13.4 Cache Flush on Topology change
+
+ If the hardware on a given host is able to indicate physical changes
+ of connectivity, then when the hardware indicates such a change, the
+ host should take this information into account in its mDNS cache
+ management strategy. For example, a host may choose to immediately
+ flush all cache records received on a particular interface when that
+ cable is disconnected. Alternatively, a host may choose to adjust the
+ remaining TTL on all those records to a few seconds so that if the
+ cable is not reconnected quickly, those records will expire from the
+ cache.
+
+ Likewise, when a host reboots, or wakes from sleep, or undergoes some
+ other similar discontinuous state change, the cache management
+ strategy should take that information into account.
+
+
+13.5 Cache Flush on Failure Indication
+
+ Sometimes a cache record can be determined to be stale when a client
+ attempts to use the rdata it contains, and finds that rdata to be
+ incorrect.
+
+ For example, the rdata in an address record can be determined to be
+ incorrect if attempts to contact that host fail, either because
+ ARP/ND requests for that address go unanswered (for an address on a
+ local subnet) or because a router returns an ICMP "Host Unreachable"
+ error (for an address on a remote subnet).
+
+ The rdata in an SRV record can be determined to be incorrect if
+ attempts to communicate with the indicated service at the host and
+ port number indicated are not successful.
+
+ The rdata in a DNS-SD PTR record can be determined to be incorrect if
+ attempts to look up the SRV record it references are not successful.
+
+ In any such case, the software implementing the mDNS resource record
+ cache should provide a mechanism so that clients detecting stale
+ rdata can inform the cache.
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 28]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ When the cache receives this hint that it should reconfirm some
+ record, it MUST issue two or more queries for the resource record in
+ question. If no response is received in a reasonable amount of time,
+ then, even though its TTL may indicate that it is not yet due to
+ expire, that record SHOULD be promptly flushed from the cache.
+
+ The end result of this is that if a printer suffers a sudden power
+ failure or other abrupt disconnection from the network, its name may
+ continue to appear in DNS-SD browser lists displayed on users'
+ screens. Eventually that entry will expire from the cache naturally,
+ but if a user tries to access the printer before that happens, the
+ failure to successfully contact the printer will trigger the more
+ hasty demise of its cache entries. This is a sensible trade-off
+ between good user-experience and good network efficiency. If we were
+ to insist that printers should disappear from the printer list within
+ 30 seconds of becoming unavailable, for all failure modes, the only
+ way to achieve this would be for the client to poll the printer at
+ least every 30 seconds, or for the printer to announce its presence
+ at least every 30 seconds, both of which would be an unreasonable
+ burden on most networks.
+
+
+13.6 Passive Observation of Failures
+
+ A host observes the multicast queries issued by the other hosts on
+ the network. One of the major benefits of also sending responses
+ using multicast is that it allows all hosts to see the responses (or
+ lack thereof) to those queries.
+
+ If a host sees queries, for which a record in its cache would be
+ expected to be given as an answer in a multicast response, but no
+ such answer is seen, then the host may take this as an indication
+ that the record may no longer be valid.
+
+ After seeing two or more of these queries, and seeing no multicast
+ response containing the expected answer within a reasonable amount of
+ time, then even though its TTL may indicate that it is not yet due to
+ expire, that record MAY be flushed from the cache. The host SHOULD
+ NOT perform its own queries to re-confirm that the record is truly
+ gone. If every host on a large network were to do this, it would
+ cause a lot of unnecessary multicast traffic. If host A sends
+ multicast queries that remain unanswered, then there is no reason to
+ suppose that host B or any other host is likely to be any more
+ successful.
+
+ The previous section, "Cache Flush on Failure Indication", describes
+ a situation where a user trying to print discovers that the printer
+ is no longer available. By implementing the passive observation
+ described here, when one user fails to contact the printer, all hosts
+ on the network observe that failure and update their caches
+ accordingly.
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 29]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+14. Enabling and Disabling Multicast DNS
+
+ The option to fail-over to Multicast DNS for names not ending in
+ ".local." SHOULD be a user-configured option, and SHOULD
+ be disabled by default because of the possible security issues
+ related to unintended local resolution of apparently global names.
+
+ The option to lookup unqualified (relative) names by appending
+ ".local." (or not) is controlled by whether ".local." appears
+ (or not) in the client's DNS search list.
+
+ No special control is needed for enabling and disabling Multicast DNS
+ for names explicitly ending with ".local." as entered by the user.
+ The user doesn't need a way to disable Multicast DNS for names ending
+ with ".local.", because if the user doesn't want to use Multicast
+ DNS, they can achieve this by simply not using those names. If a user
+ *does* enter a name ending in ".local.", then we can safely assume
+ the user's intention was probably that it should work. Having user
+ configuration options that can be (intentionally or unintentionally)
+ set so that local names don't work is just one more way of
+ frustrating the user's ability to perform the tasks they want,
+ perpetuating the view that, "IP networking is too complicated to
+ configure and too hard to use." This in turn perpetuates the
+ continued use of protocols like AppleTalk. If we want to retire
+ AppleTalk, NetBIOS, etc., we need to offer users equivalent IP
+ functionality that they can rely on to, "always work, like
+ AppleTalk." A little Multicast DNS traffic may be a burden on the
+ network, but it is an insignificant burden compared to continued
+ widespread use of AppleTalk.
+
+
+15. Considerations for Multiple Interfaces
+
+ A host should defend its host name (FQDN) on all active interfaces on
+ which it is answering Multicast DNS queries.
+
+ In the event of a name conflict on *any* interface, a host should
+ configure a new host name, if it wishes to maintain uniqueness of its
+ host name.
+
+ When answering a Multicast DNS query, a multi-homed host with a
+ link-local address (or addresses) should take care to ensure that
+ any address going out in a Multicast DNS response is valid for use
+ on the interface on which the response is going out.
+
+ Just as the same link-local IP address may validly be in use
+ simultaneously on different links by different hosts, the same
+ link-local host name may validly be in use simultaneously on
+ different links, and this is not an error. A multi-homed host with
+ connections to two different links may be able to communicate with
+ two different hosts that are validly using the same name. While this
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 30]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ kind of name duplication should be rare, it means that a host that
+ wants to fully support this case needs network programming APIs that
+ allow applications to specify on what interface to perform a
+ link-local Multicast DNS query, and to discover on what interface a
+ Multicast DNS response was received.
+
+
+16. Multicast DNS and Power Management
+
+ Many modern network devices have the ability to go into a low-power
+ mode where only a small part of the Ethernet hardware remains
+ powered, and the device can be woken up by sending a specially
+ formatted Ethernet frame which the device's power-management hardware
+ recognizes.
+
+ To make use of this in conjunction with Multicast DNS, the device
+ first uses DNS-SD to determine if Sleep Proxy Service is available on
+ the local network. In some networks there may be more than one piece
+ of hardware implementing Sleep Proxy Service, for fault-tolerance
+ reasons.
+
+ If the device finds the network has Sleep Proxy Service, the device
+ transmits two or more gratuitous mDNS announcements setting the TTL
+ of its relevant resource records to zero, to delete them from
+ neighbouring caches. The relevant resource records include address
+ records and SRV records, and other resource records as may apply to a
+ particular device. The device then communicates all of its remaining
+ active records, plus the names, types and classes of the deleted
+ records, to the Sleep Proxy Service(s), along with a copy of the
+ specific "magic packet" required to wake the device up.
+
+ When a Sleep Proxy Service sees an mDNS query for one of the
+ device's active records (e.g. a DNS-SD PTR record), it answers on
+ behalf of the device without waking it up. When a Sleep Proxy Service
+ sees an mDNS query for one of the device's deleted resource
+ records, it deduces that some client on the network needs to make an
+ active connection to the device, and sends the specified "magic
+ packet" to wake the device up. The device then wakes up, reactivates
+ its deleted resource records, and re-announces them to the network.
+ The client waiting to connect sees the announcements, learns the
+ current IP address and port number of the desired service on the
+ device, and proceeds to connect to it.
+
+ The connecting client does not need to be aware of how Sleep Proxy
+ Service works. Only devices that implement low power mode and wish to
+ make use of Sleep Proxy Service need to be aware of how that protocol
+ works.
+
+ The reason that a device using a Sleep Proxy Service should send more
+ than one goodbye packet is that the wakeup message is caused by the
+ Sleep Proxy Service seeing queries for the device's SRV and/or
+ address records, and those queries are in turn caused by the records
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 31]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ being absent from peer caches. If the records are not deleted from
+ peer caches, then those peers may use the cached value directly
+ without querying, and no wakeup message would be generated.
+
+ The full specification of mDNS / DNS-SD Sleep Proxy Service
+ is described in another document [not yet published].
+
+
+17. Multicast DNS Character Set
+
+ Unicast DNS has been plagued by the lack of any support for non-US
+ characters. Indeed, conventional DNS is usually limited to just
+ letters, digits and hyphens, with no spaces or other punctuation.
+ Attempts to remedy this have made slow progress because of the need
+ to accommodate old buggy legacy implementations.
+
+ Multicast DNS is a new protocol and doesn't (yet) have old buggy
+ legacy implementations to constrain the design choices. Accordingly,
+ it adopts the obvious simple solution: all names in Multicast DNS are
+ encoded using UTF-8 [RFC 2279]. For names that are restricted to
+ letters, digits and hyphens, the UTF-8 encoding is identical to the
+ US-ASCII encoding, so this is entirely compatible with existing host
+ names. For characters outside the US-ASCII range, UTF-8 encoding is
+ used.
+
+ Multicast DNS implementations MUST NOT use any other encodings apart
+ from UTF-8 (US-ASCII being considered a compatible subset of UTF-8).
+
+ This point bears repeating: There are various baroque representations
+ of international text being proposed for Unicast DNS. None of these
+ representations may be used in Multicast DNS packets. Any text being
+ represented internally in some other representation MUST be converted
+ to canonical UTF-8 before being placed in any Multicast DNS packet.
+
+ The simple rules for case-insensitivity in Unicast DNS also apply in
+ Multicast DNS; that is to say, in name comparisons, the lower-case
+ letters "a" to "z" match their upper-case equivalents "A" to "Z".
+ Hence, if a client issues a query for an address record with the name
+ "stuartcheshire.local", then a responder having an address record
+ with the name "StuartCheshire.local" should issue a response.
+
+ No other automatic character equivalence is defined in Multicast DNS.
+ For example, accented characters are not defined to be automatically
+ equivalent to their unaccented counterparts. Where automatic
+ equivalences are desired, this may be achieved through the use of
+ programmatically-generated CNAME records. For example, if a responder
+ has an address record for an accented name Y, and a client issues a
+ query for a name X, where X is the same as Y with all the accents
+ removed, then the responder may issue a response containing two
+ resource records: A CNAME record "X CNAME Y", asserting that the
+ requested name X (unaccented) is an alias for the true (accented)
+ name Y, followed by the address record for Y.
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 32]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+18. Multicast DNS Message Size
+
+ RFC 1035 restricts DNS Messages carried by UDP to no more than 512
+ bytes (not counting the IP or UDP headers). For UDP packets carried
+ over the wide-area Internet in 1987, this was appropriate. For
+ link-local multicast packets on today's networks, there is no reason
+ to retain this restriction. Given that the packets are by definition
+ link-local, there are no Path MTU issues to consider.
+
+ Multicast DNS Messages carried by UDP may be up to the IP MTU of the
+ physical interface, less the space required for the IP header (20
+ bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).
+
+ In the case of a single mDNS Resource Record which is too large to
+ fit in a single MTU-sized multicast response packet, a Multicast DNS
+ Responder SHOULD send the Resource Record alone, in a single IP
+ datagram, sent using multiple IP fragments. Resource Records this
+ large SHOULD be avoided, except in the very rare cases where they
+ really are the appropriate solution to the problem at hand.
+ Implementers should be aware that many simple devices do not
+ re-assemble fragmented IP datagrams, so large Resource Records SHOULD
+ only be used in specialized cases where the implementer knows that
+ all receivers implement reassembly.
+
+ A Multicast DNS packet larger than the interface MTU, which is sent
+ using fragments, MUST NOT contain more than one Resource Record.
+
+ Even when fragmentation is used, a Multicast DNS packet, including IP
+ and UDP headers, MUST NOT exceed 9000 bytes.
+
+
+19. Multicast DNS Message Format
+
+ This section describes specific restrictions on the allowable
+ values for the header fields of a Multicast DNS message.
+
+19.1. ID (Query Identifier)
+
+ Multicast DNS clients SHOULD listen for gratuitous responses
+ issued by hosts booting up (or waking up from sleep or otherwise
+ joining the network). Since these gratuitous responses may contain a
+ useful answer to a question for which the client is currently
+ awaiting an answer, Multicast DNS clients SHOULD examine all received
+ Multicast DNS response messages for useful answers, without regard to
+ the contents of the ID field or the question section. In Multicast
+ DNS, knowing which particular query message (if any) is responsible
+ for eliciting a particular response message is less interesting than
+ knowing whether the response message contains useful information.
+
+ Multicast DNS clients MAY cache any or all Multicast DNS response
+ messages they receive, for possible future use, providing of course
+ that normal TTL aging is performed on these cashed resource records.
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 33]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+ In multicast query messages, the Query ID SHOULD be set to zero on
+ transmission.
+
+ In multicast responses, including gratuitous multicast responses, the
+ Query ID MUST be set to zero on transmission, and MUST be ignored on
+ reception.
+
+ In unicast response messages generated specifically in response to a
+ particular (unicast or multicast) query, the Query ID MUST match the
+ ID from the query message.
+
+
+19.2. QR (Query/Response) Bit
+
+ In query messages, MUST be zero.
+
+ In response messages, MUST be one.
+
+
+19.3. OPCODE
+
+ In both multicast query and multicast response messages, MUST be zero
+ (only standard queries are currently supported over multicast, unless
+ other queries are allowed by future IETF Standards Action).
+
+
+19.4. AA (Authoritative Answer) Bit
+
+ In query messages, the Authoritative Answer bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+ In response messages for Multicast Domains, the Authoritative Answer
+ bit MUST be set to one (not setting this bit implies there's some
+ other place where "better" information may be found) and MUST be
+ ignored on reception.
+
+
+19.5. TC (Truncated) Bit
+
+ In query messages, if the TC bit is set, it means that additional
+ Known Answer records may be following shortly. A responder MAY choose
+ to record this fact, and wait for those additional Known Answer
+ records, before deciding whether to respond. If the TC bit is clear,
+ it means that the querying host has no additional Known Answers.
+
+ In multicast response messages, the TC bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+ In legacy unicast response messages, the TC bit has the same meaning
+ as in conventional unicast DNS: it means that the response was too
+ large to fit in a single packet, so the client SHOULD re-issue its
+ query using TCP in order to receive the larger response.
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 34]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+19.6. RD (Recursion Desired) Bit
+
+ In both multicast query and multicast response messages, the
+ Recursion Desired bit SHOULD be zero on transmission, and MUST be
+ ignored on reception.
+
+
+19.7. RA (Recursion Available) Bit
+
+ In both multicast query and multicast response messages, the
+ Recursion Available bit MUST be zero on transmission, and MUST be
+ ignored on reception.
+
+
+19.8. Z (Zero) Bit
+
+ In both query and response messages, the Zero bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+
+19.9. AD (Authentic Data) Bit [RFC 2535]
+
+ In query messages the Authentic Data bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+ In response messages, the Authentic Data bit MAY be set. Resolvers
+ receiving response messages with the AD bit set MUST NOT trust the AD
+ bit unless they trust the source of the message and either have a
+ secure path to it or use DNS transaction security.
+
+
+19.10. CD (Checking Disabled) Bit [RFC 2535]
+
+ In query messages, a resolver willing to do cryptography SHOULD set
+ the Checking Disabled bit to permit it to impose its own policies.
+
+ In response messages, the Checking Disabled bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+
+19.11. RCODE (Response Code)
+
+ In both multicast query and multicast response messages, the Response
+ Code MUST be zero on transmission. Multicast DNS messages received
+ with non-zero Response Codes MUST be silently ignored.
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 35]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+20. Choice of UDP Port Number
+
+ Arguments were made for and against using Multicast on UDP port 53.
+ The final decision was to use UDP port 5353. Some of the arguments
+ for and against are given below.
+
+
+20.1 Arguments for using UDP port 53:
+
+ * This is "just DNS", so it should be the same port.
+
+ * There is less work to be done updating old clients to do simple
+ mDNS queries. Only the destination address need be changed.
+ In some cases, this can be achieved without any code changes,
+ just by adding the address 224.0.0.251 to a configuration file.
+
+
+20.2 Arguments for using a different port (UDP port 5353):
+
+ * This is not "just DNS". This is a DNS-like protocol, but different.
+
+ * Changing client code to use a different port number is not hard.
+
+ * Using the same port number makes it hard to run an mDNS Responder
+ and a conventional unicast DNS server on the same machine. If a
+ conventional unicast DNS server wishes to implement mDNS as well,
+ it can still do that, by opening two sockets. Having two different
+ port numbers is important to allow this flexibility.
+
+ * Some VPN software hijacks all outgoing traffic to port 53 and
+ redirects it to a special DNS server set up to serve those VPN
+ clients while they are connected to the corporate network. It is
+ questionable whether this is the right thing to do, but it is
+ common, and redirecting link-local multicast DNS packets to a
+ remote server rarely produces any useful results. It does mean, for
+ example, that the user becomes unable to access their local network
+ printer sitting on their desk right next to their computer. Using
+ a different UDP port eliminates this particular problem.
+
+ * On many operating systems, unprivileged clients may not send or
+ receive packets on low-numbered ports. This means that any client
+ sending or receiving mDNS packets on port 53 would have to run as
+ "root", which is an undesirable security risk. Using a higher-
+ numbered UDP port eliminates this particular problem.
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 36]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+21. Summary of Differences Between Multicast DNS and Unicast DNS
+
+ The value of Multicast DNS is that it shares, as much as possible,
+ the familiar APIs, naming syntax, resource record types, etc., of
+ Unicast DNS. There are of course necessary differences by virtue of
+ it using Multicast, and by virtue of it operating in a community of
+ cooperating peers, rather than a precisely defined authoritarian
+ hierarchy controlled by a strict chain of formal delegations from the
+ top. These differences are listed below:
+
+ Multicast DNS...
+ * uses multicast
+ * uses UDP port 5353 instead of port 53
+ * operates in well-defined parts of the DNS namespace
+ * uses UTF-8, and only UTF-8, to encode resource record names
+ * defines a clear limit on the maximum legal domain name (255 bytes)
+ * allows larger UDP packets
+ * allows more than one question in a query packet
+ * uses the Answer Section of a query to list Known Answers
+ * uses the TC bit in a query to indicate additional Known Answers
+ * uses the Authority Section of a query for probe tie-breaking
+ * ignores the Query ID field (except for generating legacy responses)
+ * doesn't require the question to be repeated in the response packet
+ * uses gratuitous responses to announce new records to the peer group
+ * defines a "unicast response" bit in the rrclass of query questions
+ * defines a "cache flush" bit in the rrclass of responses
+ * uses DNS TTL 0 to indicate that a record has been deleted
+ * uses IP TTL 255 to verify that answers originated on the local link
+ * monitors queries to perform Duplicate Question Suppression
+ * monitors responses to perform Duplicate Answer Suppression...
+ * ... and Ongoing Conflict Detection
+ * ... and Opportunistic Caching
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 37]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+22. Benefits of Multicast Responses
+
+ Some people have argued that sending responses via multicast is
+ inefficient on the network. In fact the benefits of using multicast
+ responses result in a net lowering of overall multicast traffic, for
+ a variety of reasons.
+
+ * One multicast response can update the cache on all machines on the
+ network. If another machine later wants to issue the same query, it
+ already has the answer in its cache, so it may not need to even
+ transmit that multicast query on the network at all.
+
+ * When more than one machine has the same ongoing long-lived query
+ running, every machine does not have to transmit its own
+ independent query. When one machine transmits a query, all the
+ other hosts see the answers, so they can suppress their own
+ queries.
+
+ * When a host sees a multicast query, but does not see the
+ corresponding multicast response, it can use this information to
+ promptly delete stale data from its cache. To achieve the same
+ level of user-interface quality and responsiveness without
+ multicast responses would require lower cache lifetimes and more
+ frequent network polling, resulting in a significantly higher
+ packet rate.
+
+ * Multicast responses allow passive conflict detection. Without this
+ ability, some other conflict detection mechanism would be needed,
+ imposing its own additional burden on the network.
+
+ * When using delayed responses to reduce network collisions, clients
+ need to maintain a list recording to whom each answer should be
+ sent. The option of multicast responses allows clients with limited
+ storage, which cannot store an arbitrarily long list of response
+ addresses, to choose to fail-over to a single multicast response in
+ place of multiple unicast respones, when appropriate.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 38]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+23. IPv6 Considerations
+
+ An IPv4-only host and an IPv6-only host behave as "ships that pass in
+ the night". Even if they are on the same Ethernet, neither is aware
+ of the other's traffic. For this reason, each physical link may have
+ *two* unrelated ".local." zones, one for IPv4 and one for IPv6.
+ Since for practical purposes, a group of IPv4-only hosts and a group
+ of IPv6-only hosts on the same Ethernet act as if they were on two
+ entirely separate Ethernet segments, it is unsurprising that their
+ use of the ".local." zone should occur exactly as it would if
+ they really were on two entirely separate Ethernet segments.
+
+ A dual-stack (v4/v6) host can participate in both ".local."
+ zones, and should register its name(s) and perform its lookups both
+ using IPv4 and IPv6. This enables it to reach, and be reached by,
+ both IPv4-only and IPv6-only hosts. In effect this acts like a
+ multi-homed host, with one connection to the logical "IPv4 Ethernet
+ segment", and a connection to the logical "IPv6 Ethernet segment".
+
+23.1 IPv6 Multicast Addresses by Hashing
+
+ Some discovery protocols use a range of multicast addresses, and
+ determine the address to be used by a hash function of the name being
+ sought. Queries are sent via multicast to the address as indicated by
+ the hash function, and responses are returned to the querier via
+ unicast. Particularly in IPv6, where multicast addresses are
+ extremely plentiful, this approach is frequently advocated.
+
+ There are some problems with this:
+
+ * When a host has a large number of records with different names, the
+ host may have to join a large number of multicast groups. This can
+ place undue burden on the Ethernet hardware, which typically
+ supports a limited number of multicast addresses efficiently. When
+ this number is exceeded, the Ethernet hardware may have to resort
+ to receiving all multicasts and passing them up to the host
+ software for filtering, thereby defeating the point of using a
+ multicast address range in the first place.
+
+ * Multiple questions cannot be placed in one packet if they don't all
+ hash to the same multicast address.
+
+ * Duplicate Question Suppression doesn't work if queriers are not
+ seeing each other's queries.
+
+ * Duplicate Answer Suppression doesn't work if responders are not
+ seeing each other's responses.
+
+ * Opportunistic Caching doesn't work.
+
+ * Ongoing Conflict Detection doesn't work.
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 39]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+24. Security Considerations
+
+ The algorithm for detecting and resolving name conflicts is, by its
+ very nature, an algorithm that assumes cooperating participants. Its
+ purpose is to allow a group of hosts to arrive at a mutually disjoint
+ set of host names and other DNS resource record names, in the absence
+ of any central authority to coordinate this or mediate disputes. In
+ the absence of any higher authority to resolve disputes, the only
+ alternative is that the participants must work together cooperatively
+ to arrive at a resolution.
+
+ In an environment where the participants are mutually antagonistic
+ and unwilling to cooperate, other mechanisms are appropriate, like
+ manually administered DNS.
+
+ In an environment where there is a group of cooperating participants,
+ but there may be other antagonistic participants on the same physical
+ link, the cooperating participants need to use IPSEC signatures
+ and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS
+ messages from trusted participants (which they process as usual) from
+ mDNS messages from untrusted participants (which they silently
+ discard).
+
+ When DNS queries for *global* DNS names are sent to the mDNS
+ multicast address (during network outages which disrupt communication
+ with the greater Internet) it is *especially* important to use
+ DNSSEC, because the user may have the impression that he or she is
+ communicating with some authentic host, when in fact he or she is
+ really communicating with some local host that is merely masquerading
+ as that name. This is less critical for names ending with ".local.",
+ because the user should be aware that those names have only local
+ significance and no global authority is implied.
+
+ Most computer users neglect to type the trailing dot at the end of a
+ fully qualified domain name, making it a relative domain name (e.g.
+ "www.example.com"). In the event of network outage, attempts to
+ positively resolve the name as entered will fail, resulting in
+ application of the search list, including ".local.", if present.
+ A malicious host could masquerade as "www.example.com" by answering
+ the resulting Multicast DNS query for "www.example.com.local."
+ To avoid this, a host MUST NOT append the search suffix
+ ".local.", if present, to any relative (partially qualified)
+ domain name containing two or more labels. Appending ".local." to
+ single-label relative domain names is acceptable, since the user
+ should have no expectation that a single-label domain name will
+ resolve as-is.
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 40]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+25. IANA Considerations
+
+ The IANA has allocated the IPv4 link-local multicast address
+ 224.0.0.251 for the use described in this document.
+
+ The IANA has allocated the IPv6 multicast address set FF0X::FB
+ for the use described in this document.
+
+ When this document is published, IANA should designate a list
+ of domains which are deemed to have only link-local significance,
+ as described in this document.
+
+ No other IANA services are required by this document.
+
+
+26. Acknowledgements
+
+ The concepts described in this document have been explored and
+ developed with help from Erik Guttman, Paul Vixie, Bill Woodcock,
+ and others.
+
+
+27. Copyright
+
+ Copyright (C) The Internet Society January 2004.
+ All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 41]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+28. Normative References
+
+ [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
+ Facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+ Specifications", STD 13, RFC 1035, November 1987.
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 2279, January 1998.
+
+
+29. Informative References
+
+ [dotlocal] <http://www.dotlocal.org/>
+
+ [djbdl] <http://cr.yp.to/djbdns/dot-local.html>
+
+ [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service
+ Discovery", Internet-Draft (work in progress),
+ draft-cheshire-dnsext-dns-sd-02.txt, February 2004.
+
+ [IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
+ Overview and Architecture.
+ Institute of Electrical and Electronic Engineers,
+ IEEE Standard 802, 1990.
+
+ [NBP] Cheshire, S., and M. Krochmal,
+ "Requirements for a Protocol to Replace AppleTalk NBP",
+ Internet-Draft (work in progress),
+ draft-cheshire-dnsext-nbp-03.txt, February 2004.
+
+ [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
+ System (DNS UPDATE)", RFC 2136, April 1997.
+
+ [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+ [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [v4LL] Cheshire, S., B. Aboba, and E. Guttman, "Dynamic
+ Configuration of IPv4 Link-Local Addresses",
+ Internet-Draft (work in progress),
+ draft-ietf-zeroconf-ipv4-linklocal-11.txt, January 2004.
+
+ [ZC] Williams, A., "Requirements for Automatic Configuration
+ of IP Hosts", Internet-Draft (work in progress),
+ draft-ietf-zeroconf-reqts-12.txt, September 2002.
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 42]
+\f
+Internet Draft Multicast DNS 14th February 2004
+
+
+30. Author's Addresses
+
+ Stuart Cheshire
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino
+ California 95014
+ USA
+
+ Phone: +1 408 974 3207
+ EMail: rfc@stuartcheshire.org
+
+
+ Marc Krochmal
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino
+ California 95014
+ USA
+
+ Phone: +1 408 974 4368
+ EMail: marc@apple.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 14th August 2004 Cheshire & Krochmal [Page 43]
\ No newline at end of file
--- /dev/null
+Document: draft-cheshire-dnsext-multicastdns-05.txt Stuart Cheshire
+Category: Standards Track Apple Computer, Inc.
+Expires 7th December 2005 Marc Krochmal
+ Apple Computer, Inc.
+ 7th June 2005
+
+ Multicast DNS
+
+ <draft-cheshire-dnsext-multicastdns-05.txt>
+
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents
+ that any applicable patent or other IPR claims of which he or she is
+ aware have been or will be disclosed, and any of which he or she
+ become aware will be disclosed, in accordance with RFC 3979.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as
+ Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+
+Abstract
+
+ As networked devices become smaller, more portable, and more
+ ubiquitous, the ability to operate with less configured
+ infrastructure is increasingly important. In particular, the ability
+ to look up DNS resource record data types (including, but not limited
+ to, host names) in the absence of a conventional managed DNS server,
+ is becoming essential.
+
+ Multicast DNS (mDNS) provides the ability to do DNS-like operations
+ on the local link in the absence of any conventional unicast DNS
+ server. In addition, mDNS designates a portion of the DNS namespace
+ to be free for local use, without the need to pay any annual fee, and
+ without the need to set up delegations or otherwise configure a
+ conventional DNS server to answer for those names.
+
+ The primary benefits of mDNS names are that (i) they require little
+ or no administration or configuration to set them up, (ii) they work
+ when no infrastructure is present, and (iii) they work during
+ infrastructure failures.
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 1]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+Table of Contents
+
+ 1. Introduction...................................................3
+ 2. Conventions and Terminology Used in this Document..............4
+ 3. Multicast DNS Names............................................5
+ 4. Source Address Check...........................................8
+ 5. Reverse Address Mapping........................................9
+ 6. Querying.......................................................9
+ 7. Duplicate Suppression.........................................13
+ 8. Responding....................................................15
+ 9. Probing and Announcing on Startup.............................18
+ 10. Conflict Resolution...........................................22
+ 11. Resource Record TTL Values and Cache Coherency................23
+ 12. Special Characteristics of Multicast DNS Domains..............28
+ 13. Multicast DNS for Service Discovery...........................30
+ 14. Enabling and Disabling Multicast DNS..........................30
+ 15. Considerations for Multiple Interfaces........................30
+ 16. Multicast DNS and Power Management............................31
+ 17. Multicast DNS Character Set...................................32
+ 18. Multicast DNS Message Size....................................34
+ 19. Multicast DNS Message Format..................................34
+ 20. Choice of UDP Port Number.....................................37
+ 21. Summary of Differences Between Multicast DNS and Unicast DNS..38
+ 22. Benefits of Multicast Responses...............................38
+ 23. IPv6 Considerations...........................................39
+ 24. Security Considerations.......................................40
+ 25. IANA Considerations...........................................41
+ 26. Acknowledgments...............................................42
+ 27. Copyright.....................................................42
+ 28. Normative References..........................................42
+ 29. Informative References........................................43
+ 30. Authors' Addresses............................................44
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 2]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+1. Introduction
+
+ When reading this document, familiarity with the concepts of Zero
+ Configuration Networking [ZC] and automatic link-local addressing
+ [RFC 2462] [RFC 3927] is helpful.
+
+ This document proposes no change to the structure of DNS messages,
+ and no new operation codes, response codes, or resource record types.
+ This document simply discusses what needs to happen if DNS clients
+ start sending DNS queries to a multicast address, and how a
+ collection of hosts can cooperate to collectively answer those
+ queries in a useful manner.
+
+ There has been discussion of how much burden Multicast DNS might
+ impose on a network. It should be remembered that whenever IPv4 hosts
+ communicate, they broadcast ARP packets on the network on a regular
+ basis, and this is not disastrous. The approximate amount of
+ multicast traffic generated by hosts making conventional use of
+ Multicast DNS is anticipated to be roughly the same order of
+ magnitude as the amount of broadcast ARP traffic those hosts already
+ generate.
+
+ New applications making new use of Multicast DNS capabilities for
+ unconventional purposes may generate more traffic. If some of those
+ new applications are "chatty", then work will be needed to help them
+ become less chatty. When performing any analysis, it is important to
+ make a distinction between the application behavior and the
+ underlying protocol behavior. If a chatty application uses UDP, that
+ doesn't mean that UDP is chatty, or that IP is chatty, or that
+ Ethernet is chatty. What it means is that the application is chatty.
+ The same applies to any future applications that may decide to layer
+ increasing portions of their functionality over Multicast DNS.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 3]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+2. Conventions and Terminology Used in this Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in "Key words for use in
+ RFCs to Indicate Requirement Levels" [RFC 2119].
+
+ This document uses the term "host name" in the strict sense to mean a
+ fully qualified domain name that has an address record. It does not
+ use the term "host name" in the commonly used but incorrect sense to
+ mean just the first DNS label of a host's fully qualified domain
+ name.
+
+ A DNS (or mDNS) packet contains an IP TTL in the IP header, which
+ is effectively a hop-count limit for the packet, to guard against
+ routing loops. Each Resource Record also contains a TTL, which is
+ the number of seconds for which the Resource Record may be cached.
+
+ In any place where there may be potential confusion between these two
+ types of TTL, the term "IP TTL" is used to refer to the IP header TTL
+ (hop limit), and the term "RR TTL" is used to refer to the Resource
+ Record TTL (cache lifetime).
+
+ When this document uses the term "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 packets over IP
+ Multicast to UDP port 5353."
+
+ This document uses the terms "shared" and "unique" when referring to
+ resource record sets.
+
+ A "shared" resource record set is one where several Multicast DNS
+ responders may have records with that name, rrtype, and rrclass, and
+ several responders may respond to a particular query.
+
+ A "unique" resource record set is one where all the records with that
+ name, rrtype, and rrclass are under the control or ownership of a
+ single responder, and at most one responder should respond to any
+ given query. Before claiming ownership of a unique resource record
+ set, a responder MUST probe to verify that no other responder
+ already claims ownership of that set, as described in Section 9.1
+ "Probing".
+
+ Strictly speaking the terms "shared" and "unique" apply to resource
+ record sets, not to individual resource records, but it is sometimes
+ convenient to talk of "shared resource records" and "unique resource
+ records". When used this way, the terms should be understood to mean
+ a record that is a member of a "shared" or "unique" resource record
+ set, respectively.
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 4]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+3. Multicast DNS Names
+
+ This document proposes that the DNS top-level domain ".local." be
+ designated a special domain with special semantics, namely that any
+ fully-qualified name ending in ".local." is link-local, and names
+ within this domain are meaningful only on the link where they
+ originate. This is analogous to IPv4 addresses in the 169.254/16
+ prefix, which are link-local and meaningful only on the link where
+ they originate.
+
+ Any DNS query for a name ending with ".local." MUST be sent
+ to the mDNS multicast address (224.0.0.251 or its IPv6 equivalent
+ FF02::FB).
+
+ It is unimportant whether a name ending with ".local." occurred
+ because the user explicitly typed in a fully qualified domain name
+ ending in ".local.", or because the user entered an unqualified
+ domain name and the host software appended the suffix ".local."
+ because that suffix appears in the user's search list. The ".local."
+ suffix could appear in the search list because the user manually
+ configured it, or because it was received in a DHCP option, or via
+ any other valid mechanism for configuring the DNS search list. In
+ this respect the ".local." suffix is treated no differently to any
+ other search domain that might appear in the DNS search list.
+
+ DNS queries for names that do not end with ".local." MAY be sent to
+ the mDNS multicast address, if no other conventional DNS server is
+ available. This can allow hosts on the same link to continue
+ communicating using each other's globally unique DNS names during
+ network outages which disrupt communication with the greater
+ Internet. When resolving global names via local multicast, it is even
+ more important to use DNSSEC or other security mechanisms to ensure
+ that the response is trustworthy. Resolving global names via local
+ multicast is a contentious issue, and this document does not discuss
+ it in detail, instead concentrating on the issue of resolving local
+ names using DNS packets sent to a multicast address.
+
+ A host which belongs to an organization or individual who has control
+ over some portion of the DNS namespace can be assigned a globally
+ unique name within that portion of the DNS namespace, for example,
+ "cheshire.apple.com." For those of us who have this luxury, this
+ works very well. However, the majority of home customers do not have
+ easy access to any portion of the global DNS namespace within which
+ they have the authority to create names as they wish. This leaves the
+ majority of home computers effectively anonymous for practical
+ purposes.
+
+ To remedy this problem, this document allows any computer user to
+ elect to give their computers link-local Multicast DNS host names of
+ the form: "single-dns-label.local." For example, a laptop computer
+ may answer to the name "cheshire.local." Any computer user is granted
+ the authority to name their computer this way, provided that the
+ chosen host name is not already in use on that link. Having named
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 5]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ their computer this way, the user has the authority to continue using
+ that name until such time as a name conflict occurs on the link which
+ is not resolved in the user's favour. If this happens, the computer
+ (or its human user) SHOULD cease using the name, and may choose to
+ attempt to allocate a new unique name for use on that link. These
+ conflicts are expected to be relatively rare for people who choose
+ reasonably imaginative names, but it is still important to have a
+ mechanism in place to handle them when they happen.
+
+ The point made in the previous paragraph is very important and bears
+ repeating. It is easy for those of us in the IETF community who run
+ our own name servers at home to forget that the majority of computer
+ users do not run their own name server and have no easy way to create
+ their own host names. When these users wish to transfer files between
+ two laptop computers, they are frequently reduced to typing in
+ dotted-decimal IP addresses because they simply have no other way for
+ one host to refer to the other by name. This is a sorry state of
+ affairs. What is worse, most users don't even bother trying to use
+ dotted-decimal IP addresses. Most users still move data between
+ machines by copying it onto a floppy disk or similar removable media.
+
+ In a world of gigabit Ethernet and ubiquitous wireless networking it
+ is a sad indictment of the networking community that the preferred
+ communication medium for most computer users is still the floppy
+ disk.
+
+ Allowing ad-hoc allocation of single-label names in a single flat
+ ".local." namespace may seem to invite chaos. However, operational
+ experience with AppleTalk NBP names [NBP], which on any given link
+ are also effectively single-label names in a flat namespace, shows
+ that in practice name collisions happen extremely rarely and are not
+ a problem. Groups of computer users from disparate organizations
+ bring Macintosh laptop computers to events such as IETF Meetings, the
+ Mac Hack conference, the Apple World Wide Developer Conference, etc.,
+ and complaints at these events about users suffering conflicts and
+ being forced to rename their machines have never been an issue.
+
+ Enforcing uniqueness of host names (i.e. the names of DNS address
+ records mapping names to IP addresses) is probably desirable in the
+ common case, but this document does not mandate that. It is
+ permissible for a collection of coordinated hosts to agree to
+ maintain multiple DNS address records with the same name, possibly
+ for load balancing or fault-tolerance reasons. This document does not
+ take a position on whether that is sensible. It is important that
+ both modes of operation are supported. The Multicast DNS protocol
+ allows hosts to verify and maintain unique names for resource records
+ where that behavior is desired, and it also allows hosts to maintain
+ multiple resource records with a single shared name where that
+ behavior is desired. This consideration applies to all resource
+ records, not just address records (host names). In summary: It is
+ required that the protocol have the ability to detect and handle name
+ conflicts, but it is not required that this ability be used for every
+ record.
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 6]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+3.1 Governing Standards Body
+
+ Note that this use of the ".local." suffix falls under IETF
+ jurisdiction, not ICANN jurisdiction. DNS is an IETF network
+ protocol, governed by protocol rules defined by the IETF. These IETF
+ protocol rules dictate character set, maximum name length, packet
+ format, etc. ICANN determines additional rules that apply when the
+ IETF's DNS protocol is used on the public Internet. In contrast,
+ private uses of the DNS protocol on isolated private networks are not
+ governed by ICANN. Since this proposed change is a change to the core
+ DNS protocol rules, it affects everyone, not just those machines
+ using the ICANN-governed Internet. Hence this change falls into the
+ category of an IETF protocol rule, not an ICANN usage rule.
+
+3.2 Private DNS Namespaces
+
+ Note also that the special treatment of names ending in ".local." has
+ been implemented in Macintosh computers since the days of Mac OS 9,
+ and continues today in Mac OS X. There are also implementations for
+ Linux and other platforms [dotlocal]. Operators setting up private
+ internal networks ("intranets") are advised that their lives may be
+ easier if they avoid using the suffix ".local." in names in their
+ private internal DNS server. Alternative possibilities include:
+
+ .intranet
+ .internal
+ .private
+ .corp
+ .home
+
+ Another alternative naming scheme, advocated by Professor D. J.
+ Bernstein, is to use a numerical suffix, such as ".6." [djbdl].
+
+3.3 Maximum Multicast DNS Name Length
+
+ RFC 1034 says:
+
+ "the total number of octets that represent a domain name (i.e.,
+ the sum of all label octets and label lengths) is limited to 255."
+
+ This text implies that the final root label at the end of every name
+ is included in this count (a name can't be represented without it),
+ but the text does not explicitly state that. Implementations of
+ Multicast DNS MUST include the label length byte of the final root
+ label at the end of every name when enforcing the rule that no name
+ may be longer than 255 bytes. For example, the length of the name
+ "apple.com." is considered to be 11, which is the number of bytes it
+ takes to represent that name in a packet without using name
+ compression:
+
+ ------------------------------------------------------
+ | 0x05 | a | p | p | l | e | 0x03 | c | o | m | 0x00 |
+ ------------------------------------------------------
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 7]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+4. Source Address Check
+
+ All Multicast DNS responses (including responses sent via unicast)
+ SHOULD be sent with IP TTL set to 255. This is recommended to provide
+ backwards-compatibility with older Multicast DNS clients that check
+ the IP TTL on reception to determine whether the packet originated
+ on the local link. These older clients discard all packets with TTLs
+ other than 255.
+
+ A host sending Multicast DNS queries to a link-local destination
+ address (including the 224.0.0.251 link-local multicast address)
+ MUST only accept responses to that query that originate from the
+ local link, and silently discard any other response packets. Without
+ this check, it could be possible for remote rogue hosts to send
+ spoof answer packets (perhaps unicast to the victim host) which the
+ receiving machine could misinterpret as having originated on the
+ local link.
+
+ The test for whether a response originated on the local link
+ is done in two ways:
+
+ * All responses sent to the link-local multicast address 224.0.0.251
+ are necessarily deemed to have originated on the local link,
+ regardless of source IP address. This is essential to allow devices
+ to work correctly and reliably in unusual configurations, such as
+ multiple logical IP subnets overlayed on a single link, or in cases
+ of severe misconfiguration, where devices are physically connected
+ to the same link, but are currently misconfigured with completely
+ unrelated IP addresses and subnet masks.
+
+ * For responses sent to a unicast destination address, the source IP
+ address in the packet is checked to see if it is an address on a
+ local subnet. An address is determined to be on a local subnet if,
+ for (one of) the address(es) configured on the interface receiving
+ the packet, (I & M) == (P & M), where I and M are the interface
+ address and subnet mask respectively, P is the source IP address
+ from the packet, '&' represents the bitwise logical 'and'
+ operation, and '==' represents a bitwise equality test.
+
+ Since queriers will ignore responses apparently originating outside
+ the local subnet, responders SHOULD avoid generating responses that
+ it can reasonably predict will be ignored. This applies particularly
+ in the case of overlayed subnets. If a responder receives a query
+ addressed to the link-local multicast address 224.0.0.251, from a
+ source address not apparently on the same subnet as the responder,
+ then even if the query indicates that a unicast response is preferred
+ (see Section 6.5, "Questions Requesting Unicast Responses"), the
+ responder SHOULD elect to respond by multicast anyway, since it can
+ reasonably predict that a unicast response with an apparently
+ non-local source address will probably be ignored.
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 8]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+5. Reverse Address Mapping
+
+ Like ".local.", the IPv4 and IPv6 reverse-mapping domains are also
+ defined to be link-local.
+
+ Any DNS query for a name ending with "254.169.in-addr.arpa." MUST
+ be sent to the mDNS multicast address 224.0.0.251. Since names under
+ this domain correspond to IPv4 link-local addresses, it is logical
+ that the local link is the best place to find information pertaining
+ to those names. As an optimization, these queries MAY be first
+ unicast directly to the address in question, but if this query is not
+ answered, the query MUST also be sent via multicast, to accommodate
+ the case where the machine in question is not answering for itself
+ (for example, because it is currently sleeping).
+
+ Likewise, any DNS query for a name ending with "0.8.e.f.ip6.arpa."
+ MUST be sent to the IPv6 mDNS link-local multicast address FF02::FB,
+ with or without an optional initial query unicast directly to the
+ address in question.
+
+
+6. Querying
+
+ There are three kinds of Multicast DNS Queries, one-shot queries of
+ the kind made by today's conventional DNS clients, one-shot queries
+ accumulating multiple responses made by multicast-aware DNS clients,
+ and continuous ongoing Multicast DNS Queries used by IP network
+ browser software.
+
+ A Multicast DNS Responder that is offering records that are intended
+ to be unique on the local link MUST also implement a Multicast DNS
+ Querier so that it can first verify the uniqueness of those records
+ before it begins answering queries for them.
+
+
+6.1 One-Shot Queries
+
+ An unsophisticated DNS client may simply send its DNS queries
+ blindly to the 224.0.0.251 multicast address, without necessarily
+ even being aware what a multicast address is.
+
+ Such an unsophisticated DNS client may not get ideal behavior. Such
+ a client may simply take the first response it receives and fail to
+ wait to see if there are more, but in many instances this may not be
+ a serious problem. If a user types "http://cheshire.local." into
+ their Web browser and gets to see the page they were hoping for,
+ then the protocol has met the user's needs in this case.
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 9]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+6.2 One-Shot Queries, Accumulating Multiple Responses
+
+ A more sophisticated DNS client should understand that Multicast DNS
+ is not exactly the same as unicast DNS, and should modify its
+ behavior in some simple ways.
+
+ As described above, there are some cases, such as looking up the
+ address associated with a unique host name, where a single response
+ is sufficient, and moreover may be all that is expected. However,
+ there are other DNS queries where more than one response is
+ possible, and for these queries a more sophisticated Multicast DNS
+ client should include the ability to wait for an appropriate period
+ of time to collect multiple responses.
+
+ A naive DNS client retransmits its query only so long as it has
+ received no response. A more sophisticated Multicast DNS client is
+ aware that having received one response is not necessarily an
+ indication that it might not receive others, and has the ability to
+ retransmit its query an appropriate number of times at appropriate
+ intervals until it is satisfied with the collection of responses it
+ has gathered.
+
+ A more sophisticated Multicast DNS client that is retransmitting
+ a query for which it has already received some responses, MUST
+ implement Known Answer Suppression, as described below in Section
+ 7.1. This indicates to responders who have already replied that their
+ responses have been received, and they don't need to send them again
+ in response to this repeated query. In addition, the interval between
+ the first two queries SHOULD be one second, and the intervals between
+ subsequent queries SHOULD double.
+
+
+6.3 Continuous Querying
+
+ In One-Shot Queries, with either a single or multiple responses,
+ the underlying assumption is that the transaction begins when the
+ application issues a query, and ends when all the desired responses
+ have been received. There is another type of operation which is more
+ akin to continuous monitoring.
+
+ Macintosh users are accustomed to opening the "Chooser" window,
+ selecting a desired printer, and then closing the Chooser window.
+ However, when the desired printer does not appear in the list, the
+ user will typically leave the "Chooser" window open while they go and
+ check to verify that the printer is plugged in, powered on, connected
+ to the Ethernet, etc. While the user jiggles the wires, hits the
+ Ethernet hub, and so forth, they keep an eye on the Chooser window,
+ and when the printer name appears, they know they have fixed whatever
+ the problem was. This can be a useful and intuitive troubleshooting
+ technique, but a user who goes home for the weekend leaving the
+ Chooser window open places a non-trivial burden on the network.
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 10]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ With continuous querying, multiple queries are sent over a long
+ period of time, until the user terminates the operation. It is
+ important that an IP network browser window displaying live
+ information from the network using Multicast DNS, if left running
+ for an extended period of time, should generate significantly less
+ multicast traffic on the network than the old AppleTalk Chooser.
+ Therefore, the interval between the first two queries SHOULD be one
+ second, the intervals between subsequent queries SHOULD double, and
+ the querier MUST implement Known Answer Suppression, as described
+ below in Section 7.1. When the interval between queries reaches or
+ exceeds 60 minutes, a querier MAY cap the interval to a maximum of 60
+ minutes, and perform subsequent queries at a steady-state rate of one
+ query per hour.
+
+ When a Multicast DNS Querier receives an answer, the answer contains
+ a TTL value that indicates for how many seconds this answer is valid.
+ After this interval has passed, the answer will no longer be valid
+ and SHOULD be deleted from the cache. Before this time is reached, a
+ Multicast DNS Querier with an ongoing interest in that record SHOULD
+ re-issue its query to determine whether the record is still valid,
+ and if so update its expiry time.
+
+ To perform this cache maintenance, a Multicast DNS Querier should
+ plan to re-query for records after at least 50% of the record
+ lifetime has elapsed. This document recommends the following
+ specific strategy:
+
+ The Querier should plan to issue a query at 80% of the record
+ lifetime, and then if no answer is received, at 85%, 90% and 95%. If
+ an answer is received, then the remaining TTL is reset to the value
+ given in the answer, and this process repeats for as long as the
+ Multicast DNS Querier has an ongoing interest in the record. If after
+ four queries no answer is received, the record is deleted when it
+ reaches 100% of its lifetime.
+
+ To avoid the case where multiple Multicast DNS Queriers on a network
+ all issue their queries simultaneously, a random variation of 2% of
+ the record TTL should be added, so that queries are scheduled to be
+ performed at 80-82%, 85-87%, 90-92% and then 95-97% of the TTL.
+
+
+6.4 Multiple Questions per Query
+
+ Multicast DNS allows a querier to place multiple questions in the
+ Question Section of a single Multicast DNS query packet.
+
+ The semantics of a Multicast DNS query packet containing multiple
+ questions is identical to a series of individual DNS query packets
+ containing one question each. Combining multiple questions into a
+ single packet is purely an efficiency optimization, and has no other
+ semantic significance.
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 11]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ A useful technique for adaptively combining multiple questions into a
+ single query is to use a Nagle-style algorithm: When a client issues
+ its first question, a Query packet is immediately built and sent,
+ without delay. If the client then continues issuing a rapid series of
+ questions they are held until either the first query receives at
+ least one answer, or 100ms has passed, or there are enough questions
+ to fill the Question Section of a Multicast DNS query packet. At this
+ time, all the held questions are placed into a Multicast DNS query
+ packet and sent.
+
+6.5 Questions Requesting Unicast Responses
+
+ Sending Multicast DNS responses via multicast has the benefit that
+ all the other hosts on the network get to see those responses, and
+ can keep their caches up to date, and detect conflicting responses.
+
+ However, there are situations where all the other hosts on the
+ network don't need to see every response. One example is a laptop
+ computer waking from sleep. At that instant it is a brand new
+ participant on a new network. Its Multicast DNS cache is empty, and
+ it has no knowledge of its surroundings. It may have a significant
+ number of queries that it wants answered right away to discover
+ information about its new surroundings and present that information
+ to the user. As a new participant on the network, it has no idea
+ whether the exact same questions may have been asked and answered
+ just seconds ago. In this case, trigging a large sudden flood of
+ multicast responses may impose an unreasonable burden on the network.
+ To avoid this, the Multicast DNS Querier SHOULD set the top bit in
+ the class field of its DNS question(s), to indicate that it is
+ willing to accept unicast responses instead of the usual multicast
+ responses. These questions requesting unicast responses are referred
+ to as "QU" questions, to distinguish them from the more usual
+ questions requesting multicast responses ("QM" questions).
+
+ When retransmitting a question more than once, the 'unicast response'
+ bit SHOULD be set only for the first question of the series. After
+ the first question has received its responses, the querier should
+ have a large known-answer list (see "Known Answer Suppression" below)
+ so that subsequent queries should elicit few, if any, further
+ responses. Reverting to multicast responses as soon as possible is
+ important because of the benefits that multicast responses provide
+ (see "Benefits of Multicast Responses" below).
+
+ When receiving a question with the 'unicast response' bit set, a
+ responder SHOULD usually respond with a unicast packet directed back
+ to the querier. If the responder has not multicast that record
+ recently (within one quarter of its TTL), then the responder SHOULD
+ instead multicast the response so as to keep all the peer caches up
+ to date, and to permit passive conflict detection.
+
+ Unicast replies are subject to all the same packet generation rules
+ as multicast replies, including the cache flush bit (see Section
+ 11.3, "Announcements to Flush Outdated Cache Entries") and randomized
+ delays to reduce network collisions (see Section 8, "Responding").
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 12]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+6.6 Suppressing Initial Query
+
+ If a query is issued for which there already exist one or more
+ records in the local cache, and those record(s) were received with
+ the cache flush bit set (see Section 11.3, "Announcements to Flush
+ Outdated Cache Entries"), indicating that they form a unique RRSet,
+ then the host SHOULD suppress its initial "QU" query, and proceed to
+ issue a "QM" query. To avoid the situation where a group of hosts
+ are synchronized by some external event and all perform the same
+ query simultaneously, a host suppressing its initial "QU" query
+ SHOULD impose a random delay from 500-1000ms before transmitting its
+ first "QM" query for this question. This means that when the first
+ host (selected randomly by this algorithm) transmits its "QM" query,
+ all the other hosts that were about to transmit the same query can
+ suppress their superfluous query, as described in "Duplicate
+ Question Suppression" below.
+
+7. Duplicate Suppression
+
+ A variety of techniques are used to reduce the amount of redundant
+ traffic on the network.
+
+7.1 Known Answer Suppression
+
+ When a Multicast DNS Querier sends a query to which it already knows
+ some answers, it populates the Answer Section of the DNS message with
+ those answers.
+
+ A Multicast DNS Responder SHOULD NOT answer a Multicast DNS Query if
+ the answer it would give is already included in the Answer Section
+ with an RR TTL at least half the correct value. If the RR TTL of the
+ answer as given in the Answer Section is less than half of the true
+ RR TTL as known by the Multicast DNS Responder, the responder MUST
+ send an answer so as to update the Querier's cache before the record
+ becomes in danger of expiration.
+
+ Because a Multicast DNS Responder will respond if the remaining TTL
+ given in the known answer list is less than half the true TTL, it is
+ superfluous for the Querier to include such records in the known
+ answer list. Therefore a Multicast DNS Querier SHOULD NOT include
+ records in the known answer list whose remaining TTL is less than
+ half their original TTL. Doing so would simply consume space in the
+ packet without achieving the goal of suppressing responses, and would
+ therefore be a pointless waste of network bandwidth.
+
+ A Multicast DNS Querier MUST NOT cache resource records observed in
+ the Known Answer Section of other Multicast DNS Queries. The Answer
+ Section of Multicast DNS Queries is not authoritative. By placing
+ information in the Answer Section of a Multicast DNS Query the
+ querier is stating that it *believes* the information to be true.
+ It is not asserting that the information *is* true. Some of those
+ records may have come from other hosts that are no longer on the
+ network. Propagating that stale information to other Multicast DNS
+ Queriers on the network would not be helpful.
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 13]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+7.2 Multi-Packet Known Answer Suppression
+
+ Sometimes a Multicast DNS Querier will already have too many answers
+ to fit in the Known Answer Section of its query packets. In this
+ case, it should issue a Multicast DNS Query containing a question and
+ as many Known Answer records as will fit. It MUST then set the TC
+ (Truncated) bit in the header before sending the Query. It MUST then
+ immediately follow the packet with another query packet containing no
+ questions, and as many more Known Answer records as will fit. If
+ there are still too many records remaining to fit in the packet, it
+ again sets the TC bit and continues until all the Known Answer
+ records have been sent.
+
+ A Multicast DNS Responder seeing a Multicast DNS Query with the TC
+ bit set defers its response for a time period randomly selected in
+ the interval 400-500ms. This gives the Multicast DNS Querier time to
+ send additional Known Answer packets before the Responder responds.
+ If the Responder sees any of its answers listed in the Known Answer
+ lists of subsequent packets from the querying host, it SHOULD delete
+ that answer from the list of answers it is planning to give, provided
+ that no other host on the network is also waiting to receive the same
+ answer record.
+
+ Previous versions of this draft specified a delay of 20-120ms before
+ answering queries with multi-packet Known Answer lists. However,
+ operational experience showed that, while this works well on
+ Ethernet, on very busy 802.11 networks, it is not uncommon to observe
+ consecutively sent packets arriving separated by as much as
+ 200-400ms.
+
+
+7.3 Duplicate Question Suppression
+
+ If a host is planning to send a query, and it sees another host on
+ the network send a query containing the same question, and the Known
+ Answer Section of that query does not contain any records which this
+ host would not also put in its own Known Answer Section, then this
+ host should treat its own query as having been sent. When multiple
+ clients on the network are querying for the same resource records,
+ there is no need for them to all be repeatedly asking the same
+ question.
+
+
+7.4 Duplicate Answer Suppression
+
+ If a host is planning to send an answer, and it sees another host on
+ the network send a response packet containing the same answer record,
+ and the TTL in that record is not less than the TTL this host would
+ have given, then this host should treat its own answer as having been
+ sent. When multiple responders on the network have the same data,
+ there is no need for all of them to respond.
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 14]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ This feature is particularly useful when multiple Sleep Proxy Servers
+ are deployed (see Section 16, "Multicast DNS and Power Management").
+ In the future it is possible that every general-purpose OS (Mac,
+ Windows, Linux, etc.) will implement Sleep Proxy Service as a matter
+ of course. In this case there could be a large number of Sleep Proxy
+ Servers on any given network, which is good for reliability and
+ fault-tolerance, but would be bad for the network if every Sleep
+ Proxy Server were to answer every query.
+
+
+8. Responding
+
+ When a Multicast DNS Responder constructs and sends a Multicast DNS
+ response packet, the Answer Section of that packet must contain only
+ records for which that Responder is explicitly authoritative. These
+ answers may be generated because the record answers a question
+ received in a Multicast DNS query packet, or at certain other times
+ that the responder determines than an unsolicited announcement is
+ warranted. A Multicast DNS Responder MUST NOT place records from its
+ cache, which have been learned from other responders on the network,
+ in the Answer Section of outgoing response packets. Only an
+ authoritative source for a given record is allowed to issue responses
+ containing that record.
+
+ The determination of whether a given record answers a given question
+ is done using the standard DNS rules: The record name must match the
+ question name, the record rrtype must match the question qtype
+ (unless the qtype is "ANY"), and the record rrclass must match the
+ question qclass (unless the qclass is "ANY").
+
+ A Multicast DNS Responder MUST only respond when it has a positive
+ non-null response to send. Error responses must never be sent. The
+ non-existence of any name in a Multicast DNS Domain is ascertained by
+ the failure of any machine to respond to the Multicast DNS query, not
+ by NXDOMAIN errors.
+
+ Multicast DNS Responses MUST NOT contain any questions in the
+ Question Section. Any questions in the Question Section of a received
+ Multicast DNS Response MUST be silently ignored. Multicast DNS
+ Queriers receiving Multicast DNS Responses do not care what question
+ elicited the response; they care only that the information in the
+ response is true and accurate.
+
+ A Multicast DNS Responder on Ethernet [IEEE802] and similar shared
+ multiple access networks SHOULD have the capability of delaying its
+ responses by up to 500ms, as determined by the rules described below.
+ If multiple Multicast DNS Responders were all to respond immediately
+ to a particular query, a collision would be virtually guaranteed. By
+ imposing a small random delay, the number of collisions is
+ dramatically reduced. On a full-sized Ethernet using the maximum
+ cable lengths allowed and the maximum number of repeaters allowed, an
+ Ethernet frame is vulnerable to collisions during the transmission of
+ its first 256 bits. On 10Mb/s Ethernet, this equates to a vulnerable
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 15]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ time window of 25.6us. On higher-speed variants of Ethernet, the
+ vulnerable time window is shorter.
+
+ In the case where a Multicast DNS Responder has good reason to
+ believe that it will be the only responder on the link with a
+ positive non-null response, it SHOULD NOT impose any random delay
+ before responding, and SHOULD normally generate its response within
+ at most 10ms. In particular, this applies to responding to probe
+ queries. Since receiving a probe query gives a clear indication that
+ some other Responder is planning to start using this name in the very
+ near future, answering such probe queries to defend a unique record
+ is a high priority and needs to be done immediately, without delay. A
+ probe query can be distinguished from a normal query by the fact that
+ a probe query contains a proposed record in the Authority Section
+ which answers the question in the Question Section (for more details,
+ see Section 9.1, "Probing").
+
+ To generate immediate responses safely, it MUST have previously
+ verified that the requested name, rrtype and rrclass in the DNS query
+ are unique on this link. Responding immediately without delay is
+ appropriate for things like looking up the address record for a
+ particular host name, when the host name has been previously verified
+ unique. Responding immediately without delay is *not* appropriate for
+ things like looking up PTR records used for DNS Service Discovery
+ [DNS-SD], where a large number of responses may be anticipated.
+
+ In any case where there may be multiple responses, such as queries
+ where the answer is a member of a shared resource record set, each
+ responder SHOULD delay its response by a random amount of time
+ selected with uniform random distribution in the range 20-120ms.
+
+ In the case where the query has the TC (truncated) bit set,
+ indicating that subsequent known answer packets will follow,
+ responders SHOULD delay their responses by a random amount of time
+ selected with uniform random distribution in the range 400-500ms,
+ to allow enough time for all the known answer packets to arrive.
+
+ Except when a unicast reply has been explicitly requested via the
+ "unicast reply" bit, Multicast DNS Responses MUST be sent to UDP port
+ 5353 (the well-known port assigned to mDNS) on the 224.0.0.251
+ multicast address (or its IPv6 equivalent FF02::FB). Operating in a
+ Zeroconf environment requires constant vigilance. Just because a name
+ has been previously verified unique does not mean it will continue to
+ be so indefinitely. By allowing all Multicast DNS Responders to
+ constantly monitor their peers' responses, conflicts arising out of
+ network topology changes can be promptly detected and resolved.
+
+ Sending all responses by multicast also facilitates opportunistic
+ caching by other hosts on the network.
+
+ To protect the network against excessive packet flooding due to
+ software bugs or malicious attack, a Multicast DNS Responder MUST NOT
+ multicast a given record on a given interface if it has previously
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 16]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ multicast that record on that interface within the last second. A
+ legitimate client on the network should have seen the previous
+ transmission and cached it. A client that did not receive and cache
+ the previous transmission will retry its request and receive a
+ subsequent response. Under no circumstances is there any legitimate
+ reason for a Multicast DNS Responder to multicast a given record more
+ than once per second on any given interface.
+
+
+8.1 Legacy Unicast Responses
+
+ If the source UDP port in a received Multicast DNS Query is not port
+ 5353, this indicates that the client originating the query is a
+ simple client that does not fully implement all of Multicast DNS. In
+ this case, the Multicast DNS Responder MUST send a UDP response
+ directly back to the client, via unicast, to the query packet's
+ source IP address and port. This unicast response MUST be a
+ conventional unicast response as would be generated by a conventional
+ unicast DNS server; for example, it MUST repeat the query ID and the
+ question given in the query packet.
+
+ The resource record TTL given in a legacy unicast response SHOULD NOT
+ be greater than ten seconds, even if the true TTL of the Multicast
+ DNS resource record is higher. This is because Multicast DNS
+ Responders that fully participate in the protocol use the cache
+ coherency mechanisms described in Section 13 to update and invalidate
+ stale data. Were unicast responses sent to legacy clients to use the
+ same high TTLs, these legacy clients, which do not implement these
+ cache coherency mechanisms, could retain stale cached resource record
+ data long after it is no longer valid.
+
+ Having sent this unicast response, if the Responder has not sent this
+ record in any multicast response recently, it SHOULD schedule the
+ record to be sent via multicast as well, to facilitate passive
+ conflict detection. "Recently" in this context means "if the time
+ since the record was last sent via multicast is less than one quarter
+ of the record's TTL".
+
+
+8.2 Multi-Question Queries
+
+ Multicast DNS Responders MUST correctly handle DNS query packets
+ containing more than one question, by answering any or all of the
+ questions to which they have answers. Any (non-defensive) answers
+ generated in response to query packets containing more than one
+ question SHOULD be randomly delayed in the range 20-120ms, or
+ 400-500ms if the TC (truncated) bit is set, as described above.
+ (Answers defending a name, in response to a probe for that name,
+ are not subject to this delay rule and are still sent immediately.)
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 17]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+8.3 Response Aggregation
+
+ When possible, a responder SHOULD, for the sake of network
+ efficiency, aggregate as many responses as possible into a single
+ Multicast DNS response packet. For example, when a responder has
+ several responses it plans to send, each delayed by a different
+ interval, then earlier responses SHOULD be delayed by up to an
+ additional 500ms if that will permit them to be aggregated with
+ other responses scheduled to go out a little later.
+
+
+9. Probing and Announcing on Startup
+
+ Typically a Multicast DNS Responder should have, at the very least,
+ address records for all of its active interfaces. Creating and
+ advertising an HINFO record on each interface as well can be useful
+ to network administrators.
+
+ Whenever a Multicast DNS Responder starts up, wakes up from sleep,
+ receives an indication of an Ethernet "Link Change" event, or has any
+ other reason to believe that its network connectivity may have
+ changed in some relevant way, it MUST perform the two startup steps
+ below.
+
+
+9.1 Probing
+
+ The first startup step is that for all those resource records that a
+ Multicast DNS Responder desires to be unique on the local link, it
+ MUST send a Multicast DNS Query asking for those resource records, to
+ see if any of them are already in use. The primary example of this is
+ its address record which maps its unique host name to its unique IP
+ address. All Probe Queries SHOULD be done using the desired resource
+ record name and query type T_ANY (255), to elicit answers for all
+ types of records with that name. This allows a single question to be
+ used in place of several questions, which is more efficient on the
+ network. It also allows a host to verify exclusive ownership of a
+ name, which is desirable in most cases. It would be confusing, for
+ example, if one host owned the "A" record for "myhost.local.", but a
+ different host owned the HINFO record for that name.
+
+ The ability to place more than one question in a Multicast DNS Query
+ is useful here, because it can allow a host to use a single packet
+ for all of its resource records instead of needing a separate packet
+ for each. For example, a host can simultaneously probe for uniqueness
+ of its "A" record and all its SRV records [DNS-SD] in the same query
+ packet.
+
+ When ready to send its mDNS probe packet(s) the host should first
+ wait for a short random delay time, uniformly distributed in the
+ range 0-250ms. This random delay is to guard against the case where a
+ group of devices are powered on simultaneously, or a group of devices
+ are connected to an Ethernet hub which is then powered on, or some
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 18]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ other external event happens that might cause a group of hosts to all
+ send synchronized probes.
+
+ 250ms after the first query the host should send a second, then
+ 250ms after that a third. If, by 250ms after the third probe, no
+ conflicting Multicast DNS responses have been received, the host may
+ move to the next step, announcing. (Note that this is the one
+ exception from the normal rule that there should be at least one
+ second between repetitions of the same question, and the interval
+ between subsequent repetitions should double.)
+
+ If any conflicting Multicast DNS responses are received, then the
+ probing host MUST defer to the existing host, and MUST choose new
+ names for some or all of its resource records as appropriate, to
+ avoid conflict with pre-existing hosts on the network. In the case
+ of a host probing using query type T_ANY as recommended above, any
+ answer containing a record with that name, of any type, MUST be
+ considered a conflicting response and handled accordingly.
+
+ If fifteen failures occur within any ten-second period, then the host
+ MUST wait at least five seconds before each successive additional
+ probe attempt. This is to help ensure that in the event of software
+ bugs or other unanticipated problems, errant hosts do not flood the
+ network with a continuous stream of multicast traffic. For very
+ simple devices, a valid way to comply with this requirement is to
+ always wait five seconds after any failed probe attempt.
+
+ If a responder knows by other means, with absolute certainty, that
+ its unique resource record set name, rrtype and rrclass cannot
+ already be in use by any other responder on the network, then it MAY
+ skip the probing step for that resource record set. For example, when
+ creating the reverse address mapping PTR records, the host can
+ reasonably assume that no other host will be trying to create those
+ same PTR records, since that would imply that the two hosts were
+ trying to use the same IP address, and if that were the case, the two
+ hosts would be suffering communication problems beyond the scope of
+ what Multicast DNS is designed to solve.
+
+
+9.2 Simultaneous Probe Tie-Breaking
+
+ The astute reader will observe that there is a race condition
+ inherent in the previous description. If two hosts are probing for
+ the same name simultaneously, neither will receive any response to
+ the probe, and the hosts could incorrectly conclude that they may
+ both proceed to use the name. To break this symmetry, each host
+ populates the Authority Section of its queries with records giving
+ the rdata that it would be proposing to use, should its probing be
+ successful. The Authority Section is being used here in a way
+ analogous to the Update Section of a DNS Update packet [RFC 2136].
+
+ When a host that is probing for a record sees another host issue a
+ query for the same record, it consults the Authority Section of that
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 19]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ query. If it finds any resource record there which answers the query,
+ then it compares the data of that resource record with its own
+ tentative data. The lexicographically later data wins. This means
+ that if the host finds that its own data is lexicographically later,
+ it simply ignores the other host's probe. If the host finds that its
+ own data is lexicographically earlier, then it treats this exactly
+ as if it had received a positive answer to its query, and concludes
+ that it may not use the desired name.
+
+ The determination of 'lexicographically later' is performed by first
+ comparing the record class, then the record type, then raw comparison
+ of the binary content of the rdata without regard for meaning or
+ structure. If the record classes differ, then the numerically greater
+ class is considered 'lexicographically later'. Otherwise, if the
+ record types differ, then the numerically greater type is considered
+ 'lexicographically later'. If the rrtype and rrclass both match then
+ the rdata is compared.
+
+ In the case of resource records containing rdata that is subject to
+ name compression, the names MUST be uncompressed before comparison.
+ (The details of how a particular name is compressed is an artifact of
+ how and where the record is written into the DNS message; it is not
+ an intrinsic property of the resource record itself.)
+
+ The bytes of the raw uncompressed rdata are compared in turn,
+ interpreting the bytes as eight-bit UNSIGNED values, until a byte
+ is found whose value is greater than that of its counterpart (in
+ which case the rdata whose byte has the greater value is deemed
+ lexicographically later) or one of the resource records runs out
+ of rdata (in which case the resource record which still has
+ remaining data first is deemed lexicographically later).
+
+ The following is an example of a conflict:
+
+ cheshire.local. A 169.254.99.200
+ cheshire.local. A 169.254.200.50
+
+ In this case 169.254.200.50 is lexicographically later (the third
+ byte, with value 200, is greater than its counterpart with value 99),
+ so it is deemed the winner.
+
+ Note that it is vital that the bytes are interpreted as UNSIGNED
+ values, or the wrong outcome may result. In the example above, if
+ the byte with value 200 had been incorrectly interpreted as a
+ signed value then it would be interpreted as value -56, and the
+ wrong address record would be deemed the winner.
+
+
+9.3 Announcing
+
+ The second startup step is that the Multicast DNS Responder MUST send
+ a gratuitous Multicast DNS Response containing, in the Answer
+ Section, all of its resource records (both shared records, and unique
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 20]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ records that have completed the probing step). If there are too many
+ resource records to fit in a single packet, multiple packets should
+ be used.
+
+ In the case of shared records (e.g. the PTR records used by DNS
+ Service Discovery [DNS-SD]), the records are simply placed as-is
+ into the Answer Section of the DNS Response.
+
+ In the case of records that have been verified to be unique in the
+ previous step, they are placed into the Answer Section of the DNS
+ Response with the most significant bit of the rrclass set to one.
+ The most significant bit of the rrclass for a record in the Answer
+ Section of a response packet is the mDNS "cache flush" bit and is
+ discussed in more detail below in Section 11.3 "Announcements to
+ Flush Outdated Cache Entries".
+
+ The Multicast DNS Responder MUST send at least two gratuitous
+ responses, one second apart. A Responder MAY send up to ten
+ gratuitous Responses, provided that the interval between gratuitous
+ responses doubles with every response sent.
+
+ A Multicast DNS Responder SHOULD NOT continue sending gratuitous
+ Responses for longer than the TTL of the record. The purpose of
+ announcing new records via gratuitous Responses is to ensure that
+ peer caches are up to date. After a time interval equal to the TTL of
+ the record has passed, it is very likely that old stale copies of
+ that record in peer caches will have expired naturally, so subsequent
+ announcements serve little purpose.
+
+ A Multicast DNS Responder MUST NOT send announcements in the absence
+ of information that its network connectivity may have changed in some
+ relevant way. In particular, a Multicast DNS Responder MUST NOT send
+ regular periodic announcements as a matter of course.
+
+ Whenever a Multicast DNS Responder receives any Multicast DNS
+ response (gratuitous or otherwise) containing a conflicting resource
+ record, the conflict MUST be resolved as described below in "Conflict
+ Resolution".
+
+9.4 Updating
+
+ At any time, if the rdata of any of a host's Multicast DNS records
+ changes, the host MUST repeat the Announcing step described above to
+ update neighboring caches. For example, if any of a host's IP
+ addresses change, it MUST re-announce those address records.
+
+ In the case of shared records, a host MUST send a 'goodbye'
+ announcement with TTL zero (see Section 11.2 "Goodbye Packets")
+ for the old rdata, to cause it to be deleted from peer caches,
+ before announcing the new rdata. In the case of unique records,
+ a host SHOULD omit the 'goodbye' announcement, since the cache
+ flush bit on the newly announced records will cause old rdata
+ to be flushed from peer caches anyway.
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 21]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ A host may update the contents of any of its records at any time,
+ though a host SHOULD NOT update records more frequently than ten
+ times per minute. Frequent rapid updates impose a burden on the
+ network. If a host has information to disseminate which changes more
+ frequently than ten times per minute, then it may be more appropriate
+ to design a protocol for that specific purpose.
+
+
+10. Conflict Resolution
+
+ A conflict occurs when a Multicast DNS Responder has a unique record
+ for which it is authoritative, and it receives, in the Answer Section
+ of a Multicast DNS response another record with the same name, rrtype
+ and rrclass, but inconsistent rdata. What may be considered
+ inconsistent is context sensitive, except that resource records with
+ identical rdata are never considered inconsistent, even if they
+ originate from different hosts. This is to permit use of proxies and
+ other fault-tolerance mechanisms that may cause more than one
+ responder to be capable of issuing identical answers on the network.
+
+ A common example of a resource record type that is intended to be
+ unique, not shared between hosts, is the address record that maps a
+ host's name to its IP address. Should a host witness another host
+ announce an address record with the same name but a different IP
+ address, then that is considered inconsistent, and that address
+ record is considered to be in conflict.
+
+ Whenever a Multicast DNS Responder receives any Multicast DNS
+ response (gratuitous or otherwise) containing a conflicting resource
+ record in the Answer Section, the Multicast DNS Responder MUST
+ immediately reset its conflicted unique record to probing state, and
+ go through the startup steps described above in Section 9. "Probing
+ and Announcing on Startup". The protocol used in the Probing phase
+ will determine a winner and a loser, and the loser MUST cease using
+ the name, and reconfigure.
+
+ It is very important that any host receiving a resource record that
+ conflicts with one of its own MUST take action as described above.
+ In the case of two hosts using the same host name, where one has been
+ configured to require a unique host name and the other has not, the
+ one that has not been configured to require a unique host name will
+ not perceive any conflict, and will not take any action. By reverting
+ to Probing state, the host that desires a unique host name will go
+ through the necessary steps to ensure that a unique host is obtained.
+
+ The recommended course of action after probing and failing is as
+ follows:
+
+ o Programmatically change the resource record name in an attempt to
+ find a new name that is unique. This could be done by adding some
+ further identifying information (e.g. the model name of the
+ hardware) if it is not already present in the name, appending the
+ digit "2" to the name, or incrementing a number at the end of the
+ name if one is already present.
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 22]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ o Probe again, and repeat until a unique name is found.
+
+ o Record this newly chosen name in persistent storage so that the
+ device will use the same name the next time it is power-cycled.
+
+ o Display a message to the user or operator informing them of the
+ name change. For example:
+
+ The name "Bob's Music" is in use by another iTunes music
+ server on the network. Your music has been renamed to
+ "Bob's Music (G4 Cube)". If you want to change this name,
+ use [describe appropriate menu item or preference dialog].
+
+ How the user or operator is informed depends on context. A desktop
+ computer with a screen might put up a dialog box. A headless server
+ in the closet may write a message to a log file, or use whatever
+ mechanism (email, SNMP trap, etc.) it uses to inform the
+ administrator of other error conditions. On the other hand a headless
+ server in the closet may not inform the user at all -- if the user
+ cares, they will notice the name has changed, and connect to the
+ server in the usual way (e.g. via Web Browser) to configure a new
+ name.
+
+ The examples in this section focus on address records (i.e. host
+ names), but the same considerations apply to all resource records
+ where uniqueness (or maintenance of some other defined constraint)
+ is desired.
+
+
+
+11. Resource Record TTL Values and Cache Coherency
+
+ As a general rule, the recommended TTL value for Multicast DNS
+ resource records with a host name as the resource record's name
+ (e.g. A, AAAA, HINFO, etc.) or contained within the resource record's
+ rdata (e.g. SRV, reverse mapping PTR record, etc.) is 120 seconds.
+
+ The recommended TTL value for other Multicast DNS resource records
+ is 75 minutes.
+
+ A client with an active outstanding query will issue a query packet
+ when one or more of the resource record(s) in its cache is (are) 80%
+ of the way to expiry. If the TTL on those records is 75 minutes,
+ this ongoing cache maintenance process yields a steady-state query
+ rate of one query every 60 minutes.
+
+ Any distributed cache needs a cache coherency protocol. If Multicast
+ DNS resource records follow the recommendation and have a TTL of 75
+ minutes, that means that stale data could persist in the system for
+ a little over an hour. Making the default TTL significantly lower
+ would reduce the lifetime of stale data, but would produce too much
+ extra traffic on the network. Various techniques are available to
+ minimize the impact of such stale data.
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 23]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+11.1 Cooperating Multicast DNS Responders
+
+ If a Multicast DNS Responder ("A") observes some other Multicast DNS
+ Responder ("B") send a Multicast DNS Response packet containing a
+ resource record with the same name, rrtype and rrclass as one of A's
+ resource records, but different rdata, then:
+
+ o If A's resource record is intended to be a shared resource record,
+ then this is no conflict, and no action is required.
+
+ o If A's resource record is intended to be a member of a unique
+ resource record set owned solely by that responder, then this
+ is a conflict and MUST be handled as described in Section 10
+ "Conflict Resolution".
+
+ If a Multicast DNS Responder ("A") observes some other Multicast DNS
+ Responder ("B") send a Multicast DNS Response packet containing a
+ resource record with the same name, rrtype and rrclass as one of A's
+ resource records, and identical rdata, then:
+
+ o If the TTL of B's resource record given in the packet is at least
+ half the true TTL from A's point of view, then no action is
+ required.
+
+ o If the TTL of B's resource record given in the packet is less than
+ half the true TTL from A's point of view, then A MUST mark its
+ record to be announced via multicast. Clients receiving the record
+ from B would use the TTL given by B, and hence may delete the
+ record sooner than A expects. By sending its own multicast response
+ correcting the TTL, A ensures that the record will be retained for
+ the desired time.
+
+ These rules allow multiple Multicast DNS Responders to offer the same
+ data on the network (perhaps for fault tolerance reasons) without
+ conflicting with each other.
+
+
+11.2 Goodbye Packets
+
+ In the case where a host knows that certain resource record data is
+ about to become invalid (for example when the host is undergoing a
+ clean shutdown) the host SHOULD send a gratuitous announcement mDNS
+ response packet, giving the same resource record name, rrtype,
+ rrclass and rdata, but an RR TTL of zero. This has the effect of
+ updating the TTL stored in neighboring hosts' cache entries to zero,
+ causing that cache entry to be promptly deleted.
+
+ Clients receiving a Multicast DNS Response with a TTL of zero SHOULD
+ NOT immediately delete the record from the cache, but instead record
+ a TTL of 1 and then delete the record one second later. In the case
+ of multiple Multicast DNS Responders on the network described in
+ Section 11.1 above, if one of the Responders shuts down and
+ incorrectly sends goodbye packets for its records, it gives the other
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 24]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ cooperating Responders one second to send out their own response to
+ "rescue" the records before they expire and are deleted.
+
+ Generally speaking, it is more important to send goodbye packets for
+ shared records than unique records. A given shared record name (such
+ as a PTR record used for DNS Service Discovery [DNS-SD]) by its
+ nature often has many representatives from many different hosts, and
+ tends to be the subject of long-lived ongoing queries. Those
+ long-lived queries are often concerned not just about being informed
+ when records appear, but also about being informed if those records
+ vanish again. In contrast, a unique record set (such as an SRV
+ record, or a host address record), by its nature, often has far fewer
+ members than a shared record set, and is usually the subject of
+ one-shot queries which simply retrieve the data and then cease
+ querying once they have the answer they are seeking. Therefore,
+ sending a goodbye packet for a unique record set is likely to offer
+ less benefit, because it is likely at any given moment that no one
+ has an active query running for that record set. One example where
+ goodbye packets for SRV and address records are useful is when
+ transferring control to a Sleep Proxy Server (see Section 16,
+ "Multicast DNS and Power Management").
+
+
+11.3 Announcements to Flush Outdated Cache Entries
+
+ Whenever a host has a resource record with potentially new data (e.g.
+ after rebooting, waking from sleep, connecting to a new network link,
+ changing IP address, etc.), the host MUST send a series of gratuitous
+ announcements to update cache entries in its neighbor hosts. In
+ these gratuitous announcements, if the record is one that is intended
+ to be unique, the host sets the most significant bit of the rrclass
+ field of the resource record. This bit, the "cache flush" bit, tells
+ neighboring hosts that this is not a shared record type. Instead of
+ merging this new record additively into the cache in addition to any
+ previous records with the same name, rrtype and rrclass, all old
+ records with that name, type and class that were received more than
+ one second ago are declared invalid, and marked to expire from the
+ cache in one second.
+
+ The semantics of the cache flush bit are as follows: Normally when a
+ resource record appears in the Answer Section of the DNS Response, it
+ means, "This is an assertion that this information is true." When a
+ resource record appears in the Answer Section of the DNS Response
+ with the "cache flush" bit set, it means, "This is an assertion that
+ this information is the truth and the whole truth, and anything you
+ may have heard more than a second ago regarding records of this
+ name/rrtype/rrclass is no longer valid".
+
+ To accommodate the case where the set of records from one host
+ constituting a single unique RRSet is too large to fit in a single
+ packet, only cache records that are more than one second old are
+ flushed. This allows the announcing host to generate a quick burst of
+ packets back-to-back on the wire containing all the members
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 25]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ of the RRSet. When receiving records with the "cache flush" bit set,
+ all records older than one second are marked to be deleted one second
+ in the future. One second after the end of the little packet burst,
+ any records not represented within that packet burst will then be
+ expired from all peer caches.
+
+ Any time a host sends a response packet containing some members of a
+ unique RRSet, it SHOULD send the entire RRSet, preferably in a single
+ packet, or if the entire RRSet will not fit in a single packet, in a
+ quick burst of packets sent as close together as possible. The host
+ SHOULD set the cache flush bit on all members of the unique RRSet.
+ In the event that for some reason the host chooses not to send the
+ entire unique RRSet in a single packet or a rapid packet burst,
+ it MUST NOT set the cache flush bit on any of those records.
+
+ The reason for waiting one second before deleting stale records from
+ the cache is to accommodate bridged networks. For example, a host's
+ address record announcement on a wireless interface may be bridged
+ onto a wired Ethernet, and cause that same host's Ethernet address
+ records to be flushed from peer caches. The one-second delay gives
+ the host the chance to see its own announcement arrive on the wired
+ Ethernet, and immediately re-announce its Ethernet interface's
+ address records so that both sets remain valid and live in peer
+ caches.
+
+ These rules apply regardless of *why* the response packet is being
+ generated. They apply to startup announcements as described in
+ Section 9.3, and to responses generated as a result of receiving
+ query packets.
+
+ The "cache flush" bit is only set in records in the Answer Section of
+ Multicast DNS responses sent to UDP port 5353. The "cache flush" bit
+ MUST NOT be set in any resource records in a response packet sent in
+ legacy unicast responses to UDP ports other than 5353.
+
+ The "cache flush" bit MUST NOT be set in any resource records in the
+ known-answer list of any query packet.
+
+ The "cache flush" bit MUST NOT ever be set in any shared resource
+ record. To do so would cause all the other shared versions of this
+ resource record with different rdata from different Responders to be
+ immediately deleted from all the caches on the network.
+
+ The "cache flush" bit does apply to questions listed in the Question
+ Section of a Multicast DNS packet. The top bit of the rrclass field
+ in questions is used for an entirely different purpose (see Section
+ 6.5, "Questions Requesting Unicast Responses").
+
+ Note that the "cache flush" bit is NOT part of the resource record
+ class. The "cache flush" bit is the most significant bit of the
+ second 16-bit word of a resource record in the Answer Section of
+ an mDNS packet (the field conventionally referred to as the rrclass
+ field), and the actual resource record class is the least-significant
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 26]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ fifteen bits of this field. There is no mDNS resource record class
+ 0x8001. The value 0x8001 in the rrclass field of a resource record in
+ an mDNS response packet indicates a resource record with class 1,
+ with the "cache flush" bit set. When receiving a resource record with
+ the "cache flush" bit set, implementations should take care to mask
+ off that bit before storing the resource record in memory.
+
+
+11.4 Cache Flush on Topology change
+
+ If the hardware on a given host is able to indicate physical changes
+ of connectivity, then when the hardware indicates such a change, the
+ host should take this information into account in its mDNS cache
+ management strategy. For example, a host may choose to immediately
+ flush all cache records received on a particular interface when that
+ cable is disconnected. Alternatively, a host may choose to adjust the
+ remaining TTL on all those records to a few seconds so that if the
+ cable is not reconnected quickly, those records will expire from the
+ cache.
+
+ Likewise, when a host reboots, or wakes from sleep, or undergoes some
+ other similar discontinuous state change, the cache management
+ strategy should take that information into account.
+
+
+11.5 Cache Flush on Failure Indication
+
+ Sometimes a cache record can be determined to be stale when a client
+ attempts to use the rdata it contains, and finds that rdata to be
+ incorrect.
+
+ For example, the rdata in an address record can be determined to be
+ incorrect if attempts to contact that host fail, either because
+ ARP/ND requests for that address go unanswered (for an address on a
+ local subnet) or because a router returns an ICMP "Host Unreachable"
+ error (for an address on a remote subnet).
+
+ The rdata in an SRV record can be determined to be incorrect if
+ attempts to communicate with the indicated service at the host and
+ port number indicated are not successful.
+
+ The rdata in a DNS-SD PTR record can be determined to be incorrect if
+ attempts to look up the SRV record it references are not successful.
+
+ In any such case, the software implementing the mDNS resource record
+ cache should provide a mechanism so that clients detecting stale
+ rdata can inform the cache.
+
+ When the cache receives this hint that it should reconfirm some
+ record, it MUST issue two or more queries for the resource record in
+ question. If no response is received in a reasonable amount of time,
+ then, even though its TTL may indicate that it is not yet due to
+ expire, that record SHOULD be promptly flushed from the cache.
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 27]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ The end result of this is that if a printer suffers a sudden power
+ failure or other abrupt disconnection from the network, its name may
+ continue to appear in DNS-SD browser lists displayed on users'
+ screens. Eventually that entry will expire from the cache naturally,
+ but if a user tries to access the printer before that happens, the
+ failure to successfully contact the printer will trigger the more
+ hasty demise of its cache entries. This is a sensible trade-off
+ between good user-experience and good network efficiency. If we were
+ to insist that printers should disappear from the printer list within
+ 30 seconds of becoming unavailable, for all failure modes, the only
+ way to achieve this would be for the client to poll the printer at
+ least every 30 seconds, or for the printer to announce its presence
+ at least every 30 seconds, both of which would be an unreasonable
+ burden on most networks.
+
+
+11.6 Passive Observation of Failures
+
+ A host observes the multicast queries issued by the other hosts on
+ the network. One of the major benefits of also sending responses
+ using multicast is that it allows all hosts to see the responses (or
+ lack thereof) to those queries.
+
+ If a host sees queries, for which a record in its cache would be
+ expected to be given as an answer in a multicast response, but no
+ such answer is seen, then the host may take this as an indication
+ that the record may no longer be valid.
+
+ After seeing two or more of these queries, and seeing no multicast
+ response containing the expected answer within a reasonable amount of
+ time, then even though its TTL may indicate that it is not yet due to
+ expire, that record MAY be flushed from the cache. The host SHOULD
+ NOT perform its own queries to re-confirm that the record is truly
+ gone. If every host on a large network were to do this, it would
+ cause a lot of unnecessary multicast traffic. If host A sends
+ multicast queries that remain unanswered, then there is no reason to
+ suppose that host B or any other host is likely to be any more
+ successful.
+
+ The previous section, "Cache Flush on Failure Indication", describes
+ a situation where a user trying to print discovers that the printer
+ is no longer available. By implementing the passive observation
+ described here, when one user fails to contact the printer, all hosts
+ on the network observe that failure and update their caches
+ accordingly.
+
+
+12. Special Characteristics of Multicast DNS Domains
+
+ Unlike conventional DNS names, names that end in ".local.",
+ "254.169.in-addr.arpa." or "0.8.e.f.ip6.arpa." have only local
+ significance. Conventional DNS seeks to provide a single unified
+ namespace, where a given DNS query yields the same answer no matter
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 28]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ where on the planet it is performed or to which recursive DNS server
+ the query is sent. (However, split views, firewalls, intranets and
+ the like have somewhat interfered with this goal of DNS representing
+ a single universal truth.) In contrast, each IP link has its own
+ private ".local.", "254.169.in-addr.arpa." and "0.8.e.f.ip6.arpa."
+ namespaces, and the answer to any query for a name within those
+ domains depends on where that query is asked.
+
+ Multicast DNS Domains are not delegated from their parent domain via
+ use of NS records. There are no NS records anywhere in Multicast DNS
+ Domains. Instead, all Multicast DNS Domains are delegated to the IP
+ addresses 224.0.0.251 and FF02::FB by virtue of the individual
+ organizations producing DNS client software deciding how to handle
+ those names. It would be extremely valuable for the industry if this
+ special handling were ratified and recorded by IANA, since otherwise
+ the special handling provided by each vendor is likely to be
+ inconsistent.
+
+ The IPv4 name server for a Multicast DNS Domain is 224.0.0.251. The
+ IPv6 name server for a Multicast DNS Domain is FF02::FB. These are
+ multicast addresses; therefore they identify not a single host but a
+ collection of hosts, working in cooperation to maintain some
+ reasonable facsimile of a competently managed DNS zone. Conceptually
+ a Multicast DNS Domain is a single DNS zone, however its server is
+ implemented as a distributed process running on a cluster of loosely
+ cooperating CPUs rather than as a single process running on a single
+ CPU.
+
+ No delegation is performed within Multicast DNS Domains. Because the
+ cluster of loosely coordinated CPUs is cooperating to administer a
+ single zone, delegation is neither necessary nor desirable. Just
+ because a particular host on the network may answer queries for a
+ particular record type with the name "example.local." does not imply
+ anything about whether that host will answer for the name
+ "child.example.local.", or indeed for other record types with the
+ name "example.local."
+
+ Multicast DNS Zones have no SOA record. A conventional DNS zone's
+ SOA record contains information such as the email address of the zone
+ administrator and the monotonically increasing serial number of the
+ last zone modification. There is no single human administrator for
+ any given Multicast DNS Zone, so there is no email address. Because
+ the hosts managing any given Multicast DNS Zone are only loosely
+ coordinated, there is no readily available monotonically increasing
+ serial number to determine whether or not the zone contents have
+ changed. A host holding part of the shared zone could crash or be
+ disconnected from the network at any time without informing the other
+ hosts. There is no reliable way to provide a zone serial number that
+ would, whenever such a crash or disconnection occurred, immediately
+ change to indicate that the contents of the shared zone had changed.
+
+ Zone transfers are not possible for any Multicast DNS Zone.
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 29]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+13. Multicast DNS for Service Discovery
+
+ This document does not describe using Multicast DNS for network
+ browsing or service discovery. However, the mechanisms this document
+ describes are compatible with (and support) the browsing and service
+ discovery mechanisms proposed in "DNS-Based Service Discovery"
+ [DNS-SD].
+
+
+14. Enabling and Disabling Multicast DNS
+
+ The option to fail-over to Multicast DNS for names not ending in
+ ".local." SHOULD be a user-configured option, and SHOULD
+ be disabled by default because of the possible security issues
+ related to unintended local resolution of apparently global names.
+
+ The option to lookup unqualified (relative) names by appending
+ ".local." (or not) is controlled by whether ".local." appears
+ (or not) in the client's DNS search list.
+
+ No special control is needed for enabling and disabling Multicast DNS
+ for names explicitly ending with ".local." as entered by the user.
+ The user doesn't need a way to disable Multicast DNS for names ending
+ with ".local.", because if the user doesn't want to use Multicast
+ DNS, they can achieve this by simply not using those names. If a user
+ *does* enter a name ending in ".local.", then we can safely assume
+ the user's intention was probably that it should work. Having user
+ configuration options that can be (intentionally or unintentionally)
+ set so that local names don't work is just one more way of
+ frustrating the user's ability to perform the tasks they want,
+ perpetuating the view that, "IP networking is too complicated to
+ configure and too hard to use." This in turn perpetuates the
+ continued use of protocols like AppleTalk. If we want to retire
+ AppleTalk, NetBIOS, etc., we need to offer users equivalent IP
+ functionality that they can rely on to, "always work, like
+ AppleTalk." A little Multicast DNS traffic may be a burden on the
+ network, but it is an insignificant burden compared to continued
+ widespread use of AppleTalk.
+
+
+15. Considerations for Multiple Interfaces
+
+ A host should defend its host name (FQDN) on all active interfaces on
+ which it is answering Multicast DNS queries.
+
+ In the event of a name conflict on *any* interface, a host should
+ configure a new host name, if it wishes to maintain uniqueness of its
+ host name.
+
+ A host may choose to use the same name for all of its address records
+ on all interfaces, or it may choose to manage its Multicast DNS host
+ name(s) independently on each interface, potentially answering to
+ different names on different interfaces.
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 30]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ When answering a Multicast DNS query, a multi-homed host with a
+ link-local address (or addresses) should take care to ensure that
+ any address going out in a Multicast DNS response is valid for use
+ on the interface on which the response is going out.
+
+ Just as the same link-local IP address may validly be in use
+ simultaneously on different links by different hosts, the same
+ link-local host name may validly be in use simultaneously on
+ different links, and this is not an error. A multi-homed host with
+ connections to two different links may be able to communicate with
+ two different hosts that are validly using the same name. While this
+ kind of name duplication should be rare, it means that a host that
+ wants to fully support this case needs network programming APIs that
+ allow applications to specify on what interface to perform a
+ link-local Multicast DNS query, and to discover on what interface a
+ Multicast DNS response was received.
+
+
+16. Multicast DNS and Power Management
+
+ Many modern network devices have the ability to go into a low-power
+ mode where only a small part of the Ethernet hardware remains
+ powered, and the device can be woken up by sending a specially
+ formatted Ethernet frame which the device's power-management hardware
+ recognizes.
+
+ To make use of this in conjunction with Multicast DNS, we propose a
+ network power management service called Sleep Proxy Service. A device
+ that wishes to enter low-power mode first uses DNS-SD to determine if
+ Sleep Proxy Service is available on the local network. In some
+ networks there may be more than one piece of hardware implementing
+ Sleep Proxy Service, for fault-tolerance reasons.
+
+ If the device finds the network has Sleep Proxy Service, the device
+ transmits two or more gratuitous mDNS announcements setting the TTL
+ of its relevant resource records to zero, to delete them from
+ neighboring caches. The relevant resource records include address
+ records and SRV records, and other resource records as may apply to a
+ particular device. The device then communicates all of its remaining
+ active records, plus the names, rrtypes and rrclasses of the deleted
+ records, to the Sleep Proxy Service(s), along with a copy of the
+ specific "magic packet" required to wake the device up.
+
+ When a Sleep Proxy Service sees an mDNS query for one of the
+ device's active records (e.g. a DNS-SD PTR record), it answers on
+ behalf of the device without waking it up. When a Sleep Proxy Service
+ sees an mDNS query for one of the device's deleted resource
+ records, it deduces that some client on the network needs to make an
+ active connection to the device, and sends the specified "magic
+ packet" to wake the device up. The device then wakes up, reactivates
+ its deleted resource records, and re-announces them to the network.
+ The client waiting to connect sees the announcements, learns the
+ current IP address and port number of the desired service on the
+ device, and proceeds to connect to it.
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 31]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ The connecting client does not need to be aware of how Sleep Proxy
+ Service works. Only devices that implement low power mode and wish to
+ make use of Sleep Proxy Service need to be aware of how that protocol
+ works.
+
+ The reason that a device using a Sleep Proxy Service should send more
+ than one goodbye packet is to ensure deletion of the resource records
+ from all peer caches. If resource records were to inadvertently
+ remain in some peer caches, then those peers may not issue any query
+ packets for those records when attempting to access the sleeping
+ device, so the Sleep Proxy Service would not receive any queries for
+ the device's SRV and/or address records, and the necessary wake-up
+ message would not be triggered.
+
+ The full specification of mDNS / DNS-SD Sleep Proxy Service
+ is described in another document [not yet published].
+
+
+17. Multicast DNS Character Set
+
+ Unicast DNS has been plagued by the lack of any support for non-US
+ characters. Indeed, conventional DNS is usually limited to just
+ letters, digits and hyphens, with no spaces or other punctuation.
+ Attempts to remedy this for unicast DNS have been badly constrained
+ by the need to accommodate old buggy legacy DNS implementations.
+ In reality, the DNS specification actually imposes no limits on what
+ characters may be used in names, and good DNS implementations handle
+ any arbitrary eight-bit data without trouble. However, the old rules
+ for ARPANET host names back in the 1980s required names to be just
+ letters, digits, and hyphens [RFC 1034], and since the predominant
+ use of DNS is to store host address records, many have assumed that
+ the DNS protocol itself suffers from the same limitation. It would be
+ more accurate to say that certain bad implementations may not handle
+ eight-bit data correctly, not that the protocol doesn't support it.
+
+ Multicast DNS is a new protocol and doesn't (yet) have old buggy
+ legacy implementations to constrain the design choices. Accordingly,
+ it adopts the simple obvious elegant solution: all names in Multicast
+ DNS are encoded using precomposed UTF-8 [RFC 3629]. The
+ characters SHOULD conform to Unicode Normalization Form C (NFC): Use
+ precomposed characters instead of combining sequences where possible,
+ e.g. use U+00C4 ("Latin capital letter A with diaeresis") instead of
+ U+0041 U+0308 ("Latin capital letter A", "combining diaeresis").
+
+ For names that are restricted to letters, digits and hyphens, the
+ UTF-8 encoding is identical to the US-ASCII encoding, so this is
+ entirely compatible with existing host names. For characters outside
+ the US-ASCII range, UTF-8 encoding is used.
+
+ Multicast DNS implementations MUST NOT use any other encodings apart
+ from precomposed UTF-8 (US-ASCII being considered a compatible subset
+ of UTF-8).
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 32]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ This point bears repeating: After many years of debate, as a result
+ of the need to accommodate certain DNS implementations that
+ apparently couldn't handle any character that's not a letter, digit
+ or hyphen (and apparently never will be updated to remedy this
+ limitation) the unicast DNS community settled on an extremely baroque
+ encoding called "Punycode" [RFC 3492]. Punycode is a remarkably
+ ingenious encoding solution, but it is complicated, hard to
+ understand, and hard to implement, using sophisticated techniques
+ including insertion unsort coding, generalized variable-length
+ integers, and bias adaptation. The resulting encoding is remarkably
+ compact given the constraints, but it's still not as good as simple
+ straightforward UTF-8, and it's hard even to predict whether a given
+ input string will encode to a Punycode string that fits within DNS's
+ 63-byte limit, except by simply trying the encoding and seeing
+ whether it fits. Indeed, the encoded size depends not only on the
+ input characters, but on the order they appear, so the same set of
+ characters may or may not encode to a legal Punycode string that fits
+ within DNS's 63-byte limit, depending on the order the characters
+ appear. This is extremely hard to present in a user interface that
+ explains to users why one name is allowed, but another name
+ containing the exact same characters is not. Neither Punycode nor any
+ other of the "Ascii Compatible Encodings" proposed for Unicast DNS
+ may be used in Multicast DNS packets. Any text being represented
+ internally in some other representation MUST be converted to
+ canonical precomposed UTF-8 before being placed in any Multicast DNS
+ packet.
+
+ The simple rules for case-insensitivity in Unicast DNS also apply in
+ Multicast DNS; that is to say, in name comparisons, the lower-case
+ letters "a" to "z" (0x61 to 0x7A) match their upper-case equivalents
+ "A" to "Z" (0x41 to 0x5A). Hence, if a client issues a query for an
+ address record with the name "cheshire.local", then a responder
+ having an address record with the name "Cheshire.local" should
+ issue a response. No other automatic equivalences should be assumed.
+ In particular all UTF-8 multi-byte characters (codes 0x80 and higher)
+ are compared by simple binary comparison of the raw byte values.
+
+ No other automatic character equivalence is defined in Multicast DNS.
+ For example, accented characters are not defined to be automatically
+ equivalent to their unaccented counterparts. Where automatic
+ equivalences are desired, this may be achieved through the use of
+ programmatically-generated CNAME records. For example, if a responder
+ has an address record for an accented name Y, and a client issues a
+ query for a name X, where X is the same as Y with all the accents
+ removed, then the responder may issue a response containing two
+ resource records: A CNAME record "X CNAME Y", asserting that the
+ requested name X (unaccented) is an alias for the true (accented)
+ name Y, followed by the address record for Y.
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 33]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+18. Multicast DNS Message Size
+
+ RFC 1035 restricts DNS Messages carried by UDP to no more than 512
+ bytes (not counting the IP or UDP headers). For UDP packets carried
+ over the wide-area Internet in 1987, this was appropriate. For
+ link-local multicast packets on today's networks, there is no reason
+ to retain this restriction. Given that the packets are by definition
+ link-local, there are no Path MTU issues to consider.
+
+ Multicast DNS Messages carried by UDP may be up to the IP MTU of the
+ physical interface, less the space required for the IP header (20
+ bytes for IPv4; 40 bytes for IPv6) and the UDP header (8 bytes).
+
+ In the case of a single mDNS Resource Record which is too large to
+ fit in a single MTU-sized multicast response packet, a Multicast DNS
+ Responder SHOULD send the Resource Record alone, in a single IP
+ datagram, sent using multiple IP fragments. Resource Records this
+ large SHOULD be avoided, except in the very rare cases where they
+ really are the appropriate solution to the problem at hand.
+ Implementers should be aware that many simple devices do not
+ re-assemble fragmented IP datagrams, so large Resource Records SHOULD
+ NOT be used except in specialized cases where the implementer knows
+ that all receivers implement reassembly.
+
+ A Multicast DNS packet larger than the interface MTU, which is sent
+ using fragments, MUST NOT contain more than one Resource Record.
+
+ Even when fragmentation is used, a Multicast DNS packet, including IP
+ and UDP headers, MUST NOT exceed 9000 bytes.
+
+
+19. Multicast DNS Message Format
+
+ This section describes specific restrictions on the allowable
+ values for the header fields of a Multicast DNS message.
+
+19.1. ID (Query Identifier)
+
+ Multicast DNS clients SHOULD listen for gratuitous responses
+ issued by hosts booting up (or waking up from sleep or otherwise
+ joining the network). Since these gratuitous responses may contain a
+ useful answer to a question for which the client is currently
+ awaiting an answer, Multicast DNS clients SHOULD examine all received
+ Multicast DNS response messages for useful answers, without regard to
+ the contents of the ID field or the Question Section. In Multicast
+ DNS, knowing which particular query message (if any) is responsible
+ for eliciting a particular response message is less interesting than
+ knowing whether the response message contains useful information.
+
+ Multicast DNS clients MAY cache any or all Multicast DNS response
+ messages they receive, for possible future use, provided of course
+ that normal TTL aging is performed on these cached resource records.
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 34]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ In multicast query messages, the Query ID SHOULD be set to zero on
+ transmission.
+
+ In multicast responses, including gratuitous multicast responses, the
+ Query ID MUST be set to zero on transmission, and MUST be ignored on
+ reception.
+
+ In unicast response messages generated specifically in response to a
+ particular (unicast or multicast) query, the Query ID MUST match the
+ ID from the query message.
+
+
+19.2. QR (Query/Response) Bit
+
+ In query messages, MUST be zero.
+
+ In response messages, MUST be one.
+
+
+19.3. OPCODE
+
+ In both multicast query and multicast response messages, MUST be zero
+ (only standard queries are currently supported over multicast, unless
+ other queries are allowed by future IETF Standards Action).
+
+
+19.4. AA (Authoritative Answer) Bit
+
+ In query messages, the Authoritative Answer bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+ In response messages for Multicast Domains, the Authoritative Answer
+ bit MUST be set to one (not setting this bit implies there's some
+ other place where "better" information may be found) and MUST be
+ ignored on reception.
+
+
+19.5. TC (Truncated) Bit
+
+ In query messages, if the TC bit is set, it means that additional
+ Known Answer records may be following shortly. A responder MAY choose
+ to record this fact, and wait for those additional Known Answer
+ records, before deciding whether to respond. If the TC bit is clear,
+ it means that the querying host has no additional Known Answers.
+
+ In multicast response messages, the TC bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+ In legacy unicast response messages, the TC bit has the same meaning
+ as in conventional unicast DNS: it means that the response was too
+ large to fit in a single packet, so the client SHOULD re-issue its
+ query using TCP in order to receive the larger response.
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 35]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+19.6. RD (Recursion Desired) Bit
+
+ In both multicast query and multicast response messages, the
+ Recursion Desired bit SHOULD be zero on transmission, and MUST be
+ ignored on reception.
+
+
+19.7. RA (Recursion Available) Bit
+
+ In both multicast query and multicast response messages, the
+ Recursion Available bit MUST be zero on transmission, and MUST be
+ ignored on reception.
+
+
+19.8. Z (Zero) Bit
+
+ In both query and response messages, the Zero bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+
+19.9. AD (Authentic Data) Bit [RFC 2535]
+
+ In query messages the Authentic Data bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+ In response messages, the Authentic Data bit MAY be set. Resolvers
+ receiving response messages with the AD bit set MUST NOT trust the AD
+ bit unless they trust the source of the message and either have a
+ secure path to it or use DNS transaction security.
+
+
+19.10. CD (Checking Disabled) Bit [RFC 2535]
+
+ In query messages, a resolver willing to do cryptography SHOULD set
+ the Checking Disabled bit to permit it to impose its own policies.
+
+ In response messages, the Checking Disabled bit MUST be zero on
+ transmission, and MUST be ignored on reception.
+
+
+19.11. RCODE (Response Code)
+
+ In both multicast query and multicast response messages, the Response
+ Code MUST be zero on transmission. Multicast DNS messages received
+ with non-zero Response Codes MUST be silently ignored.
+
+
+19.12. Repurposing of top bit of qclass in Question Section
+
+ In the Question Section of a Multicast DNS Query, the top bit of the
+ qclass field is used to indicate that unicast responses are preferred
+ for this particular question.
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 36]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+19.12. Repurposing of top bit of rrclass in Answer Section
+
+ In the Answer Section of a Multicast DNS Response, the top bit of the
+ rrclass field is used to indicate that the record is a member of a
+ unique RRSet, and the entire RRSet has been sent together (in the
+ same packet, or in consecutive packets if there are too many records
+ to fit in a single packet).
+
+
+20. Choice of UDP Port Number
+
+ Arguments were made for and against using Multicast on UDP port 53.
+ The final decision was to use UDP port 5353. Some of the arguments
+ for and against are given below.
+
+
+20.1 Arguments for using UDP port 53:
+
+ * This is "just DNS", so it should be the same port.
+
+ * There is less work to be done updating old clients to do simple
+ mDNS queries. Only the destination address need be changed.
+ In some cases, this can be achieved without any code changes,
+ just by adding the address 224.0.0.251 to a configuration file.
+
+
+20.2 Arguments for using a different port (UDP port 5353):
+
+ * This is not "just DNS". This is a DNS-like protocol, but different.
+
+ * Changing client code to use a different port number is not hard.
+
+ * Using the same port number makes it hard to run an mDNS Responder
+ and a conventional unicast DNS server on the same machine. If a
+ conventional unicast DNS server wishes to implement mDNS as well,
+ it can still do that, by opening two sockets. Having two different
+ port numbers is important to allow this flexibility.
+
+ * Some VPN software hijacks all outgoing traffic to port 53 and
+ redirects it to a special DNS server set up to serve those VPN
+ clients while they are connected to the corporate network. It is
+ questionable whether this is the right thing to do, but it is
+ common, and redirecting link-local multicast DNS packets to a
+ remote server rarely produces any useful results. It does mean, for
+ example, that the user becomes unable to access their local network
+ printer sitting on their desk right next to their computer. Using
+ a different UDP port eliminates this particular problem.
+
+ * On many operating systems, unprivileged clients may not send or
+ receive packets on low-numbered ports. This means that any client
+ sending or receiving mDNS packets on port 53 would have to run as
+ "root", which is an undesirable security risk. Using a higher-
+ numbered UDP port eliminates this particular problem.
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 37]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ Continuing the previous point, since using an unprivileged port
+ allows normal user-level code to bind, a given machine may have more
+ than one such user-level application running at a time. Because of
+ this, any code binding to UDP port 5353 MUST use the SO_REUSEPORT
+ option, so as to be a good citizen and not block other clients on the
+ machine from also binding to that port.
+
+
+21. Summary of Differences Between Multicast DNS and Unicast DNS
+
+ The value of Multicast DNS is that it shares, as much as possible,
+ the familiar APIs, naming syntax, resource record types, etc., of
+ Unicast DNS. There are of course necessary differences by virtue of
+ it using Multicast, and by virtue of it operating in a community of
+ cooperating peers, rather than a precisely defined authoritarian
+ hierarchy controlled by a strict chain of formal delegations from the
+ top. These differences are listed below:
+
+ Multicast DNS...
+ * uses multicast
+ * uses UDP port 5353 instead of port 53
+ * operates in well-defined parts of the DNS namespace
+ * uses UTF-8, and only UTF-8, to encode resource record names
+ * defines a clear limit on the maximum legal domain name (255 bytes)
+ * allows larger UDP packets
+ * allows more than one question in a query packet
+ * uses the Answer Section of a query to list Known Answers
+ * uses the TC bit in a query to indicate additional Known Answers
+ * uses the Authority Section of a query for probe tie-breaking
+ * ignores the Query ID field (except for generating legacy responses)
+ * doesn't require the question to be repeated in the response packet
+ * uses gratuitous responses to announce new records to the peer group
+ * defines a "unicast response" bit in the rrclass of query questions
+ * defines a "cache flush" bit in the rrclass of response answers
+ * uses DNS TTL 0 to indicate that a record has been deleted
+ * monitors queries to perform Duplicate Question Suppression
+ * monitors responses to perform Duplicate Answer Suppression...
+ * ... and Ongoing Conflict Detection
+ * ... and Opportunistic Caching
+
+
+22. Benefits of Multicast Responses
+
+ Some people have argued that sending responses via multicast is
+ inefficient on the network. In fact the benefits of using multicast
+ responses result in a net lowering of overall multicast traffic, for
+ a variety of reasons.
+
+ * One multicast response can update the cache on all machines on the
+ network. If another machine later wants to issue the same query, it
+ already has the answer in its cache, so it may not need to even
+ transmit that multicast query on the network at all.
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 38]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ * When more than one machine has the same ongoing long-lived query
+ running, every machine does not have to transmit its own
+ independent query. When one machine transmits a query, all the
+ other hosts see the answers, so they can suppress their own
+ queries.
+
+ * When a host sees a multicast query, but does not see the
+ corresponding multicast response, it can use this information to
+ promptly delete stale data from its cache. To achieve the same
+ level of user-interface quality and responsiveness without
+ multicast responses would require lower cache lifetimes and more
+ frequent network polling, resulting in a significantly higher
+ packet rate.
+
+ * Multicast responses allow passive conflict detection. Without this
+ ability, some other conflict detection mechanism would be needed,
+ imposing its own additional burden on the network.
+
+ * When using delayed responses to reduce network collisions, clients
+ need to maintain a list recording to whom each answer should be
+ sent. The option of multicast responses allows clients with limited
+ storage, which cannot store an arbitrarily long list of response
+ addresses, to choose to fail-over to a single multicast response in
+ place of multiple unicast responses, when appropriate.
+
+ * In the case of overlayed subnets and other misconfigurations,
+ multicast responses allow a receiver to know with certainty that
+ a response originated on the local link, even when its source
+ address may apparently suggest otherwise. This can be extremely
+ helpful when diagnosing and rectifying network problems, since
+ it facilitates a direct communication channel between client and
+ server that works without reliance on ARP, IP routing tables, etc.
+ Being able to discover what IP address a device has (or thinks it
+ has) is frequently a very valuable first step in diagnosing why
+ it unable to communicate on the local network.
+
+
+23. IPv6 Considerations
+
+ An IPv4-only host and an IPv6-only host behave as "ships that pass in
+ the night". Even if they are on the same Ethernet, neither is aware
+ of the other's traffic. For this reason, each physical link may have
+ *two* unrelated ".local." zones, one for IPv4 and one for IPv6.
+ Since for practical purposes, a group of IPv4-only hosts and a group
+ of IPv6-only hosts on the same Ethernet act as if they were on two
+ entirely separate Ethernet segments, it is unsurprising that their
+ use of the ".local." zone should occur exactly as it would if
+ they really were on two entirely separate Ethernet segments.
+
+ A dual-stack (v4/v6) host can participate in both ".local."
+ zones, and should register its name(s) and perform its lookups both
+ using IPv4 and IPv6. This enables it to reach, and be reached by,
+ both IPv4-only and IPv6-only hosts. In effect this acts like a
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 39]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ multi-homed host, with one connection to the logical "IPv4 Ethernet
+ segment", and a connection to the logical "IPv6 Ethernet segment".
+
+23.1 IPv6 Multicast Addresses by Hashing
+
+ Some discovery protocols use a range of multicast addresses, and
+ determine the address to be used by a hash function of the name being
+ sought. Queries are sent via multicast to the address as indicated by
+ the hash function, and responses are returned to the querier via
+ unicast. Particularly in IPv6, where multicast addresses are
+ extremely plentiful, this approach is frequently advocated.
+
+ There are some problems with this:
+
+ * When a host has a large number of records with different names, the
+ host may have to join a large number of multicast groups. This can
+ place undue burden on the Ethernet hardware, which typically
+ supports a limited number of multicast addresses efficiently. When
+ this number is exceeded, the Ethernet hardware may have to resort
+ to receiving all multicasts and passing them up to the host
+ software for filtering, thereby defeating the point of using a
+ multicast address range in the first place.
+
+ * Multiple questions cannot be placed in one packet if they don't all
+ hash to the same multicast address.
+
+ * Duplicate Question Suppression doesn't work if queriers are not
+ seeing each other's queries.
+
+ * Duplicate Answer Suppression doesn't work if responders are not
+ seeing each other's responses.
+
+ * Opportunistic Caching doesn't work.
+
+ * Ongoing Conflict Detection doesn't work.
+
+
+24. Security Considerations
+
+ The algorithm for detecting and resolving name conflicts is, by its
+ very nature, an algorithm that assumes cooperating participants. Its
+ purpose is to allow a group of hosts to arrive at a mutually disjoint
+ set of host names and other DNS resource record names, in the absence
+ of any central authority to coordinate this or mediate disputes. In
+ the absence of any higher authority to resolve disputes, the only
+ alternative is that the participants must work together cooperatively
+ to arrive at a resolution.
+
+ In an environment where the participants are mutually antagonistic
+ and unwilling to cooperate, other mechanisms are appropriate, like
+ manually administered DNS.
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 40]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ In an environment where there is a group of cooperating participants,
+ but there may be other antagonistic participants on the same physical
+ link, the cooperating participants need to use IPSEC signatures
+ and/or DNSSEC [RFC 2535] signatures so that they can distinguish mDNS
+ messages from trusted participants (which they process as usual) from
+ mDNS messages from untrusted participants (which they silently
+ discard).
+
+ When DNS queries for *global* DNS names are sent to the mDNS
+ multicast address (during network outages which disrupt communication
+ with the greater Internet) it is *especially* important to use
+ DNSSEC, because the user may have the impression that he or she is
+ communicating with some authentic host, when in fact he or she is
+ really communicating with some local host that is merely masquerading
+ as that name. This is less critical for names ending with ".local.",
+ because the user should be aware that those names have only local
+ significance and no global authority is implied.
+
+ Most computer users neglect to type the trailing dot at the end of a
+ fully qualified domain name, making it a relative domain name (e.g.
+ "www.example.com"). In the event of network outage, attempts to
+ positively resolve the name as entered will fail, resulting in
+ application of the search list, including ".local.", if present.
+ A malicious host could masquerade as "www.example.com" by answering
+ the resulting Multicast DNS query for "www.example.com.local."
+ To avoid this, a host MUST NOT append the search suffix
+ ".local.", if present, to any relative (partially qualified)
+ domain name containing two or more labels. Appending ".local." to
+ single-label relative domain names is acceptable, since the user
+ should have no expectation that a single-label domain name will
+ resolve as-is.
+
+
+25. IANA Considerations
+
+ IANA has allocated the IPv4 link-local multicast address 224.0.0.251
+ for the use described in this document.
+
+ IANA has allocated the IPv6 multicast address set FF0X::FB for the
+ use described in this document. Only address FF02::FB (Link-Local
+ Scope) is currently in use by deployed software, but it is possible
+ that in future implementers may experiment with Multicast DNS using
+ larger-scoped addresses, such as FF05::FB (Site-Local Scope).
+
+ When this document is published, IANA should designate a list of
+ domains which are deemed to have only link-local significance, as
+ described in Section 12 of this document ("Special Characteristics of
+ Multicast DNS Domains").
+
+ The re-use of the top bit of the rrclass field in the Question and
+ Answer Sections means that Multicast DNS can only carry DNS records
+ with classes in the range 0-32767. Classes in the range 32768 to
+ 65535 are incompatible with Multicast DNS. However, since to-date
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 41]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ only three DNS classes have been assigned by IANA (1, 3 and 4),
+ and only one (1, "Internet") is actually in widespread use, this
+ limitation is likely to remain a purely theoretical one.
+
+ No other IANA services are required by this document.
+
+
+26. Acknowledgments
+
+ The concepts described in this document have been explored, developed
+ and implemented with help from Freek Dijkstra, Erik Guttman, Paul
+ Vixie, Bill Woodcock, and others.
+
+ Special thanks go to Bob Bradley, Josh Graessley, Scott Herscher,
+ Roger Pantos and Kiren Sekar for their significant contributions.
+
+
+27. Copyright
+
+ Copyright (C) The Internet Society 2005.
+ All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+28. Normative References
+
+ [RFC 1034] Mockapetris, P., "Domain Names - Concepts and
+ Facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+ Specifications", STD 13, RFC 1035, November 1987.
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 42]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+ [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [RFC 3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629, November 2003.
+
+
+29. Informative References
+
+ [dotlocal] <http://www.dotlocal.org/>
+
+ [djbdl] <http://cr.yp.to/djbdns/dot-local.html>
+
+ [DNS-SD] Cheshire, S., and M. Krochmal, "DNS-Based Service
+ Discovery", Internet-Draft (work in progress),
+ draft-cheshire-dnsext-dns-sd-03.txt, June 2005.
+
+ [IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
+ Overview and Architecture.
+ Institute of Electrical and Electronic Engineers,
+ IEEE Standard 802, 1990.
+
+ [NBP] Cheshire, S., and M. Krochmal,
+ "Requirements for a Protocol to Replace AppleTalk NBP",
+ Internet-Draft (work in progress),
+ draft-cheshire-dnsext-nbp-04.txt, June 2005.
+
+ [RFC 2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
+ System (DNS UPDATE)", RFC 2136, April 1997.
+
+ [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+ [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
+ RFC 2535, March 1999.
+
+ [RFC 3492] Costello, A., "Punycode: A Bootstring encoding of
+ Unicode for use with Internationalized Domain Names
+ in Applications (IDNA)", RFC 3492, March 2003.
+
+ [RFC 3927] Cheshire, S., B. Aboba, and E. Guttman,
+ "Dynamic Configuration of IPv4 Link-Local Addresses",
+ RFC 3927, May 2005.
+
+ [ZC] Williams, A., "Requirements for Automatic Configuration
+ of IP Hosts", Internet-Draft (work in progress),
+ draft-ietf-zeroconf-reqts-12.txt, September 2002.
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 43]
+\f
+Internet Draft Multicast DNS 7th June 2005
+
+
+30. Authors' Addresses
+
+ Stuart Cheshire
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino
+ California 95014
+ USA
+
+ Phone: +1 408 974 3207
+ EMail: rfc@stuartcheshire.org
+
+
+ Marc Krochmal
+ Apple Computer, Inc.
+ 1 Infinite Loop
+ Cupertino
+ California 95014
+ USA
+
+ Phone: +1 408 974 4368
+ EMail: marc@apple.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Expires 7th December 2005 Cheshire & Krochmal [Page 44]
projects / catta / commitdiff