brandonweiss
commented
5 years ago Yeah, I thought about this at the time, let me see if I can remember my reasoning for not doing it…
The first question is, is this actually solving a problem? Right now someone needs to edit their DNS to point to S3/CloudFront after deploying for the first time. If I create the DNS entry for them in Route53… they still have to go into their registrar and point to Route53’s nameservers, so that doesn’t feel like much of a win.
There’s also a chance they already have DNS, in which case I wouldn’t want to force them to use Route53. I’d have to have to make Discharge more complicated and add steps for them to control whether or not it created DNS records for them and where.
If they did want to use Route53 for DNS, that creates another set of problems, which is what happens when they realize they need to add a DNS record for some reason? Let’s say to verify some Google service or something. Then they’d need to sign in to AWS and figure out how to use Route53. But the whole reason Discharge exists is to abstract away as much of AWS’s complexity as possible so you don’t have to get mired in it.
I think there might be a few other reasons I‘m forgetting now, but in sum, while I conceptually love the idea of automating as much as possible, I think a feature like this would add more complexity and potentially cause more problems than it’s worth, and it also might not be something most people want.
Why can't discharge to this itself? It has the desired domain name. All it needs to do is add a Route 53 record.