What does my Stop() still needs to implement? Just closing the listener? I.e. all the graceful stuff is handled in Caddy now?
This code deletion already feels good.
So… taking this discussion forward. Right now my users run ./coredns <something>, after I fix all this, they will run ./caddy -type dns… which is different.
Should I solve this in some build script from my side?
The HTTP server uses Stop() to wait for existing connections to close. I couldn’t abstract that away into Caddy because different server types probably handle the notion of “connections” differently… e.g. HTTP has Keep-Alive.
Solve what exactly?
I guess you could build the caddy binary and name it coredns and change the default server type to DNS. But my plan is to ship your DNS plugin on the Caddy download page (I was working on this today):
Noted. Thanks.
Guess this would fall under “branding”. But shipping this directly from the Caddy page is really nice.
1 Like
- VPN server plugin
- Caddy cluster support that can talk with other Caddy servers for SSL certs for a common domain across the cluster
https://github.com/miekg/caddy-coredns is now fully working, albeit with only 1 middleware 
But it shows how it can be done. I’m pondering the exact route for getting CoreDNS to use this, but that should be relatively easy.
3 Likes
This. Is. AWESOME.
Can’t wait until the DNS server is fully ported. Nice work so far!!
And while I anticipate putting the “DNS” check box on the Caddy download page, of course you can still distribute your own binaries of CoreDNS as you please (according to the license, of course).
1 Like
The real deal: https://github.com/miekg/coredns/pull/220
Fixing up the travis build and tests, but then it should be good to go 
3 Likes
That’s a beautiful thing.
4 Likes
The PR listed above is now fully functional. I ready to test it on my personal server. I build CoreDNS, by running ‘go generate’ (surely this must be a first in go land). All tests pass, except the integration tests (see the Testing CoreDNS topic).
3 Likes
This another, little, update: CoreDNS/Caddy integration is now waiting on PR https://github.com/mholt/caddy/pull/1048 (or something like it) and will then be merged.
2 Likes
That PR has been merged. There was much rejoicing
(some k8s tests still fail, but stuff is in master now)
@matt: you can go ahead and add it to the download page of caddy. I still need to think about versioning and releasing, but for now master should be good enough (I do the same with Go DNS)
2 Likes
Awesome!! Congrats Miek! You’re not alone in thinking about versioning and such… the whole build server that actually powers the download page with those plugins needs an overhaul. We’ll be working on it. 
1 Like
Thanks Matt.
One question related to versioning. I’m now calling caddymain.Run() to run CoreDNS but this function sets the AppVersion and AppName to Caddy. Is there is way to override this?
Haha, well, maybe it’s time to have “the talk” about what Caddy really is. Now that Caddy is pieced together with a lot of different parts, is Caddy the core that all the plugins plug into, or is it the server type? If multiple server types, which one? It is kind of cyborg now.
I have a pretty clear picture of what Caddy core is, and I think it seems right to keep the application called Caddy. However, when you distribute your own binaries with just the DNS server type, I can understand why that is not desirable.
Caddy uses those two values, for example, when it requests TLS certificates from a CA server by setting the User-Agent. This is definitely Caddy doing that work, and I’m not sure where else those values are accessed within core or the TLS plugin, so customizing it may not be necessary…
Ack.
Yes, some more guidelines on what is Caddy and what can be used by server plugin(s) would be nice.
In this particular case (i.e. setting these specific values) moving them to a init function would solve this.
1 Like
Making build.bash a go program makes also sense.
FYI: I forgot to remove an entire directory and on this PR that ‘lines-deleted’ number went up to 8200. The dir that I removed contained another 1000 lines. So in all, we’ve almost deleted 10,000 lines of code 
cloc tells me CoreDNS is now 12,000 lines (mosty middleware 11,0000). So a) we’ve halved the code base b) it takes only a few lines of code to become a server plugin
2 Likes
I agree. Part of the lack of documentation is mostly because I haven’t decided yet. Experience will tell! So we’re both still figuring out these details. 
FTP server type to run a FTP-Server / Reverse Proxy with caddy work be awesome