Re: Last Call: <draft-cheshire-dnsext-dns-sd-07.txt> (DNS-Based Service Discovery) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 16 Dec 2010, at 1:02 AM, Pekka Savola wrote:

From my POV, the most important thing I'd like to see in Security Considerations section is description of that app developer will be able do the DNS updates, hopefully in a secure fashion.

Some examples of what I wonder:

 - Is the expectation that you configure the DNS server so that
   certain IP's have complete access to do updates?

 - What does that imply?  Is it possible to limit the update
   capability to some subtree?  What kind of configuration would it
   need if it should be application-specific? (I.e., if one
   application gets out of hand, can it mess up all other apps or even
   the whole DNS domain?)

 - Or do you expect deployment of DNS security (e.g. TSIG, SIG0)? If
   so, how do you configure these in the app and the server within the
   constraints of zero-conf goals?  Do the same DNS subtree
   limitations and caveats apply?

To sum it up, I suspect the zeroconf nature of the goals of this work is likely to prevent the use of TSIG/SIG(0) in DNS-updates, or at least it requires major manual operations and/or it effectively authorizes one application to update every other application's data as well. But in some contexts it could be possible to implement it in a different way.

I feel a tutorial on how to set up secure updates would be out of scope for this document.

FWIW, Apple's code on Mac OS X uses TSIG for secure updates. You enter the credentials in the "Sharing" preferences pane. What the user-interface people chose to label "User" and "Password" are in reality the TSIG key name and the TSIG key data. They felt that most users wouldn't know what TSIG meant, and it was better to have something familar (but wrong) rather than something unfamilar (but correct). Sorry.

BIND allows pretty flexible configurations to control which keys are authorized to update what records.

Stuart Cheshire <cheshire@xxxxxxxxx>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

PNG image

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]