Prev: EINSTEINIANA AND JOURNALISTS' HONESTY
Next: Quantum theory survives its latest ordeal
From: sci.math on 22 Jul 2010 20:06
On Jul 22, 4:55 pm, John Stafford <n...(a)droffats.ten> wrote:
> In article
> <4a067370-2f31-4aa8-9c73-0b41271b7...(a)d8g2000yqf.googlegroups.com>,
>
>  Huang <huangxienc...(a)yahoo.com> wrote:
> > In mathematics things are proved.
>
> Or they are not proved.
>
> > The reason you can do this is
> > because everything exists very nicely and the whole stupid thing fits
> > together like Lego building blocks, and ever piece fits perfect. That
> > is mathematics.
>
> Accepted for the moment - mathematical proofs build upon each other, and
> that is why proofs are so important - so that later posits do not
> collapse into a pile of.. well, legos as you put it.
>
> > Conjecture is diferent. You begin by saying not "what exists", but
> > "what might exist". Conjectures are NEVER proved to be true because
> > they are and must remain conjectural.
>
> No. Some conjectures have been proven. Your logic tumbles into the
> dumpster with that.
>
> > But you CAN show that
> > conjectures are consistent, and so all of these conjectures fit
> > together like Lego building blocks as well. In fact, for every
> > mathematical statement there is a corresponding conjectural statement
> > and vice versa.
>
> IOW, for every conjecture there is an infinite supply of poorly informed
> guesswork and wholly impressionistic objection which has nothing to do
> with the mathematics. I suspect you are exercising the same.
>
> > There is no mathematical way to transform back and
> > forth between the two, such operations are currently under study but
> > to be sure - I do know what math is and what it is not. I also believe
> > that there are tools other than math which can accomplish the same
> > things that math does.
>
> Exactly what is this 'back and forth' you write of?
> [...]
>
> > Ok - there are many ways to do this depending on how precise you want
> > to make it. If you want an exact derivation you'll never get it
> > because it's not calculable, would require too much computing power
> > which does not exist at this time and probably never will.
>
> You must tell us WHY this is so. A declaration is not sufficient.
>
> > However, if we allow (for brevity) to model objects more coarsely we
> > can come up with some decent models. Instead of considering every
> > individual atom, just consider a planet as a whole and skip all of the
> > fine structure.
>
> So you are presuming our planet, earth, without considering what you
> posited above which suggests differences among other planets. (In other
> words, speculative impressionistic ideas about distant systems which
> might not have the same physics humans experience. That's a
> panthromorpic view.)
>
> > A planet may then be regarded (in my model) as a gradient. The
> > gradient is comprised of a potential, and to each point in space we
> > assign a potential that the point exists. That gives rise to this
> > gradient. Consider that the nucleus of the planet is enriched, and the
> > areas in it's outer shells are rarified. A planet (or atom) is nothing
> > more than an imbalance as described.  [...]
Document: draft-cheshire-dnsext-multicastdns-11.txt Stuart
Cheshire
Internet-Draft Marc
Krochmal
Category: Standards Track Apple
Inc.
Expires: 23 September 2010 23 March
2010

Multicast DNS

<draft-cheshire-dnsext-multicastdns-11.txt>

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with
the
provisions of BCP 78 and BCP 79.

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.

This Internet-Draft will expire on 23rd September 2010.

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 23rd September 2010 Cheshire & Krochmal [Page
1]

Internet Draft Multicast DNS 23rd March
2010


Table of Contents

