[Topposting because easier to summarize]
The key point here is that all that is required to make use of SRV for Web Service lookup is to have some defined convention for converting the information from the SRV record and accompanying TXT record into some form of URI.
The problem we have today is that this is a design step that has to be taken by every individual protocol, there is no consistency and that kills efficiency because it prevents DNS resolvers returning the appropriate set of additional records.
Another benefit to standards recognition is that it would allow Microsoft and other platform providers to embed the technology at the platform level. Windows actually has a Web server built in and it is possible for applications to register to service particular http URL paths. So (if I have the privileges) I can register to service http://example.com/.well-known/mmm. And I can have one application servicing that and another servicing http://example.com/.well-known/everything.
One of the structural problems is that the DNS area in IETF is focused on DNS operations, they have not been responsive to the needs of application and service providers. The response to every proposal to adapt has been 'create a new RR' which is utter nonsense to anyone who actually knows the business end of how DNS services are provided. Telling people who are customers of a DNS registrar which is a customer of an IT provider which is a customer of C-Panel 'just add the new RR type' is simply nonsense.
The SRV+TXT approach works, but it needs some consistency between applications and some defaults and some consensus about which information needs to go into DNS discovery and which can be delayed until after the client has made contact.
The information I believe is necessary is:
1) The presentation layer protocol (Default is HTTP)
2) The transport security option (e.g. TLS)
3) The host key to be used for initial contact (e.g. X25519/X448 key)
4) Protocol options that may differentiate hosts (e.g. supported version, syntax)
This information is sufficient to allow a client to connect to a host offering service FOO without revealing that it is going to use the FOO service and to pick the right service in the case that there is a protocol version transition going on in which only some hosts offer certain protocol versions.
Since the host may offer multiple services on the same port and these may have completely different credential requirements, there is a distinction between the host credential and the service credential.
[While ECC might be vulnerable to quantum cryptanalysis, I don't consider it necessary to apply PQC protections to protect against traffic analysis attacks. Arguably, the X448 I am planning to use is overkill (I do have running code but this feature is currently disabled in the Mesh reference code because debugging code with three layers of encryption is a bit too much of a pain).]
The advantage of this approach becomes apparent when we consider how we would deploy new presentation layer substrates. Let us consider the case in which Microsoft provides the Web Service provider with an API call 'GetDnsTxt' that returns the TXT options describing the service endpoint and I write an application service that hangs off that API, let us further assume that five years after I stop supporting the code, Microsoft implements a new IETF presentation layer for Web services based on QUIC. My service will automatically inherit that layer, all I have to do is upgrade the host.
The same could be made true for Linux but the platform in that case is going to be the Web Server rather than the O/S.
On Fri, Sep 15, 2023 at 3:12 AM Masataka Ohta <mohta@xxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Keith Moore wrote:
> Since every web service has its own URI, SRV records don't work well to
> specify ports for web services.
That is a over generalization because an object identified by
a URI, in general, is not accessible and not a target of web
services.
Instead, for objects accessible by single IP addresses and single
port numbers, we can safely assume the following URL syntax:
<scheme>://[<userinfo>@]<host>[:<port0>]<path>[?<query>]
The problem, then, is that automatic conversion from
the URL (assuming <host> is not a raw IP address but
a domain name) to:
_<service>._<proto>.<host> SRV <priority> <weight> <port1> <target>
is impossible without some global database to convert <scheme>
to <service> and <proto>, which is another level of indirection,
which can be annoying.
Instead,
_<scheme>.<host> SRV <priority> <weight> <port1> <target>
should simply work and the original URL will be converted to:
<scheme>://[<userinfo>@]<target>:<port><path>[?<query>]
interpretation of which depends on <scheme> and not
affected by SRV.
A remaining problem is lack of specification on how <port0>
and <port1> interact resulting in <port>.
See draft-ohta-urlsrv-00.txt for detailed discussions, though
it assumes:
_<scheme>._<proto>.<host> SRV ...
which was fine when practically all the <proto> was TCP.
Masataka Ohta
