kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
michaeln3 has joined #sandstorm
<kentonv> whelp. my local dev server just automatically obtained and deployed a valid TLS certificate using Let's Encrypt on my own domain using Cloudflare DNS
<kentonv> now... I have to build a UI
<JacobWeisz[m]> Yay! \o/
<JacobWeisz[m]> The amount of less config complaints people will have with the ability to do that built into Sandstorm!
<ill_logic> Did you need your dev server to be exposed to the Internet?
<ill_logic> Otherwise I don't know how letsencrypt would work
<kentonv> ill_logic, nope. Let's Encrypt doesn't need to reach the server, it only needs you to set a DNS record to prove you own the domain.
<kentonv> so in my case my server talked to the Cloudflare DNS API to set those records
michaeln3 has quit [Remote host closed the connection]
michaeln3 has joined #sandstorm
michaeln3 has quit [Ping timeout: 240 seconds]
michaeln3 has joined #sandstorm
<ill_logic> Ah. Is the old way still supported? Where the server plays back a secret?
<isd> "old way?"
<isd> there are different acme challenge types, but wildcards require using dns-01
<ill_logic> Well, the way I used, at any rate, or I think I used. Where my server temporarily shows a secret supplied by letsencrypt, and letsencrypt checks it.
<isd> Other mechanisms don't require being able to configure dns, which is an advantage, but no wildcards, and typically the server needs to be publicly accessible
<ill_logic> Okay cool.
michaeln3 has quit [Ping timeout: 258 seconds]
<kentonv> yeah, we have to use DNS because we require wildcards. Annoying because there's no standard API for pushing DNS changes so we have to one-off support a bunch of popular providers... luckily we can use an existing framework that already has a bunch of such plugins
<JacobWeisz[m]> GoDaddy made this cool thing: https://www.domainconnect.org but support for it hasn't been taken up by as many services as I'd like.
<JacobWeisz[m]> They wrote an open source dynamic DNS client for it too, which is why one of my domains can't be transferred to Cloudflare.
* isd adds to reading list
<JacobWeisz[m]> It's basically a standard API to delegate DNS configuration via OAuth. I know I at least nudged someone at Cloudflare about wishing they'd support it.
<isd> Sadly OAuth also requires per-provider logic :(
<JacobWeisz[m]> As of right now I do my DDNS with a domain I don't use for anything else, so it's not a big deal I can't use it on a sub domain of anything I have with Cloudflare. But it does cost me an extra ten bucks a year over Cloudflare's registrar prices.
<isd> It would be really nice to have a standard protocol that actually enabled not writing separate code for every provider. Otherwise what's the point?
<kentonv> Cloudflare doesn't have an oauth flow of any sort yet. That's probably a prerequisite to supporting this.
<JacobWeisz[m]> I am not sure it has the exact same sticking points as OAuth, I know the flow is similar for the user.
<kentonv> once CF has oauth then I bet the entirety of DomainConnect could be implemented as a fairly simple Cloudflare Worker on top of our existing API...
<isd> I mean, it sounds like it is literally built on top of OAuth. It therefore has at least all of the problems of OAuth...
<JacobWeisz[m]> kentonv I am very excited about API scopes and such though. Cloudflare's API has seen some real progress lately.
<JacobWeisz[m]> Though I updated the Cloudflare Wordpress plugin today, which said it supports the new scoped keys, I made a key with the Wordpress template... and it didn't work at all.
<JacobWeisz[m]> So I need to experiment with that more.
<kentonv> yeah I had a problem with the acme-dns-01-cloudflare plugin, the instructions for creating the OAuth token depended on a "bug" that was recently "fixed" so the token did not work...
<JacobWeisz[m]> Ian: I wasn't positive because the site talks about two different flows, only one of which mentions OAuth.
<isd> Yeah, everything I'm reading suggest the same blindness to anything that isn't sass.
<isd> the process for integrating your service with a provider is "contact them"
<isd> SaaS
<isd> That's disappointing.
<JacobWeisz[m]> I mean, if they have an open source desktop app which can update DNS records from arbitrary PCs on dynamic addresses behind NAT...
<isd> I suppose it depends on how flexible it is.
<isd> I should dig into the actual protocol, rather than just reading the advertizing.
<JacobWeisz[m]> I think the DNS providers have to explicitly contact the SaaS services for support. But the DNS side should be accessible from any arbitrary application.
<JacobWeisz[m]> Like it sounds like if a DNS provider wants Office 365 to configure it using DomainConnect they have to contact Microsoft to enable support in Office 365.
<JacobWeisz[m]> But that sounds mostly like a choice on Microsoft's part.
<isd> The docs suggest to me that it's a two-way manual process? not sure.
<isd> Not usable by us as-is, since it only sets A-records.
<isd> I dunno. Maybe this can be turned into something we can use. We may have to actually talk to people though :P
<JacobWeisz[m]> Other templates definitely support other record types. Particular as configuring MX records is a key purpose of it. I saw Google domain verification templates and the like too.
<isd> It does look like this might provide a template for how to do this in a not-saas way, if we can talk dns providers into it: https://github.com/Domain-Connect/DomainConnectDDNS-Windows#secrets
<JacobWeisz[m]> It basically says in the spec I scrolled through that providers can decide whether or not to care who the other end is.
<JacobWeisz[m]> So presumably it's up to the DNS provider if they want to support that "secret".
<isd> Yeah. So it might mean we just have to convince some folks at various providers to support one of these "templates"
<JacobWeisz[m]> I mean, right now the primary limitation is how few DNS providers support DomainConnect itself. :P
<JacobWeisz[m]> But as a "I found out about it, and it instantly 'just worked' for me as a free DDNS solution", it made me a fan. :P
<isd> I guess that's not a lot
<isd> ...but it's more than that library kentonv found had custom plugins for?
<JacobWeisz[m]> It just kinda seems like a lot are "under development"... And have been a long time.
<isd> Really, given that I'm already running my own DNS server, I'd like a way to just get sandstorm to talk to it.
<isd> It probably wouldn't be that hard to turn the sandcats protocol into something reusable.
<JacobWeisz[m]> I also like the 'standard providers support' model better than the 'library with individual hacks for each' model, from a design standpoint.
<isd> agree.
<isd> Honestly a small bit of server software that controls powerdns and provides just enough API to do dynamic DNS and get let's encrypt certs via DNS-01 would probably be useful to a lot of people
<isd> Anyway, I'm off to bed. Hopefully I'll talk to some of you tomorrow afternoon (office hours)
_whitelogger has joined #sandstorm
rjBadger has quit [*.net *.split]
rjBadger has joined #sandstorm
michaeln3 has joined #sandstorm
michaeln3 has quit [Remote host closed the connection]
michaeln3 has joined #sandstorm
<isd> Reminder: office hours in 15
<kentonv> I'll be about 15 minutes late
michaeln3 has quit [Remote host closed the connection]