1. Introduction....................................................
3
2. Conventions and Terminology Used in this Document...............
3
3. Multicast DNS Names.............................................
5
4. Reverse Address Mapping.........................................
6
5. Querying........................................................
7
6. Duplicate Suppression..........................................
12
7. Responding.....................................................
14
8. Probing and Announcing on Startup..............................
21
9. Conflict Resolution............................................
27
10. Resource Record TTL Values and Cache Coherency.................
28
11. Source Address Check...........................................
34
12. Special Characteristics of Multicast DNS Domains...............
35
13. Multicast DNS for Service Discovery............................
36
14. Enabling and Disabling Multicast DNS...........................
36
15. Considerations for Multiple Interfaces.........................
37
16. Considerations for Multiple Responders on the Same Machine.....
38
17. Multicast DNS Character Set....................................
40
18. Multicast DNS Message Size.....................................
41
19. Multicast DNS Message Format...................................
42
20. Summary of Differences Between Multicast DNS and Unicast DNS...
46
21. IPv6 Considerations............................................
47
22. Security Considerations........................................
47
23. IANA Considerations............................................
48
24. Acknowledgments................................................
50
25. Copyright Notice...............................................
50
26. Normative References...........................................
51
27. Informative References.........................................
51
28. Authors' Addresses.............................................
53

Appendix A. Design Rationale for Choice of UDP Port Number.........
54
Appendix B. Design Rationale for Not Using Hashed Mcast Addresses..
55
Appendix C. Design Rationale for Max Multicast DNS Name Length.....
56
Appendix D. Benefits of Multicast Responses........................
58
Appendix E. Design Rationale for Encoding Negative Responses.......
59
Appendix F. Use of
UTF-8...........................................60
Appendix G. Governing Standards Body...............................
60
Appendix H. Private DNS Namespaces.................................
61
Appendix I. Deployment History.....................................
62













Expires 23rd September 2010 Cheshire & Krochmal [Page
2]

Internet Draft Multicast DNS 23rd March
2010


1. Introduction

Multicast DNS and its companion technology DNS Service Discovery
[DNS-SD] were created to provide IP networking with the ease-of-use
and autoconfiguration for which AppleTalk was well known [ATalk].
When reading this document, familiarity with the concepts of Zero
Configuration Networking [Zeroconf] and automatic link-local
addressing [RFC 2462] [RFC 3927] is helpful.

This document specifies no change to the structure of DNS messages,
no new operation codes or response codes, and new resource record
types. This document describes how clients send DNS-like queries
via
IP multicast, and how a collection of hosts cooperate to
collectively
answer those queries in a useful manner.


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].

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." The design rationale for selecting
UDP port 5353 is discussed in Appendix A.

This document uses the term "host name" in the strict sense to mean
a
fully qualified domain name that has an IPv4 or IPv6 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.
This document uses the term "IP TTL" to refer to the IP header TTL
(hop limit), and the term "RR TTL" or just "TTL" to refer to the
Resource Record TTL (cache lifetime).

DNS-format messages contain a header, a Question Section, then
Answer, Authority, and Additional Record Sections. The Answer,
Authority, and Additional Record Sections all hold resource records
in the same format. Where this document describes issues that apply
equally to all three sections, it uses the term "Resource Record
Sections" to refer collectively to these three sections.




Expires 23rd September 2010 Cheshire & Krochmal [Page
3]

Internet Draft Multicast DNS 23rd March
2010


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 conceptually under the control
or ownership of a single Responder, and it is expected that at most
one Responder should respond to a query for that name, rrtype, and
rrclass. 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 8.1
"Probing".
(For fault-tolerance and other reasons it is permitted sometimes to
have more than one Responder answering for a particular "unique"
resource record set, but such cooperating Responders MUST give
answers containing identical rdata for these records. If they do
not give answers containing identical rdata then the probing step
will reject the data as being inconsistent with what is already
being advertised on the network for those names.)

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 23rd September 2010 Cheshire & Krochmal [Page
4]

Internet Draft Multicast DNS 23rd March
2010


3. Multicast DNS Names

This document specifies that the DNS top-level domain ".local."
is 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).
The design rationale for using a fixed multicast address instead of
selecting from a range of multicast addresses using a hash function
is discussed in Appendix B.

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 via DHCP [RFC 2132],
or via any other 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 that 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, such as,
"cheshire.example.com." For those of us who have this luxury, this
works very well. However, the majority of home computer users 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


Expires 23rd September 2010 Cheshire & Krochmal [Page
5]

Internet Draft Multicast DNS 23rd March
2010


may answer to the name "MyPrinter.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
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 favor. 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.

This document recommends a single flat namespace for dot-local host
names, (i.e. the names of DNS "A" and "AAAA" records, which map
names
to IPv4 and IPv6 addresses), but other DNS record types (such as
those used by DNS Service Discovery [DNS-SD]) may contain as many
labels as appropriate for the desired usage, up to a maximum of
255 bytes, not including the terminating zero byte at the end.
Name length issues are discussed further in Appendix C.

Enforcing uniqueness of host names 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.

4. 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.

Likewise, any DNS query for a name within the reverse mapping
domains for IPv6 Link-Local addresses ("8.e.f.ip6.arpa.",
"9.e.f.ip6.arpa.", "a.e.f.ip6.arpa.", and "b.e.f.ip6.arpa.") MUST
be sent to the IPv6 mDNS link-local multicast address FF02::FB.


Expires 23rd September 2010 Cheshire & Krochmal [Page
6]

Internet Draft Multicast DNS 23rd March
2010


5. Querying

There are three kinds of Multicast DNS Queries, one-shot queries
of the kind made by 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.

Except in the rare case of a Multicast DNS Responder that is
advertising only shared resources records and no unique records, a
Multicast DNS Responder 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.


5.1 One-Shot Multicast DNS Queries

The most basic kind of Multicast DNS client may simply send its DNS
queries blindly to 224.0.0.251:5353, without necessarily even being
aware of what a multicast address is. This change can typically be
implemented with just a few lines of code in an existing DNS
resolver
library. Any time the name being queried for falls within one of
the
reserved mDNS domains (see Section 12 "Special Characteristics of
Multicast DNS Domains") rather than using the configured unicast
DNS
server address, the query is instead sent to 224.0.0.251:5353 (or
its
IPv6 equivalent [FF02::FB]:5353). Typically the timeout would also
be
shortened to two or three seconds. It's possible to make a minimal
mDNS client with only these simple changes. These queries are
typically done using a high-numbered ephemeral UDP source port,
but regardless of whether they are sent from a dynamic port or from
a fixed port, these queries SHOULD NOT be sent using UDP source
port
5353, since using UDP source port 5353 signals the presence of a
fully-compliant Multicast DNS client, as described below.

A simple DNS client like this will typically just take the first
response it receives. It will not listen for additional UDP
responses, but in many instances this may not be a serious problem.
If a user types "http://MyPrinter.local." into their web browser
and
gets to see the status and configuration web page for their
printer,
then the protocol has met the user's needs in this case.

While a basic DNS client like this may be adequate for simple
host name lookup, it may not get ideal behavior in other cases.
Additional refinements that may be adopted by more sophisticated
clients are described below.








Expires 23rd September 2010 Cheshire & Krochmal [Page
7]

Internet Draft Multicast DNS 23rd March
2010


5.2 One-Shot Queries, Accumulating Multiple Responses

A compliant Multicast DNS client, which implements the rules
specified in this document, MUST send its Multicast DNS Queries
from
UDP source port 5353 (the well-known port assigned to mDNS), and
MUST
listen for Multicast DNS Replies sent to UDP destination port 5353
at
the mDNS multicast address (224.0.0.251 and/or its IPv6 equivalent
FF02::FB).

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 useful, and for these queries a more advanced
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 advanced 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 until it is satisfied with the collection of responses it
has gathered. When retransmitting, the interval between the first
two
queries SHOULD be at least one second, and the intervals between
successive queries SHOULD increase by at least a factor of two.

A 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 6.1 "Known Answer
Suppression". 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.

5.3 Continuous Multicast DNS Querying

In One-Shot Queries, with either single or multiple responses,
the underlying assumption is that the transaction begins when the
application issues a query, and ends when the desired responses
have been received. There is another type of operation which is
more akin to continuous monitoring.

Imagine some hypothetical software which allows users to manage
their
digital music collections, with a graphical user interface which
includes a sidebar down the left side of the window, which shows
other sources of shared music the software has discovered on the
local network. It would be convenient for the user if they could
rely
on this list of shared music sources displayed in the window
sidebar
to stay up to date as music sources come and go, rather than
displaying out-of-date stale information, and requiring the user
explicitly to click a "refresh" button any time they want to see
accurate information (which, from the moment it is displayed, is


Expires 23rd September 2010 Cheshire & Krochmal [Page
8]

Internet Draft Multicast DNS 23rd March
2010


itself already beginning to become out-of-date and stale). If we
are
to to display a continuously-updated live list like this, we need
to
be able to do it efficiently, without naive constant polling which
would be an unreasonable burden on the network.

Therefore, when retransmitting mDNS queries to implement this kind
of
continuous monitoring, the interval between the first two queries
SHOULD be at least one second, the intervals between successive
queries SHOULD increase by at least a factor of two, and the
querier
MUST implement Known Answer Suppression, as described below in
Section 6.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. To avoid accidental synchronization when for some reason
multiple clients begin querying at exactly the same moment (e.g.
because of some common external trigger event), a Multicast DNS
Querier SHOULD also delay the first query of the series by a
randomly-chosen amount in the range 20-120ms.

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 which has clients with an active interest
in
the state of that record (e.g. a network browsing window displaying
a list of discovered services to the user) SHOULD re-issue its
query
to determine whether the record is still valid.

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. A Multicast DNS Querier MUST
NOT perform this cache maintenance for records for which it has no
clients with an active interest. If the expiry of a particular
record
from the cache would result in no net effect to any client software
running on the Querier device, and no visible effect to the human
user, then there is no reason for the Multicast DNS Querier to
waste network bandwidth checking whether the record remains valid.

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.


Expires 23rd September 2010 Cheshire & Krochmal [Page
9]

Internet Draft Multicast DNS 23rd March
2010


An additional efficiency optimization SHOULD be performed when a
Multicast DNS response is received containing a unique answer (as
indicated by the cache flush bit being set, described in Section
10.3, "Announcements to Flush Outdated Cache Entries"). In this
case,
there is no need for the querier to continue issuing a stream of
queries with exponentially-increasing intervals, since the receipt
of
a unique answer is a good indication that no other answers will be
forthcoming. In this case, the Multicast DNS Querier SHOULD plan to
issue its next query for this record at 80-82% of the record's TTL,
as described above.

5.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.


5.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 can detect conflicting
responses.

However, there are situations where all the other hosts on the
network don't need to see every response. Some examples are a
laptop
computer waking from sleep, or the Ethernet cable being connected
to
a running machine, or a previously inactive interface being
activated
through a configuration change. At the instant of wake-up or link
activation, the machine is a brand new participant on a new
network.
Its Multicast DNS cache for that interface is empty, and it has
no knowledge of its peers on that link. It may have a significant
number of questions 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, triggering a large sudden flood of
multicast responses may impose an unreasonable burden on the
network.

To avoid large floods of potentially unnecessary responses in these
cases, Multicast DNS defines the top bit in the class field of a
DNS
question as the "unicast response" bit. When this bit is set in a
question, it indicates that the Querier is willing to accept
unicast
responses instead of the usual multicast responses. These questions
requesting unicast responses are referred to as "QU" questions, to


Expires 23rd September 2010 Cheshire & Krochmal [Page
10]

Internet Draft Multicast DNS 23rd March
2010


distinguish them from the more usual questions requesting multicast
responses ("QM" questions). A Multicast DNS Querier sending its
initial batch of questions immediately on wake from sleep or
interface activation SHOULD set the "QU" bit in those questions.

When a question is retransmitted (as described in Section 5.3
"Continuous Multicast DNS Querying") the "QU" bit SHOULD NOT be
set in subsequent retransmissions of that question. Subsequent
retransmissions SHOULD be usual "QM" questions. 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
Appendix D). In addition, the "QU" bit SHOULD be set only for
questions that are active and ready to be sent the moment of wake
from sleep or interface activation. New questions issued by clients
afterwards should be treated as normal "QM" questions and SHOULD
NOT
have the "QU" bit set on the first question of the series.

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. In the case of
answering a probe question with the "unicast response" bit set, the
Responder should always generate the requested unicast response,
but
may also send a multicast announcement too if the time since the
last
multicast announcement of that record is more than a quarter of its
TTL.

