I have a domain which doesn’t have an origin server, it just forwards traffic elsewhere.
I’ve created page rules to do this for root and the www subdomain, but Cloudflare hasn’t automatically created A/AAAA records and it hasn’t given me any instructions on how to do this.
The DNS record page wants an origin target and there’s nothing in the documentation about this.
As you say - we dont auto create DNS records when you create rules. Easiest thing to do is head to the DNS tab in your Cloudflare zone and create dummy records with a target of either 192.0.2.1 or the IPv6 address of 100:. This ensures that traffic resolves to Cloudflare and the redirects can be applied.
As a side note, Page Rules are legacy and going away at some point in the future. I’d recommend looking into Redirect Rules, the new solution for redirects, if deploying a new workload.
Added those records and the forwarders are now working, thanks. I find it a bit messy having to use bogus origin addresses though.
Thanks, I’ll look into swapping for redirect rules. Presumably I’ll be notified before page rules stop working?
Without those records, the WWW (via DNS) doesnt have a clue what ‘redirectme.example.com’ is, as no name server contains an entry saying ‘hey, redirectme.example.com lives at {cloudflare_ip}’. So you need to do this for any hostname you want browsers to connect to.
Of course. There will be a lot of notificaiton on Page Rules deprecation. Its arguably our most used product, based on volume and deployments. Dont worry, it wont disappear overnight.
Of course, I understand that. But it’d be neater if I could create A/AAAA records that just point to Cloudflare. After all, that’s what the end result is when I create a proxied record. The bogus IP addresses aren’t doing anything, they’re just a bit ugly.
A small correction, @smarsh, there should be two colons. E.g. “100::”, for the AAAA record.
The AAAA 100::, together with being Proxied (
) is literally doing that.
The AAAA 100:: isn’t at all bogus, but has actually been standardized since August 2012, as 0100::/64 (0100:: - 0100::ffff:ffff:ffff:ffff) as a dedicated “discard prefix”, an address space dedicated for purposes where you do not need the traffic, such as e.g. when you need to null route network traffic.
The standard was made to make an unified standard, for discarding traffic, instead of having people (or organisations) incorrectly squatting arbitrary address space, such as the three IPv4 /24 subnets or the IPv6 subnet reserved for documentation purposes for that, which includes the 192.0.2.1 address mentioned above.
Therefore, this whole IPv6 space (but most often just used as “AAAA 100::”) would actually be the best, according to the standards, as it will never end up on conflicting with anything in any way, and even better than the documentation prefixes.
After all, for these redirects, or URL forwarders to use your words, … when they happen at the Cloudflare Edge, you’re literally wanting Cloudflare Edge to do something, and otherwise just discard the (potential) traffic received, and therefore, you won’t get that much closer to the purpose for the standardization of that discard prefix.
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.