On Sun, Feb 24, 2019 at 11:29:10PM -0500, Phillip Hallam-Baker wrote:
> So lets take a DNS configuration for my Mathematical Mesh service:
>
> _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"
Also, does _tcp imply HTTP/1.1 in your example?
And if you want HTTP/3, will you add:
| _mmm._udp.example.com SRV host1.example.com 0 10 80 host1.example.com
| _mmm._udp.example.com SRV host2.example.com 0 40 80 host2.example.com
| _mmm._udp.example.com TXT "version=1.0-2.0"
?
Now you're doing quite a few DNS lookups. If you need to convey that
host1 supports only version 1 and host2 only version 2, you might find
yourself with a transport x version cartesian product of DNS lookups to
do. This is bad.
I'd much rather do something like this:
_mmm._discovery.$DOMAIN SRV host1.example.com ...
_mmm._discovery.$DOMAIN SRV host2.example.com ...
; path is /mmm on all of the hosts in the SRV RRset:
_mmm._discovery.$DOMAIN TXT "path=/mmm"
host1.$DOMAIN A 10.0.1.1
host2.$DOMAIN A 10.0.1.2
then GET /mmm/discovery at either host1 or host2, which should be a
static resource with all the configuration information needed for the
mmm application.
Discovery of HTTP/2 support could be done by trying 1.1 and upgrading.
Discovery HTTP/3... idk. Maybe always use HTTP/1 or /2 for discovery
and if you get told that /3 is also supported, then switch to /3 as
desired.
No chance of cartesian products there. If you use a single A RRset for
all the servers, then you get a total of three DNS lookups for three
RRsets:
_mmm._discovery.$DOMAIN SRV mmm.example.com ...
_mmm._discovery.$DOMAIN TXT "path=/mmm"
mmm.$DOMAIN A 10.0.1.1
mmm.$DOMAIN A 10.0.1.2
and the one HTTP GET of /mmm/discovery.
Nice, simple, with constant discovery cost. Well, /mmm/discovery might
get really large, so it's O(N), but still, the number of queries is
constant.
Nico
--