Except when defending a unique name against a probe from another
host, unicast replies are subject to all the same packet generation
rules as multicast replies, including the cache flush bit (see
Section 10.3, "Announcements to Flush Outdated Cache Entries") and
randomized delays to reduce network collisions (see Section 7,
"Responding").

5.6 Direct Unicast Queries to port 5353

In specialized applications there may be rare situations where it
makes sense for a Multicast DNS Querier to send its query via
unicast
to a specific machine. When a Multicast DNS Responder receives a
query via direct unicast, it SHOULD respond as it would for a
"QU" query, as described above in Section 5.5 "Questions Requesting
Unicast Responses". Since it is possible for a unicast query to be
received from a machine outside the local link, Responders SHOULD
check that the source address in the query packet matches the local
subnet for that link, and silently ignore the packet if not.



Expires 23rd September 2010 Cheshire & Krochmal [Page
11]

Internet Draft Multicast DNS 23rd March
2010


There may be specialized situations, outside the scope of this
document, where it is intended and desirable to create a Responder
that does answer queries originating outside the local link. Such
a Responder would need to ensure that these non-local queries are
always answered via unicast back to the Querier, since an answer
sent
via link-local multicast would not reach a Querier outside the
local
link.


6. Duplicate Suppression

A variety of techniques are used to reduce the amount of redundant
traffic on the network.

