Re: What is the right way to do Web Services discovery?

[Jared Mauch <[e-mail]>]

(Not going to address things where I perhaps disagree, but focus on areas of concern …)

> On Nov 22, 2016, at 10:04 AM, Phillip Hallam-Baker <[e-mail]> wrote:
> 
> I am asking here as there seems to be a disagreement in HTTP land and DNS land.
> 
> Here are the constraints as I see them:
> 
> 0) For any discovery mechanism to be viable, it must work in 100% of cases. That includes IPv4, IPv6 and either with NAT.

I think must be sufficiently robust, where it’s defined as 98+%.  Studies on the operational networks seem to indicate this is the threshold is in the 95-99% range.  Saying 100% is a goal, but perhaps unrealistic.  Downgrade modes don’t necessarily represent an attack, and may be the intent of an enterprise.  (I don’t want to argue this point, but raise it for those that may not be aware).

> 
> 1) Attempting to introduce new DNS records is a slow process. For practical purposes, any discovery mechanism that requires more than SRV + TXT is not going to be widely used.
> 
> 2) Apps area seems to have settled on a combination of SRV+TXT as the basis for discovery. But right now the way these are used is left to individual protocol designers to decide. Which is another way of saying 'we don't have a standard'.
> 
> 3) The DNS query architecture as deployed works best if the server can anticipate the further requests. So a system that uses only SRV+TXT allows for a lot more optimization than one using a large number of records.
> 
> 4) There are not enough TCP ports to support all the services one would want. Further keeping ports open incurs costs. Pretty much the only functionality from HTTP that Web Services make use of is the use of the URL stem to effectively create more ports. A hundred different Web services can all share port 80.
> 
> 5) The SRV record does not specify the URL stem though. Which means that either it has to be specified in some other DNS record (URI or TXT path) or it has to follow a convention (i.e. .well-known). 

I think the historical error was that there wasn’t a Web-Property type application record similar to how we have MX records for other applications, eg: E-Mail.  This leads to many workarounds, including those of e-mail to a host record without MX presuming that was enough.  It worked well enough to be usable for decades, but also set into peoples minds that HTTP would go directly to the host vs an indirection layer similar to e-mail.
> 
> 6) Sometimes SRV records don't get through and so any robust service has to have a strategy for dealing with that situation.

I think a degrade mode, eg: what if MX records were filtered?  At some point, you want to exert pain on broken devices and networks to provide them an incentive to correct unintended behaviors.  One can’t workaround forever, there must be an inherent or implied TTL.  Anyone with legacy they carry around with them understands.  I have my own personal mistakes from 20+ years ago lying around my own infrastructure that will be painful to correct.  One should think about how we migrate things like the http application/transport away from the individual A/AAAA records (if that’s a desired goal) and how it would move further along the path.

- Jared