On Tue, Sep 05, 2017 at 08:04:24PM +0200, Daniel Margolis wrote:
> I had it in my head that a CNAME could only point to an A or AAAA, but I
> can't find anything like that in the RFC at a quick glance, so perhaps I
> made that up.
You've made that up. CNAMEs alias all the records for a single
node in the DNS tree to corresponding records at some other node
(sometimes recursively). It is quite common, for example, to have
CNAMES for TLSA records:
$ dig +noall +nosplit +ans +nocl +nottl -t tlsa _25._tcp.mx01.domeneshop.no
_25._tcp.mx01.domeneshop.no. CNAME mx._dane.domeneshop.no.
mx._dane.domeneshop.no. TLSA 3 1 1
69D43912A7968E0E7CF60EFD830D9167746AA8C2B2BE7C43CC7E985F0846D485
> But it sounds like you'd still prefer 302s rather than SNI (i.e. rather
> than having the mta-sts.example.com host record point to provider.net and
> have them have an HTTPS cert for that identity).
To be clear, I am by no means a fan of needing to support redirect
chasing in the MTA STS policy retrieval code. That said however,
as a hypothetical user of STS, I truly despise having anything to
do with the key management headaches of third-party SNI. So if
you want to support delegation to the provider, then a customer
who, like me, hates SNI should be able to operate a tiny HTTPS
server that serves a redirect to the provider's policy URL.
> Which isn't unreasonable,
> I think; people may not have a "policy.example.com"-only certificate and/or
> may not want to give one to the provider and/or the provider may not want
> to do SNI for all their customers.
>
> Any other opinions on this? I think it is relatively easy to switch both
> the text and the code to support redirects, so I don't have a strong
> feeling myself.
Your call. However if configure-and-forget (with occasional updates
of one's own redirect server certificate, but no constant coordination
with the provider) delegation is important, then redirect support
is likely needed.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