6.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 query
message with those answers.

A Multicast DNS Responder MUST 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 23rd September 2010 Cheshire & Krochmal [Page
12]

Internet Draft Multicast DNS 23rd March
2010


6.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 has also issued a query for that
record and is waiting to receive an answer).

If the Responder receives additional Known Answer packets with the
TC
bit set, it SHOULD extend the delay as necessary to ensure a pause
of
400-500ms after the last such packet before it sends its answer.
This
opens the potential risk that a continuous stream of Known Answer
packets could, theoretically, prevent a Responder from answering
indefinitely. In practice answers are never actually delayed
significantly, and should a situation arise where significant
delays
did happen, that would be a scenario where the network is so
overloaded that it would be desirable to err on the side of
caution.
The consequence of delaying an answer may be that it takes a user
longer than usual to discover all the services on the local
network;
in contrast the consequence of incorrectly answering before all the
Known Answer packets have been received would be wasting bandwidth
sending unnecessary answers on an already overloaded network. In
this
(rare) situation, sacrificing speed to preserve reliable network
operation is the right trade-off.


6.3 Duplicate Question Suppression

If a host is planning to send a query, and it sees another host on
the network send a QM 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.


Expires 23rd September 2010 Cheshire & Krochmal [Page
13]

Internet Draft Multicast DNS 23rd March
2010


6.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, and not also send an identical answer itself. 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 Multicast DNS Proxy
Servers
are in use, where there could be more than one proxy on the network
giving Multicast DNS answers on behalf of some other host (e.g.
because that other host is currently asleep and is not itself
responding to queries).


7. Responding

When a Multicast DNS Responder constructs and sends a Multicast DNS
response packet, the Resource Record Sections 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 Resource Record Sections 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" (255) or the rrtype is "CNAME" (5), and
the record rrclass must match the question qclass unless the qclass
is "ANY" (255).

A Multicast DNS Responder MUST only respond when it has a positive
non-null response to send, or it authoritatively knows that a
particular record does not exist. For unique records, where the
host
has already established sole ownership of the name, it MUST return
negative answers to queries for records that it knows not to exist.
For example, a host with no IPv6 address, that has claimed sole
ownership of the name "host.local." for all rrtypes, MUST respond
to AAAA queries for "host.local." by sending a negative answer
indicating that no AAAA records exist for that name. See Section
7.1
"Negative Responses". For shared records, which are owned by no
single host, the nonexistence of a given record is ascertained by
the
failure of any machine to respond to the Multicast DNS query, not
by
any explicit negative response. NXDOMAIN and other error responses
MUST NOT be sent.

