Subject: zeroconf name resolution does not mean necessarily DNS

From: Alain Durand <[email-masked]>
Date: Mon, 10 Dec 2001 21:30:47 -0800

To follow up on the DNSext discussion on mdns/zeroconf.

What is needed is something to map local names to IP addresses
in a zeroconf environment (no DNS server)
This does mean that whatever we design has to be integrate in the
general name resolution process of operating system and does not
mean it has to be integrated in the DNS itself.

As I said earlier, there is usually a switch to say in what order to
do name resolution: example: first FILES, then NIS then DNS
What is needed is just another local scope name service.

When a web browser tries to resolve a name like mylapto-at-the-airport
it calls a library function like getnameinfo(), it does not call DNS directly.
The library function goes to the switch and decide how to retrieve the 
information.

So, my point is that whatever we design does not need to look like DNS at all.
It may, but is not required and it may or may not be desirable.

	- Alain.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Dec 2001 09:34:03 -0800 (PST)

> If zeroconf requirements are broken, they should be fixed.

Agreed. Perhaps the way to accomplish this is to bring the document to
IETF last call (checked and only WG last call is complete) so that
comments from DNSEXT WG and other sources can be incorporated. Right now
the Zeroconf WG believes that it is "done".

---

From: Alain Durand <[email-masked]>
Date: Tue, 11 Dec 2001 09:29:21 -0800

At 09:05 AM 12/11/2001 -0800, Bernard Aboba wrote:
>Before we jump into a discussion of zeroconf name resolution requirements,
>it is probably worth while to at least consider what is included in the
>Zeroconf WG Requirements document, which has completed WG (and IETF?) last
>call:

>2.2 Translation between Host name and IP Address Scenarios
>
>
>    Requirement:
>    - MUST support DNS application layer interfaces as described
>      in RFC 1123, section 6.1. [RFC 1123]

RFC1123, section 6.1:

6.1.1 INTRODUCTION

Every host MUST implement a resolver for the Domain Name System (DNS),
and it MUST implement a mechanism using this DNS resolver to convert
host names to IP addresses and vice-versa [DNS:1, DNS:2].
In addition to the DNS, a host MAY also implement a host name translation
mechanism that searches a local Internet host table. See Section 6.1.3.8
for more information on this option.

         - Alain.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 11 Dec 2001 09:05:53 -0800 (PST)

Host names allow users to refer to hosts using names instead of IP
   addresses. This is among the most fundamental, thus most important,
   usage paradigms in TCP/IP networking.

   Terms:

     host name - A textual name that allows a user to refer to a host
     by name rather than IP address.

     domain name - Zero or more textual labels, separated by dots,
     that identify a DNS domain [RFC 1034] [RFC 1035].

     resolver - The host needing a name to IP address translation.

   The scenario for translation between host name and IP address is
   Web browsing. In addition, host name selection is discussed.

2.2.1  Web Browsing

   Applications, such as web browsers, make extensive use of DNS
   resolver functions.  A mechanism to support DNS resolver
   interfaces in the zero configuration environement is required.

   Requirement:

2.2.2  Host Name Selection

   How the host is administratively assigned a domain name is determined
   by some other configuration protocol or user configuration, and is
   not part of this zeroconf scenario. A protocol must allow a host
   to determine if its name is unique. If the name is not unique, the
   protocol must notify the user or some IP interface configuration
   software to select another name then repeat the process of verifying
   the uniqueness of the name.

   Requirement:

   - MUST allow a host to determine if its name is unique. Then if
     not unique, notify the user or configuration software so that
     another name may be chosen and similarly verified.

2.2.3  IPv6 Considerations

   Protocols to perform translation between host name and IP address
   have no zeroconf-related differences for IPv4 and IPv6.

3.2 Name to Address Resolution

   The security implications of this zeroconf protocol must be
   compared against the DNS protocol.

   DNS is a client-server protocol.  The zeroconf name to address
   translation protocol will likely use multicast so that any host
   may respond to queries.  This broadens the possibility that host
   authentication in the form of hostname-IP address mappings may be
   compromised, since all hosts effectively may behave as DNS servers.

   Currently it is possible to subvert DNS in various ways, unless
   DNSsec [RFC 2535, RFC 2931] is used.  For example:

   - A client may be configured with the address of an attacker's DNS
     server.  For example, an active attacker on the same subnet as the
     client may respond to DHCP DHCPDISCOVER messages and deliberately
     configure the client to use a compromised DNS server.

   - An active attack against a DNS client is possible - where an
     attacker unicasts a DNS reply to a client request that arrives
     at the client before the legitimate server's response.

   DNSsec protects against such attacks as the client can verify that
   the data it retrieves using the DNS has been signed from a source
   that the client has been configured to accept.

   A zeroconf name to address resolution protocol MUST be compatible
   with the use of DNSsec.  Therefore it MUST be possible for a host
   running a zeroconf protocol to use DNS and DNSsec for authenticated
   name resolution if that host (or its administrator) chooses to do so.
   [RFC 2541]

---

From: Aidan Williams <[email-masked]>
Date: Thu, 13 Dec 2001 10:23:43 +1100

> mean it has to be integrated in the DNS itself.

This discussion has been had before.  The zeroconf working group
charter only talks about developing two new protocols, and a name
service protocol is not one of them.  Rather, the expectation was
that the existing DNS protocol would be 'profiled' for zeroconf use.

In suggesting that the requirements document is broken w.r.t. using
DNS for name resolution, I think there is a charter issue.

> What is needed is just another local scope name service.

This discussion has been had on the dnsext mailing list too.
I wrote a draft describing the update of the DHCP search list option
supporting this sort of thing, but subsequently this turned out to be
a bad idea because of the complexity of the per-interface and
search-order interactions.

> It may, but is not required and it may or may not be desirable.

Indeed, I have a lot of sympathy for that view, and I could live with
ICMPv6 Node Information Query as the IPv6 zeroconf name resolution
protocol.

To my mind, mDNS and the ICMPv6 Node Information Query are pretty much
the same protocol.  They both use multicast, and DNS formatted packets,
but the encapsulation is different (icmp vs udp).

Therefore the issues that are dogging the mDNS protocol ought to apply
also to the ICMPv6 NI Query.  If we define the NI Query as "not DNS",
we could easily define mDNS as "not DNS" (and if I recall correctly,
that was suggested in the meeting too).

regards
	aidan
____
:wq!