RE: summary/conclusion of discussion on mdns-00

["Nicolae, Dan" <[e-mail]>]

> 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


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