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

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Nov 2010 09:32:55 +0200 (EET)

On Tue, 26 Oct 2010, The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'DNS-Based Service Discovery'
>  <draft-cheshire-dnsext-dns-sd-07.txt> as a Proposed Standard

This is an ops-dir review of draft-cheshire-dnsext-dns-sd.  Given how widely
the protocol has been implemented, I think standards track is appropriate.
I think you may be able to implement and operate the protocol based on this
specification, but the audience would greatly benefit from putting a bit
more work in the specification.

Operational perspective:
------------------------

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

The document includes requirements and recommendations to network operators
using these services (e.g. S 7.2, S 10) but it's difficult to find.

General observations:
---------------------

1) This document was IETF last called, going informational, in November 2008.
Many comments made during that LC I agree with and have not been addressed. 
See e.g. the following and the follow-ups. 
http://www.ietf.org/mail-archive/web/ietf/current/msg53658.html
http://www.ietf.org/mail-archive/web/ietf/current/msg53712.html
http://www.ietf.org/mail-archive/web/secdir/current/msg00213.html

2) I'd like to see a more detailed review from DNS directorate on this one. 
High-level issues have already been discussed on their list.
http://www.ietf.org/mail-archive/web/dns-dir/current/msg00865.html

3) The document includes protocol specification, design rationale,
to some degree product documentation, advice to application developers,
requirements for DNS servers implementors, etc. in such a fashion that it's
very difficult to find out who should do what.  This could be improved with
a document structure that makes these distinct. Details below.

4) As acknowledged by dns-dir discussion, DNS-SD is essentially a new protocol
(or at least a new kind of 'usage profile') that re-uses DNS formats and semantics.
It's not obvious how this should be addressed, i.e. is more "truth in
advertising" needed.  For example, it uses PTR record lookups in the forward
DNS zone, may store DNS labels including '.' in DNS, and uses TXT records to
store binary data.

Given that document suggests DNS-SD may be used with regular DNS servers,
I'd much more confortable if I saw a DNS-dir technical review for conflicts
or technical issues from that perspective.

Some technical details
----------------------

    There is quite a bit of 'design rationale' (or: "don't implement it this
    way") stuff in here that could probably be removed or moved to an appendix
    in the interest of tightening the main spec.

    Examples: almost all of S 4.4, second paragraph of S 5, maybe all
    of 6.1 except 1-2 last paragraphs,

    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 same also applies to operational advice to network operators (e.g. those
    parts of S 7.2 that deal with parentdomain and dividing by floors, etc., maybe S 10)

    Some are requests to DNS server implementors (S 13.1).

In S 4.1:

                      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?

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

                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.

    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.

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.

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.

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.

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

    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?

Editorial:
----------

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

...

    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.

Similarly, what would happen if someone named their Application instance
'_sub' or '_printer._sub' ?

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