There is already a scheme to do what you want, problem is that it isn't quite documented in one place, you need SRV records, DNS service discovery RFC6763 AND the Well Known services hack. This is my attempt to bring that earlier work together:
One of the underlying assumptions here is that Web Services really aren't well served by HTTP, most of which merely gets in the way. If your Web Service benefits from caching, it is an information retrieval, not a Web Service.
So at some point in the future, I assume we get round to writing a Web Services over QUIC that is optimized to that set of needs and which does not use URIs, but instead makes the .Well-Known hack the port identifier.
Using the combination of SRV and TXT allows fine grained description of both the service and the specific hosts:
_mmm._tcp.example.com SRV host1.example.com 0 10 80 host1.example.com _mmm._tcp.example.com SRV host2.example.com 0 40 80 host2.example.com _mmm._tcp.example.com TXT "version=1.0-2.0" mmm.example.com CNAME host3.example.com host1.example.com A 10.0.1.1 host2.example.com A 10.0.1.2 _mmm._tcp.host2.example.com TXT "path=/service" host3.example.com A 10.0.1.1 host3.example.com A 10.0.1.2
This approach is vastly superior to DANE because it is not limited to TLS, it is not limited to PKIX either.
In this case the mmm service is over plain old HTTP on port 80 and will be found at the URI:
Now you might be wondering why this isn't over HTTPS, that is because for this particular protocol, every transaction message is encrypted and authenticated at the presentation layer. TLS is transport security which is a good fit for HTTP but a bad fit for anything that is transactional because you want to quantize the transaction messages and fit the authentication to them in a way that the transaction endpoints have visibility.
If this was going to go over a QUIC based transport or a steganographic transport or whatever, the information to enable that would go into the TXT record for the service (if applying to all hosts) or the individual host.
This might not seem such a big win on its own, but consistency has a quality all of its own and one of the functions of my technologies is to manage services and devices.
So the medium term goal here is:
* Every device is performing DNS resolution over an encrypted, authenticated channel to the chosen DNS resolver.
* All DNS entries are generated automatically and maintained by the service orchestration.
* All DNS zones are signed.
Automating the DNS zone management is the key to making DNS based security policy practical.
A system like DANE or Cert Pinning is fine in theory, in practice it falls apart if the administrator doesn't keep the DNS zone up to date and completely correct. Which isn't going to happen without automation.
On Tue, Sep 12, 2023 at 1:30 AM Sagar Acharya <sagaracharya=40tutanota.com@xxxxxxxxxxxxxx> wrote:
Dear members,
As mentioned in RFC 6186, there are SRV records for specific services, i.e. in above document of mail submission and in many others.
My suggestion lies with regards to making each and every web service completely independent with respect to port on which it is hosted. Getting ports for each service can be done via SRV records. A/AAAA, and SRV records make a complete system thereby helping making routing extremely simple. (xyz ip at port srv)
With today's progress in NLP, it is no longer possible to differentiate human mails from those of bots.
Thanking you
Sagar Acharya
https://humaaraartha.in
