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.Bellis@xxxxxxxxxxxxxx> wrote:
IMHO, that depends on the service.
> 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.
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@xxxxxxxxxxxxxx, t: +44 1865 332211
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
--
Website: http://hallambaker.com/
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf