Re: zeroconf name resolution does not mean necessarily DNS

[Bernard Aboba <aboba@internaut.com>]

> What is needed is something to map local names to IP addresses
> in a zeroconf environment (no DNS server)

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

   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:
   - MUST support DNS application layer interfaces as described
     in RFC 1123, section 6.1. [RFC 1123]

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]




to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.