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 <cheshire(_at_)apple(_dot_)com>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf