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

From: Stuart Cheshire <[email-masked]>
Date: Tue, 14 Dec 2010 22:00:06 -0800

On 17 Nov 2010, at 11:32 PM, Pekka Savola wrote:

> I have mostly heard and seen DNS-SD used in conjunction with mDNS.  
> I do not
> know how much it has been used with regular DNS. Issues like DNS  
> updates
> that have only received superficial attention in this document will be
> present there. I'd be interested in hearing how much this is used with
> regular DNS and how information is in practise stored there (manual
> insertion vs dynamic updates).

Many millions of Apple customers have been using DNS-SD with regular  
unicast DNS for since 2007. We have added this to the document:

    While the original focus of Multicast DNS and DNS-Based Service
    Discovery was for Zero Configuration environments without a
    conventional unicast DNS server, DNS-Based Service Discovery also
    works using unicast DNS servers, using DNS Update [RFC2136] to  
create
    service discovery records and standard DNS queries to query for  
them.
    Apple's Back to My Mac service, launched with Mac OS X 10.5 Leopard
    in October 2007, uses DNS-Based Service Discovery over unicast DNS.

>    Also, there is quite a bit of text that's not specific to DNS-SD
>    protocol, but rather how e.g. an app developer should use it.  
> It's not
>    obvious how that should be part of the main spec.  I wonder if  
> these could
>    be split off to a be under a single section for clarity (e.g.  
> most of S 8, S 15).

The entire document is talking about how an app developer should use  
it. "It" in this context is the domain name system. DNS-SD is not a  
protocol in itself. It's a usage convention for DNS records. The  
entire document is telling server developers what DNS records we  
recommend they use to describe their service, and telling client  
developers what DNS records we recommend they query for to discover  
those advertised services. It describes what app developers should  
pick for Instance names and Service names. It describes what data app  
developers should put into TXT records. If we took out all the text  
directed at app developers there would be virtually nothing left.  
They are the audience for this document.

>                      In cases where the DNS server returns a negative
>    response for the name in question, client software MAY choose to
>    retry the query using "Punycode" [RFC 3492] encoding, beginning  
> with
>    using Punycode encoding for the top level label, and then issuing
>    the query repeatedly, with successively more labels converted to
>    Punycode each time, and giving up if it has converted all labels
>    to Punycode and the query still fails.
>
> .. would this "retry with punycode, expanding each label at a time"  
> result
> in a typical case in at least 3 additional lookups in the case of  
> missing
> services?

Since clients only look up services they have discovered via PTR  
queries, discovering nonexistent services would be a rare error  
resulting from some bad misconfiguration.

> .. it appears to me that you should provide a more precise  
> specification
> isntead of 'a negative response'.

We use 'negative response' in the usual DNS sense to mean NXDOMAIN or  
no-error-no-answer.

>                Every DNS-SD service MUST
>    have a TXT record in addition to its SRV record, with the same  
> name,
>    even if the service has no additional data to store and the TXT
>    record contains no more than a single zero byte.
>
> ... why?  what happens if this is not the case? will the client  
> protocol
> break down and fall to pieces?   IMHO, there should be a strong  
> operational
> and/or service publication recommendation to publish TXT records,  
> but on
> _client_ side, this kind of mandate flies against the robustness  
> principle.

We have added this to the document:

    DNS-SD clients SHOULD treat the following as equivalent:

     o A TXT record containing a single zero byte.
       (i.e. a single empty string.)

     o An empty (zero-length) TXT record
       (This is not strictly legal, but should one be received it should
       be interpreted as the same as a single empty string.)

     o No TXT record.
       (i.e. an NXDOMAIN or no-error-no-answer response.)

>    The <Service> portion of a Service Instance Name consists of a pair
>    of DNS labels, following the convention already established for
>    SRV records [RFC 2782], namely: the first label of the pair is an
>    underscore character followed by the Application Protocol Name, and
>    the second label is either "_tcp" or "_udp".
>
>    For applications using other transport protocols, such as SCTP,  
> DCCP,
>    Adobe's RTMFP, etc., the second label of <Service> portion of its
>    DNS-SD name should be "_udp".
>
> ... this might be inappropriate overloading of UDP.  The referred spec
> says any protocol is valid:
>
>    Proto
>         The symbolic name of the desired protocol, with an underscore
>         (_) prepended to prevent collisions with DNS labels that occur
>         in nature.  _TCP and _UDP are at present the most useful  
> values
>         for this field, though any name defined by Assigned Numbers or
>         locally may be used (as for Service).  The Proto is case
>         insensitive.
>
> ... but I suppose changing this from UDP is a non-starter for
> background-compatibility perspective. If so, I suggest documenting  
> this as a
> backward-compat solution rather than construing as if the referred  
> spec
> required this.

We have added this to the document:

    Note that this usage of the "_udp" label for all protocols
    other than TCP applies only to DNS-SD names following the  
conventions
    established by this document. Other specifications using SRV records
    may specify other naming conventions.

> In S 8:
>
>    To help guard against this, when there are two or more network
>    protocols which perform roughly the same logical function, one of
>    the protocols is declared the "flagship" of the fleet of related
>    protocols. Typically the flagship protocol is the oldest and/or
>    best-known protocol of the set.
>
> .. who makes this flagship declaration?  The next paragraph appears  
> to imply
> that it must be done when registering DNS-SD profiles with IANA (in  
> the
> future). In which case IANA guidance would be needed. I may be
> misunderstanding something.

We have added this to the document:

    When IANA records an application protocol name registration, if the
    new application protocol is one that conceptually duplicates  
existing
    functionality of an older protocol, and the implementers desire the
    Flagship Naming behavior described in Section 8, then the registrant
    should request IANA to note the name of the flagship protocol in the
    "notes" field of the new registration. For example, the  
registrations
    for "ipp" and "pdl-datastream" both reference "printer" as the
    flagship protocol name for this collection of printing-related
    protocols.

> 17. Security Considerations
>
>    DNSSEC [RFC 2535] should be used where the authenticity of
>    information is important. Since DNS-SD is just a naming and usage
>    convention for records in the existing DNS system, it has no  
> specific
>    additional security requirements over and above those that already
>    apply to DNS queries and DNS updates.
>
> .. this is a bit weak. There's more stuff to put in DNS updates.  
> See the
> referred sec-dir review from two years ago.  The text is unchanged.

The sec-dir review said "I find this inadequate" and "this document  
seems to need more work". Can you suggest some specific text? DNS-SD  
is a convention for how to name and use DNS records. Every security  
consideration that applies to a client using DNS queries and updates  
would apply to a client following the conventions in this document.

Right now we have updated the document to say this:

    Since DNS-SD is just a naming and usage convention for records in
    the existing DNS system, it has no specific additional security
    requirements over and above those that already apply to DNS queries
    and DNS updates.

    For DNS queries, DNSSEC [RFC 2535] should be used where the
    authenticity of information is important.

    For DNS updates, secure updates [RFC 3007] should generally be
    used to control which clients have permission to update DNS records.

> 18. IANA Considerations
>
>    IMPORTANT NOTE: Once draft-ietf-tsvwg-iana-ports is published, most
>    of this IANA Considerations section can be deleted.
>
> .. I don't quite understand how draft-ietf-tsvwg-iana-ports relates  
> here and
> more specific descriptions would be useful.

Because draft-ietf-tsvwg-iana-ports documents how to register service  
names with IANA.

> .. Is this doc expected to be published before draft-ietf-tsvwg- 
> iana-ports? It's not a normative reference, and if you want to wait  
> for that to complete, it should be recorded as normative.

Normative Reference added.

>    Some developers have expressed concern that publicly registering
>    their service names (and port numbers today) with IANA before a
>    product ships may give away clues about that product to  
> competitors.
>    For this reason, IANA should consider allowing service name
>    applications to remain secret for some period of time, much as US
>    patent applications remain secret for two years after the date of
>    filing.
>
> .. How is this protected with current dns-sd.org maintenance  
> regime?  Unless
> you make an NDA with the party you're exposing your patent secrets  
> to, you're
> considered to have been made information public.  So creating a new  
> kind of
> secret registration doesn't seem to cut it.  Just register when  
> you're ready
> to register?

We have deleted this section.

> Editorial:
> ----------
>
>  - IANA considerations does not explicitly mention 'DNS-SD profile'
>    referred to in S 6 (though you can work out what you mean).

Can you suggest some specific text?

>    For this reason, a special meta-query is defined. A DNS query  
> for PTR
>    records with the name "_services._dns-sd._udp.<Domain>"
>
> .. in the DNS-SD profiles or IANA considerations, you do not define  
> these
> special strings that should not be registered.

The "_dns-sd" string is already in the list at <http://www.dns-sd.org/ 
ServiceTypes.html> and will be migrated to IANA as per draft-ietf- 
tsvwg-iana-ports.

> Similarly, what would happen if someone named their Application  
> instance '_sub'

Nothing bad would happen.

> '_printer._sub' ?

Application protocol names are not allowed to contain dots.

> 16. IPv6 Considerations
>
>    IPv6 has no significant differences, except that the address of the
>    SRV record's target host is given by the appropriate IPv6 "AAAA"
>    address records instead of (or in addition to) IPv4 "A" records.
>
> .. well it's not obvious if you count it significant or not, but the
> reverses IP entries are under a different tree and longer.  This  
> comes up
> e.g. with _dns-sd discovery of browsing domains (S 12).

