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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf