Deterministic ordering for CF_SINGLE_REDIRECT records

[tlimoncelli]

Is your feature request related to a problem? Please describe.

We would like to control the order of CF_SINGLE_REDIRECT records.

For example, we might want to have redirects that match on:

          foo.com/bar?query=bang     redirects to X
          foo.com/*                  redirects to Y
          foo.com/                   redirects to Z

If we can't control the order, there's a chance everything gets redirected to "Z" because foo.com/

Describe the solution you'd like

The easy way would be for DNSControl to just abide by the order they appear in dnsconfig.js. The code might already do this.

@blackshadev: Is there any reason this might not be the case? Could you verify?

Describe alternatives you've considered

The hard way would be to add metadata for each record that lists a priority, and have dnssort/dnsgraph sort by that priority.

It would look something like this:

      CF_SINGLE_REDIRECT("foo", "bar", { priority: 1 } ),
      CF_SINGLE_REDIRECT("foo", "bar", { priority: 2 } ),

Additional context

CF_SINGLE_REDIRECT is described here: https://docs.dnscontrol.org/language-reference/domain-modifiers/service-provider-specific/cloudflare-dns/cf_single_redirect

[blackshadev]

There shouldn't be a reason for this to conflict with the recording, and I think you can add it quite easily. As long as you can group all of these "prioritized" records together.

The reordering algorithm adds changes to the record set based on the resolved dependencies of the records. Currently the only record types with dependencies are "NS", "SRV", "CNAME", "MX", "ALIAS", "AZURE_ALIAS", "R53_ALIAS" (see record.go:432). I am unsure if you can reuse the original ordering, because depending on the diff2 type you do not know the original ordering anymore. That was one of the reasons for me to start the reordering algorithm.

[tlimoncelli]

Thanks for explaining that!

I now I've had more time to think about this, the Cloudflare "rule id" is unrelated to the order that the changes are done during "push". This becomes easier to implement than I had previously thought.