Expires 23rd September 2010 Cheshire & Krochmal [Page
14]

Internet Draft Multicast DNS 23rd March
2010


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 [IEEE 802] 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 a large number of 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 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 that will
send
a response (i.e. because it is able to answer every question in the
query packet, and for all of those answer records it has previously
verified that the name, rrtype and rrclass are unique on the link)
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 with the "unicast
response" bit set. 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 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 8.2, "Simultaneous Probe Tie-Breaking").

Responding without delay is appropriate for records like the
address
record for a particular host name, when the host name has been
previously verified unique. Responding 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.
The reason for requiring that the delay be at least 20ms is to
accommodate the situation where two or more query packets are sent


Expires 23rd September 2010 Cheshire & Krochmal [Page
15]

Internet Draft Multicast DNS 23rd March
2010


back-to-back, because in that case we want a Responder with answers
to more than one of those queries to have the opportunity to
aggregate all of its answers into a single response packet.

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,
as described in Section 6.2 "Multi-Packet Known Answer
Suppression".

The source UDP port in all Multicast DNS Responses MUST be 5353
(the
well-known port assigned to mDNS). Multicast DNS implementations
MUST
silently ignore any Multicast DNS Responses they receive where the
source UDP port is not 5353.

The destination UDP port in all Multicast DNS Responses MUST be
5353
and the destination address must be the multicast address
224.0.0.251
or its IPv6 equivalent FF02::FB, except when a unicast response has
been explicitly requested:

* via the "unicast response" bit,
* by virtue of being a Legacy Query (Section 7.6), or
* by virtue of being a direct unicast query.

The benefits of sending Responses via multicast are discussed in
Appendix D.

To protect the network against excessive packet flooding due to
software bugs or malicious attack, a Multicast DNS Responder MUST
NOT
(except in the one special case of answering probe queries)
multicast
a record on a given interface until at least one second has elapsed
since the last time that record was multicast on that particular
interface. 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. In the special case of answering
probe
queries, because of the limited time before the probing host will
make its decision about whether or not to use the name, a Multicast
DNS Responder MUST respond quickly. In this special case only, when
responding via multicast to a probe, a Multicast DNS Responder is
only required to delay its transmission as necessary to ensure an
interval of at least 250ms since the last time the record was
multicast on that interface.


7.1 Negative Responses

In the early design of Multicast DNS it was assumed that explicit
negative responses would never be needed. Hosts can assert the
existence of the set of records which that host claims to exist,


Expires 23rd September 2010 Cheshire & Krochmal [Page
16]

Internet Draft Multicast DNS 23rd March
2010


and the union of all such sets on a link is the set of Multicast
DNS
records that exist on that link. Asserting the non-existence of
every
record in the complement of that set -- i.e. all possible Multicast
DNS records that could exist on this link but do not at this moment
-- was felt to be impractical and unnecessary. The non-existence of
a record would be ascertained by a client querying for it and
failing
to receive a response from any of the hosts currently attached to
the
link.

However, operational experience showed that explicit negative
responses can sometimes be valuable. One such case is when a client
is querying for a AAAA record, and the host name in question has no
associated IPv6 addresses. In this case the responding host knows
it
currently has exclusive ownership of that name, and it knows that
it
currently does not have any IPv6 addresses, so an explicit negative
response is preferable to the client having to retransmit its query
multiple times and eventually give up with a timeout before it can
conclude that a given AAAA record does not exist.

A Multicast DNS Responder indicates the nonexistence of a record by
using a DNS NSEC record [RFC 3845]. In the case of Multicast DNS
the NSEC record is not being used for its usual DNSSEC security
properties, but simply as a way of expressing which records do or
do not exist with a given name.

Implementers working with devices with sufficient memory and CPU
resources may choose to implement code to handle the full
generality
of the DNS NSEC record [RFC 3845], including bitmaps up to 65,536
bits long. To facilitate use by clients with limited memory and CPU
resources, Multicast DNS clients are only required to be able to
parse a restricted form of the DNS NSEC record. All compliant
Multicast DNS clients MUST at least correctly handle the restricted
DNS NSEC record format described below:

