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