Subject: [art] What is the best current reference for using SRV with Web services?

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 18 Nov 2016 13:11:19 -0500

I asked this a couple of years back and people returned material on
protocols that have implemented pretty much every single approach possible.
Before I commit to code, I was wondering if anything new was available.

The basic concept here is that we have a Web Service "mmm" and we wish to
make use of the DNS for discovery in a fashion that is as compatible with
existing infrastructure as possible and reasonably performant. Web Services
are not usually like Web Browsing. Latency is not an issue.

This is the structure that I am looking to fill to describe a Service:

    public class ServiceDescription {
        public List<ServiceEntry> Entries = new List<ServiceEntry>();
        public ServiceEntry Default ;

And here are the service entries

    public class ServiceEntry {
        public virtual string Address;
        public virtual int Port= -1;
        public virtual int Priority ;
        public virtual int Weight;

        /// <summary>URI path to connect to (will default to
/.well-known/&lt;Service&gt;</summary>
        public virtual string Path;

        public virtual TransportSecurity TransportSecurity =
                TransportSecurity.UNKNOWN;
        public virtual Transport Transport = Transport.UNKNOWN;

        public virtual string URI ;
        public virtual string UDF ;
        }

The objective is to encode the data in some combination of DNS records.
Right now I am looking to follow the CALDAV approach and use a combination
of SRV and TXT records:

https://tools.ietf.org/html/rfc6764

I have an SRV prefix assigned for mmm. So let us say that my DNS
configuration is

_mmm._tcp.prismproof.org  SRV 1 100 80 host1.prismproof.org
_mmm._tcp.prismproof.org  SRV 1 100 80 host2.prismproof.org
_mmm._tcp.prismproof.org  TXT "policy=http://prismproof.org/policy/s13/ "

 "udf=M23kj-qewjh-qwdwe-iei3d"
host1.prismproof.org A 10.0.0.1
_mmm._tcp.host1.prismproof.org TXT "path=/mesh/"
host2.prismproof.org A 10.0.0.1

Assume the DNS settings are protected using DNSSEC.

I have put a security policy attribute in this example but it could equally
well be a statement 'also supports QUIC'. HTTP really is not ideal for a
Web Service transport. QUIC plus a very minimal presentation layer,
basically the ability to specify the Web Service Endpoint would be better.

So obviously, the first step in resolution is to resolve the SRV record and
the associated TXT records. The TXT record for host1.prismproof.org takes
priority over the service record that sets defaults. So we have two
services with the following attributes:

host1.prismproof.org:80 "policy=.. udf=.. path=/mesh/"
host2.prismproof.org:80 "policy=.. udf=.. "

These correspond to the following Web Service Endpoints:

http://host1.prismproof.org:80/mesh/
http://host2.prismproof.org:80/.well-known/mmm/

The reason for changing the DNS address in the URI to the host name is a
little involved. Basically, not changing the DNS address would render large
amounts of support library code unusable because they are hardwired to the
platform DNS resolver. Providing a supplemental DNS resolver just to do SRV
and TXT lookup is a lot easier than replacing the platform resolver.

The downside to this is that we have in effect performed an internal HTTP
redirect. And this is going to mess things up for TLS unless we require
prismproof.org as the subjectAltName.

Fortunately, most libraries seem to allow apps to override the cert
checking so this is not a problem on my systems. It might be an issue with
some scripting level languages though. Another reason for adopting this
approach is that the security policy might say 'just use this certificate
and don't check validity'. Which would be nonsense for a Web site but might
make a lot of sense for a lightbulb or other IoT device

*Alternative approaches*

The TXT records could be replaced with a new DNS record but this does not
actually help anything unless that is done for the purpose of making
prefixes work with wildcards and DNSSEC.
The DNS URI record has been proposed but it offers no practical advantage
over the TXT approach and is limited to expressing path attributes. For
DNSSEC to provide any value to me, I need to be able to put a security
policy in there. I also want to be able to advertise alternative transports.

At present, the policy is specified as a url and fingerprint. This allows
the policy to be specified as a document on a Web site. It could also be a
DNS record. Obviously, some very simple policies such as 'must use TLS'
could be encoded in the DNS.

The simplest policies could be specified in DANE. But as with the use of
URI records, that doesn't seem to offer any advantage over putting the same
information in the TXT record.