--- Begin Message ---
Hi Mark,
On 10/23/24 01:16, Mark E. Jeftovic wrote:
But most providers do it via CNAME flattening, so at the end of the process,
they aren't really CNAMEs, they're A recs.
But this will not work for Substack custom domains - and after going back and
forth with their support, who took it up with some ops, it turns out that
custom domains /at the apex/ on Substack will /only work/ when the query
returns, literally, a CNAME when queried.
Hm, so why is that?
From Substack's web server perspective, the client is making an HTTP request to
their IP address, and it does not matter (in fact, the web server does not
know) whether that IP address is looked up from a CNAME or via an A record
directly. In the latter case, it also does not matter whether that A record is
maintained manually or automatically (via CNAME flattening).
Of course, the flattened CNAME (A target) could be out of date, but I imagine
that an auth synthesizing such flattening would update the synthesized address
record(s) after the TTL expires, so the effects are supposed to be the same as
those of a cached CNAME target (and associated target address) in a resolver.
So it seems to me that if done "correctly" (with refreshing), there's no reason
why flattening shouldn't work. Can you provide some detail why that should be different?
(Note that their support might have said "you must do apex CNAME" so they don't
have to address out-of-date flattened addresses; I don't think that their statement
actually is accurate.)
Apart from wanting to understand this better, Paul is of course right that
SVCB/HTTPS records are the way to go, and in fact surprisingly widely supported
already (https://www.netmeister.org/blog/https-rrs.html).
Cheers,
Peter
--
https://desec.io/
--- End Message ---
_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
