Subject: RE: summary/conclusion of discussion on mdns-00

From: "Levon Esibov" <[email-masked]>
Date: Mon, 14 May 2001 15:31:36 -0700

I'll submit the updated draft by 5/25.

Thanks,
Levon.

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

---

From: "Nicolae, Dan" <[email-masked]>
Date: Tue, 15 May 2001 14:30:23 -0400

> [12] DNS server discovery
> 
>     We debated whether or not it is a good idea to offer more than
>     one optional mechanism for configuring DNS server locations.
>     Randy doubted whether we need more than DHCP.  Bernard noted
>     that when we have a DNS server we can often assume there will
>     be a DHCP server too.  All others participating in the discussion
>     found some advantage in being able to use DNS to configure DNS.
> 
>     Note that this potential is present using mdns as defined, after
>     change [1] above.  If an mdns query type='NS' is sent, any mdns
>     enabled DNS server that responds has been discovered!
> 
>     Suggestion:  Add a note that DNS servers MAY listen for mdns
>     requests of type=NS and respond (if the name corresponds to 
>     the domain for which the server is authoritative).  Resolvers 
>     MAY issue these requests to discover DNS servers.
> 

This solution only enables discovery of DNS servers that hold authoritative
data. Most resolvers need to discover a local DNS server configured as
caching-only or slave.

The NS records are intended for navigating the DNS name space (finding the
servers authoritative for a particular zone). They are mostly useful to
servers that provide recursive services to stub resolvers, or resolvers that
perform their own recursion.

For a stub resolver to discover a local server that provides DNS services
the problem is similar to any other service (item 13 below). For example, a
query for QNAME="_DNS._TCP.local.arpa.", QTYPE=SRV would be needed.

Secondly, a mDNS device itself would respond to a query for a NS record
associated with its name (it is authoritative for the DNS zone with only one
node: itself). The requestor would then think that the mDNS device is a DNS
server. For example, child.host.example.com. could discover
host.example.com. and believe that it is a DNS server)

> [13] Service discovery
> 
>     We discussed how this might be possible with mdns and SRV RRs.
>     Yes it is.  We could debate whether it is the right way to 
>     discover services for some time.  Trust me on this.
> 
>     Suggestion: Say nothing about service discovery in this draft.  
>     If mdns servers support SRV RRs they can respond to queries of 
>     type=SRV, but this is already clear in the text:
> 
> >A sender sends multicast DNS query for any legal Type of 
> resource record
> >(e.g. A, PTR, etc.) for a name...
>

---

From: "Nicolae, Dan" <[email-masked]>
Date: Wed, 16 May 2001 13:26:32 -0400

> >[9] Change text: 'A gratuitous name resolution query SHOULD be done
> >     to check for a name conflict.  This is done by having 
> the resolver
> >     send a multicast query for a SOA type query for its own 
> name (i.e.
> >     for the name it is authoritative for.'
> >     s/SHOULD/MAY/
> >     s/SOA/A/
> 
> No way this change should be done!!! Read notes from the 
> Adelaide lunch 
> meeting to understand why.
> 

Are these notes available on-line, or were they sent to the namedroppers
list? I can't locate them in the archive.

Thanks,
Dan

---

From: "Nicolae, Dan" <[email-masked]>
Date: Wed, 16 May 2001 16:42:56 -0400

> > This one was extensively discussed already, and WG 
> consensus was to use
> > .local.arpa. So default should be to reject the change 
> unless it can be
> > demonstrated that the WG has changed its mind. 
> 
> When thinking about local.arpa it would be good to take a look at
> draft-iab-arpa-01.txt.
> 
>   Erik
> 

I could not find any indication in draft-iab-arpa-01.txt that the arpa
domain is appropriate for mDNS purposes:
    "This domain is termed an "infrastructure domain", as its role is to
     support the operating infrastructure of the Internet. In particular,
     the ARPA domain is not to be used in the same manner (e.g. for
     naming hosts) as other generic Top Level Domains are commonly used."

Any non-existent domain name could be used with the same results. 
The intents of using local.arpa are not clearly stated in the document. I
gather that the rationales are:
[a] to avoid the definition of a new DHCP option to enable/disable mDNS
[b] to prevent a mDNS host to behave like an authoritative DNS server for a
'real', administratively managed domain name

Is that right? Are these the rationales?

Dan

P.S. As a side note, I can't identify the "single change to the method of
use"; it seems like there are quite a few changes:
"This document discusses multicast DNS, an extension to the DNS protocol
which consists of a single change to the method of use, and no change to
the format of DNS packets."

---

From: "Nicolae, Dan" <[email-masked]>
Date: Thu, 31 May 2001 12:26:07 -0400

> How is DDNS to be secured in an adhoc environment? 

How is DDNS secured in a managed environment? The mechanisms defined in
RFC3007/RFC25235 should suffice  should any authentication means be needed
in an adhoc environment. They don't help with the authorization policy as
this is left up to the DNS administrator and there isn't any in a pure
peer-to-peer network. And they only provide a means for passing
authentication information back and forth.

This is a very good question, but I don't see any new security issues
introduced by DDNS; using only queries to grab names and handle conflicts is
no different. The draft proposes a authorization policy where the first host
able to grab the name can keep it (assuming that it is able to defend it).
The likelihood to successfully enforce this policy should be the same if
DDNS is used instead of gratuitous queries.

On the other hand:

The proposed gratuitous query mechanism may serve the purpose as is. DDNS is
only potentially better because it is more versatile and using it is
coherent with the algorithms for managed networks. Also, if we talk
security, DNS transaction authentication is more meaningful for DDNS than
for standard queries.

It is interesting to observe that the proposal to send a gratuitous name
query for the SOA record is consistent with DDNS algorithms used by real
implementations. This is the first step that an updater takes: it sends a
query for a SOA RR associated with its own name. If one exists then that's a
problem. But if not, the response will (hopefully) contain both the
appropriate zone name and the primary name server to be used for subsequent
updates.

So, in a way, mDNS already uses DDNS. Or, better said, it gets ready to,
should more action be needed.

A positive response returned to the SOA query does not necessarily indicate
a name (A RR) conflict. It only indicates that some other entity (mDNS host
or DNS server perhaps) has assumed the authority for the zone where the
update should take place. The updater may still try to send updates for its
name to the identified authority but it cannot assume authority (unless the
other gives up for some reason)...etc. This can get complicated. 

I propose to leave the draft as is for now but further investigate DDNS,
name conflicts and security later. More opinions would be helpful.

dan