We have updated the document to say:

    IPv6 has only minor differences.

    The address of the SRV record's target host is given by the
    appropriate IPv6 "AAAA" address records instead of (or in addition
    to) IPv4 "A" records.

    Address-based Domain Enumeration queries are performed using names
    under the IPv6 reverse-mapping tree, which is different to the IPv4
    reverse-mapping tree and has longer names in it.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: Pekka Savola <[email-masked]>
Date: Thu, 16 Dec 2010 11:02:20 +0200 (EET)

On Tue, 14 Dec 2010, Stuart Cheshire wrote:
> The entire document is talking about how an app developer should use it. "It" 
> in this context is the domain name system. DNS-SD is not a protocol in 
> itself. It's a usage convention for DNS records. The entire document is 
> telling server developers what DNS records we recommend they use to describe 
> their service, and telling client developers what DNS records we recommend 
> they query for to discover those advertised services. It describes what app 
> developers should pick for Instance names and Service names. It describes 
> what data app developers should put into TXT records. If we took out all the 
> text directed at app developers there would be virtually nothing left. They 
> are the audience for this document.

In a way, I understand that it could be argued that this is just a 
"naming convention" (also see the security considerations below).

Practically, however, it could be said to describe at least the 
solution framework.  In practise, it describes the functionality that 
should be implemented in a DNS-SD software library the apps can link 
to, or even some kind of separate sofware package.  While implementing 
everything described here would also be doable in each application (no 
doubt some will do so), that would be waste.

The point is underlined in e.g. how DNS-updates or related DNSSEC 
keying material would be configured, i.e. everything where there's 
more to it than just a naming convention.

>>    convention for records in the existing DNS system, it has no specific
>> .. this is a bit weak. There's more stuff to put in DNS updates. See the
> The sec-dir review said "I find this inadequate" and "this document seems to 
> need more work". Can you suggest some specific text? DNS-SD is a convention 
> for how to name and use DNS records. Every security consideration that 
> applies to a client using DNS queries and updates would apply to a client 
> following the conventions in this document.

>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.

> Can you suggest some specific text?

The minimal fix would be to change:

    This document specifies the following IANA allocation policy for
    unique application protocol names:

to:

    This document specifies the following IANA allocation policy for
    unique application protocol names (DNS-SD profiles):

... but it would still leave IANA considerations a big ambiguous.  It 
would be much better if the required checklist on what to report and 
how IANA should record it in its registry was in a tabular format. 
While it's not in tabular format, the bullet list at 
http://www.dns-sd.org/ServiceTypes.html describes this rather well.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 22 Dec 2010 22:10:57 -0800

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

> 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.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 23 Dec 2010 09:33:12 +0200 (EET)

On Wed, 22 Dec 2010, Stuart Cheshire wrote:
> 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.
>

What I'm saying is that having to manually pre-configure the hostname 
in DNS goes against what appears to be one of the main DNS-SD goals, 
i.e., the host can invent the hostname or use it in a zero-conf 
fashion.

I don't think it's possible to integrate DNS-SD with secure DNS 
without losing at least some of the properties DNS-SD was designed to 
address.  So it would be unrealistic to require this from the 
protocol, especially given its background.

What I would have wanted to see is more truth in advertising how in 
practise using security impedes the use of DNS-SD.  Which usage modes 
of DNS-SD can be made to work and at what cost.

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 23 Dec 2010 15:16:38 -0800

On 22 Dec 2010, at 23:33, Pekka Savola wrote:

> What I'm saying is that having to manually pre-configure the hostname in DNS goes against what appears to be one of the main DNS-SD goals, i.e., the host can invent the hostname or use it in a zero-conf fashion.
> 
> I don't think it's possible to integrate DNS-SD with secure DNS without losing at least some of the properties DNS-SD was designed to address.  So it would be unrealistic to require this from the protocol, especially given its background.
> 
> What I would have wanted to see is more truth in advertising how in practise using security impedes the use of DNS-SD.  Which usage modes of DNS-SD can be made to work and at what cost.

I see the confusion. Multicast DNS is intended to be zero-configuration. DNS-SD is not necessarily. I have added this to the introduction which should hopefully clarify this:

   When used with Multicast DNS, DNS-SD can provide zero-configuration
   operation -- just connect a DNS-SD/mDNS device and its services are
   advertised on the local link with no further user interaction.

   When used with conventional unicast DNS, some configuration will
   usually be required -- such as configuring the device with the DNS
   domain(s) in which it should advertise its services, and configuring
   it with the DNS Update [RFC 2136] keys to give it permission to do
   so. In rare cases, such as a secure corporate network behind a
   firewall where no DNS Update keys are required, zero-configuration
   operation may be achieved by simply having the device register its
   services in a default registration domain it learns from the network
   (See Section 12 "Discovery of Browsing and Registration Domains")
   but usually security credentials will be required to perform DNS
   Updates.