Why ALIAS-type DNS Records Break The Internet

Re:Why ALIAS-type DNS Records Break The Internet by colmmacc on Wednesday January 08, 2014 @10:50AM (#7024187)

Amazon Route 53's ALIAS implementation takes a different approach. We only allow ALIASes to data that we know about authoritatively; so with Route 53 you can ALIAS to an S3 website Bucket (which also lets you do HTTP redirects), a CloudFront distribution (which can serve as a bridge to any arbitrary domain you may care), an ELB or to other records in your zone (which lets you combine routing policies in a compositional way).

The main benefits are;

   No dependency on a third party DNS service, we stand behind our 100% SLA
 
   DNS-based routing policies still work correctly

   No delay in responding to health check failures

but there's another (future, for us) ancillary benefit too;

   Compatibility with offline-signed DNSSEC

The big downside of course is that the record has to be in our system in order to ALIAS to it. For HTTP services, using CloudFront is a pretty good workaround, it can handle dynamic and static sites. If you merely want to redirect from your apex to your www. domain, then S3 with a redirect works great too.

We're also open to enabling ALIASing to other zones hosted in Route 53 on a case by case basis. If you have a multi-tenant service and you're managing (or willing to manage) a zone on Route 53 with something like [customer-or-resource-identifier].yourservicename.com we can enable ALIASing to those names. If you're interested, get in touch via the limit increase process; http://docs.aws.amazon.com/general/latest/gr/aws_service_lim... .

Obvious question: Why don't we enable ALIASing across zones by default? Firstly, zones which can be aliased to have to be replicated and available in all shards of our partitioned datastore (some day we may use some kind of cross-shard query protocol to resolve that, but even then we'd prefer to minimize the traffic) and secondly we want to ensure some stability for ALIAS targets and avoid situations where targets may be discontinued or deleted by their owners leaving our mutual customers stranded.

[ Parent | on HN ]

Re:Why ALIAS-type DNS Records Break The Internet by aleem on Wednesday January 08, 2014 @12:53PM (#7025104)

I host a high profile news site on AWS infrastructure.

> The big downside of course is that the record has to be in our system in order to ALIAS to it.

I need DDoS protection as the site gets attacked from time to time. I went with CloudFlare since ELB doesn't say much if anything about DDoS protection. This means I can't use Route53 and so I cannot work around apex issues and I can't point my apex to ELB either.

The suggested work around I keep coming across is to poll the ELB IP and update it at CloudFlare via an API though I am not sure how good that would work if someone cached the IPs for whatever reason (even though ELB will honor requests up to one hour after the IP change I read somewhere else).

Do you have any suggestions either for DDoS mitigation or finding a work around to my apex woes?

[ Parent | on HN ]

Re:Why ALIAS-type DNS Records Break The Internet by colmmacc on Wednesday January 08, 2014 @01:13PM (#7025301)

We've opened up a little lately, and some of our DDOS mitigation details are now available in my colleague Nate's talk from Re:Invent: www.youtube.com/watch?v=V7vTPlV8P3U .

What I can repeat from that talk is that we've handled DDOS attacks in the same orders of magnitude that are as large as anything else we've ever heard, that we use them ourselves for our own services.

We'd certainly be interested in a conversation about your needs, attacks you've experienced, and how we can meet them. (e-mail: [email protected]).

ELB is a multi-IP service and can dynamically scale from 1 to ~100 IPs. In general, when scaling down, IPs are retired from DNS but aren't removed from an ELB until we've seen traffic drain (which would explain the hour, but it's variable). If you want to know all of the IPs for an ELB, you can query;

   all.[elb-name].[region].elb.amazonaws.com
   all.ipv6.[elb-name].[region].elb.amazonaws.com

and you'll get them all. Though we strongly recommend against CNAMEing to those names directly, it can useful if you need the scrape the IPs systematically for some reason (and it sounds like this might be such a case). I'm not sure what other workarounds may be available via CloudFlare.

[ Parent | on HN ]

Re:Why ALIAS-type DNS Records Break The Internet by igor47 on Wednesday January 08, 2014 @01:12PM (#7025290)

We specifically tried using CloudFront, solely for it's ability to serve as the target in an ALIAS record. However, CloudFront is useless for dynamic sites because it does not support passing the original Host header back to the origin. Any site that serves localized content (including localized redirects) is doomed by this inadequacy.

[ Parent | on HN ]

Re:Why ALIAS-type DNS Records Break The Internet by colmmacc on Wednesday January 08, 2014 @01:15PM (#7025312)

I'll pass this on to the CloudFront team. CloudFront distributions are free, so would it be possible to use a different distribution for each hostname? Or is this more of a wildcard set up?

[ Parent | on HN ]