Should we support ALIAS records?

[captncraig]

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]

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]

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]

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]

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]

@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]

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

[captncraig]

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

[danielkza]

@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]

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]

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]

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 iOS<https://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 GitHub<#50 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAHHMEe6V263svuedEM_FfYem350zRc4ks5r144EgaJpZM4Mhm25>.

[tlimoncelli]

This is implemented CloudFlare.

[captncraig]

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]

@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]

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]

Any updates on Aliases for route 53?