Has anyone talked to anyone in the applications world about this?
The use of a new DNS Resource Record creates far more problems than any of
these proposed discovery mechanisms offer. No matter how much the DNSEXT
people want to believe that adding DNS records is not an issue, the fact is
that it is.
SRV is a well established record. It is already widely used for service
discovery. This new proposal does not offer any real functionality. All it
allows is for the service administrator to choose a random string to insert
into every one of their service URLs. The random string chosen has no
semantic significance whatsoever, has no security benefit and the only
constraint on it is that it should be unique for each service.
Back in the earliest days of the web, the first web server was info.cern.ch.
After a short while www.example.com became the standard naming to the point
where it is now embedded in many browsers that if a search for a domain
fails, add www. to the name and try again.
Whether you like that approach or not, the fact is that the administrative
constraint of a web server being expected to be at www has not proved
onerous. If we pick out one way to do the management of web services via SRV
lookup the software world will quickly adapt to it. The transition from the
SRV way of doing things to the new way of doing things can be easily managed
through server side URI mapping. There is no need for HTTP redirects of any
on-the-wire protocol impact.
What we are missing here is a better way to find the protocol properties.
That is something that should be done through a DNS record rather than an
HTTP lookup. If the protocol properties are discovered through HTTP lookup
then we have already made the decision to use HTTP and we can't use DNSSEC
to advertise that SSL is always available to avoid a downgrade attack.
On Fri, Jun 25, 2010 at 3:53 AM, Ray Bellis
<Ray(_dot_)Bellis(_at_)nominet(_dot_)org(_dot_)uk>wrote:
I can certainly see where it would be useful. However, I question your
comments in Section 9 of your draft: specifically that URI should be viewed
as a replacement for SRV. URI (may) make sense for "resource" discovery, but
I don't believe that is true for "service" discovery - I think SRV still
makes the best sense for that.
IMHO, that depends on the service.
In RAI we have "LoST" and "HELD", both of which are HTTP(s) based services
contacted through a URI.
A "URI" RR-based solution for discovery of those would, I think, have been
cleaner than the current U-NAPTR based methods.
Ray
--
Ray Bellis, MA(Oxon) MIET
Senior Researcher, Nominet
e: ray(_at_)nominet(_dot_)org(_dot_)uk, t: +44 1865 332211
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
Website: http://hallambaker.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf