Subject: On Scaling of DNS-SD

From: Stuart Cheshire <[email-masked]>
Date: Tue, 30 Jul 2002 21:24:26 -0700

>I would like it to be able to "scale" above a single link.

Apple's position is that Multicast DNS is intended for use on small 
networks with no infrastructure support, and it intentionally uses 
link-local multicast. If a network has two links then it needs a bridge 
or router to connect those links, so by definition you now have a box 
that is (or should be) capable of providing some level of infrastructure 
support.

Apple's position is that (in the example given above) the router that is 
connecting the two links should also include a DHCP server to assign 
addresses, and a little mini-DNS server which handles both standard DNS 
queries and Dynamic DNS Updates [RFC 3007].

>So it seems to me that either DNS-SD has to scale gracefully all
>the way up to huge, or that I will have to bite the bullet and
>build in something tougher like SLP anyway. And then why would I
>want to do DNS-SD as well?

DNS-SD does scale gracefully all the way up to huge, and it does so using 
software that large organizations already have running on their networks 
-- a DNS server.

Don't make the mistake of assuming that this has to be the same hardware 
as your existing DNS server (though it can be if you want). The important 
point is that it is the same *software* as your existing DNS server -- so 
you don't have to learn, install, operate and maintain some new kind of 
server.

If you are worried about extra load on your existing DNS server, then 
just delegate the "_tcp.example.com." and "_udp.example.com." subdomains 
to a different machine. The important point is that this may be a 
different machine, but it doesn't have to be running different software.

If you want to have a specific machine that is responsible for storing 
printing service records, then you can get even more fine-grained -- 
delegate the "_printer._tcp.example.com." and "_ipp._tcp.example.com." 
subdomains to that machine.

[See also my upcoming reply on attribute-based queries]

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 30 Jul 2002 21:35:03 -0700 (PDT)

On Tue, 30 Jul 2002, Stuart Cheshire wrote:
    > Apple's position is that --------- --- is intended for use on small
    > link-local multicast.

Except, remember, you're not allowed to call it that, since that isn't
what you did.

                                -Bill

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 01:47:02 -0400

> queries and Dynamic DNS Updates [RFC 3007].

I don't know where Apple gets off thinking it can redefine the Internet
arcihtecture to make DHCP mandatory and to overload DNS to change its
semantics in a way that breaks applications.  frankly, I find it both
offensive and technically bankrupt.

Keith

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 30 Jul 2002 23:17:02 -0700 (PDT)

> offensive and technically bankrupt.

Huh? Companies have been shipping such gateways for years now, and they
work fine. Nothing about mini-DNS servers breaks applications, assuming
that it is implemented correctly. Remember, the mini-DHCP/DNS approach is
an *alternative* to mDNS, which if available, should cause mDNS not to be
used, at least as described in draft-ietf-dnsext-mdns-11.txt. So it's
quite harmless.

About the only new wrinkle in Stuart's post is the support for Dynamic DNS
updates, which while a good idea, is not yet supported in most home
gateways. However, it is not hard to add, and is particularly useful for
IPv6, where DHCPv6 lite may not be available on the gateway. Supporting
Dynamic DNS update would therefore permit dynamic name resolution in
situations where this would not otherwise be possible.

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 09:26:13 -0400

> Nothing about mini-DNS servers breaks applications, assuming

the conclusion does not follow, because some nodes in an applicaiton may
be using addresses obtained from mDNS at the same time others are using 
addresses obtained from DNS - if the two views are inconsistent (and they
will be) this can break the application.  also it appears that mDNS 
introduces new error conditions that applications written to expect
DNS semantics will misinterpret, and also uses existing error codes
to report conditions that differ from those used in DNS (e.g. NXRRSET
to report the case where no host responds even though there may actually
be such an RRSET in DNS).

mDNS WILL break applications if it is used to implement DNS APIs. 

Keith

---

From: Brad Hards <[email-masked]>
Date: Wed, 31 Jul 2002 23:32:39 +1000

> will be) this can break the application.  also it appears that mDNS
<snip>
The two views don't need to be inconsistent. You haven't provided any
_evidence_ that this will occur.

So your statement is reduced to an unsubstantiated assertion.

Either people want to make this work, or they just want to kill
the whole thing. If you don't like what is being proposed, then
either propose something else, or don't use the implementations.
If the 80% solution breaks a few buggy applications, then it
was probably well beyond time to upgrade them anyway.

Brad
-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 09:57:16 -0400

> _evidence_ that this will occur.

the only way to have _evidence_ is to deploy the thing, which we rarely
have at the time a protocol is up for proposed standard.  I've made an
_argument_, based on some analysis, that this problem will occur.
 
> So your statement is reduced to an unsubstantiated assertion.

the assertion is substantiated by analysis.   the analysis could
be incorrect of course, but I don't think so.
 
> the whole thing. 

false.  having a local name lookup service is clearly useful, I don't
know anybody who wants to kill that.  the problem is that people are 
trying to "make this work" by overloading an existing DNS query
interface and/or by having that interface respond (inconsistently
from DNS) for existing DNS names.

> If you don't like what is being proposed, then

so what you are saying that it's okay for the zeroconf WG to approve
something that breaks existing applicaitons, and if it does so then 
it's the applications' fault.  what a crock!  that's like saying
that if the bridge collapses then it was the cars' fault for driving
over it...

and though I often try to do so --- no, I don't need to propose something 
else.  the burden is on those who propose new standards-track protocols 
to produce protocols that don't have known technical limitations with 
respect to the requirements placed on them.   if they can't do that,
the proposals deserve to either die or be labelled as informational or
experimental until such time as the problems have been solved.

it's been obvious since the first zeroconf BOF that this WG would have a
difficult time developing protocols that met its goals without breaking
things - what it seems like now is that the WG has mostly ignored that 
set of problems.

Keith

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 31 Jul 2002 06:32:51 -0700 (PDT)

> addresses obtained from DNS

Not sure why this causes mini-DNS servers to break applications. Can you
explain? mDNS will never be used where a mini-DNS server is present so
there are no "error conditions" or "inconsistencies".

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 10:40:32 -0400

> there are no "error conditions" or "inconsistencies".

the problem is in the notion of "where a mini-DNS server is present" -
it can be present for some nodes in an application and absent for others.

---

From: "Jim Fleming" <[email-masked]>
Date: Wed, 31 Jul 2002 10:20:11 -0500

----- Original Message ----- 
From: "Bernard Aboba" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: "Stuart Cheshire" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 31, 2002 1:17 AM
Subject: Re: On Scaling of DNS-SD 

> situations where this would not otherwise be possible.

There does seem to be some interest in .MAC...

http://www.icann.org/comments-mail/icann-current/msg00342.html
130 WEBSITE
 130 RAY
 130 NAME
 130 MAC  <<<<<<<<<
 130 EYES
 130 CORPORATION
 130 COLORADO
 130 CHAMBER

It appears to be in the Proof-of-Concept phase...
http://root-dns.org/vuedig/vuedig_tld.php?record=NS&tld=mac&submit=Submit
 
Jim Fleming
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 31 Jul 2002 16:35:03 -0700 (PDT)

> it can be present for some nodes in an application and absent for others.

Here is my understanding of the origin (and solution) to this problem.

Let's go through what happens in a home gateway failure scenario. Since
the home gateway has addressing & configuration (e.g. DHCPv4, IPV6 RA,
DHCPv6-lite, etc.) as well as DNS server functionality, if it goes down,
then nodes coming up will have neither a configured address nor a DNS
server address.

For LL IPv4, this means that they will auto-allocate an address from
169.254/16, and will also use mDNS for name resolution.

Hosts that booted when the home gateway was up will also have an IPv4 LL
address (at least under draft-ietf-zeroconf-ipv4-linklocal-05.txt), but
they also may have a configured address. So they can still communicate
with the zeroconf-only hosts. Eventually when the home gateway comes
back the zeroconf-only nodes will find it and will also have a
configured address. So the problem will right itself, though the timescale
on which this occurs might be an issue (I've not found 5 minutes to be a
satisfactory time between attempts to find a home gateway, in my
experience).

Similarly, hosts that booted when the gateway was up will be configured
with a DNS server (the gateway) which will not be functioning, while the
hosts that booted when the gateway was down will not have a DNS server
configured. As a result, the configured hosts will send their queries to
the (down) DNS proxy, while the zeroconf hosts will send mDNS queries
immediately.

This situation will be remedied iff the process by which a zeroconf
requests a configured non-LL address periodically also results in the host
being configured with a DNS server. This is true, for example, for DHCPv4,
since this provides both addressing and configuration. Thus, if the
gateway comes back, then all the hosts on the network will be in the same
state with respect to mDNS usage eventually.

However, for IPv6, the repair process is more complex. While RA might
provide a non-LL address, if the DNS configuration mechanism is not also
periodically retried (presumably with the same timers as address
configuration), then the zeroconf and configured hosts may retain
different configurations indefinitely. I think that this is an issue.

The effects of this are far from catastrophic though. Assuming that the
configured hosts query mDNS only for non-qualified names (e.g. "foo") as
advocated in mDNS-11, then they will be able to resolve the non-qualified names of
zeroconf hosts.

On the other hand, the zeroconf hosts will query for FQDNs, but will not
receive an answer in most cases, since hosts only answer mDNS queries
for names for which they are authoritative. Having the host query via
mDNS because the gateway is initially down does create a
security vulnerability, because an attacker could answer the mDNS
queries of zeroconf hosts, poisoning the mDNS cache, whereas configured
hosts would not send such queries. To take advantage of this, the attacker
could overwhelm the DNS configuration server.

The solution is to require that the DNS configuration mechanism be
periodically retried if it initially fails. Of course this also implies
that it be able to "fail" -- which is not possible for some IPv6 DNS
configuration mechanisms.

---

From: Keith Moore <[email-masked]>
Date: Wed, 31 Jul 2002 21:34:48 -0400

> Here is my understanding of the origin (and solution) to this problem.

first off, this is just one scenario in which the problem can occur.  
and your proposed solution only works for that scenario (perhaps a
few others) but not for the problem in general.

here's some big problems with this scenario: you're assuming that
all of the hosts of concern are on the same link and they're all
affected in the same way.  you're assuming that the component that
exhibits the failure and the DNS server(s) used by the nodes
share fate.  I'm not saying that this situation cannot exist or 
even that it cannot be common; I'm saying that a solution that
happens to work in this situation cannot be considered general.
 
> they also may have a configured address. 

it's also not reasonable to assume that other hosts even on the same link
have a linklocal address - first because they may predate the introduction
of linklocal address space; second because they may have (quite reasonably) 
disabled LL addresses since it will cause problems for some applications .
actually insisting that every host support linklocal is one of the 
unacceptable (to me) provisions of the current draft that I hope IESG has 
the good sense to block.  (and no, this scenario doesn't justify forcing 
each host and app to deal with linklocal addresses)

> So they can still communicate
> with the zeroconf-only hosts. 

false.  but even that is not the real problem.

the real problem is that you can have some hosts using DNS servers
(not all the same DNS server) and other hosts using mDNS, talking
to each other at the same time.  and some of these hosts can have
connectivity to the outside world while others do not.

because in the real world networks do not fit into neat litle patterns. 

Keith