Handle R53 'Alias' Records about octodns-route53

[ross]

Thanks for the report and PR. ALIAS records are pretty annoying in that they exist in most providers, but look/function pretty differently. It's something I'd like to tackle, but don't have a specific timeline on due to the amount of research required to come up with a plan that has a chance of being supported across multiple providers.

The changes in octodns/octodns#27 are a good work around, but I'd prefer to hold off on it in favor of the full solution. I'd rather not merge something now that would later confuse people by changing behavior or break things. @michaelmcallister your branch is probably a good option for people using Route53 to avoid this problem in the interim.

/cc https://serverfault.com/questions/613829/why-cant-a-cname-record-be-used-at-the-apex-aka-root-of-a-domain for related background on why CNAMEs aren't supported at the apex.
/cc @joewilliams @MikeMcQuaid

[vanbroup]

Maybe an idea to create a filter option for providers? The default filter for A is none, but the default filter for ALIAS excludes Route53?

If you would want to add the record to Route53 because you understand the limitation you could use:

host:
  ttl: 300
  type: ALIAS
  value: cdn.example.com.
  octodns:
     exclude: none

Or if you prefer to use a CNAME at Route53 only, you could do:

host:
  ttl: 300
  type: ALIAS
  value: cdn.example.com.
host:
  ttl: 300
  type: CNAME
  value: cdn.example.com.
  octodns:
    include: route53

[ross]

Fail with an exception when the record can't be created (this feels better than silently ignoring)

I went back and forth on this early on. In general I decided that when a provider didn't support something that it'd just be ignored. There should be a log message at the warning level, can't remember if that's the case tbh or not, but it's supposed to be 😁

This allows you to support providers with disparate functionality, making things an error wouldn't. An example where this is ~ok: Dyn supports SSHFP, but Route53 doesn't. They're not critical records so if someone wants to do it they should be able to.

It might make sense to make it a configuration option to switch between a warning and error for this case.

Fallback to a CNAME when the creation of an ALIAS record fails, raise an exception when that is also not possible.
Use a CNAME to the ALIAS target, raise an exception when that is also not possible.

Looked at these sorts of options for Route53 ALIAS and didn't feel like either of them were something that octoDNS should try and do for you. When it would and wouldn't work was too complicated to reason about and the caveats would concern me.

I think the best route would be to add a SYMLINK (name TBD) record type that only Route53 supported which should allow you to do the "right" thing in Route53 and you could use CNAME/ALIAS to (manually decide) what to do elsewhere. That said I haven't been particularly motivated to add that support b/c we don't use it since it's a Route53 only concept.

...?

I've personally been pushing Route53 to add support for the style of ALIAS that everyone else has implemented. Well over half of our (ancillary) domains can't live on Route53 b/c it lacks ALIAS.

[ross]

Worked on general ALIAS support in octodns/octodns#47, but unfortunately Route53 is too different at this point to get mapped into the same things as all of the other providers.

Route53's ALIAS requires that the target be in the same zone and (the bigger problem) is per-type. That makes them really difficult to manage automatically as you'd need to look at the target to see what types are available or to manually configure each. I made several attempts at it as part of octodns/octodns#47, but they were getting really complicated and impossible to map to any other provider.

Decided to just got with the "common" ALIAS behavior that all the other providers use for now. For the primary use-case of octoDNS (multiple providers with the same records) R53's version doesn't make sense. Not opposed to adding support for it to the provider, but it'd need to be called something else since no other provider would support it, maybe SYMLINK or something as that's kind of what it is.

[vanbroup]

The ALIAS type implementation of Route53 is indeed quite different from the other providers. Creating an alternative SYMLINK type doesn't solve the problem, does it?

If you list a record in the config you expect it to be created or to fail (especially not a silent fail). With a SYMLINK record you could create two records, one ALIAS that is ignored by Route53 and one SYMLINK that is ignored by all other providers? That does sound like an ugly solution and I don't think it resolved the problem of an unexpected failure.

The best implementation would be to test everything, but I understand and agree that this makes the code much more completed, what are the alternatives?

1. Fail with an exception when the record can't be created (this feels better than silently ignoring)
2. Fallback to a CNAME when the creation of an ALIAS record fails, raise an exception when that is also not possible.
3. Use a CNAME to the ALIAS target, raise an exception when that is also not possible.
4. ...?

[vanbroup]

I think the best route would be to add a SYMLINK (name TBD) record type that only Route53 supported which should allow you to do the "right" thing in Route53 and you could use CNAME/ALIAS to (manually decide) what to do elsewhere.

I don't get how you would decide this manually? If I set a CNAME along with the ALIAS record Route53 would only have the CNAME but all other providers will have both.

I've personally been pushing Route53 to add support for the style of ALIAS that everyone else has implemented. Well over half of our (ancillary) domains can't live on Route53 b/c it lacks ALIAS.

Let me know if there is a place where we can support your push!

[slandry90]

@ross do you have any interest in reviving the idea of handling route53 alias records with a new type such that it would be possible to manage alias records with route53? If so I can open a new issue to discuss specifics if needed.

[ross]

I have some thoughts on allowing providers to dynamically register new record types and that'd be appropriate for the Route53 idea of ALIAS. I actually sat down to sketch it out a bit last week, but didn't get very far. I can probably start to explore it a bit more early next week.

I'll go ahead and reopen this after transferring it to octodns-route53.

[ross]

Prototyping/testing of the concepts here in octodns/octodns#889 & #25

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.