[dns-operations] Apex ALIASES that re NOT flattened CNAMEs

[Peter Thomassen]

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/