o The 'Next Domain Name' field contains the record's own name.
When used with name compression, this means that the 'Next
Domain Name' field always takes exactly two bytes in the packet.

o The Type Bit Map block number is 0.

o The Type Bit Map block length byte is a value in the range 1-32.

o The Type Bit Map data is 1-32 bytes, as indicated by length
byte.

Because this restricted form of the DNS NSEC record is limited to
Type Bit Map block number zero, it cannot express the existence of
rrtypes above 255. Because of this, if a Multicast DNS Responder
were
to have records with rrtypes above 255, it MUST NOT generate these
restricted-form NSEC records for those names, since to do so would
imply that the name has no records with rrtypes above 255, which
would be false. In such cases a Multicast DNS Responder MUST either


Expires 23rd September 2010 Cheshire & Krochmal [Page
17]

Internet Draft Multicast DNS 23rd March
2010


(a) emit no NSEC record for that name, or (b) emit a full NSEC
record
containing the appropriate Type Bit Map block(s) with the correct
bits set for all the record types that exist. In practice this is
not
a significant limitation, since rrtypes above 255 are not currently
in widespread use.

If a Multicast DNS implementation receives an NSEC record where the
'Next Domain Name' field is not the record's own name, then the
implementation SHOULD ignore the 'Next Domain Name' field and
process
the remainder of the NSEC record as usual. In Multicast DNS the
'Next Domain Name' field is not currently used, but it could be
used
in a future version of this protocol, which is why a Multicast DNS
implementation MUST NOT reject or ignore an NSEC record it receives
just because it finds an unexpected value in the 'Next Domain Name'
field.

If a Multicast DNS implementation receives an NSEC record
containing
more than one Type Bit Map, or where the Type Bit Map block number
is
not zero, or where the block length is not in the range 1-32, then
the Multicast DNS implementation MAY silently ignore the entire
NSEC
record. A Multicast DNS implementation MUST NOT ignore an entire
packet just because that packet contains one or more NSEC record(s)
that the Multicast DNS implementation cannot parse. This provision
is to allow future enhancements to the protocol to be introduced in
a backwards-compatible way that does not break compatibility with
older Multicast DNS implementations.

To help differentiate these synthesized NSEC records (generated
programmatically on-the-fly) from conventional Unicast DNS NSEC
records (which actually exist in a signed DNS zone) the synthesized
Multicast DNS NSEC records MUST NOT have the 'NSEC' bit set in the
Type Bit Map, whereas conventional Unicast DNS NSEC records do have
the 'NSEC' bit set.

The TTL of the NSEC record indicates the intended lifetime of the
negative cache entry. In general, the TTL given for an NSEC record
SHOULD be the same as the TTL that the record would have had, had
it
existed. For example, the TTL for address records in Multicast DNS
is
typically 120 seconds, so the negative cache lifetime for an
address
record that does not exist should also be 120 seconds.

A Responder should only generate negative responses to queries for
which it has legitimate ownership of the name/rrtype/rrclass in
question, and can legitimately assert that no record with that
name/rrtype/rrclass exists. A Responder can assert that a specified
rrtype does not exist for one of its names only if it previously
claimed unique ownership of that name using probe queries for
rrtype
"ANY". (If it were to use probe queries for a specific rrtype, then
it would only own the name for that rrtype, and could not assert
that other rrtypes do not exist.) On receipt of a question for a
particular name/rrtype/rrclass which a Responder knows not to exist


Expires 23rd September 2010 Cheshire & Krochmal [Page
18]

Internet Draft Multicast DNS 23rd March
2010


by virtue of previous successful probing, the Responder MUST send a
response packet containing the appropriate NSEC record, if it can
do so using the restricted form of the NSEC record described above.
If a legitimate restricted-form NSEC record cannot be created
(because
rrtypes above 255 exist for that name) the Responder MAY emit a
full
NSEC record, or it MAY emit no NSEC record, at the implementer's
discretion.

