Comments (10)
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 CNAME
s aren't supported at the apex.
/cc @joewilliams @MikeMcQuaid
from octodns-route53.
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
from octodns-route53.
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.
from octodns-route53.
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.
from octodns-route53.
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?
- Fail with an exception when the record can't be created (this feels better than silently ignoring)
- Fallback to a
CNAME
when the creation of anALIAS
record fails, raise an exception when that is also not possible. - Use a
CNAME
to theALIAS
target, raise an exception when that is also not possible. - ...?
from octodns-route53.
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!
from octodns-route53.
@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.
from octodns-route53.
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.
from octodns-route53.
Prototyping/testing of the concepts here in octodns/octodns#889 & #25
from octodns-route53.
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.
from octodns-route53.
Related Issues (20)
- AwsAcmMangingProcessor can't be referenced HOT 2
- Route53: dynamic record triggers update even with no changes to the record HOT 5
- Route53 pool with health check that doesn't match the cname HOT 1
- Public and Private DNS in Route53 HOT 7
- route53 with healthcheck record sync issue HOT 2
- Ability to set FailureThreshold on healthchecks HOT 2
- Updating to 0.0.5 breaks previously existing ALIAS records HOT 7
- Latency Routing Policy HOT 3
- TCP health check failure HOT 1
- Octodns does one change at a time HOT 13
- Does OctoDNS handle weighted Route53 records? HOT 3
- ALIAS records for Global Accelerator are not supported
- Need to add a space before ";" (semi-colon)? HOT 2
- Regression with `lenient` setting for multi-answer PTR record HOT 5
- ALIAS record dump issue HOT 2
- Is there a way to hide "root NS record supported"? HOT 7
- Feature Request: Add DS record support to octodns-route53 HOT 3
- Add option to turn off trailing dot enforcing HOT 2
- Does Octodns-route53 support sub-domain NS records HOT 3
- Add IRSA support HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from octodns-route53.