A/AAAA records for custom hostnames
Hello, when setting up a custom hostname for a client, the documentation instructs to ask the client to set up a CNAME for that custom hostname pointing to our Cloudflare hostname.
How can we use A/AAAA records instead of a CNAME?
Im asking because due to changes in ITP (https://bugs.webkit.org/show_bug.cgi?id=215201) CNAMEs are quite vulnerable and even HttpOnly cookies set through CNAMEs will be limited to 7 days
1 Reply
How can we use A/AAAA records instead of a CNAME?I believe you can only get A/AAAA with the Apex Proxying Enterprise Addon https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/advanced-settings/apex-proxying/
This limitation does not apply with apex proxying. Cloudflare assigns a set of IP prefixes - cost associated, reach out to your account team - to your account (or uses your own if you have BYOIP). This means that customers can create a standard A record to route traffic to your domain, which can support the domain apex.
CNAMEs are quite vulnerableThere's nothing really special about CNAMEs over normal A/AAAA records, DNS Resolvers just keep resolving until they get a A/AAAA record they can connect to.
HttpOnly cookies set through CNAMEs will be limited to 7 daysIt looks like its way more nuanced then that That specific bug you talk about mentions
Third-party CNAME cloaking means a first-party subdomain resolves to a third-party domain which does not match the resolution for the top frame host.They're not saying the normal use case of just connecting to example.com and it points to a CNAME, they're talking about situations where you load example.com, and it sends a request to tracking.example.com which is an analytics service on a custom domain and uses a CNAME to resolve to a third-party domain like tracking-company.com. That's what they're trying to fight https://louder.com.au/2023/07/06/apple-itp-targets-http-cookies-with-7-day-cap/ Additionally it looks like all client-side cookies are capped to 7 days in general with ITP Enabled https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/ The wording is a bit confusing, I think this was talked about before but I can't remember. Specifically though there is a comment in the code of the bug you linked which helps to clarify things:
First-party host | First-party subdomain | Capped expiry 26 ------------------|----------------------------|-------------- 27 No CNAME cloaking | No CNAME cloaking | No 28 No CNAME cloaking | First-party CNAME cloaking | No 29 No CNAME cloaking | Third-party CNAME cloaking | Yes 30 CNAME cloaking | No CNAME cloaking | No 31 CNAME cloaking | Matching CNAME cloaking | No 32 CNAME cloaking | First-party CNAME cloaking | No 33 CNAME cloaking | Third-party CNAME cloaking | Yes This is called from NetworkDataTaskCocoa::updateFirstPartyInfoForTaskAndSession() when there is CNAME cloaking for the first party host. This is done to make it possible to not cap the expiry of cookies if subsequent subresource loads have CNAME cloaking that matches the first-party host's CNAME cloaking. This happens when whole websites are hosted on edge networks. This function is also used by the test infrastructure to mock the DNS resolution for a first-party host.If a page loads on a CNAME (example.com -> CNAME -> yoursite.com), that becomes the First-party host. So there's no extra capping there, unless they requested another subdomain like tracking.example.com (which even if it did CNAME to alt.example.com which had A/AAAA records, it would still be restricted, looks like)