search

StackExchange / dnscontrol

Infrastructure as code for DNS!
https://dnscontrol.org/
MIT License
3.18k stars 399 forks source link

Should we support ALIAS records? #50

Closed captncraig closed 7 years ago

captncraig commented 7 years ago

Some providers support an ALIAS or ANAME record type that acts like a CNAME, but converts it dynamically to an A or AAAA record at dns request time.

The primary use case I believe is allowing a CNAME type record at the zone apex where it is not usually allowed.

R53, DME, and DNSimple, and CF support them natively, while others do not at the moment.

Proposal:

  1. Add an ALIAS( name, aliasDomain) record type.

  2. Add some mechanism for a provider to indicate it supports these records (perhaps by implementing interface { SupportsAlias() bool }).

  3. At validation time, check if you use ALIAS records with a non-supporting provider, and error if so.

  4. Potentially add some "override" metadata, to resolve the name at "compile time" and use that A and/or AAAA records instead for non-supporting providers. This would be a one-time lookup, but could still "work" in a way. Perhaps you run dnsconrtol on a cron job to keep it updated it or something. I would want to use something like ALIAS("@", "otherdomain.com", { lookup_on_build: true}) to make sure you are really ok with that behaviour. (name negotiable).

Concerns:

  1. Inconsistent experience if using some supporting providers and some non-supporting. Dual host setups could end up with divergent zones.

  2. Is this feature even needed? I do think CNAME apex records could be valuable, but don't want to do it if nobody will use it.

  3. Is "compile time" lookup a horrible idea in general?

tlimoncelli commented 7 years ago

Compile-time lookups are generally a bad idea. We currently don't have any compile-time DNS queries.

We could restrict it to domains in the dnsconfig.js file and simply resolve it by looking at the data. It would have to be done after any transforms, etc. I don't think there is currently a lookup function. We could do a simple lookup, ignore wildcards, etc.

ANAME("@", "dest.foo.com.", {lookup_if_unsupported: true}),

A benefit of restricting this to destination domains that are in dnsconfig.js is that you know that if the A record changes, DNScontrol will be run. They can't get out of sync.

captncraig commented 7 years ago

I see where you are coming from there. In that case I think there are really 2 categories:

  1. ALL providers you are using support ALIAS/ANAME records, and we can use them appropriately.
  2. They don't. And you use A records instead.

If you control the domain, I don't see a real reason to use ALIAS vs just defining the A records multiple times (or a macro).

The main use case I see for ALIAS is if I want to use a 3rd party service at the zone apex, and they don't have a long-term stable IP address.

I agree that mixing lookups with creating actual records in a provider should not be mixed. So I'd probably vote for all or nothing with provider support for alias within a domain, and we never try to fake it.

captncraig commented 7 years ago

I may go so far as to say that ALIAS is only supported if using a single provider that supports it. Odd interactions could occur if half of your nameservers are resolving or caching differently than the other half.

danielkza commented 7 years ago

If you control the domain, I don't see a real reason to use ALIAS vs just defining the A records multiple times (or a macro).

@captncraig In addition to handling apexes, aliases can have special support for provider-specific resources with automatic updating. In R53 you can point them to a Cloudfront distribution or a load balancer, and they will always be up-to-date even if the underlying resources change.

tlimoncelli commented 7 years ago

@danielkza I'd be interested in understanding how we can better support AWS features like that. SO doesn't use AWS (except R53), so personally I'm pretty ignorant of what the features/requirements would be for us to support AWS better. I'd love to know your thoughts in this area.

tiernano commented 7 years ago

On a related but non AWS r53 note, cloudflare allows cnames in their apex records... Not sure what difference that makes...

captncraig commented 7 years ago

Yes, because cloudflare transparently "flattens" CNAMES. I think in the CF case, we would just convert ALIAS to CNAME

danielkza commented 7 years ago

@tlimoncelli AFAIK the only thing necessary to support R53 aliases is to change some API calls. Instead of passing RecordSets you pass AliasTargets. IIRC they can point to Cloudfront distributions, Load Balancers, S3 buckets and other records in the same zone.

Aliases are preferred over CNAMEs in some cases because they can survive changes to underlying resources (although they are infrequent) and respond to them immediately. CNAMEs are of course more flexible and can point to external resources of any type.

tiernano commented 7 years ago

I tried creating a domain today with route53. It has some alias records pointing at cloudfront... when i try run it with dnscontrol, i am getting:

2 Validation errors:
ERROR: %!s(<nil>)
ERROR: %!s(<nil>)

I am guessing that its not supported? I know Alias records are working on Cloudflare...

captncraig commented 7 years ago

Oh, those errors are useless. I'll look into that. Correct, r53 just needs to explicitly support alias. Should be super easy, I just havn't had time to validate and push it.

tiernano commented 7 years ago

If you need anyone to help test, just shout. I have domains registered in name.com and dnsimple, and DNS providers in route53, cloudlfare and dnsimple. I would like to try make code changes, but I know nothing of go... not even enough to be dangerous!

Get Outlook for iOShttps://aka.ms/o0ukef

From: Craig Peterson notifications@github.com Sent: Tuesday, May 2, 2017 9:11:48 PM To: StackExchange/dnscontrol Cc: Tiernan OToole; Comment Subject: Re: [StackExchange/dnscontrol] Should we support ALIAS records? (#50)

Oh, those errors are useless. I'll look into that. Correct, r53 just needs to explicitly support alias. Should be super easy, I just havn't had time to validate and push it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/StackExchange/dnscontrol/issues/50#issuecomment-298747229, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAHHMEe6V263svuedEM_FfYem350zRc4ks5r144EgaJpZM4Mhm25.

tlimoncelli commented 7 years ago

This is implemented CloudFlare.

captncraig commented 7 years ago

ALIAS is now a record type you can use. All providers for a domain must opt into it for it to be valid. Each provider can deal with it or transform it as they need to. There still may be providers that support it that have not been updated.

jmickey commented 7 years ago

@tlimoncelli @captncraig Thanks a lot for implementing this despite the fact you guys (seemingly) have no need for this feature internally.

So I am clear: will this now work for Route53? Or will the Route53 provider need to updated?

captncraig commented 7 years ago

Route 53 will not work at present. I am hoping it is as simple as adding a single flag to the provider registration and it will work. I just need to validate that.

jr-RXcode commented 7 years ago

Any updates on Aliases for route 53?

ptrdsh commented 2 months ago

Hi @captncraig et al, we recently tried to migrate our page to amplify (AWS) and are supposed to define an ANAME record. After our dnscontrol tests failed, we found this issue. Is there a workaround / alternative? Thanks in advance!

tlimoncelli commented 2 months ago

(FYI: captncraig hasn't been with the project for a few years.)

AWS has their own alias mechanism: R53_ALIAS(). Docs are here: https://docs.dnscontrol.org/language-reference/domain-modifiers/service-provider-specific/amazon-route-53/r53_alias

(I've never used AWS so I'm just going by the docs)

ptrdsh commented 2 months ago

Thank you @tlimoncelli !