Viktor Dukhovni:
> On Tue, Feb 14, 2023 at 12:00:45PM -0500, Wietse Venema wrote:
>
> > Tomas Korbar:
> > > Hi guys,
> > > It's great news that this is at least in non production release!
> > > Thanks for all your work on this. Let me know if I can provide further
> > > help.
> >
> > As you can see I overhauled the user interface a bit. Does the user
> > interface cover your use cases well? The documentation describes a
> > number of examples.
>
> A potential MTA-to-MTA use-case is to specifically designate the domains
> for which the SRV lookup must take place (no MX fallback).
>
> * Define an "srvsmtp" transport in master.cf that only uses SRV
> records for "smtp".
>
> * Use the transport table to map some peer domains to that
> transport.
>
> For some unclear reason these could be preferred over MX records for the
> destinations in question.
Having done the work to implement SRV support, I just wanted to
make this possible, if only for testing.
The nxginx docs have examples using SRV to discover services running
in a container, so it might even be useful.
> Fiction aside, the use-cases look reasonable to me. I haven't thought
> through of what downgrade (from e.g. DANE) are introduced by the various
> (optional) fallback controls. If they do introduce potential
> downgrades, a brief note to that effect may be warranted in the docs.
There is no implied downgrade. SRV is really like MX, with weights
and ports added. As long as the port info is propagated properly,
TLSA will just work, and connection caching will maintain separation
of traffic streams that should be distinct.
Wietse