The design rationale for this mechanism for encoding Negative
Responses is discussed further in Appendix E.


7.2 Responding to Address Queries

In Multicast DNS, whenever a Responder places an IPv4 or IPv6
address
record (rrtype "A" or "AAAA") into a response packet, it SHOULD
also
place the corresponding other address type into the additional
section, if there is space in the packet.

This is to provide fate sharing, so that all a device's addresses
are
delivered atomically in a single packet, to reduce the risk that
packet loss could cause a querier to receive only the IPv4
addresses
and not the IPv6 addresses, or vice versa.

In the event that a device has only IPv4 addresses but no IPv6
addresses, or vice versa, then the appropriate NSEC record SHOULD
be placed into the additional section, so that queriers can know
with certainty that the device has no addresses of that kind.

Some Multicast DNS Responders treat a physical interface with both
IPv4 and IPv6 address as a single interface with two addresses.
Other
Multicast DNS Responders treat this case as logically two
interfaces,
each with one address, but Responders that operate this way MUST
NOT
put the corresponding automatic NSEC records in replies they send
(i.e. a negative IPv4 assertion in their IPv6 responses, and a
negative IPv6 assertion in their IPv4 responses) because this would
cause incorrect operation in Responders on the network that work
the
former way.


7.3 Responding to 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 23rd September 2010 Cheshire & Krochmal [Page
19]

Internet Draft Multicast DNS 23rd March
2010


7.4 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.


7.5 Wildcard Queries (qtype "ANY" and qclass "ANY")

When responding to queries using qtype "ANY" (255) and/or qclass
"ANY" (255), a Multicast DNS Responder MUST respond with *ALL* of
its
records that match the query. This is subtly different to how qtype
"ANY" and qclass "ANY" work in Unicast DNS.

A common misconception is that a Unicast DNS query for qtype "ANY"
will elicit a response containing all matching records. This is
incorrect. If there are any records that match the query, the
response is required only to contain at least one of them, not
necessarily all of them.

This somewhat surprising behavior is commonly seen with caching
(i.e. "recursive") name servers. If a caching server receives a
qtype
"ANY" query for which it has at least one valid answer, it is
allowed
to return only those matching answers it happens to have already in
its cache, and is not required to reconsult the authoritative name
server to check if there are any more records that also match the
qtype "ANY" query.

For example, one might imagine that a query for qtype "ANY" for
name
"host.example.com" would return both the IPv4 (A) and the IPv6
(AAAA)
address records for that host. In reality what happens is that it
depends on the history of what queries have been previously
received
by intervening caching servers. If a caching server has no records
for "host.example.com" then it will consult another server (usually
the authoritative name server for the name in question) and in that
case it will typically return all IPv4 and IPv6 address records.
If however some other host has recently done a query for qtype "A"
for name "host.example.com", so that the caching server already has
IPv4 address records for "host.example.com" in its cache, but no
IPv6
address records, then it will return only the IPv4 address records
it
already has cached, and no IPv6 address records.

Multicast DNS does not share this property that qtype "ANY" and
qclass "ANY" queries return some undefined subset of the matching
records. When responding to queries using qtype "ANY" (255) and/or
qclass "ANY" (255), a Multicast DNS Responder MUST respond with
*ALL*
of its records that match the query.


Expires 23rd September 2010 Cheshire & Krochmal [Page
20]

Internet Draft Multicast DNS 23rd March
2010


7.6 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. In addition, the "cache flush"
bit described in Section 10.3 "Announcements to Flush Outdated
Cache
Entries" is specific to Multicast DNS, and MUST NOT be set in
legacy
unicast responses.

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 10 "Resource Record TTL
Values and Cache Coherency" 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. 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: Probing (Section 8.1) and Announcing (Section 8.3).







Expires 23rd September 2010 Cheshire & Krochmal [Page
21]

Internet Draft Multicast DNS 23rd March
2010


8.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 us
 | 
Pages: 1
Prev: EINSTEINIANA AND JOURNALISTS' HONESTY
Next: Quantum theory survives its latest ordeal